navigation menu (menu role and menuitem) (duplicate of #89)

[DavidMacDonald]

The examples provided recommend role="menu" or "menubar", and role="menuitem" which will override the traditional link role. This is a lot of extra code, and a big departure from what users will expect...

Is this really the direction we want to go? Why not a simple <nav> wrapped around a bunch of links? I'm afraid it won't be taken seriously requiring "menu" and "menuitem?"

See issue #299 for more discussion.

[mcking65]

@DavidMacDonald,

How site navigation is implemented is a design decision.

1. If the desire is for it to work in a way that is consistent with the ARIA menu pattern, then the ARIA menu pattern should be used.
2. If designers want it to work like a simple set of links where each link is in the tab sequence, then a nav containing ul is adequate.
3. If they want a persistent set of links but all in a single tab stop with arrow nav, then a grid with one link per cell is best.
4. If they want a simple list of links that only appears when a certain action is taken, then a disclosure may be appropriate. But, another option could be a dialog containing a list of links or even a grid.
5. Etc.: Thanks to the descriptive power of ARIA, we a practically infinite number of fully accessible options.

Every possible approach to site nav may be perceived by some segment of users to have some advantages or disadvantages, some of which may be related to specific modalities of interaction, whether that be touch, mouse, keyboard, or screen reader with either keyboard or touch or both.

Is this issue asking for a section in the Authoring Practices that provides a more comprehensive treatment of this subject?

BTW, when it comes to screen reader users in particular, the primary, almost exclusive, user expectation that the Authoring Practices attempts to address is, "The page behaves in a way that is consistent with the information provided about the page by my screen reader."
That is, if the user heres links, the user gets link interactions.
if the user hears menu interaction cues, the user gets menu interactions.
Our goal is to help authors use ARIA that is always truthful in its description of the page.

[LaurenceRLewis]

@mcking65 This is a very useful summation of site navigation, purpose and usage. Thank you.

[DavidMacDonald]

Is this issue asking for a section in the Authoring Practices that provides a more comprehensive treatment of this subject?

Yes, that would be helpful. Navigation menus are super critical to the web, and there is a discrepancy between current predominant practices and the proposed direction of tab into and arrow through strategy, with aria roles. If we are to change the culture we'll need to explain well.

Also, of prime importance is responsive menus, and consideration of these recommendations in light of how they will morph to Mobile.

The next version of WCAG may formalize responsive designs (and menus) as part of the accessible landscape, for low vision users who use browser zoom. This means that almost all accessible menus going forward will be responsive.

[mcking65]

@DavidMacDonald, then I think this is issue is a duplicate of #89. I edited the title of #89 to make its scope and purpose more clear.

I am closing as a duplicate. Feel free to comment further here and re-open if you disagree.

BTW, The point of telling people about how to use the menu pattern for navigation is not to get people to change all their site navigation systems to be ARIA menus. We are not trying to force people into a specific design; we are teaching them which types of designs need ARIA and how to implement that ARIA.

Designers can decide how a site's keyboard interface for site navigation works; it is not forced by accessibility standards. You can meet WCAG with a design that puts every link in the tab sequence or a design that enables arrow key navigation.

Which designs are good is the subjective aspect. That is the part everyone loves to debate.

What is not debatable is:

1. If the implementation uses the ARIA menu, menubar, and menuitem roles, the implementation is defective if the appropriate arrow key support is not present.
2. If arrow key support is present, there should be appropriate ARIA markup in place to describe it. This could be using a menu pattern, a toolbar pattern, a listbox pattern, a tree pattern, or a grid pattern. It is important to note that the only two types of containers that both communicate an arrow key interface and enable links to retain link semantics are toolbar and grid. The other patterns recast links a menuitems, option items, or treeitems.