WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: mouseover/hover and keyboard accessible expandablemenu?

for

From: Moore,Michael (DARS)
Date: Nov 6, 2009 2:20PM

Jared wrote

"...This is an interesting discussion ..."


I have been fortunate to have been involved as an accessibility and 508 compliance SME (subject matter expert) for several major web applications projects. The most successful outcomes have included early and active participation by disabled staff who would be using the system with assistive technologies (AT). The testers, all volunteers, primarily use JAWS, ZoomText, Dragon Naturally Speaking, keyboard only access or combinations of those tools. Two of the most successful projects thus far rely on accessible drop down menus as part of the navigation. This has meant that at times over 100 links may be presented to a user on a single page, however when asked the AT users in our test groups have preferred this situation to that of multiple pages with fewer choices but more "clicks" to get where you needed to go. Navigation within these systems has been enhanced through the use of short-cut keys and headings but AT users employ many strategies that we frequently do not discuss
within accessibility forums.

A few examples:

Screen readers allow users to sort links lists in the order that the links appear or alphabetically, when sorted alphabetically the user can quickly jump to the set of links beginning with any given letter. Form controls, graphics, graphics and just about any other object that you can imagine can also be sorted similarly. To see what is available use Instert+F3 in JAWS.

JAWS find, a page level search tool, is frequently used to find particular text, links or functionality, even when a user only suspects that the content may exist somewhere on the page.

Dragon users have similar functionality available to identify and jump to particular links or controls on a page.

Finally we have found that an alternative style sheet that left justifies everything can very useful for screen magnifier users, as does including the form label in the title attribute of form fields since label elements are not properly supported by ZT. I am very well aware that this is not the "standard" use of the title attribute.

There is a saying within the disabled community, "Nothing about us without us" this certainly must include web and other forms of EIR (Electronic Information Resources) accessibility. As accessibility experts we cannot and should not get too wrapped up in "standards" and "best practices." Standards are best thought of as more guidelines than a rules (is it Pirate Friday?), thus the last word in the acronym WCAG. Having in Web accessibility since 2003, I have found that "best practices" are very transitory. Heck, I have even posted on this list about the "evils" of keyboard shortcuts, and later found myself endorsing them for particular projects.

So for my perspective on accessible drop down navigation, it's probably time for another accessibility balancing act. Will the users be interacting with the site or application daily, weekly, monthly, or once in a blue moon? How many total links are there, and what does the list look like when I sort it? Is there a way to integrate headings into sections of the fly out menus? There are probably many more questions that should be considered but it's getting late on Friday afternoon and I have probably tested everyone's patience enough with another long winded post.

Jared, this is definitely something that I would like to see some data on in the next survey. Remember the difference we saw between accessibility aware developers and users on the issue of image descriptions.

Mike Moore