WebAIM Blog

Last month, I gave a lab at Accessing Higher Ground titled "Using JAWS to test for web accessibility."  This lab is the basis of our recent JAWS tutorial. During this lab, I presented a couple of "inaccessible" examples that I think surprised some of the people in the group. Specifically, I showed a data table without headers (<th>), a form without labels (<label>), and a non-linked image that had no alt attribute. All three examples were basically accessible in modern screen readers. Some participants were surprised that the lack of accessibility features (headers, labels, and alt text), things that they had believed to be crucial to accessibility, didn’t seem to actually impact screen reader accessibility.

How many of us have read/written/heard/said that tables without headers, forms without labels, sites without skip to content links (I know this one is debated, but stay with me), and images without alt text are inaccessible to screen reader users? This is not necessarily the case. What would happen when someone starts testing with a screen reader and realizes that some of the things they have thought were essential don’t always make a significant difference? Would they begin to wonder whether there are other accessibility issues that are less significant than they have previously thought?

(In)accessible to whom?

One way to minimize this potential problem is to be a little more accurate when we discuss screen reader accessibility, and to clarify that, just as there are varying levels of accessibility, there are varying levels of "inaccessibility." For example, instead of saying that a table without headers is inaccessible to a screen reader user, you should probably clarify that a table without headers may be inaccessible to a screen reader user, depending on the screen reader version, the complexity of the table, and the expertise of the screen reader user. Similar statements should probably be made about other accessibility principles.

Other advantages to accessible design

It also means that we should probably be a little more thorough when we discuss the benefits of accessible design decisions. While it may not be accurate to say that tables without headers are inaccessible to screen reader users, it is accurate to say that table headers (or form labels, or true headings) will almost always make your content more accessible.

• Accessible content behaves more predictably. There are conventions for how properly-formatted content are read by a screen reader, but the behavior of incorrectly-formatted content is much less certain. Yes, a screen reader will read headings for a simple data table, but what if that table is inside a layout table? Screen readers can associate text with an adjacent form element, but what if the text "label" is adjacent to two form elements? Which one will be assigned the label? The behavior of inaccessible content is much less predictable. It’s better to do it the right way than to worry about how screen readers (and browsers) will compensate for less accessible content.
• The more complex your content, the more important accessible design becomes. When images are the only content within a link, they must have alt text. Complex tables (where data has more than one row header or column header) require headers to be explicitly associated with the data cells. Complex forms and forms that are organized in tables may require true labels to be accessible to screen reader users.
• Accessible content is more robust. Older versions of screen readers may not compensate for improperly formatted elements in the same way. Future screen readers may change the way that improperly formatted elements are supported. Just because something works in JAWS doesn’t mean it will behave the same way in Window-Eyes, other screen readers, or in future assistive technologies.
• "Accessible" doesn’t just mean accessible to screen reader users. This is probably the most important principle of all. Form elements that use <label> are much easier to select with a mouse. Content that uses proper headings is almost certainly more clearly structured, benefitting users with cognitive disabilities and others as well. Tables that use <th> appropriately are easier to style in a way that makes them easier to read and comprehend. Basically every accessible principle benefits more than just one group of users with disabilities.

It won’t make it less accessible

We are often asked if a certain accessibility technique will make content more accessible. Sometimes our reply is that it will certainly not make it any less accessible. So we will continue to encourage true table headers, labels, headings, etc., because it will usually make things better, especially if you remember that there is more to accessibility than screen reader users. It will never make things worse.

I recently finished a tutorial on using JAWS to evaluate web content. This article provides an overview for beginners on how to use screen readers to evaluate the accessibility of web content.  

Many people seem to treat screen reader testing as something that should be left to experts or to blind screen reader users. It is true that screen readers are complex, and that user testing with blind screen reader users is important, but I still believe developers should evaluate their own web content with screen readers.  Here are a few things I think they can learn from doing this.

Accessible design does matter

One of the easiest ways to show someone the potential impact of accessible design is to show them the difference it can make when using a screen reader. The significance of things like a "skip to content" link, a Table of Contents, headings, lists, etc. becomes much more apparent after using a screen reader. Something like a fieldset for grouped checkboxes may seem unnecessary until you try accessing an unfamiliar form in a screen reader.

Screen reader testing is an especially good way of demonstrating the importance of good alt text. A screen reader user may be able to compensate for missing headings or table headers, or poor link text, but can do little, if anything, to compensate for missing or improper alt text.

Your content may not be as accessible as you thought

