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 #13 and #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.

[DavidMacDonald]

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>

[mcking65]

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

[mcking65]

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

[patrickhlauke]

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.

[patrickhlauke]

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

[mraccess77]

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.

[mcking65]

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

[mcking65]

@mraccess77 commented:

In my opinion navigation structures should not use role menu.

To re-emphasize two earlier points:

1. 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.
2. 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.

[aardrian]

@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:

1. 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.
2. 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?

[patrickhlauke]

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.

[mraccess77]

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#

[mcking65]

@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:

1. You have encountered some people who believe the APG says they should use the ARIA menu pattern for site navigation.
2. There are reasons to be concerned about people implementing the menu pattern for site navigation.
3. 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:

1. There is a simple nav element containing a list of links at the top of every APG example page.
2. 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.
3. 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.

[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!