Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarify Purpose of Menu Navigation #353
I am seeing more and more cases of authors who believe that web site navigation menus must be marked up with the ARIA menu role and adhere to the ARIA menu pattern.
In challenging developers to identify where that recommendation comes from, they have pointed to this document. This document does not explicitly state that standard web site navigation should or should not follow the pattern. The overall document implies that many (most?) of these patterns are for custom widgets that should behave as their native analogues.
This confusion is also fed by a linked example of a web site menu at the end of the section:
If the example is truly worthy and accurate and represents an exceptional departure from the menu pattern as one for applications, then it should be stated as such.
I feel strongly that regular web site navigation should not be treated as an application menu, nor should it follow the pattern outlined here. At least not without a really good reason.
Supporting this, nowhere does the HTML spec say that ARIA is necessary for site navigation, nor do any instructions for using the
I feel even more strongly, however, that this document needs to add clarity in the pattern description about when it is appropriate to apply this pattern. Here is the opening paragraph with some suggested language in bold:
Thank you Adrian for bringing this up.
Just so we’re all looking at the latest version of the “Navigation menubar example”.
I agree that using
Can you expand on that? As far as I know, using the native
@aardrian what I meant with “more complete keyboard support” is the ability to use the arrow keys to navigate the navigation menu. That doesn’t requires a bunch of ARIA to achieve as that can be done with JS. However, it does raise the question how you communicate that such features exist.
A similar issue arrises when I finally get to breadcrumbs with one tab stop. There’s currently nothing that tells a user that it has only one tab stop and that you should use the arrows to move through it.
No. For JS we test with various AT and browsers but do not require “best practices” if that makes sense. For CSS there’s the CSS-a11y TF.
<w3c-hat type="off" title="Commenting as a private citizen :-)">
I, too think that regular site menus should not use ARIA application semantics and keyboard navigation.
My basic decision tree is: If the menu items are links to other pages (including AJAX trickery), don’t use aria menu. If every menu item in the menu carries out an action (copy, paste, new document), use aria menu.
The WAI tutorials try to make that distinction similarly in the menus tutorial (some minor updates have been added but not published).
I would not expect this pattern to ever be used for a primary navigation, where the purpose of the nav was to bring people to different pages / sections of a site/app, and think that the purpose of this role/pattern needs to be called out more explicitly, as @aardrian proposed.
added this to Do Later
in Menu, Menubar, and Menu Button patterns and examples development project
Aug 14, 2017
referenced this issue
Oct 23, 2017
referenced this issue
Nov 28, 2017
I agree with the sentiment here. A list of links is a very understandable construct for simple list of navigation items..
That decision tree suggests that authors use ARIA widget roles to describe the purpose of the elements rather than their interaction model.
Of course, you can decide to draw any lines you wish around what types of functions you think belong inside specific widgets. That is a design call that has nothing to do with ARIA. If opening a different page is a function you wish not to put inside of ARIA menus, you don't have to put that function into an ARIA menu.
But, please, regardless of the function of an element, never use the menu role unless the element to which you apply it behaves like a menu as described in the APG menu pattern. And, always use the menu role if the element acts like a menu as described in the menu pattern.
The one certainty I see in this topic is that it is not black or white. A UX design is not necessarily good or bad based only on whether it uses ARIA menus for some of its navigation functions. It could be horrible or excellent or somewhere inbetween. You have to evaluate the total design.
David, Thanks for using a button there. I have often seen people make a disclosure that operates with a link, which is not what a link does. A link moves your focus to a new location ... not show/hide or perform other functions.
HOWEVER, please do not use
FWIW agree, unless it's a desktop-like application menu, don't use the full-on ARIA menu when a simple disclosure widget plus a series of links will also work just fine and not break some user's expectations that they can just TAB to links etc rather than having to work out they can only use arrow keys.
one caveat there would be that for AT users, you'd likely be competing with their AT keys (and I hope the answer here won't be to use
In my opinion navigation structures should not use role menu. Role menu forces AT into a certain mode as does role of application and this can be problematic especially when other elements exist in a navigation structure such as headings. In my experience role menu constructs can also be problematic in some mobile situations as well because they expect certain keystrokes. The ARIA example from the W3C incorrectly uses these roles for navigation despite the good advice from the WAI tutorials project not to use these roles.
Definitely not the application role. If you are creating menu behaviors, then you need to use the menu pattern and its associated roles. That is the best way to serve all users, especially AT users.
Again, the purpose of ARIA is to describe the accessibility features you provide. The most important principle here is to use ARIA accurately. If you create something that walks like a duck, be sure to describe it as a duck. Generally, it is also really smart to make it look like a duck too, but there are some situations, e.g., a person that is doing a duck dance, where looks are secondary.
To re-emphasize two earlier points:
Agree that you definitely do not want to put headings inside of menuitems!
However, if the purpose of a particular navigation design is to provide features like arrow key navigation, typeahead, efficient hierarchy, etc., then you really want the AT users to automatically get the mode switching. So, design first, then use the ARIA that describes the design. For instance, consider the bookmarks menu in most browsers. If you want to provide that type of experience, then you will need the ARIA menubar pattern.
Sounds like an implementation issue as I am pretty sure that the menu pattern roles are reasonably supported for touch interfaces.
Please elaborate? Which example is incorrect? What aspects are incorrect? They are admitedly complex and there are still improvements being made as you can see from the APG menu project.
APG has a pattern that explicitly refers to itself as web site navigation. The APG menu pattern at no point explicitly states that it is for application-level menus. This original report is to address that. The current description is so broad that a developer could take it to mean that it applies to web site navigation, while what I think you are saying is that if it has the behaviors you suggest it should get a menu role.
I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role. Which I think is probably a good idea, as the menu role is for application-style menus.
That is not strictly true. I am avoiding spec quoting since this is its own rabbit hole, but that assertion is a bit simplified. Certainly
You have described a native application control. Which is fine, as that is what the menu and menubar roles are for.
I am not sure anyone is arguing against those points. Or even raised those objections.
To re-emphasize my original point:
I think @mraccess77 is talking about the examples in the APG, though I leave it for him to clarify. I can tell you, however, that these do contradict the WAI Tutorial, which he referenced: https://www.w3.org/WAI/tutorials/menus/
Regardless, to bring this back around to the original issue — I provided suggested text to amend the menu pattern description. Is that text acceptable to you? What do I need to do to it to have it accepted?
nah, what patrick was suggesting was in response to @MichielBijl's suggestion of NOT using the menu pattern (so using, say, expand/collapse disclosure widgets which then open up and contain a series of focusable elements like links) but including additional cursor up/cursor down functionality anyway (mimicing the ARIA menu keyboard handling to an extent, while also allowing regular tab/shift+tab). and i pointed out that doing this will work for non-AT keyboard users, but that for AT users those additional keystrokes won't work as they'll compete with AT reading keys. (and then imploring that hopefully the plan then isn't to suppress THOSE via
I have provided below the menubar example from the ARIA 1.1 AP examples. While this menu looks like an application it really feels like it is meant for navigation.
@aardrian, It feels like we are talking past each other. I'll restart and try to discover where I am getting off track.
I see three primary points raised in your first comment:
The third point is purely editorial. It is low hanging fruit. So, as you suggested at the tail end of your last comment, let's start there.
And your proposed revision is:
Would the following be sufficient?
Note: keep in mind that the first occurrence of the word "menu" is a link to the ARIA spec for the menu role.
If we can come to consensus on the APG description of the menu pattern, I think it will help with one of the disconnects propagating through this thread and beyond. Specifically, there are several different meanings of the term "menu" being invoked. This problem is exacerbated by the fact that we have multiple WAI resources that use the term "menu" in very different ways. The ARIA spec and APG use "menu" in a narrow sense whereas the WAI tutorial is using it in a very broad and generic way. I agree 100% with the sentiment that it would be helpful to create more harmony among these resources.
With respect to your first point, your original comment acknowledges that the APG does not tell people they should use the menu pattern for navigation. It does say they can, but it does not say or even imply they should. Along these lines, even though we have not yet completed issue #89, "Draft site navigation guidance section that addresses choosing among structures, disclosures, menus, grids, toolbars, trees, etc.," I hope that all the following would disavow the idea that the APG dictates use of the menu pattern for site navigation:
For that matter, it is important for everyone to understand that the APG is informative, not normative. As an editor, I am pretty maniacal about avoiding language and phrasing that could be mistaken as normative. I have been working on getting rid of even the non-normative uses of the words "should" or "must"; a few do remain. Further, the APG uses present tense language that purposely does not make the author the subject of active phrasing, e.g., "the element has role x" instead of "Authors should use role X on elements that".
Your second point, which has been the focus of most of this thread, is more complex and subtle. Perhaps one approach to making headway is to answer the question, "Why does the APG include examples of navigation widgets that implement the menu, tree, and grid patterns given that there are so many seasoned professionals who have raise legitimate concerns with using ARIA widgets for navigation functions?"
I'd like to address the second aspect of that question first -- why does the APG seem to be silent about many real-world consequences of utilizing ARIA widgets?
While silent about specifics, the APG does acknowledge a couple classes of problems with real-world use of the patterns. The first link on every example page is to the Browser and Assistive Technology Support section of the "Read Me First" section of the guide, which starts with the paragraph:
The fact is that every browser/assistive technology combination has its own unique set of ARIA support dead spots where it does not yet accurately and effectively render the experience represented by the ARIA. This spotty rendering of ARIA is one of the root causes of the practical problems generating concerns about wrapping up core site functionality in ARIA widgets. The APG is meant to be a canonical resource that can serve as a foundation for improving this situation. That is why the "Read Me First" also says:
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem. To that end, the scope of the APG task force also includes a project for assessing the experiences provided by assistive technologies for each pattern, i.e., a "CanIUse" type of resource for the patterns. Acting on the assessments will be part of ARIA working group collaboration with assistive technology and browser developers. I am spinning up that project now and hope to be sharing those plans as part of our presentation at CSUN.
So, the goal is progress toward a time when ARIA is so beautifully rendered that assistive technology users everywhere are clambering for web-based versions of all their native apps. This is realistically feasible. Bringing all the accessibility advantages of native GUIs to web GUIs is exactly what ARIA is designed to do.
The nascent accessibility advantages of web GUIs that have fabulous keyboard support and work really well with assistive technologies are the reason the APG includes examples like the navigation menubar. These advantages are well proven by GUI widgets that support navigation in native apps. Native apps have long been very effectively employing widgets, such as menubars, trees, toolbars, and grids, for navigating everything from libraries of books and file systems to email folders and screen reader help. Apps that do so are strongly preferred by assistive technology and keyboard users over apps that force the user to tab through every single element or memorize arcane keyboard shortcut schemes.
Admittedly, there is a lot of work to do to get to the point where we can transform any web GUI into something that is as enjoyable and efficient for people who rely on keyboards or assistive technologies as it is for the typical mouse user. Not all of that work is specific to ARIA. For instance, another gaping hole is the common lack of visual design features that reveal keyboard affordances. Even though that is not an ARIA-specific issue, since it impedes adoption and value realization, it could someday become something that the APG task force helps address.
It is worth emphasizing again that the APG is not suggesting that navigation should or should not be designed in some specific manner. However, if you choose to use an ARIA widget, such as a menu, it is providing best practice for implementing that widget. Whether or not the menu pattern is a good choice for a particular navigation feature on a particular site depends on many factors, some of which are beyond the scope of the APG. We will attempt to address the in-scope factors when completing issue #89.
It is true that the APG does not attempt to limit the uses of the menu pattern to functions other than navigation. That is intentional.
The APG is also saying that if a widget "has the behaviors you suggest it should get a menu role."
As an aside, because of the following remark, I would like to highlight changes we made to role application in ARIA 1.1 that have not received much attention.
That idea is inline with the original concept behind the application role, but that type of use created more problems than it solved. Consequently, after considerable deliberation, we made significant changes to the definition and description of the application role in ARIA 1.1. The new definition is:
The description also says:
In other words, people should not wrap ordinary ARIA widgets in an application. Just use it to make interactive experiences that can't be made with existing ARIA widget roles.
moved this from Do Later
to In Progress
in Menu, Menubar, and Menu Button patterns and examples development project
Feb 23, 2018
@mcking65 Would you entertain changing the items in this example https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html away from a navigation bar to something else like an email application?
@mcking65 , I have been on the road for the last 6 weeks, so I appreciate your patience with my response time.
Yes. That would work for me.
Agreed. However, lack of clarity in the description (which is addressed in our proposed language) and a linked example of site navigation using the menu role (which @mraccess77 has asked you to change) has been read as endorsement of that model. In my experience conducting training, and most recently from a speaker at CSUN, many APG readers do not do any of the deeper digging that your paragraphs (above) offer. They see the APG as a cut-and-paste-ready pattern library (right or wrong).
I think me opening this issue suggests we are generally aligned
Most of the rest of your comments are beyond the scope of my original issue, but I want to address this:
I feel that this statement makes an assertion that is not backed by data. In other words, I think you may be wrong in many cases / for many users.
I agree that for technically savvy AT users it is true. In my own years of usability testing, most users are not that tech savvy, and your statement does not bear itself out. Navigating a native tab menu, tree grid, menu bar, etc., relies on arcane commands to many. Shift + F10 is handy for power users who already know this from native platforms. As more and more AT users (with restricted finances) move to a mobile-only computing environment, with apps (and desktop applications) that are deployed solely through a web UI, reliance on native platform understanding is less and less valid.
This is, of course, anecdata from my limited research over a decade or so with hundreds of users in different testing environments (a drop in the bucket of users). But it is not a blanket assertion as you are making.
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem… by educating practitioners about how developers and users are actually using the advice we provide.
In case it's helpful, I opened #633 to try to address:
The idea is to encourage authors to pause before jumping into a pattern, because maybe there's a perfectly good, accessible, native way to accomplish the task.
Pretty sure @mcking65 would appreciate a pull request for #633, if anyone has the time.