[menu] Navigation vs menu items use case

[domfarolino]

During the meeting where we presented the menu elements proposal for incubation (minutes) (explainer), @scottaohara raised the topic of navigation menu bars (https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/) being particularly thorny, and being a different beast than what I'll call the "normal menubar" use case, which is described by https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-editor/.

In particular, see these lines from the minutes:

sorvell: navigation is a deep can of worms, people have strong opinions about navigations and menus

...

scott: im going to talk about navigation use case

scott: that is one thats on the apg and is the most contentious

scott: one of the reasons that navigation use case is not preferred is that menuitems are not navigable using screenreaders. theyre meant to be treated like navigation to menus in macos windows etc

scott: as far how theyre used on the web and used for navigation purporses, they can make finding what youre looking for harder for screenreader users because you cant just bring up a list of hyperlink

scott: if the navigation menubar is to go forward, we would need to do work thats never been done before to make this a thing that is not just another way of saying menu

...

scott: i am not opposed to it moving forward, but theres a lot of work moving forward

scott: if its just going to be menu but it has type=nav but no actual difference then we havent helped anyone

Somewhere in the minutes I say:

dom: thanks, i understand why its a big deviation

...but either I was wrong at the time, or I've forgotten. Some of us at Google have been trying to understand how the navigation use case is so different form the "normal (editor example) menubar" use case. Even if we decide navigation is too scary to tackle right away, I still think we need to have this discussion because I fear if we don't design something for this use case, developers will just use the "normal menubar" primitives to achieve this, by stuffing navigating actions/commands in each <menuitem>, thus ossifying a poor accessibility experience.

So I think we have a few questions, much of which we intend to discuss at the next meeting:

• Why is the navigation use case different?
  • The real question here I think is: what would need to be semantically distinct in a <navbar> from <normalmenubar> in order to make <navbar> suitable for the navigation use case? What's the real delta between these
  • @scottaohara mentions "they can make finding what youre looking for harder for screenreader users because you cant just bring up a list of hyperlink", but I don't fully understand this. Why can you just "bring up a list of hyperlinks"? In the non-navigation menubar case, we're certainly going to "just bring up a list of menuitems"—does that have the same accessibility concerns?
• Is it actually bad if developers manually navigate the page in response to <menuitem> clicks? This could be done
• Multi-page app vs single-page app: I can imagine developers implementing SPA navigations with a normal menubar that responds to <menuitem> activations to swap in new content, since they don't need traditional anchor semantics. Is the "SPA use case" considered the same as the "navigation use case", and would it be a bad outcome if developers this? MPAs and SPAs have the same navigation intent: show new content to the user when they click something, but they do this very differently. Is the "navigation intent" what's scary about the navigation use case? Or is it just the raw-anchor-tags-inside-of-the-menuitem MPA case that's scary about the navigation use case?

/cc @dizhang168 @mfreed7 @josepharhar

[scottaohara]

i know i've provided a reference to this long issue about the apg menu/nav example - but it seems my access to the google doc has been restricted, and if the comment still exists, i can't see it anymore.

Adrian Roselli has an updated throughout the years blog post that goes into more detail on the opposing thoughts to the menu navigation pattern. There are other people who have written about this as well (adrian even links to some of them).

Something else to know is that the main reason the APG's disclosure navigation pattern was created was to provide a counter example and additional information concerning the menu nav example. The following is the intro to the disclosure nav pattern:

Although this example uses the word "menu" in the colloquial sense to refer to a set of navigation links, it does not use the WAI-ARIA menu role. This implementation of site navigation does not use the menu role because it does not provide the complex functionality that assistive technologies expect in a widget that has the menu role. Typical site navigation does not need all the keyboard interactions specified by the menu and menubar pattern.

we can go over the above more on the call - but i think that largely covers your first two bullets. Those should probably be mentioned in the explainer, if attempting to take on this scary topic.

regarding:

