Categories
gov review

Suggestions for the new Disability.gov

Last month (March 2012), Disability.gov (@DisabilityGov) relaunched its website; there is an announcement in its newsletter. I discovered this actually by coming across an article posted on Twitter, A Look behind the Scenes – Part I: Making Disability.gov Accessible which discusses considerations made when developing an accessible website.

Naturally, this peaked my curiosity and was compelled to investigate. I found mixed results. Every website, no matter how great the foundation, is a work in progress and could use improvements. Disability.gov is no exception. Here’s my review of the home page.

  • Heading usage needs improvement. Currently no H1 and only two H2 elements, nothing else. Besides the H1, suggest at least adding headings for the featured/slide content and the Connect section at bottom.
  • In very top section, the elements are keyboard accessible which is great, but the visual placement of print button is out of tab order which makes it a little confusing. (On other pages, three added text links in this area compound the problem.)
  • The “Skip to Page Content” link is good, but needs a JavaScript enhancement for browsers that don’t support the functionality. The fix is explained at end of article Back to Basics: Skip to Main Content Links by @TerrillThompson (which I implemented on Easy Chirp). (Skip-to link is the first of three main features listed on the site’s accessibility statement.)
  • I like the implementation of the search form (besides the 1 extra span in the markup). It uses a visually hidden label and an HTML5 placeholder attribute.
  • High contrast controls are good as the input label and submit button are included. But there are a few issues; the first two mesh with usability. (High contrast is the second of three main features listed on the site’s accessibility statement.)
    • It seems that “Full Graphics” is a poor choice of words for the default state. After all, both states have the graphics.
    • There are only two options, so why have a select dropdown? Unless more options are planned, I suggest using two simple radio options or a single checkbox option.
    • While in high contrast mode, text links in the featured/slide content are unreadable (yellow on white).
  • About the feedback modal/overlay window:
    • After opening, the focus is managed and the feature is keyboard accessible, which is super. But the “Save” button is misleading and confusing. It should simply be “Submit”; the user is not saving the selection for later, but actually submitting his or her response.
    • After closing the feedback modal/overlay window, the keyboard focus is lost. When closing, suggest placing focus on control that opened it (the button “Tell us what you think”).
  • In the non-JavaScript use case:
    • The feedback is missing a submit button (and the button “Tell us what you think” should not be present).
    • The featured/slide content doesn’t degrade well. Most of the slide sections are still visually hidden with no controls to view.
  • There is a visual hover/focus indicator for text links, which is great, but should be more prominent (more obvious, too subtle); it’s currently dark blue text which changes to purple text.
  • The links under Information by Topic have a lot of content in the title attribute. If the content is that long, and especially if it’s important to the user (not “supplementary”), then title attributes are not the best solution.
  • Under News and Events, a title attribute is fine for links in new window, but also need visual indication (icon) and/or include “new window” in anchor (and possibly hide off screen).
  • It’s good practice to declare a language in the HTML element with the lang attribute, in this case, lang=”en-us”.
  • The text-resize widget works, but I see two issues (this is the third of three main features listed on the site’s accessibility statement):
    • The text-resize widget doesn’t resize text specifically; it makes the whole design larger, which is basically the same as browsers’ page zoom feature. So why have the widget? Recommend replacing with real text-size functionality since browsers bury this feature or don’t provide it at all anymore.
    • The hover/focus state of the options in the text-resize widget is so subtle (purple instead of black) that it’s very difficult to notice the change.
  • The options in the “Add This” flyout provides visual feedback with the mouse hover, but is missing keyboard focus.

After completing this review, I unfortunately wouldn’t agree with the claim in the footer that the Disability.gov website adheres to WCAG 2 level AA.

The site’s accessibility statement states:

If you experience any technical problems or have issues with accessibility, please contact dgovdeveloper AT devis DOT com with your feedback, and we’ll do our best to respond to your concerns.

I have emailed a link to a link to this blog and hope more improvements can be made soon. -Dennis

Categories
jobs

Web Accessibility Jobs, April 2012

Great opportunities in US, UK, and Australia!

For more, be sure to follow me, accessible_jobs and @a11yjobs on Twitter!

Categories
review

Response to blog Web Accessibility Initiative

This is a response to the blog Web Accessibility Initiative by Nathan Crause. Contrary to the title, the article attempts to disclaim the need for web accessibility, particularly for visual impairments. I submitted a comment but it wasn’t posted. So here it is:

A 3.8% population with visual impairment is not minor at all. If your company has 1 million potential customers, you are ignoring 38,000 chances to make money! And if they’re already customers, be prepared to receive up to 38,000 complaints.

Keep in mind that accessibility also benefits people who have mobile, hearing, and cognitive impairments. They are potential customers, too, and they themselves add up to much more than 3.8% of the U.S. population. The 2009 stats from DisabilityStatistics.org say about 2% of the U.S. population is visually impaired, while total percentage of people who are disabled is around 12%.

Java Applets…seriously?

Content of SVG can be made accessible. And even the accessibility of HTML5 canvas is being worked out.

In addition, Flash can be made accessible. Adobe has made huge improvements here, although not on the Mac. The problem is that developers have the tools to make web sites/apps accessible, but just hardly ever do it.

JavaScript libraries are usually not an issue either. For example, YUI3 and jQuery UI incorporates ARIA which help screen reader users with the interaction.

Still don’t believe me? Check out the W3C’s Developing a Web Accessibility Business Case for Your Organization.

If you current with web technologies, an accessible website doesn’t have to be “crippling”. The bar is now set much higher with modern coding practices available such as progressive enhancement, ARIA, and managing focus. A good example of an accessible web application is Yahoo! email.

The real issue here is ignorance. Ignorance in business, empathy, and proper development technologies and practices. I do agree with you [the author, Nathan] on one point, though; accessibility is a touchy subject.

Categories
csun

CSUN12 Quick Review

Another CSUN conference has come and gone and this year was better than ever. I met many great people for the first time including Joe Dolson, who’s been on the Web Axe podcast a couple times in the past. The conference included much discussion on Google and accessibility, the announcement of WAVE5 beta by WebAIM, and the Tweetup was a bash! Special thanks to Adobe, Deque, and Accessible Media for being such great hosts. On Saturday morning, I attended the SS12 finals in which @Jennison was one of three judges (I judged last year). Be sure to check out the Great Big List by @mactoph which includes many links to presentations, round-ups, podcasts, and more. Also, here’s my Flickr CSUN12 photo album. -Dennis

Joe, Jennison, Dennis, and John sitting at table for lunch.
Photo: Joe, Jennison, Dennis, and John at lunch. Credit: Angela Hooker.
Categories
design review

Comment on Effective Web Design to Enhance Accessibility

Several days ago, I submitted a comment to the article Effective Web Design to Enhance Accessibility, which was recently going around Twitter. The comment wasn’t published, so here it is:

Proper use of headings is another very important issue.
Comments on points above:

  1. Adequate font size by default is best; 16px ideal, 10 or 12 is unacceptable.
  2. Alternative text is a basic requirement that many folks still miss. Especially important on infographics (and comics!). If too long for alt attribute, just put text on page.
  3. Great point, but “link text” or “link content” may be better use of words. The “title” attribute (a.k.a. tooltip) should only be used for supplemental (and not duplicate) information.
  4. Symbols in addition to color is a good practice. In W3C words, “don’t rely on color alone to convey meaning”.
  5. Be sure to have a label for each form component (and associate correctly). Use Fieldset/Legend for long forms to break in sections.