After my crisis of faith about whether accessibility is really enhanced by standards, I read an interesting report into how blind people really surf, and was inspired to do my own investigations into the best way to code accessible navigation menus.
Here’s my report and mp3s of how Jaws 6/ Win XP reads out the different ways of presenting menus. Each test validates to xhtml 1 transitional, although only one is properly “semantic”.
I checked out three different kinds of navigation bars:
a) a vertical table of links, each in its own cell
b) a single table cell containing an unordered list of links, with a sublist as a child of one of the list items
c) a list as in (b) above but with the list contained in a div rather than a table cell.
When checking in Jaws, I was drawing from the excellent paper “Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers” by Theofanos and Redish, as this paper observed real users.
Specifically, I’ve been interested in reducing the verbosity of the screenreader while emphasising structural information, dealt with in the paper in the section “Screen-reader users scan with their ears”:
Blind users … object to listening to descriptions of elements, such as decorative bullets that add no meaning to the page and that make them wait through three words to get to the real meaning.
Guideline 4. For designers and developers of Web sites: Make the site structure clear and obvious. The more obvious the structure of the site, the easier it will be for screen-reader users (as well as for sighted users) to understand and use the site.
I’m grateful to Lachlan Hunt who suggested ways of making these tests more useful.
Results for presentational tables-based navigation.
Test (1), with each link as a bare anchor tag in its own table cell carries no structural information to pass to Jaws. Visually, is obviously presented as a vertical navigation list – there were decorative bullets (each with blank alt text), and all the text was in the same font colour, different from the colour of the main content.
The way that some links were presented as being children of the top level navigation is by having those placed in cells in the third column of the table rather than the second column as the parent link was.
But this was only presentation; without the underlying semantic markup saying “this is a list”, Jaws couldn’t announce that it as such, and thus couldn’t announce how many items were in the list, or the relationship between those list items.
Jaws reads out each link perfectly – so it is technically accessible – but there’s no indication of the hierarchy of links, which my client certainly feels degrades the accessibility of the site. (Hear it, mp3)
Results for semantic list
Jaws loved the semantic list, even when it was contained ina 1×1 table. I checked out a semantic list contained in a div, too.
I used Jaws’ out-of-the-box settings (cos Theofanos and Redish report “users who work with screen magnifiers customize them extensively, but that users who listen to screen readers do not”) and it got stuck in, announcing “List with x items”, alerting the user when a sublist begins and ends, and helping the user understand the structure of the site. (Listen to Jaws read the list in a single table cell.)
Jaws is more verbose when reading real lists, as it tells you “bullet” for each new list entry; this is suppressed in the non-list tabular version as the image that is presentationally a bullet is given blank alt text, as the WAI guidelines suggest.
Interestingly, as long as the entire list is contained in a single table cell, there was no accessibility difference between using a div or table as a container. (Hear Jaws read the list in a div.)
Personally, I’d want the flexibility of the layout that used a div rather than a table cell (eg, an alternative stylesheet that could allow the user to choose whether the nav appears on the left or the right of the page regardless of where it comes in the source), but that’s not an accessibility issue.
It’s a shame that the <menu> tag is deprecated, as it would be cool to have a way to semantically mark a navigation list from a common-or-garden list (and a cognate element <nl> will be introduced in xhtml 2, but that’s 46 years away in browser support, and no-one will ever use it anyway. Get rid of the img tag? PAH!).
When screenreaders are up to it, you could give a class to your navigation lists and then mark up some aural stylesheets to say that any
div#mainnav ul should be read in an authoratative voice – say, Morgan Freeman or our very own Jeffrey Zeldman, while content should be read out in the style of Kenneth Williams, Kylie Minogue or a Venezuelan harlot.
And who could object to that?
Coming soon Also …
The enhanced accessibility of using the css