WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: SC 2.1.2: Leave, but to where?

for

From: Birkir R. Gunnarsson
Date: Nov 29, 2020 12:34PM

So it sounds like what you are experiencing has to do with the
application/form vs. browse modes in screen readers, common with menu
elements.
When you use the menu roles correctly, a screen reader will
automatically switch into application/forms mode when focus moves
inside an elemetn with role="menu", this is to hand control of the
arrow keys over to the browser, trusting that the author has
implemented a mechanism to navigate between items in the menu with
arrow keys.
The only way to shake the screen reader back out of this mode is to
get outside the menu, but the only two ways to do that are to press
the tab key and move focus to the first focusable element outside the
menu or use the screen reader built-in command keys to switch to
browse mode (in Jaws it is Jaws key + ;).
If you use the tab key you have to then use arrow up in browse mode to
check if there was content between the menu and the focusable element.
Forcing a screen reader into browse mode while inside a menu does not
always work.
This isn't a violation of 2.1.2, this is a problem in how screen
reader vendors handle managing arrow keys, but it is a usability issue
that can have significant impact on screen reader users.

This is why, for all navigation menus, I recommend a variant of the
accordion control
* A button with aria-expanded to display/hide the menu (menu can also
be expanded automatically when you tab out of it)
* A <nav> element that contains the navigational items, the <nav>
element has aria-labelledby refering back to a unique id on the menu
button. This way the menu is in a navigation item with an accessible
name matching its trigger button.
* Use a <ul> element with each navigation item in a <li> element.
This is a bit verbose sometimes, but it is predicable, works on mobile
devices, and does not trigger menu navigation issues that most novice
screen reader users don't understand and don't know how to manage.


On 11/29/20, <EMAIL REMOVED>
< <EMAIL REMOVED> > wrote:
> A project wants to include a navigational menubar. Searching for best
> practices I found a WAI example:
>
>
> <https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar
> -1.html#ex_label>
> https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-
> 1.html#ex_label
>
>
>
> The problem: I cannot leave the menu with arrow keys. Pressing arrow-right
> holds me in the carousel of elements in the menubar.
>
> By pressing tab, I can leave the navigational component, but I land
> somewhere on the next focusable element. This way I bypass the content
> between.
>
>
>
> Is this a violation of SC 2.1.2?
>
> How should we solve this issue? Give the first element behind the
> navigation
> in the DOM a tabindex?
>
>
>
> As a SR user I don't like menus for navigations at all, but this is because
> I never found an example causing no problems. I tested the example above
> with jaws 2020 Firefox, chrome, and edge. None supported all available
> aria-attributes. And when the mouse occasionally was in the wrong place,
> arrow-right did not move the focus but started spelling a word letter by
> letter. And I use the mouse, when I work with magnification.
>
>
>
> Thanks for ideas!
>
> Wolfgang
>
> > > > >


--
Work hard. Have fun. Make history.