Totally agree that:
- the menu and menuitem roles are used incorrectly more than they are used correctly.
- We need to put a stop to incorrect use!
- For a simple list of links, and for most site nav, they are not the ideal pattern.
The point of the ARIA practices is to promote correct use and thus help eliminate incorrect and damaging use.
However, none of that means that there are never situations where site nav isn’t massively more accessible to a broad set of users, both sighted and blind, both mouse and non-mouse, by implementing either the menu or menubar pattern.
There is a lot more to say on this topic. But, it is important to keep in mind that:
- There is no single design for nav that is best everywhere.
- A primary objective of ARIA is making accessible web-based GUIs possible.
- GUI elements do not have to be limited to traditional desktop purposes.
Matt, when you sayThe point of the ARIA practices, I am assuming you are referencing WAI-ARIA Authoring Practices 1.1. I think it’s a great document and I reference it all the time in training, documentation, etc.
As a result of referencing it so frequently, I also have heard back regularly that the menu pattern in particular is confusing and, for those who read the ARIA spec itself for menus, confuses the issue. It is what led to me filing an issue in April to adjust the language describing the pattern, yet not suggest change to the code.
As for your points:
- Completely agree
- I also agree, except the plain HTML pattern I outline above is already accessible and does not need ARIA. In fact, adding it has, in my experience, made menus less accessible.
- I agree GUI elements do not have to be limited to desktop mimicry, and I think ARIA live regions are a great example of this. I think the ARIA menu pattern, however, should be limited unless there is a hell of a lot of testing saying otherwise.
I generally avoid absolutes in my blog posts (and titles), but in this case I feel my advice is appropriate. Plenty of practical (and anecdotal) experience supports this. There are always exceptions, but I’d rather someone has to make a damn good case for it.
This is a very timely post, as I’m currently working on a project where I evaluated that the menu design pattern was appropriate. But now I might need to reconsider it.
I was, indeed, misled by the WAI-ARIA Authoring Practices document, that implicitly validates the use of this pattern for navigation menus, through its examples. My starting point was a burger menu, and when trying to find guidance on broadly agreed keyboard behavior, I felt the menubutton pattern was a solid ground for this, especially because the document provides an example of a menu button for a navigation menu… And while I was at it, I went through the whole pattern and duly documented how to properly implement all the roles and attributes for that — even the roving tabindex algorithm. And the devs actually, and properly, implemented it. Doh.
The story does not end here. This burger menu is, in this responsive design website, just the narrow-screen version of a more classical menu (fixed list of links). Of course I didn’t intend that the menubutton/menu design pattern also applies to the wider-screen version, but since the ARIA stuff is embedded as static HTML, it’s still there, no matter how wide is the viewport.
I feel rather angry about this document now, because it really is deceptive on this matter (also, note that the so-said nav menu example is actually faulty in many ways: its code is utterly flawed, keyboard navigation doesn’t work with VO on Mac… the list of issues is telling). And slightly angry at myself for not reading the whole list of open issues for the document — but hey, who would go through this, frankly?
I used to think that the published W3C documents were reliable enough. I understand this is a working draft, but since it’s online, shouldn’t it be more carefully reviewed? And when additional resources, such as these examples, are evidently flawed, shouldn’t they be discarded until they are fixed?
Ok, now time for a difficult message to the devs who struggled with this pattern…
Thanks for this post, though, you probably avoided me more trouble in the future!
Olivier, on one hand, I am impressed that you made a menu pattern that conforms to all the requirements outlined in the draft ARIA practices document. At the very least, save that pattern in your library!
On the other hand, I feel your pain. I wrote this post because I have seen that very thing happen too often, and heard the frustration from clients in user testing when users have no idea how any of this works nor why their regular method of navigating sites is broken on this one.
Draft documents can be dangerous for those not steeped in the standards process. It’s how we got people advocating for all-
<h1>pages because they believed the Document Outline Algorithm was a real thing before it even made it into a final spec (which it did not).
Hi Adrian, I am glad that you raised this point. I have been following this guidance because it was in the ARIA Authoring Practices document. I see value in having the site navigation be a single tab stop on the web page with arrow keys for navigation inside it for increased efficiency. Unfortunately, the trade-off for that is that users have to become trained to understand that new interaction model. I am glad you have logged your thoughts with the document as ultimately I will implement and train others based on what becomes the established practice.
Thomas, unfortunately the current Authoring Practices document is a draft. The 1.0 version is… hard to find.
I understand the potential value of having the menu as a compound widget (one tab-stop on the page), though I am always wary of any assertions about ease of use or efficiency barring usability testing with the target audience. Especially since this pattern is not extant on the web, and primarily only in installed applications.
All that being said, I look forward to clarity from the document and consistency across the web. Please feel free to weigh in on the open issue as well, since the loudest / grumpiest voices should not be the only ones represented.
Hey, great read, just a quick one, you’ve misspelt Bootstrap in the second last paragraph under the title “Really, This Is a Thing”
“Tutorials often get it wrong, such as the always useless W3 Schools in its Bootsrap documentation. Not that Bootstrap is off the hook”