When “inaccessible” isn’t

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.