This is a crosspost of http://dotgov.com. Author: Jim Thatcher.
Jim Thatcher, one of the godfathers of Section 508, reviews Government websites on Web Accessibility.
In this article, Jim verdicts on the website of Washington DC, the seat of President Obama’s Open Government.
My thesis is that there are thousands and thousands of really smart web developers out there who could tackle those challenges – if only they understood the basics of accessibility, the issues that drive the simplest of the accommodations, like alternative text for images, headings navigation and labeling forms. In fact there are subtleties in these basics and I believe that understanding those subtleties helps developers identify with the person with a disability and that in turn will help in tackling the really tough challenges.
It is astonishing and disappointing that government sites consistently fail in these basics. I am talking about the easy stuff – that which is laid out in “Section 508 Web Accessibility Tutorial” and in my chapters of “Web Accessibility: Web Standards and Regulatory Compliance.” Here are examples from the home page of the District of Columbia, http://dc.gov.
Navigating the DC home page
What’s this “navigating a page” idea? Here’s the problem. When a sighted person looks at the DC homepage (screen shot below) they can focus in on their area of interest – at least in principle. A blind visitor does not have the luxury of a two dimensional view of the page, but instead must listen from the top to the bottom – a process that can be long, frustrating and discouraging.
In the late 90’s I advocated what was called a “skip link”, a hidden link at the top of the page that would take a screen reader user to the main content of the page. In those days, most pages had navigation areas at the top and on the left with the “main content” in the center. So the idea was that the skip link would “skip over” all the repetitive navigation links and bring the user to the main information on the page.
The structure of web pages has changed a lot since then but so to have the tools that screen readers offer. The key here is html headings (h1, h2, … h6). If there are headings on the page, and if those headings are marked up as html headings, then screen reader users can just use the H-key to move from section to section, resulting in an immense improvement in finding information on the page.
There is no heading markup on the DC.gov home page. There is no skip link either. Clearly there are visual headings. If those were marked up as html headings it would immensely improve access to the page for blind visitors. Down the center (in them main content!) there are three, “NEWS NOW,” “DC TODAY,” and “OTHER NEWS.” These should be h2 headings. And each of the red headings, like “What can we help you find,” “Featured Sites,” and “DC Webcasts” should be a level three heading. With this markup a blind user can appreciate the content of the page by just pressing the h key 12 times and hopefully find what he or she is looking for.
Alt-text on Images
Every image needs an alt-attribute. We call the value of that alt-attribute “alt-text.” The reason all images need alt-text is that screen readers can’t read an image, but they can read the alt-text instead. Images which are not active (not links or buttons) should have alt-text which conveys the same information as the image and when the image is text then the alt text should be that text. When images are active the alt-text should say what the link does, where it goes.
Sections down the center of the DC home page begin with image headings, like and which we mentioned above. These are images but the first has no alt-text (use alt=”News Now”) and the second has alt=”Other News Header” (which describes the image) it should just be alt=”Other News”.
Those headings are followed by a links that look like this “More News >>” and with JAWS sound like this: “link More News greater greater.” If you want that “>>” as part of your visual design then make it an image with empty alt-text, alt=””. It is important to think about how it sounds!
Speaking of empty alt-text, there are 88 formatting images on the DC home page, typically used for help with the layout- these too should all have empty alt-text, alt=””, because they convey no information what so ever, and they do!
Repetitive Alt-text is Annoying
Down the center of the page are the “Other news” stories. Below is a screen shot of a typical entry.
The entry consists of an image link on the left with alt-text (indicated in the screen shot with a text pop-up) which is identical to the adjacent text on the right. This situation is very common, especially on commercial sites, where you see a product image which is a link and then the product title which is also a link. What it means is that a screen reader user has to listen to that long link twice and that is annoying.
Because the image is a link you cannot use alt=”” on it. In principle there is simple to fix, just combine the image with the text in the same anchor and then you can use alt=“” on the image. It isn’t quite so simple in this case because the image and the adjacent text are in separate table cells so the layout needs reworking to eliminate the table cells.
Though purists whould have you never use tables for layout, I don’t agree with that. Here, however, is an example where the the use of tables complicates the process – and it is an example which is very common
Other alt-text issues
There are several places (sample on the left) where the alt-text duplicates adjacent text. Down the left are four links and each has this problem. Some duplicate the explanatory text, not just the link text. As was the case above, to repair this you will also have to eliminate some table structure.
There are 10 active images that have no alt-text, these are the previous and current icons (, ) under each of the rotating images top center. These images are not of much use to a blind user but image links without alt-text are a burden because screen readers will find src or href information to speak that instead. Use alt=”Previous” and alt=”Next”.
A blind person using a form on the web needs to know the purpose of each from control, what is to be entered in a text field or what is being agreed to with a check box. The process that ensures this is called programmatic labeling of the form controls. There are two basic techniques, using the label element when the visible text is clear or using the title attribute on the form control when it isn’t. Lacking this programmatic labeling screen readers guess pretty well – but different screen readers guess differently, sometimes they guess the wrong thing; often they guess nothing at all. So every form control must be labeled.
Above are two samples. The search form (on the left ) has no text available for a label so title=”search” works. On the other hand the log-in field has good text which should be wrapped in a label element with code like the following:
<label for=”name”>*Username:</label> <input type=”text” id=”name”…>
There are four form controls on DC home page. All are easily accommodated with the title attribute. Although they attempted labeling, the coding is wrong and they have a title on a label element which wraps the control.
How about a grade for basic accessibility for the DC.gov home page? Clearly the page gets an F for in-page navigation.
For forms I give a C for effort, because the at least developers knew something was supposed to be done.
For alt-text, B, because most images do in fact have adequate alt-text, though repetitive.
The overall grade is C-
Which is a shame for the city that is the center of President Obama’s Open Government. Unfortunately this seems to be typical of government sites. We will take a look at another city next month.
Still not convinced about Web Accessibility? Also read Why Web Accessibility is More Than a Legal Obligation.