mentions "they can make finding what youre looking for harder for screenreader users because you cant just bring up a list of hyperlink", but I don't fully understand this. Why can you just "bring up a list of hyperlinks"? In the non-navigation menubar case, we're certainly going to "just bring up a list of menuitems"—does that have the same accessibility concerns?

This is some basic information about how screen readers work: screen readers allow users to navigate by specific elements. Someone using a screen reader can specifically navigate by hyperlinks, or form controls, or specific types of form controls (e.g., buttons or comboboxes instead of all form controls), headings, landmarks, etc.
In contrast, menuitems are not a type of element that one can navigate by with any screen reader, as far as I am aware. So, when I was saying users can bring up a list of links and quickly navigate to the one they want - that meant with their screen reader they can do exactly that. But, if navigation items (hyperlinks) are instead coded as a menubar/menu/menuitems, that won't be a feature the screen readers provides. Because menus are not commonly expected to be used as navigation patterns.
Edit: another UX issue that was mentioned to me is that menu navigations can often be more difficult to use for people who use voice dictation software (Voice Access, Voice Control, Dragon, etc.). The reasoning being similar to the screen reader scenario - navigations are commonly links and buttons that open popups of more links. But when coded as menus the typical commands for activating hyperlinks and buttons no longer work. A user then has to use alternate voice commands to try to activate the controls, repeatedly asking to "show numbers" for the AT that supports that, or dictating keyboard commands to attempt to navigate to the menuitem of choice, rather than just being able to consistently say "click [name of thing that isn't a link]".

My point in the quoted minutes (which have some quite abbreviated versions of what i was saying... i do speak rather fast...) - was that if navigation menus are a use case that "needs to be handled", then effort should be taken to create the feature in a way that handles the criticisms / failings of using a menubar for navigation purposes. This isn't "scary" as you mentioned a few times. But properly handling and taking on a contentious UX topic - where some (a11y advocates and users which is supposed to be important here) would describe this use case as an antipattern. My criticism to the menu nav use case has always been that in the proposal, none of the problems were being addressed (or acknowledged). I would like to think we could come up with a proposal that could attempt to solve for the use case. Just more work to do, and understanding the use case one is trying to solve for.

I don't think I need to get into the last two bullets now. I've already covered them a bit in what I've already written as they're really just re-asking the same question in different ways. Gotta leave some stuff for the actual meeting :)

[scottaohara]

FYI - I've opened an issue for the ARIA working group to consider the menu navigation use case. w3c/aria#2510

[josepharhar]

Thanks Scott!

I wonder how menus which are mostly actions but also have a few links fit into this. For example, in the google docs menubar there is a link under "Help" called "Training", which opens the link in a new tab when activated. Surely the entire google docs menubar is not a navigation, right? Is the site wrong for having a link in this menu? If not, shouldn't we provide a declarative way for making a menuitem open a link so they don't have to write a bunch of script to do it?

[domfarolino]

But, if navigation items (hyperlinks) are instead coded as a menubar/menu/menuitems, that won't be a feature the screen readers provides. Because menus are not commonly expected to be used as navigation patterns.

Got it! This leaves me with two questions:

1. In that case, supporting hyperlinks inside menuitems would probably be a requirement for supporting the navigation use case, right? That way they can quickly search through all of the hyperlinks, instead of opaque <menuitem href=foo>.
2. How will screen readers navigate complex menu layouts in the non-navigation menu case, if "menuitems are not a type of element that one can navigate by with any screen reader"?

[scottaohara]

If not, shouldn't we provide a declarative way for making a menuitem open a link so they don't have to write a bunch of script to do it?

i've never been opposed to that. and per the linked aria issue, i cite this as a use case. we did talk about supporting href on a menuitem to account for this without JS in the google doc.

In that case, supporting hyperlinks inside menuitems would probably be a requirement for supporting the navigation use case, right? That way they can quickly search through all of the hyperlinks, instead of opaque <menuitem href=foo>.

