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, […]

[JAWS-test]

If menus are considered problematic for navigation (I can share some of the concerns), the question is whether the problems do not all apply to application menus (https://w3c.github.io/aria-practices/examples/menubar/menubar-editor.html)? If not: what is the difference?

[carmacleod]

@JAWS-test I think (?) the difference is mostly in user expectations.

Users expect to tab through navigation links, which is why ARIA menubar (single tab stop, arrow through navigation links) may not be the best choice.

However, users expect to use arrow keys in an application menubar because that's what they use in desktop menubars (and google docs. ;) The menuitems are not links. They don't behave like links. They behave like menuitems. So arrow keys to move through them are not unexpected as long as it's clear that it's an application menubar by placement and visual styling.

[patrickhlauke]

also, design-wise, application-like menus are indeed fairly standardised in what they contain, as they still mostly mimic native app menus. there's less variety/desire for cramming additional functionality into them, whereas "navigation" is a much looser idea (particularly once you start factoring in things like mega-menus etc, which don't exist as such in native applications)

[guyhickling]

So a new section will be added to the Authoring Practices for navigation menus, which is excellent. But could a sentence also be added to the current menubar section to explicitly say something like "This pattern is not intended to be used for navigation menus."? Otherwise developers and other users will continue to be confused and mislead and still use this pattern for the wrong purpose.

[carmacleod]

Dorothy's email thread about this issue.

[carmacleod]

My reply in the mailing list thread is hidden behind a "text/html attachment: stored" link, so pasting here for easier viewing:

---

Hi, Dorothy!

I've pasted a link to this email thread into GitHub issue #353 in order to keep the conversation all in one place. :)

Please note that a section called Navigation Systems for Sites and Apps is currently being drafted for the APG. Review comments are welcome in GitHub pull request #1492.

Please also note that the problem you observed in JAWS is JAWS bug #415. NVDA correctly says "submenu" when a focused menuitem has a submenu. There's also JAWS bug #411 that is asking for left/right arrow instructions to open submenus.

Hope this is helpful! Carolyn

[aardrian]

@carmacleod Dorothy's second link points to a pattern that has been removed from the A11y Style Guide site (which used roles incorrectly) and is no longer at that URL: https://github.com/cehfisher/a11y-style-guide/issues/255

I know that is not the only one she tried, so when she says to follow every link that is probably a good idea if anyone else wants to dive in as I did.

Also, very glad your email was an attachment which retained her original formatting as it proved to help me understand her message much better (the plain-text was rough on me).

[Anubarak]

Coming a little bit late to the party. I just recently started to add a11y support for my website and I thought the example here was best practice.

I guess that's not really the case - but then again: what would be considered to be "best practice"? Because I would consider those as even far worse since you would have to TAB through the entire (first level) menu before you can "pass" it instead of just skipping it all the way. Could someone please explain me why that would be better - that would help me a lot to understand what should be done? (sorry if that's the wrong place to ask, but I have the feeling there is not that much help on Stack Exchange when it comes to this topic)

[aardrian]

@Anubarak I consider these two as options worth testing:

• https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-navigation.html
• https://w3c.github.io/aria-practices/examples/disclosure/disclosure-navigation-hybrid.html

The second one corresponds to a pattern I have used with success. Up above, @carmacleod highlights three navigation patterns in APG that you could test for your needs.

[Anubarak]

@aardrian Thank you very much for your fast answer: But how can I make these work with arrow/navigation keys (the one that should be compatible)? When I try those examples with NVDA and press Arrow[key] it only spells out a character instead of changing a tab. I would always consider my first example as much better since it allows you to use arrow keys.

