WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard navigation using arrows only

for

From: Birkir R. Gunnarsson
Date: Sep 4, 2014 6:50AM

Shawn
Please make sure to post any demos or blogs regarding your experience
that you are allowed to share to this list.
ARIA is still a standard in the making.
We are relying on the markup to be applied correctly, for the browser
to interpret it correctly and map it to its accessibility API, the
various assistive technologies to access and interpret that
information and on the end user to understand what it means and how to
interact with it.
With the myriad of developers, browsers and assistive technologies we
have out there it gets tricky, don't get me started on end users, why
can't we standardize them. ;)

So all of you developers out there, please file your bugs, write your
thoughts and explain how ARIA helps or hinders your problems.
Though we have come a long way we are not nearly there yet.



On 9/4/14, Sean Curtis < <EMAIL REMOVED> > 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
>
>> On 4 Sep 2014, at 6:51 pm, "Bryan Garaventa"
>> < <EMAIL REMOVED> > wrote:
>>
>> A slight correction, it looks like the latest version of JAWS15 has
>> regressed and no longer honors aria-posinset/aria-setsize in IE, so I'll
>> need to file a bug. Also, I just noticed that JAWS no longer indicates
>> selection on multiselect ARIA Listboxes. Two steps forward one step back,
>> it always seems.
>>
>>