i also commented on this in the google doc - but no. not nested. it would be invalid to put hyperlinks within menuitems. menuitems are interactive elements already. When someone is navigating a menu, they are either automatically, or they manually switch (based on the screen reader/os) into an "application" mode. arrow key navigation takes over and it is not expected to navigate into menuitems - just like it is not expected to navigate into buttons on the web. A user likely wouldn't be aware of the nested hyperlink.

This touches on your next question a bit as well - and this really seems like needing a kind of primer on how screen readers (and per my mention of voice dictation software in my last comment - other AT) work with different markup patterns. It's probably best to go over that in the call, at least for a high level anecdotes pertaining to this topic.

[aardrian]

I have a few concerns, which I'll break up with headings, but this is not my day job and I have little time to wade into this in detail.

Overcoming Prior Challenges

Reading through the explainer:

This proposal introduces new menu elements to give web developers more flexibility while following the ARIA practices on menu and menubar. Namely, we suggest adding <menubar>, <menulist> and various types of <menuitem> elements.

As you know, <menu> was redefined in HTML5 and <menuitem> was deprecated and removed. Originally they were meant for OS-like context menus.

I appreciate the explainer touches on this history, but the explainer doesn't, er, explain how the proposal addresses the reasons UAs showed little interest.

Use Case Confusion

It seems the OS-like menu feature is the baseline, per this comment above:

... a different beast than what I'll call the "normal menubar" use case ...

Then I saw this in the transcript:

scott: one of the reasons that navigation use case is not preferred is that menuitems are not navigable using screenreaders.

That is not true and also nothing Scott would ever say. I am pointing this out because that's a signal to me the transcript incorrectly captured the conversation. As such, I am ignoring it.

These reinforce my experience with getting authors to understand that the word "menu" has different meanings to different audiences. I outlined 15 examples of different meanings in a post a couple years ago.

Navigation Misunderstanding

Scott already linked an APG issue from 2017 where the APG inappropriately created a web page navigation mechanism from ARIA menus (in its defense, APG was only ever showing idealized ARIA approaches, not production-ready code).

I encourage you to read that thread if your team has "been trying to understand how the navigation use case is so different form the 'normal (editor example) menubar' use case." In particular, I caution you to avoid calling it "scary" when that mis-use presented genuine barriers to people in that thread.

A shorter version of that issue is in another post of mine Don’t Use ARIA Menu Roles for Site Nav. That issue and then a pile of testing with users lead to me writing the Link + Disclosure Widget Navigation, which may be useful for understanding how the same pattern landed at APG (thanks to Sarah Higley).

Your Questions

• Why is the navigation use case different?

Because the link paradigm is as old as the web. Its AAPI mappings are known. arbitrarily trying to shoehorn them into a new OS-style menuing approach only creates risk if you don't have a user-defined problem you are trying to solve with it.

• The real question here I think is: what would need to be semantically distinct in a from in order to make suitable for the navigation use case? What's the real delta between these

One is links the other is not. One offers all the affordances of links and the other does not. This is assuming you plan to use ARIA menu roles and their AAPI exposure as the core of your proposal.

• @scottaohara mentions "they can make finding what youre looking for harder for screenreader users because you cant just bring up a list of hyperlink", but I don't fully understand this. Why can you just "bring up a list of hyperlinks"? In the non-navigation menubar case, we're certainly going to "just bring up a list of menuitems"—does that have the same accessibility concerns?

I posit you don't fully understand it because that's one minor argument. To your point, yes, you can convince screen readers to provide a mechanism to bring up a list of menu items. But given my answer above, it would need to be distinct because of the different affordances.

• Is it actually bad if developers manually navigate the page in response to clicks? This could be done

Arguably SPAs already do this. But users are confused and lots of jury-rigging has to happen to make them behave as if a navigation event happened.

• Multi-page app vs single-page app: I can imagine developers implementing SPA navigations with a normal menubar that responds to activations to swap in new content, since they don't need traditional anchor semantics. ...

Many already do this. And when built like an application, that works well.