Tables that seem to be clearly organized visually may be more confusing to a screen reader than you thought (I have seen screen reader users that are unable to follow tables with two rows of headers, even when they are properly formatted). Alt text may seem less helpful than you thought, or it might be too detailed or repetitive.

Screen reader users are not helpless

A screen reader allows navigation to and through content in a number of ways. The same block of text may be found by using Find, navigating by headings, navigating by links, etc. Using these many options, screen reader users can often navigate less-than-ideal sites quite capably, depending on their level of expertise. It is important that developers understand that screen reader users are capable people using capable software to accomplish a task that may seem almost impossible–navigating through a visual and mouse-dependent environment using a auditory and keyboard-controlled "interface".

Feedback welcome

I welcome feedback on the article, especially from sighted users who test with screen readers. Please post your comments below. I would also like to know how interested our readers would be in a similar article on testing with or other common screen readers (e.g. Window-Eyes), screen enlargers (e.g. ZoomText), or other assistive technologies.

Update: Maurício Samy Silva of maujor.com has provided a Portuguese translation of this article.

WCAG 2.0 has been recommended for Last Call. While this will be the second last call for the document and (by my count) the 13th formal draft since January 2001, the document is currently shaping up rather nicely. The guidelines are available at http://www.w3.org/TR/WCAG20/. You are invited to provide comments by February 1, 2008.

Having been involved in the guideline development process with the Section 508 advisory committee, I can attest that creating accessibility guidelines is very difficult. No guideline will ever be perfect - which is why we should use them as tools, not as an absolute manifesto of truth. There will always be political motivations, implementation problems, and people that just can’t agree on what the guidelines should do. Despite the inherent problems with the development process, I am encouraged by the current state of the guidelines.

Most of my previous concerns about the May 2007 draft have been addressed. Here are a few specific comments:

Alternate versions

One of the issues with the May draft was how to provide access to an accessible alternative to inaccessible content. If you create an inaccessible Flash movie and an accessible HTML alternative, how does somebody find the accessible alternative if they are directed (via a link or search engine result, for example) to the inaccessible Flash movie?

There really is not a perfect solution to this problem. WCAG 2.0 now requires:

1. the conforming version can be reached from the non-conforming page via an accessibility supported mechanism, or
2. the non-conforming version can only be reached from the conforming version, or
3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

If one of these is provided, adequate access to the alternative version should be available.

Link context

WCAG 2.0 now requires at Level A:

2.4.4 - The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

While I’m not on WCAG, I am a bit proud of the fact that they accepted my language recommendation.

This means that link labels must make sense by themselves or in their programmatically determined context. So links such as “more…” or “click here” are not typically allowed. But if these links were in a table with headings that provided a programmatic context, then they would be allowed.

But what exactly is ‘programmatically determined link context’? Table headers can clearly provide this context. But what about the word before and after? The surrounding sentence? The sentence previous? The title attribute for the link? All of these COULD be determined programmatically (though some would be rather difficult), but the likelihood of them being available to A.T. in a way that would be useful makes this allowance a bit troublesome. It seems that there needs to be some distinction between contexts that could conceivably be determined and those that functionally and logically would actually work.

Of note, at Level AAA (2.4.9) the link must make sense by itself.

Transcripts

I’m still a bit dismayed by the fact that transcripts for multimedia remain at Level AAA. Captions are required at Level A. So are audio descriptions OR textual descriptions for blind users. Captions for live media are required at Level AA. Yet the working group does not seem to understand that transcripts often provide BETTER accessibility than captions for those who are deaf, deaf-blind, have certain cognitive disabilities, or are non-native speakers, in addition to screen reader users and those using print/braille output, etc. Transcripts are the ONLY mechanism by which media can be made accessible to the deaf-blind and some other disabilities.

I voiced this concern with the previous draft and my concern remains. If the working group truly evaluated success criteria levels based upon their own considerations of whether it is essential for access, possible to implement and reasonably achievable (certainly transcripts are much easier to provide than captions, audio description, and sign language), does not impact look, feel, or functionality (again, captions carry a bigger impact than a link to a transcript), and that no alternative is available for providing access (there is none for the deaf-blind), then transcripts MUST be assigned to at least level AA. I fear that with transcripts assigned a AAA level that many users will not be provided reasonable access to multimedia.

Well, these are the things I’ve noticed so far. I imagine there will be other things I’ll discover as I dig deeper into the document. I will post them later. I invite you to post your comments here and if they are relevant, be sure to send them to the working group.