Should The menu and menubar design pattern caution authors not to use the pattern for site navigation menus?

[ZoeBijl]

From @detlevhfischer on November 4, 2015 16:5

Using role=menubar for navigation sections leads to badly accessible or inaccessible navigation menus in several combinations of browser / screenreader (in a recent test, problems occured in JAWS / IE, NVDA/FF, iOS/VoiceOver.
Authors should be strongly advised to use menubar / menu consatructs ONLY for application-type content mimicking desktop menus. We havehad cases where developers followed ARIA best practice in good faith and made their navigation inaccessible for SR users as a consequence.

Copied from original issue: w3c/aria#102

[ZoeBijl]

From @StommePoes on December 7, 2015 15:58

+1, developers call all sorts of things menus, the specs need to be clear what role="menu" means. I have seen in two sites unusable role="menu" navigation mega-menus.

[ZoeBijl]

Link to working draft: http://www.w3.org/TR/wai-aria-practices-1.1/#menu
Link to editors draft: https://cdn.rawgit.com/w3c/aria/master/practices/aria-practices.html#menu

Current description:

A menu is a type of widget that offers a list of choices to the user. A menu is often a list of common actions or functions that the user can invoke. The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application.

A menubar is a presentation of a menu that usually remains visible and is usually presented horizontally. The menubar role is used to create a menu bar similar to those found in Windows, Mac, and Gnome desktop applications. A menu bar is used to create a consistent set of frequently used commands.

This also came up during last weeks (?) APG call. Not sure if there is an action for this there is no action on the internal tracker.

[ZoeBijl]

From @StommePoes on December 7, 2015 16:48

That first paragraph can be thought of in terms of navigation menus, as links count as choices in many's minds. Menubar, same thing, except where it says similar to those found in OSes.

An explicit "not meant for typical website navigation" is the right direction and possibly adding "typical desktop application menus offering options as File, View, Edit..." will help developers think of the kinds of menus these roles are meant for.

[ZoeBijl]

Maybe something like:

A menu is a type of widget that offers a list of choices to the user. A menu is often a list of common actions or functions that the user can invoke within an application/web application. The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application, where typical offerings are File, View, and Edit.

[ZoeBijl]

@StommePoes some changes have been pushed today: w3c/aria@cb19e22...e199d95

[ZoeBijl]

From @jasonkiss on December 9, 2015 1:38

Using role=menubar for navigation sections leads to badly accessible or inaccessible navigation menus in several combinations of browser / screenreader (in a recent test, problems occured in JAWS / IE, NVDA/FF, iOS/VoiceOver.
Authors should be strongly advised to use menubar / menu consatructs ONLY for application-type content mimicking desktop menus. We havehad cases where developers followed ARIA best practice in good faith and made their navigation inaccessible for SR users as a consequence.

If the inaccessibility of menubar is the result of poor implementation by browsers and/or AT, then bugs should be filed with them. And any advice to not use menubar should be clear that it is temporary and/or in place because of the lack of existing support.
If the inaccessibility of menubar is a problem for navigation menus, why is it not also a problem for "application-type content mimicking desktop menus"?

[ZoeBijl]

From @StommePoes on December 10, 2015 11:59

I think the problem comes in where traditional navigation menus have been a thing since forever and have at least been basically navigable in the past (pre-aria), but now with these added, vaguely-supported new roles can turn these nav menus into almost-entirely-unusable nav menus. Nav menus meaning, nested links with anchors in them, mega menus, etc. Where no form controls are present. My understanding of the menu(item) roles is they are not meant for navigation menus, but application menus.

I see this issue as saying "make it super-captain-obvious clear to devs looking to do the right thing to leave navigation menus alone and NOT implement these "menu/menuitem" roles for them," rather than "don't use menu roles evar."

Whereas if vague half-butted support for menu(item) roles causes issues for actual command-menus, this is similar to support issues with other things like drag and drop not passing on keystrokes when lisitem/treeitem roles are used, and that's a separate, per-vendor issue as you say.

[mcking65]

We will revisit this issue after the reference implementations of menubar are complete so that the discussion can be had based on a known, good implementation.

Nonetheless, the content of a menubar does not change its effectiveness or utility. And, it may very well be an excellent choice for site navigation if a site uses the menubar/menu type of interaction model for its primary navigation.

[mcking65]

@StommePoes, @detlevhfischer, @jasonkiss,

In its December 14 heartbeat publication, The Authoring Practices Task Force has updated the menu and menubar pattern. The pattern includes functioning examples of a command menubar as well as a navigation menubar.

Like other Authoring Practices design patterns, The intent of the pattern is to facilitate correct application of the relevant roles, states, and properties as well as good quality support by assistive technologies. After reviewing the examples,the task force believes they accomplish these ends and welcomes your feedback.