E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: wolfgang.berndorfer@zweiterblick.at
Date: Sun, Nov 29 2020 12:08PM
Subject: SC 2.1.2: Leave, but to where?
No previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Sun, Nov 29 2020 12:34PM
Subject: Re: SC 2.1.2: Leave, but to where?
← Previous message | Next message →

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 ADDRESS REMOVED =
< = EMAIL ADDRESS 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.

From: wolfgang.berndorfer@zweiterblick.at
Date: Sun, Nov 29 2020 1:58PM
Subject: Re: SC 2.1.2: Leave, but to where?
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of
Birkir R. Gunnarsson
Sent: Sunday, November 29, 2020 8:35 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
< = EMAIL ADDRESS 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

From: Patrick H. Lauke
Date: Sun, Nov 29 2020 3:17PM
Subject: Re: SC 2.1.2: Leave, but to where?
← Previous message | Next message →

On 29/11/2020 19:08, = EMAIL ADDRESS REMOVED = wrote:
[...]
> Is this a violation of SC 2.1.2?

Strictly, no, as there *is* a way to leave the component you were in.

As noted, this is likely the difference between being in browser vs
forms mode. That's not something authors have control over directly.

> 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.

And arguably ARIA-style menus should not be used for regular navigation,
but for application-like menus. But that's been a long ongoing
discussion even among WCAG/ARIA folks...

https://github.com/w3c/aria-practices/issues/353

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Sun, Nov 29 2020 4:11PM
Subject: Re: SC 2.1.2: Leave, but to where?
← Previous message | Next message →

I would explain the usability issue with the menu construct, saying
that while technically it passes accessibility it requires a lot of
scripting overhead for developers and causes a lot of confusion for
screen reader users.
Recommend that instead you construct accordion/navigation constructs
(very minor Javascript for developers, easy and intuitive navigation
for screen reader users).


On 11/29/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 29/11/2020 19:08, = EMAIL ADDRESS REMOVED = wrote:
> [...]
>> Is this a violation of SC 2.1.2?
>
> Strictly, no, as there *is* a way to leave the component you were in.
>
> As noted, this is likely the difference between being in browser vs
> forms mode. That's not something authors have control over directly.
>
> > 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.
>
> And arguably ARIA-style menus should not be used for regular navigation,
> but for application-like menus. But that's been a long ongoing
> discussion even among WCAG/ARIA folks...
>
> https://github.com/w3c/aria-practices/issues/353
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: wolfgang.berndorfer@zweiterblick.at
Date: Mon, Nov 30 2020 12:45PM
Subject: Re: SC 2.1.2: Leave, but to where?
← Previous message | Next message →

Thank you Patrick for your interpretation of 2.1.2.

And, I know it's a new subject, but it was very helpful for me too:
A very clarifying discussion for me on github. So, let us hope, the
aria-best-practice-example for navigation menus is not used any more for
navigations. It simply makes a lot of effort for technical realization and
causes problems and confusion to AT users. [Just saw that Birkir has nearly
the same formulation]

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
Patrick H. Lauke
Sent: Sunday, November 29, 2020 11:17 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] SC 2.1.2: Leave, but to where?

On 29/11/2020 19:08, = EMAIL ADDRESS REMOVED = wrote:
[...]
> Is this a violation of SC 2.1.2?

Strictly, no, as there *is* a way to leave the component you were in.

As noted, this is likely the difference between being in browser vs forms
mode. That's not something authors have control over directly.

> 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.

And arguably ARIA-style menus should not be used for regular navigation, but
for application-like menus. But that's been a long ongoing discussion even
among WCAG/ARIA folks...

https://github.com/w3c/aria-practices/issues/353

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
http://webaim.org/discussion/archives

From: Laura Fathauer
Date: Mon, Nov 30 2020 12:59PM
Subject: Re: SC 2.1.2: Leave, but to where?
← Previous message | No next message

There actually is a disclosure based button navigation example:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/disclosure/disclosure-navigation.html

Note that it still supports arrow key navigation, so the coding to support
that would still be similar to the navigation menu example provided in the
prior email.

Laura


On Mon, Nov 30, 2020 at 2:45 PM < = EMAIL ADDRESS REMOVED = > wrote:

> Thank you Patrick for your interpretation of 2.1.2.
>
> And, I know it's a new subject, but it was very helpful for me too:
> A very clarifying discussion for me on github. So, let us hope, the
> aria-best-practice-example for navigation menus is not used any more for
> navigations. It simply makes a lot of effort for technical realization and
> causes problems and confusion to AT users. [Just saw that Birkir has nearly
> the same formulation]
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Patrick H. Lauke
> Sent: Sunday, November 29, 2020 11:17 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] SC 2.1.2: Leave, but to where?
>
> On 29/11/2020 19:08, = EMAIL ADDRESS REMOVED = wrote:
> [...]
> > Is this a violation of SC 2.1.2?
>
> Strictly, no, as there *is* a way to leave the component you were in.
>
> As noted, this is likely the difference between being in browser vs forms
> mode. That's not something authors have control over directly.
>
> > 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.
>
> And arguably ARIA-style menus should not be used for regular navigation,
> but
> for application-like menus. But that's been a long ongoing discussion even
> among WCAG/ARIA folks...
>
> https://github.com/w3c/aria-practices/issues/353
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > at
> http://webaim.org/discussion/archives
> >
> > > > >