WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard navigation using arrows only

for

From: Wyant, Jay (MNIT)
Date: Sep 4, 2014 11:26AM

This conversation highlights, to me, the need for:
- publicly available, reusable pattern libraries
- fervent bug reporting to AT manufacturers

As much as we all want accessibility to work, when executives look at the price Atlassian paid for 9 months of work to make a dropdown menu (add up development hours, testing hours, debugging hours, and pretty soon you get into real money) many are going to decide it isn't worth it. So we need to make sure that future efforts can build upon Michael's and Sean's work and Bryan's bug reports and all other related work.

Jay

-----Original Message-----
From: Bryan Garaventa [mailto: <EMAIL REMOVED> ]
Sent: Thursday, September 04, 2014 11:35 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] Keyboard navigation using arrows only

Thanks, that info will help a lot, and please do file bugs.

Much of this is the result of how the ARIA widget markup is handled by the browser/AT combination on the OS, so this doesn't surprise me at all. For instance you can run the same code on the iPad using Safari and get different results on the Android with Chrome, or even using IE versus Chrome on Windows using differing screen readers.

I'm glad this testing is being done elsewhere too, so that differences can be shored up in the future.

All the best,
Bryan

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Sean Curtis
Sent: Thursday, September 04, 2014 4:41 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Keyboard navigation using arrows only

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.
>
> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of Bryan
> Garaventa
> Sent: Wednesday, September 03, 2014 11:44 PM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] Keyboard navigation using arrows only
>
> Thanks, I appreciate the feedback.
>
> The point of the demos isn't to be overly complicated or to represent mega-menus, but to convey what ATs like screen readers convey when encountering properly coded ARIA Menu constructs. It's true that aria-owns isn't strictly necessary, but it does explicitly set a parent child relationship that, when more fully supported by browsers, may increase speed by making it easier for browsers to map these associations in the Accessibility Tree.
>
> Regarding the use of aria-posinset and aria-setsize, I agree that this isn't necessary. However, if these aren't included, then positioning data such as "1 of 6", "2 of 6", etc., won't actually be announced using both JAWS and NVDA in IE and Firefox equally, so it is useful at times for this purpose.
>
> One of the primary problems with ARIA Menus that include both horizontal and vertical menus together at the same time, is that the horizontal and vertical aspects of these menus are not conveyed to screen reader users, so it is impossible for a blind screen reader user to know when pressing the Down arrow will navigate to another menu item at the same logical level, or if it will open a submenu instead, or if pressing the Right arrow will do the same, and so on with Up and Left. This is extremely confusing to a person who cannot see what the menus look like.
>
> The same issue can be observed in a standard ARIA Menubar construct, where menuitems are represented from left to right, then pressing the Down arrow will open drop down submenus that are vertical, which then require a different mode of interaction to open submenus by using the Right arrow instead, none of which is conveyed to a blind screen reader user.
>
> Currently the only way to deal with this at present is to either add offscreen text within the menuitem node that states which arrow press will open a submenu, or to include an aria-describedby attribute that does the same.
>
> None of this will work well for mega-menu constructs however, because the nesting is too deep and this makes content very difficult to locate.
>
> I recommend reading what Adobe has done to solve this problem, which is a good solution that is also an open source project that can be implemented by others for the same purpose.
> Blog: http://blogs.adobe.com/accessibility/2013/05/adobe-com.html
> Test:
> http://terrillthompson.com/tests/menus/accessible-mega-menu/test.html
>
>
> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of Michael
> Tangen
> Sent: Wednesday, September 03, 2014 9:36 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Keyboard navigation using arrows only
>
> I did read through that document, along with a variety of others like Terril Thompson's blog and WebAIM. It was modestly helpful, but when it came to gleaning information from it to the specific context of a deeply-nested UL-based menu (one typical of a government entity), it wasn't nearly as helpful. The horizontal and vertical examples were not applicable — we don't typically see a single button clicked to engage a large menu, but rather an opening UL list of several items, each with their own deep list of descendants, up to five or six levels deep. Mega-menus, generally-speaking, do not work well for government agencies or organizations with vast amounts of information that cannot be organized into two or three levels of navigation.
>
> What web developers are looking for is pretty simple (and I know this from my discussions with colleagues and reading other developer blogs frustrated by the lack of cohesive and concise information on the subject). They want to know what the required mark-up is for their nested UL lists — what goes in the first <navigation> and <ul> tags, what goes in those first level of <li> and <a> tags, and what goes in the descendant <ul> <li> and <a> tags.
> They also want to know what are the proper CSS attributes to use in their stylesheet when hiding and displaying the children of a menu item.
> Everything else (within that context of developing accessible navigation) is just noise.
>
> One other thing about the examples (your horizontal and vertical menus), there is a lot of ARIA-related controls and attributes that aren't necessary when a menu is contained within the DOM's structure like aria-owns, aria-posinset, aria-setsize. The example uses hidden divs out of the context of the navigation (hence the extra controls and attributes, I know). But most navigation these days, as someone pointed out earlier is either deep UL trees or the so-called "mega-menu."
>
> If those that develop some of the ARIA documentation for web developers would like another pair of eyes to read for "developer accessibility" (in terms of understanding the documentation....which I do believe is yet another aspect of WCAG 2.0 guidelines), I'd be happy to try and help if I've got some time.
>
>
>
>
>
>> On Wed, Sep 3, 2014 at 6:07 PM, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>>
>> I understand your points, and those documenting the standards are
>> aware of and do understand this problem as well, which isn't helped
>> by the proliferation of outdated, half-correct, and incorrect data
>> distributed across the web regarding ARIA that is publically
>> accessible for all developers.
>>
>> If I may ask, did reading the training guide at
>> http://whatsock.com/training/ help at all? A little bit?
>>
>> This was written to educate standard developers with a background in
>> HTML and JavaScript with little to no knowledge of ARIA, for the
>> purpose of breaking down these concepts into sensible primary topics
>> in order to make learning how ARIA works, and how it can be used
>> properly, easier for those developers unfamiliar with ARIA that make up the majority worldwide.
>>
>> In order to ensure the highest level of accuracy possible, and so as
>> not to add to the prolific amount of bad ARIA advice globally, this
>> was a collaborative effort with W3C PFWG members in order to ensure
>> that this would be true before it was released publically.
>>
>> Since I'm still in the process of fine-tuning the details, please let
>> me know where anything is unclear and I'll be happy to clarify and
>> expound the sections where this occurs.
>>
>> Best wishes,
>> Bryan
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED> [mailto:
>> <EMAIL REMOVED> ] On Behalf Of Michael Tangen
>> Sent: Wednesday, September 03, 2014 2:04 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Keyboard navigation using arrows only
>>
>> +1 Mallory
>>
>> A lot of us web developers are *trying hard* to be compliant, but
>> let's be honest — those documenting ARIA standards for web developers
>> are not doing us any favors, those of us who don't work with system
>> properties and operating system level environments. Most web
>> developers work with HTML and Javascript, or perhaps CSS — we're
>> largely familiar with those sorts of things.
>>
>> I realize this is a sidebar to the actual context of this thread, but
>> those responsible for ARIA documentation really need to address how
>> they communicate standards to those that don't work on the operating
>> system level (or understand it's deep level of complexity), but
>> rather work on things like DOM structure of HTML, Javascript events, and CSS properties.
>> If those documenting ARIA standards could translate those standards
>> for web professionals in terminology and contexts we understand and
>> work with, then I think we'd be a lot further along in building menus
>> that were much more accessible.
>>
>>
>> On Wed, Sep 3, 2014 at 3:16 PM, Mallory van Achterberg <
>> <EMAIL REMOVED> > wrote:
>>
>>>> On Wed, Sep 03, 2014 at 11:29:52AM -0500, Michael Tangen wrote:
>>>> I get your point, but the problem is that all of the documentation
>>>> out there for creating accessible web menus is in itself both
>>>> convoluted and inaccessible to the average web developer/designer.
>>>> You know why
>>> there's a
>>>> lot of "hacks" out there? This would be the reason.
>>>
>>> I have to agree with this, and I feel I'm not too horrible at
>>> reading "spec-ese". Tutorials and blogs with proven, correct
>>> implementations are the only thing saving a lot of us at the moment,
>>> which is a bit of a shame because with for example these menus (if
>>> one chooses the convoluted-in-my-opinion menu roles instead of the
>>> traditional unordered nested list) is that if you use the wrong
>>> roles, you can easily totally break the whole menu.
>>>
>>> And even when you get it right, a "typical" (non-developer) screen
>>> reader user may still have no idea wtf this menu (or whatever
>>> widget) is or how to use it (as evidenced by my co-tester on a
>>> website which used a correct implementation of the menu-role setup
>>> for a mega-menu, where she was quite confused as what the structure
>>> actually meant, especially as NVDA (her normal reader) and JAWS15
>>> (her testing reader) both worked but acted slightly different).
>>> ...and yes, users have a responsibility to learn their software but
>>> being both relatively "new" and often not so straight-forward means
>>> there are a good number of users having trouble figuring out correct
>>> implementations and hearing new things being announced.
>>>
>>> _mallory
>>> >>> >>> list messages to <EMAIL REMOVED>
>> >> >> list messages to <EMAIL REMOVED>
>>
>> >> >> list messages to <EMAIL REMOVED>
> > > list messages to <EMAIL REMOVED>
>
> > > list messages to <EMAIL REMOVED>
>
> > > list messages to <EMAIL REMOVED>