(Don't get me wrong - I believe you that it is considered as better, I would just like to understand why, because it might help me to be less confused about things I would never want to use myself) Currently I would add a role="application" to that thing to allow arrow keys (I know - a no go - but if I was blind right now I would wish every menu was like that)

[JAWS-test]

Because I would consider those as even far worse since you would have to TAB through the entire (first level) menu before you can "pass" it instead of just skipping it all the way.

To avoid this, there is WCAG 2.4.1. You could implement a skip link to skip the menu

[JAWS-test]

if you want a menu with arrow key operation (with screen reader), then only this works: https://www.w3.org/TR/wai-aria-practices-1.2/examples/menubar/menubar-1/menubar-1.html

[Anubarak]

if you want a menu with arrow key operation (with screen reader), then only this works: https://www.w3.org/TR/wai-aria-practices-1.2/examples/menubar/menubar-1/menubar-1.html

But this one is considered as bad, right? Sorry for all the trouble I just have a hard time to understand the reasons behind it. It's not that I want to navigate via arrow keys, I just think that would be ideal because desktop programs handle it the same way and I'm used to it because I navigate via keyboard most of the time in my IDE. Maybe my current test cases are not correct or my expectation how users navigate via screen reader is plain wrong.

[mraccess77]

Site navigation is - well - navigation and not a menu in the sense of software applications where menus often perform actions or open dialogs. Using the menu role also forces screen readers into forms/focus mode which sometimes can cause issues getting out of that mode - especially if you accidently get into it and don't realize. Mega menus have a lot of other details that menus weren't designed to handle - so these may necessitate a disclosure pattern. Mostly though for years there was no menu role and folks - including some non-screen reader keyboard users expected tabs and menu items to each be reachable with the tab key. So while a menu could be used in some situation and is not wrong it's generally not the expected behavior we have found for most users.

[JAWS-test]

But this one is considered as bad, right?

Some see this as a bad thing. But not me, for example - I think it's good. And there has at least been the APG example for years - so it can't be that bad. In my opinion, the only important things are the following:

• ARIA menu: All entries must be reachable with the arrow keys. The menu may only contain menu entries and no other elements (drop-down lists, input fields, subheadings, etc.).
• HTML menu: All entries must be reachable with Tab key.

[patrickhlauke]

and noting that if you are using an ARIA menu, you can't use anything that isn't normally in a Windows-style menu. you can only include menu items, checkbox and radio menu items, separators (though they're not conveyed by AT so mostly pointless), and other menus. as soon as you want to include any kind of additional text content, headings, maybe a built-in search form in a dropdown menu, etc ... you can't use ARIA menu, because the rigid structure of ARIA menus doesn't allow for that and it's likely that AT will not be able to sensibly convey it / let users use reading keys to explore further static content / etc. [ edit: ah, i see i made a similar point before #issuecomment-6645705630 ]

[wkeese]

It looks like they are slowly moving to fix this, although the guidance is still unclear. But the latest W3C menubar example now says that:

A pattern more suited for typical site navigation with expandable groups of links is the disclosure pattern. For an example, see Example Disclosure Navigation Menu.

Disclosure pattern supports navigating to links by both the tab key and arrow keys.

Another interesting thing is that latest W3C menubar example indicates that IF using role=menu/menubar, where the TAB key skips over the whole group, then you need a group focus outline on the menu/menubar in addition to the outline for the currently focused (or aria-activedescendant?) element, like this:

(The blue outline around the whole menubar only appears when focus is inside the menubar.)

[patrickhlauke]

Another interesting thing is that latest W3C menubar example indicates that IF using role=menu/menubar, where the TAB key skips over the whole group, then you need a group focus outline on the menu/menubar in addition to the outline for the currently focused (or aria-activedescendant?) element

I'd clarify that the example doesn't say that you need to have that focus outline. it just points out that this is a feature that was added to this particular example. there's no need or requirement for anybody to do this.

[wkeese]

That's true, what they say is:

To help communicate that the arrow keys are available for directional navigation within the menubar and its submenus, a border is added to the menubar container when focus is within the menubar.

IMO they could have also said:

To help communicate that the tab key ISN'T available for navigation within the menubar...

In any case, that menubar focus border thing was just an aside, my main point is that they are recommending the disclosure pattern for site nav, rather than the menubar pattern.

PS: I still wish they would get rid of the site navigation menubar example, and just keep the editor menubar example... which is the point of this ticket.

[mbgower]

I’m very late to this conversation, but a back and forth I’ve been having with @wkeese at IBM inspired me to dig more into what’s going in current disclosure pattern discussions.

This is a very long issue thread, but I will summarize my concerns with the direction it’s tilting in a few points, with the hope I can join in some group discussions on future calls to elaborate:

1. First, to state the obvious, in the early days of the web, links became a catch-all method for backfilling for a whole lot of richer interactions in software. However, ‘we’ve always used links for this’ is a not a conclusive argument for why we need continue in the same manner; there are, for example situations where the madness of a 100-link left nav can be improved massively by use of a tree (which is another form of disclosure).
2. @mcking65 said it earlier, but it’s worth repeating: there are situations where it makes sense to construct something as a list of links in series and other situations where it makes sense to treat something as a menu (or tree, or whatever) that takes a single tabstop. It would be a mistake to create a culture where designers are constrained to always allowing Tab interaction through every node in a menu-like interaction (which is the argument advanced by some)
3. There are 2 factors that need to be aligned to arrive at a successful design -- how an interaction is visually presented and how it is programmatically presented. Those together are going to determine a lot of user expectations about how to interact (both through a pointer or through the keyboard API). I’ve been surprised to see some conversations applauding the usa.gov site, whose top navigation I find very problematic (I could waste a lot of time talking about how it gets both arrow key interaction wrong AND creates a persistent menu that obscures content, amongst several other things). I think it serves rather as a caution.
4. We must factor in potential consequences of pushing a prescriptive disclosure pattern. I don’t know when someone made the first steps to bind Space and Enter to the same action, but I have grieved for it these 20 years and more. It seems tragic that with so few keys available, they should end up being bound together for the same purpose. Yet an outcome that seems inherent in one approach being discussed here is to make Arrow key and Tab key actions also quite synonymous -- yes, you’ll be able to use arrow keys to navigate this quasi menu structure, but you’ll have to provide Tab operation too. Please, let’s not give up another key.
5. I’ve heard some arguments that the result of activation should determine the nature of the component -- links always open new pages, therefore anything that does so should be a link. This argument doesn’t hold up, both because there can be different interpretations of “new page” and because lots of components besides links can trigger new page content (whether a full reload or a replacement of content without changing the url). Returning to my first point, an obvious improvement that can happen on some sites is to provide a tree in place of a massive left nav. But if we turn around and say ‘the targets of the tree are different pages, therefore they must be created as links that are each in the tab order serially’ we lose all the efficiency of the tree (especially the ability to bypass the entire tree by making it a single tabstop). ARIA gives us the ability to assign roles. If a link looks like a menu item and presents with a menu item role, it’s a menu item. That can be the case regardless of whether it launches a new page, opens a dialog, toggles a setting or any of the myriad things a menu item can cause on activation. The menu item's name can offer some context. Could always consider specific types of info, like menuitemlink, I guess.

[mraccess77]

Challenges with how trees are displayed with screen reader in browse mode make it potentially easier to miss things - they may limit searchability for screen reader users and limit access the list of links, etc. so movement toward these structure would really need better support with screen readers before wide spread implementation in my opinion.

[aardrian]

Hi, @mbgower! Nothing you have said is controversial (to me at least), but while it is fresh I am responding since I opened the issue…

1. A link to jump past a group links is an 'early days' ARIA-free method that can work too. It is better supported in AT than ARIA tree/treegrid (as @mraccess77 suggests and my own experience supports). And it obliquely honors the First Rule of ARIA.

2. No argument there. Everything has its place, and when testing with users shows one pattern does not work, adjustments should be made. Especially when a pattern is proposed that relies on a new paradigm native to another platform.

3. I don't see USA.gov mentioned in this thread at all (I only did a Ctrl+F though).

4. Breaking this one up as you hit more than one point:

   1. I was not pushing a prescriptive disclosure pattern and I am not sure anyone else is either. This issue is me raising a concern over APG pushing a prescriptive menu pattern for site navigation.

   2. To your point about losing use of keys, I know I, for one, hate giving up my arrow keys to navigate long menus when I just want to scroll that page. Or the space key when I want to scroll while in the menu and it activates the menu item instead.

5. Breaking this up as well:

   1. Links do not always open new pages. Links go somewhere; sometimes to an anchor on the page. Within applications, it makes sense to avoid links. Within "web apps", where a new screen results in a new URL, new <title>, and new history object, then now you arguably have navigation as far as the user is concerned.

   2. Returning to your first point, I disagree that an ARIA tree/treegrid is an improvement. In my own testing, it is a net loss of usability and functionality for many users.

   3. Remember that links have context-menu features (open in new tab, open incognito, save, copy URL, etc.). Once you give a link a menu role, you risk obfuscating for certain AT users that they can take the same actions with it that they might with a standard link. As @mcking65 points out early in this conversation, APG asserts that a role is a promise. Assigning a menu role to a link is breaking the promise of the implicit link role and making a new promise that hides features. A user who brings up the context menu will know they have been lied to.

   4. If you are proposing a menuitemlink role then you should open a new issue for that.

[mbgower]

Thanks for the response, @aardrian. I may have picked up on the usa.gov in various post about this topic, rather than in this thread. A few different topics have glommed onto your topic, and it is referenced in a number of discussions, so sorry to cause confusion.

That said, I do think that usa.gov's implementation of their navigation serves as a good cautionary tale for what can go wrong with the navigation disclosure pattern that looks like a menu but is 'a bunch of links' behind a facade. A sighted keyboard-biased user trying to use arrow keys to operate it will find a couple of 'wah!?' moments (opening a vertical menu and arrowing down into it, the focus merrily proceeds across the parent menu bar instead). A keyboard user biasing to Tab operation also encounters a couple of head scratchers (tabbing through the items in an exposed navigation menu, the menu persists on the screen, blotting out all visual affordance of where keyboard focus resides, etc).

I've seen enough of both these behaviours that I know they are common implementation challenges. Which is just to make the point that we don't arrive at a necessarily happier world avoiding menu roles.

One thing I'm curious about. How much does adding a menuitemlink role change this discussion for you? I realize overriding an anchor's implicit link role with an explicit menu item role is not your only concern, but just trying to understand its relative importance.

[aardrian]

How much does adding a menuitemlink role change this discussion for you?

This issue discussion? For me? Not at all.

If it gets scoped to replicate a link in every way, minted and supported in all browsers and appropriate AT, and we later get data on how it performs for users in the real world across application and web contexts, perhaps it will then be relevant for me?

[patrickhlauke]

simply inventing a new role like menuitemlink is all well and good, but the big question for me would be if that is also mapped in a sensible way to the accessibility API of the OS/AT ... if it's even possible for those more complex widget constructs with fairly strict structures, such as menus, to just magic up a new kind of child element/role it can have.

and again, one of my main gripes with the menu pattern is that it is so restrictive and limiting ... i've spent a good chunk of my time getting well-meaning developers to remove menu / menuitem etc roles from their fancy special dropdowns that then also included headings, search fields, etc, because the latter were either simply not seen/conveyed (because they are not "legal" inside a proper menu structure), or unusable (because AT switched into menu navigation mode, so it wasn't possible for AT users to actually use reading keys to get to the mixed-in static non-menu content in those megamenus, of to meaningfully interact with other interactive controls that were incorrectly nested inside the menu)

[smhigley]

@mbgower I think you bring up good points about how context matters when considering what type of control to use. I definitely don't read this issue and discussion as implying that someone should never use a menu or tree for app navigation, though. For instance, any of the following example circumstances could easily justify composite widget for navigation IMO:

• your entire app is a desktop-like app (or actual web port of an existing desktop app), and is designed to be used pretty much entirely in forms mode (if using a Windows SR) and with keyboard shortcuts
• your "navigation" is a mixed set of links and actual menu items, e.g. having "help", "contact", etc. together with file/edit/view/etc
• you have 100+ links, and they are not hidden behind a search function or separate sitemap page

The thing is, the APG navigation menu example shows a very traditional content-centered website with a very standard navigation, and doesn't model any context that would justify menu roles. If we changed it to show navigation functionality in a context that did justify a composite widget (e.g. a word editing app with a "Files" navigation sidebar), I at least would no longer have an issue with it remaining.

[wkeese]

Remember that links have context-menu features (open in new tab, open incognito, save, copy URL, etc.). Once you give a link a menu role, you risk obfuscating for certain AT users that they can take the same actions with it that they might with a standard link.

Good point. It definitely seems like users (including screen reader users) should be able to open the links in https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html in separate tabs or windows. I know some web apps constrain the user to stay inside a single tab, but a college information website shouldn't do that.

[TastyPi]

Our company had an engineer spend a week implementing a navigation menu following the Navigation Menubar Example before discovering the discussion around it not being a good practice. Could we please remove that example or at least update it to have a note saying it's not the recommended approach so that no-one else falls into that trap?

[JAWS-test]

@TastyPi Just because some have concerns, it is not wrong to use the ARIA menu roles for navigation. Only when the discussion is finished will there be a result, e.g. removal of the menu navigation pattern, warning or everything remains as it is. Even if the pattern was removed, it would not be wrong to use it. It is then only no longer recommended, but not automatically forbidden. Therefore I would say: Don't worry

[aardrian]

@JAWS-test:

…Only when the discussion is finished will there be a result, e.g. removal of the menu navigation pattern, warning or everything remains as it is.

There is a warning. The 1.1 pattern has, as the very first link, info about browser and AT support. I opened this issue to make that more obvious (because many users do not follow the link). The APG 1.2 Draft navigation menubar example and APG 1.3 Editor's Draft navigation menubar example each have an on-page disclosure about best practices, and an orange always-visible CAUTION!

If anything, I think @TastyPi has demonstrated the value of that pair of warnings being more visible.

As it is, this valuable context is buried in the document (along with the context that APG is not a production-ready pattern library) and still a link away from all the stand-alone pattern pages:

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

[ForbiddenEra]

Curious about something that I don't particularly see addressed anywhere.

I see some recommendations saying you should use ul or ol for nav lists; what about menu?

The <menu> HTML (https://developer.mozilla.org/en-US/docs/Web/HTML) element is a semantic alternative to <ul> It represents an unordered list of items (represented by <li> elements), each of which represents a link or other command that the user can activate.

AFAICT it's identical to ul but possibly more 'semantic'; it has the implicit list role and many other allowed roles including menu and menuitem.

Does this have any negative affect in reality? If it's not useful semantically, especially for accessibility, should the element perhaps be deprecated? Or, if it's OK to use, should the specs be updated to mention that a

is the same as a

basically?

[aardrian]

@ForbiddenEra

<menu> was originally minted to produce a context menu (such as when you right-click), but got no traction. It was co-opted for other uses owing to misunderstanding. W3C deprecated <menu>, but WHATWG has not since it took over HTML. Now it is effectively no different from a list container. WHATWG seems to have no interest in removing it nor re-scoping it, but you can make the pitch to WHATWG given its lack of differentiation from from a <ul>.

Frankly, I don't have the time to fix every MDN entry, but MDN's <menu> entry claim that "The <menu> HTML element is a semantic alternative to <ul>" is demonstrably not true (assuming its use of the word "semantic" means it is exposed in some unique way).

In short, I would (and do) ignore <menu>.

Edit: I created a PR to fix the MDN entry for <menu>.

[ForbiddenEra]

@ForbiddenEra

<menu> was originally minted to produce a context menu (such as when you right-click), but got no traction. It was co-opted for other uses owing to misunderstanding. W3C deprecated <menu>, but WHATWG has not since it took over HTML. Now it is effectively no different from a list container. WHATWG seems to have no interest in removing it nor re-scoping it, but you can make the pitch to WHATWG given its lack of differentiation from from a <ul>.

Frankly, I don't have the time to fix every MDN entry, but MDN's <menu> entry claim that "The <menu> HTML element is a semantic alternative to <ul>" is demonstrably not true (assuming its use of the word "semantic" means it is exposed in some unique way).

In short, I would (and do) ignore <menu>.

Edit: I created a PR to fix the MDN entry for <menu>.

I'm aware of the history (html since 96, heh..), since context menu stuff was deprecated I've always preferred using it to at the very least differentiate in code the difference between a non-menu-type list and a list since it seems to be treated the same as <ul> otherwise; I haven't seen it particularly cause any issues anywhere but was curious if it could be an accessibility issue.

Thanks for the clarification.

[grelas]

Still a bit confused on usage differences between something like select-only combobox vs. menu/menuitem - opened this question about what to use in a situation where you are filtering and/or sorting existing content on a page - e.g. Sort by: Relevancy. For example, a user wants to sort user-submitted comments on an eCommerce product page. They click "Sort by" dropdown, select "Most recent", and the page automatically updates with sorted comments (there is no form or form submit button).

According to Menu pattern:

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.

In this case, a "Sort by" menu dropdown does not seem to be like a "native operating system menu" (or is it??). Would a Select-only Combobox be the more appropriate pattern?

[aardrian]

@grelas This issue relates to web site navigation. Your question is out of scope for the issue. If the issue you opened and closed was not enough clarity, you may want to open another, asking in a dedicated support forum, or pinging some practitioners.

That being said, I don't know what you mean by "dropdown", but how it would be coded affects how some users will experience and interact with it.

A listbox/combobox is for submitting information in a form (and should have a submit button since firing onchange is problematic). A menu is for adjusting the current state of a thing (and does not use a submit button). Granted, I am greatly over-simplifying, but that is because this question is out scope.

[grelas]

@aardrian Sorry about that! Thanks for sending that article - haven't seen this!