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.
- 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:
- Example 2:
- Example 1:
- 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.
- 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.
- 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:
- Horizontal scrollbars in 1024 resolution. Need better resizing/width design.
- Lots of CSS in header (and inline); much better to use external file.
- Why display the date? Just adds to cluttered screen.
- 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.
11 replies on “Critique – New Section 508 Web Site”
I thought the recommendation for ALT tags descriptions was not to use the words image, picture or graphic of… as the screen reader would do that automatically and you end up with “image of a picture of…@
It appears the site is not fully accessible but I’m sure this is always a work in progress. In fact, it’s probably years beyond some federal sites out there. New technology, great resources, greater navigation than the old site, better labels. Hey, there’s alot to be thankful for. I appreciate the resource. Some folks find fault in everything feds do, and although there is room for improvement, the majority of information on the site is accessible. BTW, your blog’s visual verification is NOT visable!
When the site fails to underline hyperlinks, what hope do we have? OK – maybe it’s technically compliant with WCAG 2 but not by using the preferred technique.
As this is a government website the coding and design was probably contracted to the lowest bidder and developed to meet ‘government standards.’
Or it was created by a government agency which produced equivalent results.
How could you expect it to be anything but what it is?
I have good friends that work for the Access Board and quite likely built this site, so it’s with some trepidation that I share your disappointment in its current inaccessibility. This is a great example of a bit of accessibility knowledge poorly implemented. I doubt it was tested or even viewed outside a few insiders before launch.
I will point out, however, that with perhaps the exception of the form labels, the site is Section 508 compliant. Even the form elements could be argued to be compliant because the labels have a title attribute (they should be on the form elements instead).
This site highlights perfectly how Section 508 compliance != accessible.
On the other hand, blogger uses captcha, and the verification image didn’t show up and I don’t have sound on my pc here, so…lucky me that it showed up the second time. I don’t suppose that works so well in a text browser either.
One quick clarification on my previous comment. It is the General Services Administration that oversees the section508.gov web site, not the Access Board.
The fact that GSA “has been charged with the task of educating Federal employees and building the infrastructure necessary to support Section 508 implementation” makes this site’s accessibility issues all-the-more egregious.
Brian: The alt text examples are showing the current code, not the solution. Sorry for not being clear.
Anonymous: There is some good info, yes. But honestly, I don’t think the feds are doing nearly enough, and what they are doing is obviously very poor quality. Besides the sad state of Section 508 right now, the feds need require some sort of web accessibility nationwide, not limited to just federal funded sites. ADA? (PS: Next time be brave and leave your name.)
Ken: A few people Twittered the same thing–probably a contractor who did the work. But that is no excuse. Actually, it’s worse if they used a contractor and picked someone with obviously a lack of accessibility knowledge.
Jared: Good point. Section 508 compliance does not equal web accessibility. On the contrary, Section 508 is very outdated and barely relevant now. Rumor is it will soon be revised to align with W3C WCAG2 level AA, which is more reason why the new Section 508 site should pay more attention to the modern way of coding and designing an accessible and standards-compliant web site. But since it’s a new site, that should have been done anyway. Also, I disagree; it’s not Section 508 compliant. For example, in addition to form labels as you point out, what about the no-scripting scenario? In the blog I point out that this totally messes up the main menu and the slider feature, the two most important part of the page!
Anonymous and Bill: This site is hosted by Blogger, a Google company. They control the commenting mechanism including the CAPTCHA. Major apologies for Google’s terrible accessibility practices. I’ll look into migrating the site to a better service.
People in glass houses should be careful when throwing stones. The WebAxe site is neither standards-compliant nor accessibility compliant.
Anonymous: Next time be brave enough to use your name and to cite issues to back up your statements. PS: ARIA doesn’t validate with some tools, and the warnings about the unencoded ampersand in URLs doesn’t affect accessibility whatsoever.
Thanks for the effort of critiquing this web site – discussion is a great way for raising awareness and ultimately improvement.
I somewhat disagree with Jared and you in that compliancy != accessibility -> a compliant site assures that e.g. screen readers can interpret and therefore access elements on the page vs. making sense – so being compliant is important and the first step for assuring access to the content. The second step is making sense of it, it’s like a light switch that is low enough to be reached by a person in a wheel chair (and therefore accessible), but the connection to the light bulb isn’t working (as expected) – that is a usability issue.
In the case of section508.gov the page itself is the issue, I don’t see the usefulness (others than a warehouse of junks of content) and therefore a steep decrease in usability. How will a sighted user find anything in this mess (not even the breadcrumbs work as expected, link sections all over the place) let alone a user with disability (vision, motor skills).
In summary: The UX of the accessible site != UX of regular site
In the same way that one has to validate the usability of a site, one has to validate the usability of the compliant site – Has anybody tested section508.gov with participants using a screen reader? b/w monitor, 4x zoom level,
Example: Syntactical (h1, h2, …) hierarchy vs. visual (font-sizes, backgrounds) hierarchy and cues; correct implementation of fall-backs (all menus become regular lists if scripts are disabled), …
PS.: I found an H1 tag (“What’s new on the Site…” to the right) – totally wrong usage 😉