Web Accessibility. Keyboard navigation behavior with [TAB]

[nfxpnk]

Hello, community!

Here is a list of randomly selected websites which follow (or not) best practices.

Most visited e-commerce websites top list:

1. Amazon
2. eBay
3. Target
4. Etsy
5. Best Buy
6. Home Depot

Additional

1. Apple
2. Nike
3. Zappos

I checked how keyboard navigation works on each site from the list above.

With [TAB] key I can choose every item of top navigation menu.

And only here https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ we can't do the same.
It is only possible to choose first item with [TAB]. And then we need to press arrow keys to continue navigation.

Question is: Most of the developers (Amazon/eBay) have done it wrong? Or navigation on top level menu can be done with [TAB] as well? With no issues to Accessibility?

Thank you.

[JAWS-test]

It depends on what roles the elements have in the navigation:

• Links - TAB navigation (see https://www.w3.org/WAI/tutorials/menus/)
• Menu - arrow navigation

Question is: Most of the developers (Amazon/eBay) have done it wrong?

If they use role=menuitem/menubar/menu, they did it wrong. If they are links, they have done it right

[JAWS-test]

Menu for navigation is not without controversy: #353

[nfxpnk]

Hello @JAWS-test
If I will add small change to https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ implementation on my website.

Pressing TAB, Shift+TAB will go through all items of top navigation menu.
Pressing TAB will do the same as Right arrow key
Pressing TAB+Shift will do the same as Left arrow key

Would it be a mistake? Is it allowed for that specification / recommendation?

Behavior will be the same as on https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/

Another question:
Is it important to follow the second item of Accessibility Features? https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/

2. To help communicate that the arrow keys are available for directional navigation within the menubar and its submenus, a border is added to the menubar container when focus is within the menubar.

Thank you

[mcking65]

@nfxpnk asks:

Hello @JAWS-test If I will add small change to https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ implementation on my website.

Pressing TAB, Shift+TAB will go through all items of top navigation menu. Pressing TAB will do the same as Right arrow key Pressing TAB+Shift will do the same as Left arrow key

Would it be a mistake? Is it allowed for that specification / recommendation?

Yes, it would be a mistake. Please see explanation in my comment on 2607.

@nfxpnk asks:

Another question: Is it important to follow the second item of Accessibility Features? https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/

2. To help communicate that the arrow keys are available for directional navigation within the menubar and its submenus, a border is added to the menubar container when focus is within the menubar.

This is a recommendation for helping sighted keyboard users understand when they can use arrow keys to navigate among items that are grouped together in a single tab stop. The outer border is intended to signal the grouping. It is not the only way to visually provide that kind of information. While providing such support to sighted keyboard users is not yet a common practice, the APG Task Force views the lack of such support as problematic.

[mcking65]

@nfxpnk if your question is not sufficiently answered, please feel free to re-open.

[JAWS-test]

@nfxpnk

Would it be a mistake? Is it allowed for that specification / recommendation?

It would be a violation of the ARIA APG recommendations. However, it is important to understand that the ARIA APG are only recommendations - it is not mandatory to follow them.

There are normative requirements that are in the ARIA specification and WCAG, for example. Unfortunately, in both specifications there are hardly any requirements regarding the concrete keyboard operation. A menu with the ARIA roles for menus that can be navigated with TAB and arrow keys would not be a violation of the ARIA specification and the WCAG. In this respect, you are welcome to do it that way, but it would not make sense and would confuse blind people.

[mcking65]

@JAWS-test wrote:

It would be a violation of the ARIA APG recommendations. However, it is important to understand that the ARIA APG are only recommendations - it is not mandatory to follow them.

There are normative requirements that are in the ARIA specification and WCAG, for example. Unfortunately, in both specifications there are hardly any requirements regarding the concrete keyboard operation. A menu with the ARIA roles for menus that can be navigated with TAB and arrow keys would not be a violation of the ARIA specification and the WCAG. In this respect, you are welcome to do it that way, but it would not make sense and would confuse blind people.

While the ARIA specification does not absolutely forbid tabbing inside a menu, that does not mean authors are welcome to build a menu that way. The ARIA spec contains a normative requirement stating that authors SHOULD provide arrow key navigation instead of tab navigation inside menus. That is just one step down from "authors MUST".

The menu role includes the following normative requirement:

To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.

[JAWS-test]

@mcking65

Thanks for the addition. Yes, fortunately it is a bit more clearly stated in the ARIA specification. But unfortunately in WCAG, which are accessibility guidelines for many countries in the world, there are few concrete requirements for keyboard operation, so according to WCAG a menu with TAB operation inside would not be a violation.

See w3c/wcag#872