Category: gov

Rock bottom for Captcha, White House

Unbelievable and embarrassing. Is this a new low for CAPTCHA and also for the White House? Let me explain.

In order to sign an online petition by the White House to make books globally accessible to the blind, one must register an account. The fail point is that to register, one must complete a Captcha and the audio version is indecipherable. Therefore, blind folks cannot sign a petition advocating equality for the blind!

A very sad irony.

Here’s an example of the audio Captcha required to decipher in order to register to complete the petition. Because it’s impossible to decipher, the website does not meet Section 508 requirements as the White House claims.

Unfortunately there is still no clear solution to the Captcha accessibility and usability issues. For now it seems a combination of other techniques (see links below) is the best way to go.

Press links:

Articles on Captcha alternatives:

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

Critique – New Section 508 Web Site

Below are suggestions for improving the web accessibility of the new United States government Section 508 web site. Well, from analyzing the home page at least. This is basic stuff and I’m very disappointed that the site leaves so much to be desired. The site, which is U.S. government law with rules for web accessibility, should itself be an example of an accessible web site. And with the recent ADA anniversary, this was a great opportunity to move forward in the field of web accessibility. But instead, unfortunately, this was a failed attempt. The U.S. government has a lot of work to do.

Core Issues

  • No headings! Not one. Need headings in markup, period. There are many headings indicated visually, but inappropriately coded such as using strong or div tags.
  • Labels for text inputs are incorrect; there’s a label tag, but no text label! See the search text and email address for news signup.
  • Alternative text for many images need improvement such as removing “Graphic for”. Better yet, do not use a graphic when it’s not needed; text is fine in the following two cases. (Losing the inline style would also be good.)
    • Example 1:
      Graphic for how do I get my 508 questions answered
    • Example 2:
      Graphic for An Official Website of the United States Government
  • No keyboard focus to match mouse hover effect. In addition, a hover & focus could be added in several places to make it more usable, such as the first-level items in the left/main navigation menu.
  • The “AddThis” social media feature requires JavaScript and in either case is not keyboard accessible.
  • No ARIA implemented, not even landmark roles to help with navigation.
  • Links such as “read more >>” have no context; not unique. Also recommend removing the “>” character (better to use CSS for these types of markers/symbols).
  • Text links are not clear. The underlines are removed and dark blue not distinct enough from black text.
  • Poor progressive enhancement. With JavaScript off, the menu options do not fully display and the content of the slider feature is not displayed.
  • Redundant title attributes must go! I’m so tired of seeing this. It’s not useful but on the contrary gets in the way; and it creates code bloat. Example: Link Policy
  • The placeholder email content is confusing. The example is not even a valid email address (missing the top-level domain). The feature can be done with unobtrusive JavaScript and even use the label text, if it existed.

Other Issues

  • Horizontal scrollbars in 1024 resolution. Need better resizing/width design.
  • Lots of CSS in header (and inline); much better to use external file.
  • The attribute language=”JavaScript” not needed in XHTML.
  • Why display the date? Just adds to cluttered screen.
  • Print button not needed. Just adds to cluttered screen. Requires JavaScript.
  • Conditional comment for IE6 CSS should be in head, not body.
  • Text resizing tool not needed; let the browser do this! And clutters screen.
  • Some navigation items use lists while others do not.
  • Image need better optimization/compression. One image alone in the slider feature is over 150k and can easily be compressed to 35k.
  • 67 XHTML validation errors.

The CA.gov Accessibility Page Updated!

Today, just 3 working days after my critique of the CA.gov Accessibility page was published, the CA.gov Accessibility page has been updated! Some of the point discussed were removed and other modified. As for the site itself, the “skip to content” is now visible when tabbed upon. Hooray!

Also, a couple of interesting links were added to the “related sites” at the bottom of the page: Accessible Twitter and California’s Accessibility Standards.

The CA.gov Web Site Accessibility Page

The accessibility page of the State of California web site lists many claims on what makes their web site accessible. Frankly, I’m pretty embarrassed for this state is which I live; nearly all of the bulleted items have major web accessibility mistakes and flaws. Let’s take a look. (All of the assessments were made from referencing only the one accessibility page.)

Clean, Simple and Consistent
This is true. Although it’s consistently inaccessible, as we’ll see.
“Skip To:” Menu
Skip nav is good, but it’s not visually displayed, not even when tabbed upon. This is a major issue for sighted keyboard users. Also, the skip link lands the user before the breadcrumbs; it should go past the breadcrumbs since the object is to pass over all the navigation to the main content.
The Navigation
The main menu requires a mouse to access the second level of items, therefore, it’s not keyboard accessible. What’s worse is that the second level links are not listed on the main page of parent menu item! In other words, there’s no fallback.
Breadcrumb Navigation
Breadcrumbs are a good idea, but first of all, they require JavaScript [on this site’s implementation which is unnecessary; a server-side solution is ideal]. And, there is no semantic markup or a heading denoting what this section is. Also, it’s better practice to markup the breadcrumb links in an unordered list.
Images With Alternative Text
Wow, I didn’t know that alt text is “visible when the mouse is placed over the image”! LOL, that’s just silly IE. (It’s the title attribute which is rendered as a tooltip in most browsers.) Also, say no to alt=”bullet”, yuck!
Relative Font Sizing
This doesn’t work when the text is a graphic! A graphic doesn’t increase when text size increased. See “Popular Pages”. Note that graphic text will increase in size with page zoom, but then may be very pixelated and unreadable.
Style Sheets
What? The second paragraph is instructing the user to install a developer toolbar!
Fluid Sizing Display
Says “viewed best at a minimum of 800 x 600 pixels” but the web page doesn’t fit in that screen resolution! There’s a nasty horizontal scrollbar. So I took a better look and there is no fluid sizing. The CSS is clearly static: width:972px;
Accessible Via Mouse or Keyboard
Uh, no, see reasons above.
Access Keys
Implementing access keys is an outdated practice and get in the way of assistive technology. But the site has implemented only 1 anyway. Just silly. Draw your own conclusions here.
No Sound, No Images, No Problem
Lies I tell you!
Improved Search Engine
This is more of a usability issue.

Although there’s clearly a lot of effect here, it’s almost worse off than no effort at all. Sticking with semantic markup and unobtrusive JavaScript in itself may have been a better start.