... Is the "SPA use case" considered the same as the "navigation use case", and would it be a bad outcome if developers this?

When SPAs are used where users expect web pages, then they are not the same and outcomes can be bad.

... MPAs and SPAs have the same navigation intent: show new content to the user when they click something, but they do this very differently.

They do and they don't. MPAs move users to a new URL. SPAs keep the user at the same URL and swap content around (with varying levels of success as far as users are concerned).

... Is the "navigation intent" what's scary about the navigation use case? Or is it just the raw-anchor-tags-inside-of-the-menuitem MPA case that's scary about the navigation use case?

Again, this is not "scary". The concern is about mis-use of elements that can present barriers to users. Such as if it means redefining valid nesting behavior.

Overall Concerns

This proposal doesn't feel like it has engaged users most likely to be harmed by misuse. There is prior feedback from users already out there, much linked in this comment and Scott's.

This proposal doesn't seem to build on what hooks exist in AAPIs today (whether directly or via ARIA roles).

This proposal is not making accessibility a first principle. There are, IMO, too many DX-driven proposals of late that are getting traction without consideration for existing art, past history, or user experience. While this is a relatively new thing for you, I have literal decades of watching these efforts spin up, results in unintended harms, and then die on the vine (if lucky). Yes, I am allowing my frustration through on this point.

[yatil]

Thanks, Adrian, for putting this so clearly.

[aardrian]

Oh hey, there are 3 instances of "ARIA guidelines" in the explainer. Those point to APG patterns, which are not guidelines. Can you, at the very least, link to (the roles in) the actual ARIA spec?

I ask this because APG has encoded anti-patterns, has known of bugs, and only ever targeted ARIA purity. It was never meant to be a source of truth, despite its effort at rebranding itself as a ready-to-use pattern library.

If this team or readers are leaning on APG as a resource then that creates problems out of the gate.

[hidde]

Reading through the various comments and the 20 March minutes I'm very concerned we're wanting to move this too quickly. I want to specifically thank Scott and Adrian for their thoughtful comments.

