WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: First letter/number navigation for ARIA Listboxes, Menus, and Tabs

for

From: Bryan Garaventa
Date: Aug 8, 2013 1:53PM


As we recently discussed regarding Accordions, the recommendations at
http://www.w3.org/TR/wai-aria-practices/#aria_ex
Are not always conducive to better accessibility.

E.G

Accordions should not include role=tablist or role=tab, and enforcing one
tab stop will impair accessibility for keyboard users trying to navigate
consecutive sections via tabbing forward through active elements.

The Dialog pattern specifies that role=dialog be used, but doesn't indicate
any of the drawbacks associated with doing this, as documented in the ARIA
Warnings section at
http://whatsock.com/tsg
These ARIA drawbacks need to be taken into account for all references to
role=alertdialog and role=application within the W3C documentation as well.
Here is a simple example of why this is a problem, using NVDA in Firefox,
visit
http://www.oaa-accessibility.org/examplep/alertdialog1/
This is the demo referenced within the W3C section "Alert or Message Dialog
(widget)".
Notice that you can't read the text "Instructions: In this game you guess a
number between 1 an 10 and then press the "Check My Guess" button to check
your responses. An ARIA dialog box will display the results of your guess.
To start over again to press the "Play Again" button."
The reason, because role=application is used to wrap the section.

Also, always setting focus to the first form field in a dialog may cause
screen reader users to accidentally jump passed any instructional text
associated with that functionality, such as a license agreement.

I recommend that people always fully test the functionality of a component,
including it's impact in Assistive Technologies, before making a generalized
design decision.

----- Original Message -----
From: "Gunderson, Jon R" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Thursday, August 08, 2013 11:57 AM
Subject: Re: [WebAIM] First letter/number navigation for ARIA Listboxes,
Menus, and Tabs


> Here is a reference to the design patterns for using ARIA, including
> suggested keyboard shortcuts:
> http://www.w3.org/TR/wai-aria-practices/#aria_ex
>
>
> One of the uses of ARIA is to help users understand how to interact with a
> widget using the keyboard.
>
> If I go to a menu and can't use the arrow keys to navigate menu options,
> it will be confusing to users.
>
>
> Jon
>
>
> On 8/8/13 1:33 PM, "Bryan Garaventa" < <EMAIL REMOVED> > wrote:
>
>>Actually I don't think discoverability would be a problem, since it
>>simply
>>matches current paradigms for these control types.
>>
>>For example, the ARIA Listbox literally sounds like a standard Select
>>element when implemented, which also matches Windows Listbox control
>>feedback on the desktop. When you are interacting with a standard Select
>>element, you can do the same thing, press a letter or number to jump to
>>the
>>item that starts with that character.
>>
>>The same is true for the ARIA Menu, which matches the standard Windows
>>Menu
>>functionality, which you can see by right clicking the web page to open a
>>context menu that literally provides the same type of feedback, as does a
>>properly formed ARIA Menu. This can be seen by opening the File menu from
>>any Windows application toolbar to hear the same, and all of these menus
>>support single letter navigation. The only difference with the ARIA Menu,
>>is
>>that I programmed it to simply move focus instead of automatically
>>activating the item, which I think is more intuitive for browsing.
>>
>>The goal is to make the ARIA Widget behave as closely as possible with
>>the
>>keyboard functionality of it's standard control counterpart. This will
>>prevent confusion in the future, since screen reader users will likely
>>never
>>know that a simulated control is present, if it sounds exactly like a
>>standard control of the same type. This is why matching keyboard
>>functionalities is so important.
>>
>>The Tabs module is one exception where the looping arrow key navigation
>>and
>>first character keypress doesn't exist in Windows, but I see this as more
>>of
>>a beneficial optimization, and one that I wish Windows actually provided
>>as
>>well.
>>
>>----- Original Message -----
>>From: "Alastair Campbell" < <EMAIL REMOVED> >
>>To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>>Sent: Thursday, August 08, 2013 1:29 AM
>>Subject: Re: [WebAIM] First letter/number navigation for ARIA Listboxes,
>>Menus, and Tabs
>>
>>
>>> Hi Bryan,
>>>
>>> Interesting, at first I thought it would over-ride default key
>>> commands for Windows based screen readers, but it is only active once
>>> the user has selected the widget.
>>>
>>> I imagine that would be very useful for often-used things like
>>> Intranets, perhaps less so for public facing sites as discoverability
>>> of that feature isn't easy without instructions?
>>>
>>> -Alastair
>>> >>> >>> >>
>>>>>>>
> > >