WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard navigation using arrows only

for

From: Mallory van Achterberg
Date: Sep 4, 2014 8:47AM

On Thu, Sep 04, 2014 at 09:40:50PM +1000, Sean Curtis wrote:
> After spending the last 9 months building an accessible dropdown menu component, I can say that none of the demos I found worked reliably in a variety of screen reader/browser combinations. In fact many seemed to have been developed to work in only say IE+JAWS, or NVDA+Firefox. Also many seemed to only include a subset of the available options for menus - eg links and radios, but not checkboxes or submenus. None included groups, or headings for them.
>
> We built our menu up by spiking managing focus using aria-activedescendant and also by programmatically setting explicit focus. I was hoping using aria-activedescendant would work, however in our tests (JAWS, NVDA, VoiceOver using Chrome, Firefox, IE, Safari) it turned out that once you start using anything but plain old menuitems (links) the screen reader or browser (I'm not sure which is at fault for each case) support failed.
>
> We defined a series of interactions, opening the dropdown, moving down through items, "activating" each item (using enter or space or special AT shortcuts like VO+Space which fires a click event) and then recording the feedback for each interaction, for each browser/screen reader combination. This was a long, painstakingly manual process. We ended up with 2 markup patterns, one which worked for JAWS and NVDA, the other for VoiceOver. We ended up OS sniffing (yes, I know) to switch between each pattern. It felt nasty at the time, but there is no way around it. When role="checkbox" works on one OS, but needs to be role="menuitemcheckbox" on the other, there's not much of an alternative.
>
> We have nearly finished all our unit testing and documentation for this control. Hopefully I'll have time to blog about everything we learnt so others can benefit from it too. All I know is that the markup pattern ended up about twice as verbose as I was expecting. It is also a great deal more accessible than the other examples we found. It is only accessible in what is call the "good" browser+AT combinations (JAWS/NVDA + Firefox on Windows, and VO + Firefox/Chrome on OSX). Safari and IE failed some crucial interactions, no matter how hard we tried. I'll be creating reduced test cases to show these failures and then be raising a heap of bugs with the relevant browser or AT vendors.
>
> Cheers,
>
> Sean Curtis
>
Man, that sucks.
For "typical" webby dropdown menus, this is what I would hope hardest for:
1. that the suckerfish-style markup could generally be preserved. It's
clear, traditional and well-known to many users.
2. that if we use display: none to hide submenus (which I initially
didn't like now must use to preserve tabbing sanity with large subs),
that some small set of aria-roles/states and easily let the user know
that "ta-da! There is now a submenu available/visible!", and maybe even
when they leave that "the submenu is now gone!" if that's not too
verbose or unhelpful.
3. Javascripting to help interaction where pure CSS fails, which we all
already do.

Your tests are a bit devestating. :(

_mallory