open-ui
open-ui copied to clipboard
openui
[menu] Navigation vs menu items use case
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?
- The real question here I think is: what would need to be semantically distinct in a
- 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
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 :)
FYI - I've opened an issue for the ARIA working group to consider the menu navigation use case. https://github.com/w3c/aria/issues/2510
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?
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:
- 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>. - 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"?
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.
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
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
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.
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.
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:
- https://github.com/w3c/aria/issues/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
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
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
menuandmenuitemroles (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.
We already have lists of hyperlinks for navigation:
<nav>
<ul>
<li><a href>Hyperlink</a></li>
</ul>
</nav>
"menu" is a misnomer for this.
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hey everyone, we're revisiting this issue—the navigation use case—after having made more progress on our prototype and requesting WHATWG stage 1 consideration.
I wrote up https://docs.google.com/document/d/1Xg3nOWABOHMrYFyAc7aYOtpmeo6_dPE1Sdfxu9AQG1g/edit?tab=t.0#heading=h.7h03hljdagg8 and added everyone's email address on this thread that I have as a collaborator, and agenda+'d this issue so we can discuss. But please feel free to engage on the doc! It tries to summarize the issues with using role=menu for navigation menus, and has a bunch of very specific questions that should help us create something that mitigates the accessibility issues here.
@domfarolino I'm sorry if this sounds petty, which is not my intent, but I am struggling with the file a bit. Partly because Google Docs are accessibility quagmires, but also because of highlight and text contrast issues. I can get through it, but for broader participation from the very audience this proposal can most impact, it will need some updates (contrast is a good first step, and a non-Google-Doc option is a better second step).
That aside, with all those embedded "Question for experts," where are you soliciting answers? As comments? Inline (with author name/date)? Something else? Pretend I don't use Google Docs.
@aardrian
with all those embedded "Question for experts," where are you soliciting answers? As comments? Inline (with author name/date)? Something else?
Seconding this question. As a screen reader user, I will find it relatively difficult to keep track of the conversation if people are free to comment/edit in multiple places. Not least because I get notifications from GitHub about the convo here, but not for people making changes to a separate thing.
I would suggest either:
- Linking to a read-only version of the doc and having comments added to this GitHub thread; or
- just pasting the content in a GitHub comment here and moving away from a separate doc altogether.
@aardrian No worries, thanks for your patience! I've updated the contrast on all of the "Questions for experts" parts, but if you have other places you'd like to see contrast changes, please let me know or propose them in suggestion mode.
That aside, with all those embedded "Question for experts," where are you soliciting answers? As comments? Inline (with author name/date)? Something else? Pretend I don't use Google Docs.
Docs comments would be great. But since you don't use Google Docs, I've converted the doc to markdown, so feel free to leave comments on: https://gist.github.com/domfarolino/794086908fcd7c207bf8575d66282daf.
I've been following this issue for a while because I'm interested in a "menuitem that navigates", but it seems like the discussion is focused almost entirely on the "primary navigation menu" use case.
To better understand this specific case using an example, consider a File menu within a desktop-like web application, containing a few items: New, Open, Save and Download. Of these items, "Open" and "Save" will open a dialog or perform an action, but "New" and "Download" are ideally implemented as links. This is because I want the "New" menuitem to open a new tab and the "Download" menuitem to link to a downloadable resource. Today, I would code this menu as roughly:
<div role="menu">
<a role="menuitem" href="/new" target="_blank" tabindex="-1">New</a>
<button role="menuitem" tabindex="-1">Open</button>
<button role="menuitem" tabindex="-1">Save</button>
<a role="menuitem" href="blob:…" download tabindex="-1">Download</a>
</div>
(assume that the tabindex will be updated dynamically in response to keyboard events)
There are many other valid cases where it is desirable for a menuitem to perform a navigation (sometimes even to a different website, as in the case of a "Help" menuitem within a mixed menu).
The problem is that the menu elements in their current proposed form do nothing to help with this, and require using workarounds which would otherwise not be necessary if implementing the same pattern using ARIA.
My hope is that these valid cases for "menuitems that navigate" are given more weight than the "navigation menu" use case. The former can help make the web a more capable platform for building complex applications, while the latter is very much an anti-pattern, especially when used in content-focused static websites.
The Open UI Community Group just discussed [menu] Navigation vs menu items use case, and agreed to the following:
RESOLVED: separate explainers into application menu and navigation menu; produce mechanisms to highly discourage/forbid the use of anchor tags inside menu* elements; Do NOT introduce <menuitemlink>; support one-off navigations inside application menus via JavaScript/related things
The full IRC log of that discussion
<masonf> domfarolino: We revived the nav menu discussion. Lots of documents, and more clarity on the problem, as I understand it. And people can correct me.<masonf> ...links inside a role=menu cause screen readers to go to virtual cursor mode. So keyboard controls that control application menu will be overridden.
<masonf> ...another problem: menu items aren't traditional links, and navigate on custom click handler. Bad for discoverability.
<sarah> q?
<masonf> s/menu items aren't/menu items that aren't
<masonf> ...other proposal in my doc tries to figure out if a menu is trying to be a navigation menu, and fix the role to navigation
<masonf> ...some discussion of that also being a bad idea.
<masonf> ...adding menu style keyboard functionality to navigation landmark link containers might also be bad.
<masonf> ...trying to thread the needle and make this work.
<masonf> ...is that a fair summary?
<sarah> q+
<masonf> scotto: yeah, I think so. Menu patterns derive from OS menus. For the last N years, it was expected that menu items would be inside them.
<masonf> ...variable results for inserting a link inside a menu.
<masonf> ...keyboard interactions are different. Links are supposed to be part of document flow. So virtual cursor mode happens.
<masonf> ...but inside a menu (NVDA, JAWS, narrator, etc.) will turn off that behavior, and assume you're using arrow keys for nav.
<masonf> ...existence of links in those menus likely go unnoticed, depending on whether links focus themselves.
<masonf> ...it's a strange thing to do.
<masonf> ...what about a link to a help page? That's a use case for a menu item being a link.
<masonf> ...let's just make people use javascript to do that.
<keithamus> q+
<masonf> ...use case for a menu is to do things, not have links.
<masonf> ...and use Javascript to make the links work.
<masonf> ...by making menu navigations a thing, that opens the door to fix the problems that come with that.
<masonf> q++
<masonf> qq+
<masonf> ack +
<masonf> domfarolino: we see this pattern a lot. Nested panels of navigation links.
<lwarlow> q+
<masonf> ack mason
<Zakim> masonf, you wanted to react to a previous speaker
<flackr> masonf: There's 2 cases, 1. primarily app menu and one or two random links, 2. a navigation menu where everything is a link
<masonf> thanks flackr
<masonf> domfarolino: AT handles those differently
<flackr> masonf: I think the container's role is different in those cases
<masonf> sarah: if you have a one-off link, it should be a menuitem (button) whose JS navigates
<masonf> sarah: I agree with Mason that these are different use cases
<masonf> scotto: the problem use case is the one where you stick a link in an application menu.
<masonf> scotto: the mega-menus in the doc are wrong. People are making them incorrectly. Those are navigation menus with links.
<masonf> ...It's definitely an anti-pattern to stick links into a role=menu element.
<masonf> ...use <nav> for navigation menu. We could help fix that use case. Let's focus there, without getting menus involved.
<masonf> ...we keep conflating these two, but we don't need to
<masonf> domfarolino: I thought the problem was that developers are sticking navigation links into menus.
<masonf> ...I thought the concern was that solving the menu use case makes this more prevalent, then great.
<masonf> ...if we just don't want to support that, then that's easier.
<masonf> ack sarah
<lwarlow> ```css
<lwarlow> menulist > a {
<lwarlow> display: none !important;
<lwarlow> }
<lwarlow> ```
<lwarlow> UA style and bam?
<masonf> sarah: you have a point. It's not that common for developers to use aria menu role. If there's a new element that makes something that looks like a navigation menu, then yeah people will start doing that.
<bkardell> lwarlow: should it be `a[href]`?
<masonf> ...if we add something like a <menuitemlink> element. Pretty common use case. Perhaps we wait to do that, but it's something we could do maybe.
<masonf> ...some people will abuse this. Not sure what the best way to prevent them. Best way isn't to make hybrid nav/menu.
<masonf> q+
<masonf> domfarolio: can you clarify hybrid?
<masonf> sarah: I thought you were proposing an attribute that says "this is for navigation" to allow links or something?
<masonf> domfarolino: proposal was glorified <nav> with keyboard handling
<masonf> sarah: element that has keyboard handling with the addition of focusgroup, popover, dialog for popups, etc. So you're proposing something that ties it all together?
<masonf> domfarolino: yes, that's the proposal. hover triggering, popover activation, all that built-in.
<masonf> sarah: just remove role=menu and role=menuitem with a <nav> menu. If the proposal is just something that wires behaviors to <nav>.
<masonf> domfarolino: yes, just the APG
<masonf> sarah: yeah maybe the APG makes it confusing. Just don't use menu roles for navigation menus.
<masonf> scotto: I read that wrong also. I thought this was just <menu*> elements.
<sarah> masonf: in the proposal there's a new menulist and menubar, for app menus. For the moment let's say no links allowed, full stop
<sarah> masonf: second part of the proposal, nav element. The existing thing, wiith maybe an attr to opt in. It can contain links, not menuitems. We'd like to add is a behavior that comes with the proposal for menulist and menuitems. Hover over something, popup, focusgroup, all that stuff. But build that in to nav, with links, to have that behavior so they
<sarah> don't need to build that themselves
<sarah> q+
<lwarlow> Isn't the keyboard navigation "menu" focusing behaviour difference? Because they want to tab it not arrow key it?
<masonf> scotto: there will be a problem where some sites implement the new thing, and others that don't, it'll confuse users. Maybe send a signal to screen readers to tell them.
<masonf> domfarolino: would require screen reader support?
<masonf> scotto: yes, likely
<masonf> ack masonf
<masonf> sarah: as Scott said, there are still things to iron out, but it seems iron-out-able
<masonf> ...I've done a bunch of user studies on this. People have opinions about role for navigation menus, but have tree type keyboard behavior.
<masonf> ...strong feedback. Links for things that are navigations.
<masonf> ...arrow key behavior between links doesn't seem to impact screen reader users. They're not generally tabbing. Non-power users use {browse?} mode.
<masonf> ...forms mode sometimes is used. Need to tell them that arrow keys exist.
<masonf> ...that's simpler than you think. Should just be a notification that "arrow keys are a thing here".
<masonf> ...questions about sighted users - how do they know?
<masonf> q+
<masonf> ack sarah
<masonf> ...probably more user studies needed. But seems fixable.
<lwarlow> qq+
<masonf> domfarolino: some opt in that gives you menu behaviors without menu* roles, like nav with focusgroup.
<masonf> scotto: this is a workable thing. I'm only against including links in menus or still using menuitems in nav menus.
<masonf> domfarolino: if we go new route <navigationlist> we shouldn't touch <menuitem>. Get better keyboard experience but with links in these elements.
<masonf> ...but need notification to screen readers that arrow keys work
<keithamus> ack lwarlow
<Zakim> lwarlow, you wanted to react to sarah
<keithamus> ack lwarlow
<masonf> lwarlow: can I suggest that since there's approval for application menu stuff. We should forget links entirely.
<masonf> ...we have approval for that. It fits into ARIA nicely. Famous last words: should be easy!
<masonf> ...it'd be valuable if the menu proposal is that.
<masonf> ...even ok to make UA styles make contained links invisible inside <menulist> and <menubar>
<masonf> ...separately make a new document for the separate navigation list proposal.
<bkardell> +1
<masonf> ...here a <nav>, with an opt-in, gets fancy behaviors.
<masonf> +1
<masonf> +1 but we think both of them are very important. Half the menus we see in the wild are navigation menus.
<masonf> ...a big part of the contention is that a big part of the <menu*> proposal mentions navigation, and alarm bells go off.
<masonf> ...make separate documents, separate proposals, keep it clear.
<masonf> ...scare fewer people because it's clear.
<masonf> ...don't block menu* on navigation stuff
<masonf> keithamus: devil's advocate: not always up to the developer - architectural constraints about whether something navigates.
<masonf> ...if you build a traditional desktop app - you might need to navigate to get e.g. a print dialog.
<masonf> ...not necessarily stylistic choice.
<sarah> q?
<lwarlow> window.open() right? Like we can navigate via JS?
<masonf> ...if we put this in front of developers. Need clear guidance on how to build it.
<sarah> q+
<masonf> ...end up in the same situation as <select> because design systems need something it doesn't do.
<masonf> ack keith
<masonf> ack mason
<lwarlow> q+
<keithamus> masonf: +1 to splitting, but I think both are equally important. We've seen a lot of navigation menus on the web
<keithamus> masonf: To Keith's point having both... there's a point that it's more than stylistic, but that's why we need both proposals. There's not a lot of platform guidance on what to build. "If this is your set of elements, then this is what you need".
<domfarolino> q+
<masonf> sarah: clarify: navigation menus is separate menuitemlink
<keithamus> q+
<masonf> domfarolino: maybe not a new link elemen t
<masonf> sarah: I agree that having menu item in application menu that can link you - that's an important use case.
<masonf> ...many developers don't get the difference between application menu and navigation menu, because both use "menu".
<masonf> ...worry about linking application menu item like <menuitemlink> because they'll just use a ton of those.
<masonf> ...good use case
<masonf> ...there are privacy and security implications, but can't we add a direct JS way.
<masonf> ...right now you render a link and click on it via JS.
<masonf> ...if there was something easy to do in JS
<lwarlow> https://developer.mozilla.org/en-US/docs/Web/API/Navigation/navigate - you can navigate right?
<masonf> ...isn't there an easy JS way to navigate?
<keithamus> ack sarah
<masonf> keithamus: navigation API or history.pushstate
<masonf> lwarlow: navigation.navigate()
<masonf> sarah: concern is whether we need a new menu item that navigates out of the box
<masonf> domfarolino: planning not to introduce <menuitemlink>. Write JS if you need to do that.
<masonf> ...avoid a new element that triggers navigations.
<bkardell> +!
<masonf> lwarlow: +1 to not introducing new link element
<bkardell> +1
<masonf> ...likely DOA.
<keithamus> ack lwarlow
<masonf> ...onclick has a number of easy ways.
<keithamus> q-
<masonf> domfarolino: I like the discussion and direction. We're happy separating them. Application menu and navigation menu.
<dbaron> I think the oldest navigate-from-JS technique is probably `window.location = url`
<masonf> ...to support one-off navigation menu - are we comfortable triggering navs via JS, so we don't support embedded <a>
<masonf> ...?
<masonf> {lots of +1's on VC}
<masonf> q?
<masonf> ack dom
<lwarlow> proposed resolution?
<masonf> Proposed resolution: separate explainers into application menu and navigation menu
<lwarlow> +1
<bkardell> +1
<domfarolino> proposed resolution: separate explainers into application menu and navigation menu; produce mechanisms to highly discourage/forbid the use of anchor tags inside menu* elements; Do NOT introduce <menuitemlink>; support one-off navigations inside application menus via JavaScript/related things
<bkardell> +1
<lwarlow> +1
<masonf> RESOLVED: separate explainers into application menu and navigation menu; produce mechanisms to highly discourage/forbid the use of anchor tags inside menu* elements; Do NOT introduce <menuitemlink>; support one-off navigations inside application menus via JavaScript/related things
@domfarolino I was able to work with the Google Doc. I left my notes as comments, following the lead of existing comments. I tried to honest and frank in my responses, so they may feel more biting than intended (I am a fan of letting frustration show through instead of wordy reframings).
I also think @mayank99's comment about "menuitems that navigate" versus "avigation menu" is the reality you're looking to address and I don't believe your document makes that distinction.