The consequences for AT users seem underresearched, and we should be careful to look at APG for guidance here (+1 to Adrian's comment that APG was not meant as a source of truth; it has its uses, in addition to what he said it is also not holistic, nor user tested). Navigation in a menu would be a huge change to how things work today, it seems not impossible, but needs much more research and broader discussion around user and AT expectations.

Also, to have links in menus would orthogonal to what I and many others have been teaching developers for years, it might break developer expectations in addition to user expectations.

Though I get the idea of wanting links in a menu potentially… may I suggest for us to postpone further discussion on navigation in menus here until either:

• Concerning navigation "menus" (open ui related) w3c/aria#2510 has had more comments and/or discussion in ARIA WG?
• more research, eg into ARIA (not just APG), ATs, users, and how this could potentially become a thing

[css-meeting-bot]

The Open UI Community Group just discussed [menu] Navigation vs menu items use case, and agreed to the following:

• RESOLVED: We are right at the start of this menu element incubation. We are very much interested in input, and the design is very fluid at this point. Please help! And please don't assume the explainer's current state is somehow anything other than "draft". We are interested in feedback, including/especially if it means we need to change the proposal.

The full IRC log of that discussion

<keithamus> masonf: the rest of things on the agenda - we might talk about range at the end - but this is menu.
<keithamus> masonf: 1193 is the right place to minute these. I'd like to set the stage; a lot of the comments on the agenda have impassioned comments.
<keithamus> masonf: We've (domenic, di, joey) just started adding working on adding menu elements to the platform. I've seen comments around "Google is moving too fast" - we've just started, there's not a single line in chromium. Many of the issues raised are around accessibility and we're very interested in resolving these.
<keithamus> masonf: I am just wanting to appeal to the community around us moving too fast, we'd love actual input and guidance, expertise of the community. We're trying to do the right thing, raising the issues first.
<brecht_dr> q+
<keithamus> masonf: We don't have all the answers and that's why we're asking the questions first. We're appealing to the experts for help and we're willing to take on the guidance.
<scott> q+
<hdv> q+
<keithamus> masonf: there is an explainer - and as all openui explainers are - it is a living document. It is not done, not shipped, it is an explainer and we will evolve it as we get things right.
<keithamus> masonf: These comments are on every specific issue but we can talk about the meta issue first perhaps?
<masonf> ack brecht
<keithamus> brecht_dr: if it's about moving too fast - we're talking about an experimental implementation, Chrome canary first. We had the same concerns on stacks etc. An implementation may help to spot issues. I don't necessarily agree about moving too fast as long as it's in an experimental phase, more opportunity to test.
<masonf> ack scott
<keithamus> masonf: We're planning on an experimental thing but we haven't written a line of code yet.
<lwarlow> q+
<keithamus> scott: I'll assume the comments here are for the broader audience?
<keithamus> masonf: Yes, for sure!
<keithamus> q+
<keithamus> scott: I got the impression from the way this particular issue was filed was that I was in opposition. I'd like to restate that I've been trying to find a way to explain this, this is exactly the issue and the use case I tried to warn about as being contentious. I want to make it clear I am trying to help and put as much information as possible
<keithamus> scott: there are a lot of basic questions here. If there's anything that I haven't explained appropriately please let me know. There's a lot of fundamental stuff that needs to be taken into account. I linked to many articles in the original google doc.
<keithamus> scott: Hopefully that explains the lengthly responses.
<keithamus> scott: We were just talking about this in the ARIA WG and it seems there is appetite on this.
<keithamus> scott: more on that tbd.
<keithamus> masonf: we're doing a lot of reading. We're ingesting this.
<keithamus> dom4: I am also ingesting, the APG, blog posts, etc, this is exactly what we need at this stage - to discover the prior art.
<keithamus> dom4: Please bear with us and thankyou.
<keithamus> scott: I appreciate that, I am trying to be careful and respectful about this - the nuances are difficult. I can at least say for most people in this group, they want to do good things. I want to be very very clear that this is a contentious issue. This isn't accessibility people saying "you cant mix stuff, you have to use the right elements" and
<keithamus> so on. But there are also concerns around the specific use case. Users have complained about this, the APG pattern, and so on.
<keithamus> scott: Specifically menu navigations
<keithamus> scott: there are valid use cases for menu items that do link out to stuff, but how do we straddle the line of something we absolutely have to support, while also making the experience better for users who currently don't know how to navigate these webpages because developers used a menu bar which might not even exist on their OS.
<masonf> ack hdv
<keithamus> masonf: I was worried to see this because it has so much history, and the issues around the APG. It can be a very confusing document. A lot of chats with users - it was very confusing to them. Anyone who doesn't understand what APG is for - that is normal, it's not super clearly presented. I was slightly worried to see we'd follow exactly what was
<keithamus> there and it's good that we're not.
<masonf> ack lwarlow
<keithamus> s/masonf/hdv/
<keithamus> lwarlow: OpenUI is here to incubate things. We should be able to say "the sky is green" and validate that, let people tell us that it's actually blue. That's the process working.
<keithamus> lwarlow: It's a contentious topic and I expected that, but I think raising an issue on the ARIA WG to discuss it is exactly what we intend. It's a pattern people do, it might be a bad one, but it's worthwhile doing. Even if the result is "do not do this" - we can establish that.
<masonf> ack keith
<masonf> keithamus: a lot of the consternation comes from a11y experts spending a lot of energy describing these things, and usually a11y is something that's hard to get funding for. So many a11y experts use their "free time" to stop accidental bad things from happening. So my interpretation is that people are expending surplus energy to continue this
<masonf> debate, which they've already spent a lot of time already.
<masonf> keithamus: that extra effort might not have been appropriately recognized. There's a perception that coming in asking for "free advice" from people using their free time - that might be the issue.
<masonf> keithamus: one way to alleviate that is to consider this part of the due diligence on the budget required to implement this. E.g. maybe some of these people could be hired as consultants to help.
<keithamus> masonf: nobody else is on the queue, so let's actually discuss 1193
<keithamus> masonf: So the question is; there is a navigation menu, and a regular menu. Navigation to me means browser navigation - click a link, load a new page, MPA in the terminology. It does not mean SPA, I guess. Click a link and replace parts of the document. I think, naively, why or how that effects a user. Why does it matter if the browser does a full
<keithamus> document or partial document refresh.
<keithamus> q+
<scott> q+
<keithamus> dom4: That's one question we had, I learned from the thread. Maybe it's more of a discovery problem, picking up links inside a nested structure of menu items.
<keithamus> dom4: Before we make more progress on this issue I think we might need to do a lot more reading. This pattern is super common on sites: a site map, nested menus, sometimes small sites sometimes very large.
<keithamus> dom4: I think understanding why its controversial in the accessibility community is important so I think if all these answers are in the blog posts then I will consume them and I will know.
<keithamus> dom4: My gut sense is that maybe we can't progress on it until we read everything in the github thread.
<masonf> keithamus: I don't know about this either, but when I think about menus in applications, there's an ambiguity about what the button does. Often, clicking a button changes selected text (e.g. formatting buttons) or they might open a web page, or open a new document, etc.
<masonf> keithamus: those same ambiguities track into AT, so that'd be my reading.
<masonf> keithamus: those menus aren't the easiest to navigate via a keyboard, compare to traditional link navigation.
<masonf> ack keith
<masonf> ack scott
<keithamus> scott: This is a lot in the pre-read, but to summarise: the crux of a lot of the user issues around menus as navigations, a navigation pattern is understood. "I am in a nav element, I hear role navigation. I'm in a list I hear role list. When I focus a hyperlink I hear link. When I am in a menu of menuitems, I will commonly here I am inside a menu
<keithamus> but there is no distinction between menu items other than whether they can be checked or not.
<lwarlow> q+
<keithamus> scott: So when a menu contains menuitems that contain popups that contain menuitems, users lose the ability to use the features of their screenreader to find the list of links to navigate to. Menuitems aren't in that list, because they're not considered to be links. A list of hyperlinks is far easier to navigate in these, and it's a lot of how the
<keithamus> web is built
<keithamus> scott: Menus can make sense for more "app heavy" settings. But a complex app where there might be inappropriate use of widgets might be expected, but it might be more surprising to say, see a blog with menus. For a standard website we might break the way to interact with this, that users now need more work to do something that they used to be able
<keithamus> to do more efficiently.
<keithamus> scott: SPAs suffered the same problem but routing has made this less of an issue - there's more work they need to do but it becomes less of an issue now. So SPA vs MPA is not so much of an issue, it is more the replacement of roles such as hyperlinks with menuitems.
<dom9> q+
<keithamus> scott: It's more about roles, rules, expectations, discoverability. Not SPA vs MPA. Us being in the tech industry, are likely working with technical users of AT - and they have learned to deal with patterns that are less problematic for their experience level. Maybe something your coworker has no problem with might not be something that is
<keithamus> surmountable for a non-technical AT user.
<dom9> q?
<keithamus> scott: The issue comes with people misusing these patterns.
<masonf> ack lwarlow
<keithamus> masonf: hopefully the browser can do more with this pattern to expose such things
<keithamus> lwarlow: regarding navigation - we're all in agreement that a menu might have a single hyperlink that might do something, this might be okay?
<keithamus> scott: just quickly on that - there's no way to distinguish a menu item as to what it does other than how it's named. Someone won't know it's a hyperlink, but in the context of the application they're in they might make an expectation that it'll open a dialog or send them off to a help site. They don't know but they can reasonably deduce.
<keithamus> lwarlow: I guess on the other side of things, a nav with a list of links... what is the keyboard navigation? Is it expected to work with tabbing or arrow keys? My interpretation is that arrow keys shouldn't be allowed but I see a lot of sites that do this.
<keithamus> q+
<keithamus> scott: I was hoping we had more discussion about this. There are expectations that you can tab through some, or use arrow keys with roving focus, so you don't have to navigate through 10 hyperlinks of navigation, fewer tab stops. You'll get different answers talking to folks who are sighted users using a keyboard as to whether they prefer that or
<keithamus> not.
<keithamus> scott: There are problems with for e.g. focusgroup and hyperlinks. Some screen readers won't send users into forms mode where it turns off some functionallity to allow the scripted nature of these components. Screen readers like JAWS or NVDA - really all of them - have different modes like virtual cursor mode. For the hyperlink situation I can use
<keithamus> keys to navigate visited links or unvisited links.
<masonf> ack dom
<keithamus> scott: there are multiple different ways how folks use their screen reader to navigate in certain ways. If you want to know how to get to the, for example 5th item in this, you have to navigate through the DOM to find the menu, then use keyboard arrow keys to re-navigate to where you are, how many nested levels to traverse. All things a sighted
<keithamus> keyboard user has to do but they get a broader representation of the visuals on the page.
<keithamus> dom4: the big thing I hear is discoverability of anchors.
<keithamus> scott: at a high level yes. Part of why I brought it up in the ARIAWG. If we really want to do this we can't add type=navigation, that doesn't mean anything right now. Maybe there's a new menuitem role that's exposed as a hyperlink. Or beyond that maybe use traits (like on iOS) where a heading can also be a button or a menuitem that's also a
<keithamus> hyperlink. If that concept can be introduced and implement it can go beyond this menu component.
<keithamus> scott: this might quell a lot of concern of, e.g. buttons in headings
<keithamus> dom4: This is reductive but: Is this almost solved by allowing menus to have anchors - inside a menulist? That's the easiest way to trigger a navigation, so we can expose all the navigable menu items as actual anchor tags.
<keithamus> dom4: is something like that the idea here
<keithamus> scott: That's something worth at least floating by people.
<keithamus> scott: The way a lot of screen readers look at these patterns is expecting very specific things within them. Just putting hyperlinks in a menu would involve not just exposing the right stuff from the browser - which might not be that hard - but doing stuff screen readers never accounted for, and then each of these need to be updated to support this
<keithamus> new pattern.
<jarhar> q?
<jarhar> q+
<keithamus> scott: Outside of screen readers that are free, sometimes people might not be able to afford for the new paid upgrades. There's even reticence to upgrade as it might introduce bugs.
<lwarlow> q+
<jarhar> maybe a way that we could solve this without updating/changing screen readers is by exposing links inside menus in a separate copy of a nav-like thing in the a11y tree.
<lwarlow> <menuitem href> might be iffy from a security point of view.
<lwarlow> q-
<keithamus> scott: So we might say menuitem href= might expose a link, or menu with hyperlinks in it might not even use menuitems, but it's more about "thats the initial plan, what do we do after it"
<keithamus> dom4: you mention SRs expect things to be in specific containers - but these are new elements that SRs have never heard of before.
<keithamus> scott: No because menus have expected child elements which are only menuitems, if you were to nest other content inside of a menu JAWS for instance would pass over them entirely, you wouldn't find them in there.
<jarhar> luke, what is the security issue of <menuitem href>?
<keithamus> scott: if you could them and correct for them but then if you were navigating with a SR virtual cursor it would completely skip over it.
<keithamus> scott: You haven't gone into application mode so you might not even get to interact with it.
<keithamus> scott: Hyperlinks inside of menuitems - menuitems are already top level elements and you won't get insight into what's inside of them.
<keithamus> dom4: we might want to make the menubar have a navigation role inside of it? That would allow the user to interact not in application mode but in a way that JAWS wouldn't skip over it?
<keithamus> scott: For all intents and purposes let's just say thats right. It's a change in expectations. It's a much deeper problem.
<masonf> ack keith
<masonf> keithamus: Suggestion: use voiceover. Cmd-shift-F5 on Mac. Don't necessarily have to use tab key, the virtual cursor is there. The voiceover app has a web rotor. F8. UI that navigates a fixed list to look at sections of the page. Navigate all headings, all hyperlinks. Try it out!
<masonf> ack jarhar
<keithamus> masonf: with only 6 minutes left I had a suggestion for a solution - but let's finish the queue
<masonf> s/solution/resolution
<masonf> the "re" was important
<lwarlow> q+
<keithamus> jarhar: I like the idea of href on menuitems, as having them be a new thing, maybe not. In order to avoid changing screen readers or ARIA itself, in the a11y tree we generate, maybe we can pull all of the links out of menu and create a separate menu - it wouldn't exist in the DOM except in the menu it's in. So we could make it a generated nav, and
<keithamus> as the screen reader navigates the generated nav it pops open the visible menu in the DOM.
<keithamus> scott: that's got some complexities, maybe to discuss another day
<keithamus> scott: I know people might consider menus like megamenus a use case for this - but even then you have sections of content, even headings or images or paragraphs can be included in these megamenus.
<keithamus> scott: That's why some widgets have been created to take over these roles, there's a lot of stuff in there, I understand the want to use arrow keys to navigate it. It's much like the problems with select and the listbox popup and putting arbitrary content in there, people won't even know it exists they won't even be able to get to it because
<keithamus> they're in application mode.
<hdv> q?
<keithamus> scott: If we do go down this route, people might say "what about this use case" and we have to continue to expand support?
<masonf> Proposed resolution: We are right at the start of this menu element incubation. We are very much interested in input, and the design is very fluid at this point. Please help! And please don't assume the explainer's current state is somehow anything other than "draft". We are interested in feedback, including/especially if it means we need to change
<masonf> the proposal.
<lwarlow> +1
<keithamus> +1
<hdv> +1
<masonf> RESOLVED: We are right at the start of this menu element incubation. We are very much interested in input, and the design is very fluid at this point. Please help! And please don't assume the explainer's current state is somehow anything other than "draft". We are interested in feedback, including/especially if it means we need to change the
<masonf> proposal.
<scott> +1
<keithamus> lwarlow: If we add href to menuitem we may run into concerns from security, stuff like sanitizers....
<keithamus> dom4: I'm opposed anyway

[jscholes]

These minutes were very helpful. I wanted to call out one specific part from the discussion (as written).

dom4: Before we make more progress on this issue I think we might need to do a lot more reading. This pattern is super common on sites: a site map, nested menus, sometimes small sites sometimes very large.

(Not sure who dom4 is on GitHub to mention them, sorry.)

I think the word "pattern" is in danger of being overloaded:

• So-called "mega menus", with two or more levels of navigation, are indeed quite common on sites. While I'm sure there are opinions within the accessibility community about their usability, they are broadly accepted as a "design pattern".
• Marking up such mega menu structures with menu and menuitem roles (i.e. the accessibility semantics), and attaching the corresponding arrow key behaviour, are the aspects people are objecting to in this issue and the linked literature.
• To probably oversimplify: Design pattern fine, functional/semantic pattern not fine.

We already have suitable semantics for conveying multi-level navigation structures: The <nav> element wrapping an <ul>, where the <ul> contains links and/or expand/collapse (disclosure) buttons for controlling access to deeper levels. The deeper levels can then recursively follow the same <ul> plus link/disclosure button pattern, and it can even be appropriate to use popover attributes for the expand/collapse controls.

This existing approach is demonstrated in the Disclosure Navigation APG example already linked earlier in the thread:

https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/

It can also be seen on sites such as:

• https://humanrights.ca/
• https://nmwa.org/
• https://mcn.edu/

TL;DR: "Mega menus" as a navigational design pattern, and semantic menu markup as a functional pattern, are not the same thing.

[paulshryock]

We already have lists of hyperlinks for navigation:

<nav>
  <ul>
    <li><a href>Hyperlink</a></li>
  </ul>
</nav>

"menu" is a misnomer for this.