The seciton about role=menubar should caution authors not to use it for navigation menus

[detlevhfischer]

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.

[StommePoes]

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

[StommePoes]

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: cb19e22...e199d95

[jasonkiss]

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"?

[StommePoes]

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.

[ZoeBijl]

This issue was moved to w3c/aria-practices#13