Clarify Purpose of Menu Navigation

[aardrian]

I am seeing more and more cases of authors who believe that web site navigation menus must be marked up with the ARIA menu role and adhere to the ARIA menu pattern.

In challenging developers to identify where that recommendation comes from, they have pointed to this document. This document does not explicitly state that standard web site navigation should or should not follow the pattern. The overall document implies that many (most?) of these patterns are for custom widgets that should behave as their native analogues.

This confusion is also fed by a linked example of a web site menu at the end of the section:

• Navigation Menubar Example: Demonstrates a menubar that provides site navigation.

If the example is truly worthy and accurate and represents an exceptional departure from the menu pattern as one for applications, then it should be stated as such.

I feel strongly that regular web site navigation should not be treated as an application menu, nor should it follow the pattern outlined here. At least not without a really good reason.

Supporting this, nowhere does the HTML spec say that ARIA is necessary for site navigation, nor do any instructions for using the <nav> element suggest it.

I feel even more strongly, however, that this document needs to add clarity in the pattern description about when it is appropriate to apply this pattern. Here is the opening paragraph with some suggested language in bold:

A For the scope of this pattern, a menu is a widget that offers a list of choices to the user, such as a set of actions or functions , and which is intended by the author to function identically to a native operating system menu (such as an application menu). A menu is usually opened, or made visible, by activating a menu button, choosing an item in a menu that opens a sub menu, or by invoking a command, such as Shift + F10 in Windows, […]

[ZoeBijl]

Thank you Adrian for bringing this up.

Just so we’re all looking at the latest version of the “Navigation menubar example”.

I agree that using role=menu for site navigation is a weird concept. That said, I can also see the need for more complete keyboard support when it comes to site navigation with sub menus.

[aardrian]

That said, I can also see the need for more complete keyboard support when it comes to site navigation with sub menus.

Can you expand on that? As far as I know, using the native <a href> gives complete keyboard support. CSS can hide things and pull them out of the tab-stop flow, JS can do the same, but those are not HTML (which is where ARIA comes into play). So what in HTML does not provide sufficient keyboard support for a list of links? Should the pattern also address JS / CSS practices as well?

[ZoeBijl]

@aardrian what I meant with “more complete keyboard support” is the ability to use the arrow keys to navigate the navigation menu. That doesn’t requires a bunch of ARIA to achieve as that can be done with JS. However, it does raise the question how you communicate that such features exist.

A similar issue arrises when I finally get to breadcrumbs with one tab stop. There’s currently nothing that tells a user that it has only one tab stop and that you should use the arrows to move through it.

Should the pattern also address JS / CSS practices as well?

No. For JS we test with various AT and browsers but do not require “best practices” if that makes sense. For CSS there’s the CSS-a11y TF.

[aardrian]

Thanks for clarifying. All of that sounds like it is outside of the scope of my issue. I misunderstood and thought you were making a case for or against my proposed language change.

[mcking65]

This is related to issues w3c/wcag#13 and w3c/wcag#287.

[straker]

I'd just like to say that Heydon Pickering's Inclusive Components article of when to use menu navigation vs site navigation was very helpful and clarifying. Would love to see it used as a reference/link in the new aria practices.

[yatil]

<w3c-hat type="off" title="Commenting as a private citizen :-)">

I, too think that regular site menus should not use ARIA application semantics and keyboard navigation.

1. ARIA semantics are not visually indicated to sighted keyboard users. Especially for users that are not used to using the keyboard, it can be disorienting when the tab key does not work as expected. Regardless of the knowledge level, I don’t think we want to expect that users just try which keyboard interaction method works for a particular menu.

2. For menus in web application that mimic desktop applications, I strongly think that it is reasonable to use the ARIA menu semantics and keyboard interaction.

My basic decision tree is: If the menu items are links to other pages (including AJAX trickery), don’t use aria menu. If every menu item in the menu carries out an action (copy, paste, new document), use aria menu.

The WAI tutorials try to make that distinction similarly in the menus tutorial (some minor updates have been added but not published).

[scottaohara]

I agree with the points @aardrian , @straker, and @yatil are raising.

I would not expect this pattern to ever be used for a primary navigation, where the purpose of the nav was to bring people to different pages / sections of a site/app, and think that the purpose of this role/pattern needs to be called out more explicitly, as @aardrian proposed.