aria-practices
aria-practices copied to clipboard
w3c
Clarify Purpose of Menu Navigation
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, […]
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.
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?
@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.
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.
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.
<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.
-
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.
-
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).
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.
I agree with the sentiment here. A list of links is a very understandable construct for simple list of navigation items..
<nav><button aria-expanded="true" ...>Our services</button>
<ul><li><a href="..." >Hats</a></li>
<li><a href="..." >Shoes</a></li>
<li><a href="..." >Pants</a></li>
...
</ul>
</nav>
@yatil commented:
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.
That decision tree suggests that authors use ARIA widget roles to describe the purpose of the elements rather than their interaction model. ARIA widget roles are designed to represent interaction models while accessible labels and content describe purpose. Basically, a widget role is a promise to the user -- I promise this thing that I gave the menu role will act like a menu. We cover this in the Read Me First section of the APG.
Of course, you can decide to draw any lines you wish around what types of functions you think belong inside specific widgets. That is a design call that has nothing to do with ARIA. If opening a different page is a function you wish not to put inside of ARIA menus, you don't have to put that function into an ARIA menu.
But, please, regardless of the function of an element, never use the menu role unless the element to which you apply it behaves like a menu as described in the APG menu pattern. And, always use the menu role if the element acts like a menu as described in the menu pattern.
The one certainty I see in this topic is that it is not black or white. A UX design is not necessarily good or bad based only on whether it uses ARIA menus for some of its navigation functions. It could be horrible or excellent or somewhere inbetween. You have to evaluate the total design.
@DavidMacDonald commented:
I agree with the sentiment here. A list of links is a very understandable construct for simple list of navigation items..
<nav><button aria-expanded="true" aria-haspopup="true" ...>Our services</button> <ul><li><a href="..." >Hats</a></li> <li><a href="..." >Shoes</a></li> <li><a href="..." >Pants</a></li> ... </ul> </nav>
David, Thanks for using a button there. I have often seen people make a disclosure that operates with a link, which is not what a link does. A link moves your focus to a new location ... not show/hide or perform other functions.
HOWEVER, please do not use aria-haspopup="true" in this construct. That changes the button to a menu button. But, your markup indicates that this is not a menu. This is the HTML that you would use for an element that behaves like a disclosure. Obviously, I am assuming you would not add JavaScript that would insert menu and menuitem roles and add arrow key support.
FWIW agree, unless it's a desktop-like application menu, don't use the full-on ARIA menu when a simple disclosure widget plus a series of links will also work just fine and not break some user's expectations that they can just TAB to links etc rather than having to work out they can only use arrow keys.
@MichielBijl
@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.
one caveat there would be that for AT users, you'd likely be competing with their AT keys (and I hope the answer here won't be to use role="application" ;) ). sure, you can enhance the interaction for non-AT keyboard users, I guess...
In my opinion navigation structures should not use role menu. Role menu forces AT into a certain mode as does role of application and this can be problematic especially when other elements exist in a navigation structure such as headings. In my experience role menu constructs can also be problematic in some mobile situations as well because they expect certain keystrokes. The ARIA example from the W3C incorrectly uses these roles for navigation despite the good advice from the WAI tutorials project not to use these roles.
@MichielBijl commented:
@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.
@patrickhlauke responded:
one caveat there would be that for AT users, you'd likely be competing with their AT keys (and I hope the answer here won't be to use
role="application";) ). sure, you can enhance the interaction for non-AT keyboard users, I guess...
Definitely not the application role. If you are creating menu behaviors, then you need to use the menu pattern and its associated roles. That is the best way to serve all users, especially AT users.
Again, the purpose of ARIA is to describe the accessibility features you provide. The most important principle here is to use ARIA accurately. If you create something that walks like a duck, be sure to describe it as a duck. Generally, it is also really smart to make it look like a duck too, but there are some situations, e.g., a person that is doing a duck dance, where looks are secondary.
@mraccess77 commented:
In my opinion navigation structures should not use role menu.
To re-emphasize two earlier points:
- If you want to draw boxes that exclude some design options from consideration for navigation functions, you can do so. The ARIA spec and APG do not force people to stay inside or outside such boxes.
- You should only use the menu role if you are implementing one of the ARIA menu patterns.
Role menu forces AT into a certain mode as does role of application and this can be problematic especially when other elements exist in a navigation structure such as headings.
Agree that you definitely do not want to put headings inside of menuitems!
However, if the purpose of a particular navigation design is to provide features like arrow key navigation, typeahead, efficient hierarchy, etc., then you really want the AT users to automatically get the mode switching. So, design first, then use the ARIA that describes the design. For instance, consider the bookmarks menu in most browsers. If you want to provide that type of experience, then you will need the ARIA menubar pattern.
In my experience role menu constructs can also be problematic in some mobile situations as well because they expect certain keystrokes.
Sounds like an implementation issue as I am pretty sure that the menu pattern roles are reasonably supported for touch interfaces.
The ARIA example from the W3C incorrectly uses these roles for navigation despite the good advice from the WAI tutorials project not to use these roles.
Please elaborate? Which example is incorrect? What aspects are incorrect? They are admitedly complex and there are still improvements being made as you can see from the APG menu project.
@mcking65
But, please, regardless of the function of an element, never use the menu role unless the element to which you apply it behaves like a menu as described in the APG menu pattern. And, always use the menu role if the element acts like a menu as described in the menu pattern.
APG has a pattern that explicitly refers to itself as web site navigation. The APG menu pattern at no point explicitly states that it is for application-level menus. This original report is to address that. The current description is so broad that a developer could take it to mean that it applies to web site navigation, while what I think you are saying is that if it has the behaviors you suggest it should get a menu role.
Definitely not the application role. If you are creating menu behaviors, then you need to use the menu pattern and its associated roles. That is the best way to serve all users, especially AT users.
I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role. Which I think is probably a good idea, as the menu role is for application-style menus.
Again, the purpose of ARIA is to describe the accessibility features you provide.
That is not strictly true. I am avoiding spec quoting since this is its own rabbit hole, but that assertion is a bit simplified. Certainly aria-hidden does not describe an accessibility feature.
For instance, consider the bookmarks menu in most browsers. If you want to provide that type of experience, then you will need the ARIA menubar pattern.
You have described a native application control. Which is fine, as that is what the menu and menubar roles are for.
To re-emphasize two earlier points:
- If you want to draw boxes that exclude some design options from consideration for navigation functions, you can do so. The ARIA spec and APG do not force people to stay inside or outside such boxes.
- You should only use the menu role if you are implementing one of the ARIA menu patterns.
I am not sure anyone is arguing against those points. Or even raised those objections.
To re-emphasize my original point:
- This document needs to add clarity in the pattern description about when it is appropriate to apply this pattern. General web site navigation is not it (by default), though cases may exist where it is appropriate. See the suggested language I provided.
Please elaborate? Which example is incorrect? What aspects are incorrect? They are admitedly complex and there are still improvements being made as you can see from the APG menu project.
I think @mraccess77 is talking about the examples in the APG, though I leave it for him to clarify. I can tell you, however, that these do contradict the WAI Tutorial, which he referenced: https://www.w3.org/WAI/tutorials/menus/
Regardless, to bring this back around to the original issue — I provided suggested text to amend the menu pattern description. Is that text acceptable to you? What do I need to do to it to have it accepted?
I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role
nah, what patrick was suggesting was in response to @MichielBijl's suggestion of NOT using the menu pattern (so using, say, expand/collapse disclosure widgets which then open up and contain a series of focusable elements like links) but including additional cursor up/cursor down functionality anyway (mimicing the ARIA menu keyboard handling to an extent, while also allowing regular tab/shift+tab). and i pointed out that doing this will work for non-AT keyboard users, but that for AT users those additional keystrokes won't work as they'll compete with AT reading keys. (and then imploring that hopefully the plan then isn't to suppress THOSE via role="application"). a shorter way of saying it would be: don't do it, but if you do, know you're not helping keyboard AT users.
I have provided below the menubar example from the ARIA 1.1 AP examples. While this menu looks like an application it really feels like it is meant for navigation. https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html#
@aardrian, It feels like we are talking past each other. I'll restart and try to discover where I am getting off track.
I see three primary points raised in your first comment:
- You have encountered some people who believe the APG says they should use the ARIA menu pattern for site navigation.
- There are reasons to be concerned about people implementing the menu pattern for site navigation.
- You requested a revision to the menu pattern description to emphasize that the interaction patterns of ARIA menus are like those of desktop menus.
The third point is purely editorial. It is low hanging fruit. So, as you suggested at the tail end of your last comment, let's start there.
You wrote:
to bring this back around to the original issue — I provided suggested text to amend the menu pattern description. Is that text acceptable to you? What do I need to do to it to have it accepted?
And your proposed revision is:
~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, […]
Would the following be sufficient?
A menu is a widget that offers a list of choices to the user, such as a set of actions or functions. Menu widgets behave like native operating system menus, such as the menus that pull down from the menubars commonly found at the top of many desktop application windows. 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, […]
Note: keep in mind that the first occurrence of the word "menu" is a link to the ARIA spec for the menu role.
If we can come to consensus on the APG description of the menu pattern, I think it will help with one of the disconnects propagating through this thread and beyond. Specifically, there are several different meanings of the term "menu" being invoked. This problem is exacerbated by the fact that we have multiple WAI resources that use the term "menu" in very different ways. The ARIA spec and APG use "menu" in a narrow sense whereas the WAI tutorial is using it in a very broad and generic way. I agree 100% with the sentiment that it would be helpful to create more harmony among these resources.
With respect to your first point, your original comment acknowledges that the APG does not tell people they should use the menu pattern for navigation. It does say they can, but it does not say or even imply they should. Along these lines, even though we have not yet completed issue #89, "Draft site navigation guidance section that addresses choosing among structures, disclosures, menus, grids, toolbars, trees, etc.," I hope that all the following would disavow the idea that the APG dictates use of the menu pattern for site navigation:
- There is a simple
navelement containing a list of links at the top of every APG example page. - The landmark region examples demonstrate site nav made with a navigation region containing a simple list of links and
aria-current="page"as a current page indicator. - Patterns other than menu, including grid and tree, also include examples of how to group navigation functions.
For that matter, it is important for everyone to understand that the APG is informative, not normative. As an editor, I am pretty maniacal about avoiding language and phrasing that could be mistaken as normative. I have been working on getting rid of even the non-normative uses of the words "should" or "must"; a few do remain. Further, the APG uses present tense language that purposely does not make the author the subject of active phrasing, e.g., "the element has role x" instead of "Authors should use role X on elements that".
Your second point, which has been the focus of most of this thread, is more complex and subtle. Perhaps one approach to making headway is to answer the question, "Why does the APG include examples of navigation widgets that implement the menu, tree, and grid patterns given that there are so many seasoned professionals who have raise legitimate concerns with using ARIA widgets for navigation functions?"
I'd like to address the second aspect of that question first -- why does the APG seem to be silent about many real-world consequences of utilizing ARIA widgets?
While silent about specifics, the APG does acknowledge a couple classes of problems with real-world use of the patterns. The first link on every example page is to the Browser and Assistive Technology Support section of the "Read Me First" section of the guide, which starts with the paragraph:
Testing assistive technology interoperability is essential before using code from this guide in production. Because the purpose of this guide is to illustrate appropriate use of ARIA 1.1 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.1 in browsers and assistive technologies. It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that is relevant within a target audience.
The fact is that every browser/assistive technology combination has its own unique set of ARIA support dead spots where it does not yet accurately and effectively render the experience represented by the ARIA. This spotty rendering of ARIA is one of the root causes of the practical problems generating concerns about wrapping up core site functionality in ARIA widgets. The APG is meant to be a canonical resource that can serve as a foundation for improving this situation. That is why the "Read Me First" also says:
Except in cases where the ARIA Working Group and other contributors have overlooked an error, examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs. Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.1.
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem. To that end, the scope of the APG task force also includes a project for assessing the experiences provided by assistive technologies for each pattern, i.e., a "CanIUse" type of resource for the patterns. Acting on the assessments will be part of ARIA working group collaboration with assistive technology and browser developers. I am spinning up that project now and hope to be sharing those plans as part of our presentation at CSUN.
So, the goal is progress toward a time when ARIA is so beautifully rendered that assistive technology users everywhere are clambering for web-based versions of all their native apps. This is realistically feasible. Bringing all the accessibility advantages of native GUIs to web GUIs is exactly what ARIA is designed to do.
The nascent accessibility advantages of web GUIs that have fabulous keyboard support and work really well with assistive technologies are the reason the APG includes examples like the navigation menubar. These advantages are well proven by GUI widgets that support navigation in native apps. Native apps have long been very effectively employing widgets, such as menubars, trees, toolbars, and grids, for navigating everything from libraries of books and file systems to email folders and screen reader help. Apps that do so are strongly preferred by assistive technology and keyboard users over apps that force the user to tab through every single element or memorize arcane keyboard shortcut schemes.
Admittedly, there is a lot of work to do to get to the point where we can transform any web GUI into something that is as enjoyable and efficient for people who rely on keyboards or assistive technologies as it is for the typical mouse user. Not all of that work is specific to ARIA. For instance, another gaping hole is the common lack of visual design features that reveal keyboard affordances. Even though that is not an ARIA-specific issue, since it impedes adoption and value realization, it could someday become something that the APG task force helps address.
It is worth emphasizing again that the APG is not suggesting that navigation should or should not be designed in some specific manner. However, if you choose to use an ARIA widget, such as a menu, it is providing best practice for implementing that widget. Whether or not the menu pattern is a good choice for a particular navigation feature on a particular site depends on many factors, some of which are beyond the scope of the APG. We will attempt to address the in-scope factors when completing issue #89.
You wrote:
The APG menu pattern at no point explicitly states that it is for application-level menus. This original report is to address that. The current description is so broad that a developer could take it to mean that it applies to web site navigation, while what I think you are saying is that if it has the behaviors you suggest it should get a menu role.
It is true that the APG does not attempt to limit the uses of the menu pattern to functions other than navigation. That is intentional.
The APG is also saying that if a widget "has the behaviors you suggest it should get a menu role."
As an aside, because of the following remark, I would like to highlight changes we made to role application in ARIA 1.1 that have not received much attention.
I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role. Which I think is probably a good idea, as the menu role is for application-style menus.
That idea is inline with the original concept behind the application role, but that type of use created more problems than it solved. Consequently, after considerable deliberation, we made significant changes to the definition and description of the application role in ARIA 1.1. The new definition is:
A structure containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a widget role.
The description also says:
When there is a need to create an element with an interaction model that is not supported by any of the WAI-ARIA widget roles, authors MAY give that element role application.
In other words, people should not wrap ordinary ARIA widgets in an application. Just use it to make interactive experiences that can't be made with existing ARIA widget roles.
@mcking65 Would you entertain changing the items in this example https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html away from a navigation bar to something else like an email application?
@mcking65 , I have been on the road for the last 6 weeks, so I appreciate your patience with my response time.
Would the following be sufficient?
A menu is a widget that offers a list of choices to the user, such as a set of actions or functions. Menu widgets behave like native operating system menus, such as the menus that pull down from the menubars commonly found at the top of many desktop application windows. 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, […]
Yes. That would work for me.
With respect to your first point, your original comment acknowledges that the APG does not tell people they should use the menu pattern for navigation.
Agreed. However, lack of clarity in the description (which is addressed in our proposed language) and a linked example of site navigation using the menu role (which @mraccess77 has asked you to change) has been read as endorsement of that model. In my experience conducting training, and most recently from a speaker at CSUN, many APG readers do not do any of the deeper digging that your paragraphs (above) offer. They see the APG as a cut-and-paste-ready pattern library (right or wrong).
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem.
I think me opening this issue suggests we are generally aligned
Most of the rest of your comments are beyond the scope of my original issue, but I want to address this:
Native apps have long been very effectively employing widgets, such as menubars, trees, toolbars, and grids, for navigating everything from libraries of books and file systems to email folders and screen reader help. Apps that do so are strongly preferred by assistive technology and keyboard users over apps that force the user to tab through every single element or memorize arcane keyboard shortcut schemes.
I feel that this statement makes an assertion that is not backed by data. In other words, I think you may be wrong in many cases / for many users.
I agree that for technically savvy AT users it is true. In my own years of usability testing, most users are not that tech savvy, and your statement does not bear itself out. Navigating a native tab menu, tree grid, menu bar, etc., relies on arcane commands to many. Shift + F10 is handy for power users who already know this from native platforms. As more and more AT users (with restricted finances) move to a mobile-only computing environment, with apps (and desktop applications) that are deployed solely through a web UI, reliance on native platform understanding is less and less valid.
This is, of course, anecdata from my limited research over a decade or so with hundreds of users in different testing environments (a drop in the bucket of users). But it is not a blanket assertion as you are making.
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem… by educating practitioners about how developers and users are actually using the advice we provide.
In case it's helpful, I opened https://github.com/w3c/aria-practices/issues/633 to try to address:
I am seeing more and more cases of authors who believe that something must adhere to the APG Something pattern.
The idea is to encourage authors to pause before jumping into a pattern, because maybe there's a perfectly good, accessible, native way to accomplish the task.
Pretty sure @mcking65 would appreciate a pull request for #633, if anyone has the time. Also, please feel free to verify the native-patterns that @MichielBijl and I listed there, and add any that you feel are missing.
A developer at Twitter has just tried to code a disclosure widget on individual tweets as an ARIA menu. When asked why, the feedback he provided was the exact text I requested be changed when filing this issue.
But according to the desc of a menu it seems much more like that than a disclosure:
https://www.w3.org/TR/wai-aria-practices/#menu
"A menu is a widget that offers a list of choices to the user, such as a set of actions. A menu is usually opened, or made visible, by activating a menu button"
https://twitter.com/CharlieCroom/status/1042798596918132736
Please just make the change I requested. I have been batting down incorrect use of menu roles for the year and a half since I opened this issue. When companies like Twitter encode it in their interface, it not only confuses users, it also justifies further mis-use.
+1 to what @aardrian said. i know the issue is "controversial", but in line with advice from other corners of W3C https://www.w3.org/WAI/tutorials/menus/ and other experts such as https://www.marcozehe.de/2018/09/22/wai-aria-menus-and-why-you-should-generally-avoid-using-them/ ... it would be good to get ARIA practices to also follow suit.
I'm a screen reader user, and I run into this practice more often than ever. More developers are just putting menu and menuitem for navigation links. In fact this github also has the problem when you click your name to expand Your profile, repositories, stars, gists... . #user-links > li:nth-child(3) > details > details-menu I know people have a good intention for using aria everywhere, and developers are probably thinking that they're doing extra job to accommodate AT users by putting menu and menuitem roles manually. However, it actually creates an inconvenience by triggering screen reader to go into application mode and disable html navigation keys for screen reader. Maybe menu and menu item should be renamed to more specific (application-menu or desktop-menu,) or have a warning statement in the beginning of description to clarify and discourage this practice.
I should probably add a discussion I recently had with a development team. They are creating a main navigation classic mega menu for a major retail chain. They have been pushing very hard on using menubar, menu, menuitem for all of the links on the menu. I am pointing them to this discussion. I think at the current time for a mega menu we should not use these roles. It may be better if we discourage the use of menu roles on main site navigation menus where there are native <ul><li><a> elements. I suggest we amend the navigation menu example to be some other sort of menu.
Either that or we'll really need to put some hard core energy on developing, testing a variety of navigation menus. This pattern library is quickly becoming the defacto standard referenced in legal cases and elsewhere. It is considered a cut and paste library for the majority of users I have encountered. I'm fine with that, but I really would like to ensure there is strong consensus on all patterns presented.
@carmacleod @mcking65 I think we need to have guidance section on collections of links used for navigation of pages in a website, with examples using menubar, menu buttons, disclosure and simple tab navigation. The section would describe the accessibility features and issues of using these different techniques. This section could also address issues of mega menus. Hopefully can get this topic on an agenda some time.
@jongund While I like that idea overall, I am not sure how much bandwidth this team has to manage a full pattern library (even if navigation only) when this issue alone has been open for 3¼ years.
My understanding is that this Note started as a way to show how ARIA can re-create native-like controls (or replicate some HTML capabilities) but as its scope continues to grow (see sections 4 through 9, which are not patterns) I feel that trying to become a full-blown pattern library with the necessary ongoing testing is outside the scope and release timing of this Note.