WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: SC 2.1.2: Leave, but to where?

for

From: wolfgang.berndorfer@zweiterblick.at
Date: Nov 29, 2020 1:58PM

Thank you Birkir for jaws tutorial. I didn't know the shortcut jaws + ;.

Now: Is the application mode really necessary for a site navigation?
Even when we have nested sub-navigations, we could handle this with buttons
with aria-expanded=true/false as triggers.
Navigating between the elements in the navigation would be more stable in
browse mode.

I understand that it is an usability issue and that we have to blame AT
vendors, Browsers or OS.
But when I understand you right, you also experience problems and oddities
in the application mode. We know, how to handle our SR around those somehow.
But I am sure, you know SR novices and long-time users, who despair every
day.

So my consideration would be somehow: Stay in browse mode! Application mode
brings more elegance but also more glass that can be broken.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
Birkir R. Gunnarsson
Sent: Sunday, November 29, 2020 8:35 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] SC 2.1.2: Leave, but to where?

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/m
> enubar
> -1.html#ex_label>
> https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/me
> nubar-
> 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
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.
http://webaim.org/discussion/archives