Standards and Accessibility – navigation lists

Do Standards- based menus help accessibility?

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.

and

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.

Conclusion

“Use lists for navigation, or you’ll make the Baby Jesus cry.”

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 ul.mainnav or 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 hover pseudo-class for rollovers on links, compared with JavaScript onmouseover.

14 Responses to “ Standards and Accessibility – navigation lists ”

Comment by Lachlan Hunt

The accessibility of test one would have been greatly improved if you had thought about using the alt attribute appropriately. The most appropriate alternate text for a decorative bullet image is either alt=”*” or simply alt=”".

Comment by Bruce

you’re right, Lachlan; ta for the the reality check!

Test 1 is directly taken from a site I’m retrofitting for a client at the moment. But in order to compare like-for-like, and make the test more useful, I need to tweak it as you suggest.

Comment by Matt

Hey Bruce, now to make the test more interesting you’ll have to try it with IBM Homepage Reader and Speak-up (Linux screenreader) too.

After all, just designing for one browser’s not on. Right? ;)

Comment by Bruce

Yeah yeah yeah Matt.I’m getting Windows Eyes soon and will test on that, but there’s no Linux going on my prisitine box, you know. (Only cos I’m scared of it, though). Are you volunteering to test in Speak-up for me, given you’re a Linux-lovin’ open-source collaborative hippie? ;-)

Comment by neytema

A solution for this problem might be to use an ordered list instead of the unordered one.

I guess screen readers will read out numbers of items (and subitems as well) instead of reading out ‘bullet’.

Comment by The Frog Blogger

Brucie, Baby!

Apple have also muscled their way into the screen reader market with VoiceOver. It’s built into Tiger (Mac OS X.4).

I tested it out and although it’s not enormously intuitive to begin with (*Frog Blogger: “How do I _start_ the darn thing?”*), the fact that it comes ready integrated makes it an interesting addition to the Apple armoury.

You can alter some of the voices to readreallyfastifyouhavetogetthroughadocumentbeforeyetanothermeeting and you can adjust the pitch and volume of others according to the type of content they’re reading – news: authoritative, etc. I didn’t play with any of the settings, though – I tried it “straight out of the box” (Mr Jobs would have been so proud) and IM(very)HO, it’s cool!

Well worth the price of a Mac mini, I reckon… *The Frog Blogger looks around shiftily, hoping no one noticed the brief slip into Mac geek mode*

Comment by Jim

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 no issue at all – you can style tables in the same way as div elements. There’s no reason you need to stick to the default layout of tables.

PS: your b-quote button generates invalid markup – it wrapped the text in blockquote tags – the blockquote element needs block-level children like p elements, not PCDATA.

Comment by Bruce

Thanks Jim. You’re completely accurate, of course, that you can layout tables with CSS, and even use cunning positioning to place table cells in an order other than tabular order (see my absolute positioned tables test, in which I have a 2×2 table and use absolute positoning to move the table cells around into a completely illogical order).

But what’s the point? Why not use an arbitrary container like a div which can be positioned at will, as showcased on things like the css zen garden, rather than (mis-)use a structural element like a table for presentational layout, and then confuse the issue further by positioning the cells in what appears to be the incorrect order?

About the b-quote button: do you mean that text that is blockquoted should be inside another tag (eg a paragraph tag) rather than just inside the blockquote (eg, are you saying that <blockquote>Hello</blockquote> is wrong)?

I’m using xhtml 1 transitional, and I tried a “naked blockquote” test, and it validates just fine.

Comment by Jim

Ah, didn’t realise you were still on Transitional. It’s invalid in Strict documents. It’s still worth fixing, though – less of a headache if you want to move to Strict if you don’t have to fix up a load of comments.

Comment by Bruce

Actually, I’m undecided about whether to switch to strict (I like the discipline, but there’s the old mime-type debate) or whether to go to html 4.01 strict.

Either way, though, there’s a hell of a lot of scripts to write to retrofit old posts.

So inertia and a dash of ignorance will ensure that nothing will happen!