WAI-ARIA menus, and why you should handle them with great care

The WAI-ARIA standard defines a number of related menu roles. However, before using them, please give great consideration to the implications.

Preface

This article was previously published under a different title and with a different tone. The comments below, left here for documentary and historic reasons, speak to that fact. At the time, it felt right to write it the way I did. However with some time passed and some reflection, it was time to update it to a more balanced tone and statement. Thank you to Sina and all others who voiced their opinion about that article being “out of character”, as they say. I needed some time to realize this myself, but better late than never. 😉 So here goes!

A bit of history

In the mid 2000s, people were arguing over whether HTML4.01 or XHTML 1.x was the better standard. Both markup languages had in common that they hardly knew anything about advanced widgets. However, such widgets were more and more asked for, by web developers around the world, but because standards processes were very slow, and browser vendors were not that many as today, things were moving too slowly.

So, web developers started wildly implementing these with div and span elements and style them to look like desktop counterparts. This was to create richer user experiences for their web sites which were slowly transitioning to what we today would consider web applications.

Back then, people were still using mostly desktop applications that had classic menu bars with dropdown menus, on operating systems like Windows XP. The Mac still knows these today, so do most Linux desktops. Windows, however, has moved away from them in modern applications. They are either gone completely, like in most Universal Windows Platform apps, or replaced by ribbon-style tabs and toolbars, as known from Office applications such as Word, Outlook or OneNote.

WAI-ARIA to the rescue

To somehow cope with the influx of new web experiences, the WAI-ARIA standard was brought to life by a group of very talented people, to map desktop concepts to the web, and give web authors the means to communicate to desktop screen readers what desktop equivalent of a widget was being created. Screen readers were thus given the information to deal with these widgets in a similar way as they would in desktop applications.

One set of widgets were menu bars, menus, menu items, and their siblings menuitemradio and menuitemcheckbox. These were to mimic a menu bar, menus that popped up from these, and the three types of menu items that Windows, Linux/GNOME and Mac knew about. Screen readers reacted to these menus the same way as for desktop applications. Because of a long history of no proper programming interface support, especially on Windows, screen readers had to hack together special so-called menu modes for applications, because technically, focus was in two places at the same time, or so it seemed. And there were a bunch of other problems and quirks.

One problem was that in browsers, such menus lived alongside the native menu bar the browsers had. And unlike that native menu bar, these menus acted like any other widget in that, properly coded, they did take focus and thus had a very unambiguous model. But screen readers still applied their mechanisms for dealing with menus to these, sometimes leading to situations where the closing of a menu would not be recognized, and new focus changes required the user to actually force the native menu open and closed once to get the screen reader back in check.

The important takeaway is that menuitem and friends provoke a very specific set of expectations within users and screen readers of a web application’s behavior. A menu can only contain menu items, for example, a menu bar only menus, and such. Also, the keyboard is expected to behave in a very specific way: A set of menu bar items is traversed from left to right (or right to left in RTL languages), menus are dropped down with Enter or DownArrow, the menu is closed with Escape etc.

The problem

Over the years, it has become very apparent that these concepts are, with the receding of menus especially on Windows, less and less known to people. Many web developers, despite the WAI-ARIA authoring practices having design specifications for these, unfortunately lack the context of this complex set of widgets and the expected interaction. One of the most common ARIA errors we see in the wild comes from improper uses of the menu roles. Often, menu items are used without proper menu parents, resulting in totally improper behavior by assistive technologies. A screen reader could get stuck in their menu mode, for example, because the web author doesn’t signal when a menu has been closed.

Generally, it seems that web developers read about these menu roles, and think a set of links within a list that may pop open another sub set of links is enough to warrant it to be called a menu. Well, let me put it bluntly: Nope. Because:

  • A link is a very specific widget. It brings you to another page. A menu item, on the other hand, performs an action within an application, or in the case of checkbox or radio item, changes the state of a certain behavioral component.
  • A menu item needs a menu as its parent, and that either needs a button as a parent that pops it open, or a menu bar that drops it down.
  • Users expect to navigate among menu items using the arrow keys, and not tab.
  • They also expect Escape to either close the menu or back them up a level.

In other words, if a web developer wants to use the menu item roles, they enter into quite a specific contract with their users and the browser that turns their code into properties the assistive technology of people with disabilities understand.

Likewise, a button that, when pressed, pops open a set of options or actions to choose from is often coded as a menu. While this is correct in principle, it, too, means that you have to use menu and menuitem, and the proper set of key strokes. It also means that you have to manage focus precisely. Up and down arrows navigate among the items, Enter executes, and Escape closes the popup menu and — and this is very often forgotten – returns focus to the button. This does not happen automatically, you as a web developer have to do this explicitly. Always. Deal?

But because of all these problems that screen readers have to deal with when it comes to menus in desktop applications, testing is paramount. Bring in users. See that you get different browser and screen reader combinations covered. While NVDA and Firefox might cope fine in an instance, JAWS may react differently, and where both JAWS and NVDA might cope well, VoiceOver might fall over, or any other combination of these. And Narrator, the new kid on the block on Windows, which now not only supports Microsoft EdgeHTML Edge, but also Chrome and the new Chromium-based Edge in Windows 10 May 2019 update and later, there’s one more screen reader to test. Good thing is, that’s one you already have and don’t need to download even. Trust me, I have seen them all over the years. And the only thing that keeps them reasonably in check is indeed proper focus management. Always keep track of where your focus is, and never assume the browser will manage something for you in this instance.

The solution

Think about your design carefully. Is what you’re building really a menu in an application sense of the word? Especially if you are building something more complex like a super menu, the answer is probably yes. If you are popping up a set of choices at the press of a button, it is, too. If you reveal a subset of links when a link gains hover and keyboard focus, or even better, gains focus and has Enter pressed on it, it, and the links in the sub list are probably not if it is just a top level plus one level down navigation.

Test your design with users by providing a prototype. Don’t be afraid to call for help.

And document your user interaction for those who actually have to use your application. This will not only help screen reader users who cannot see your design in full, but also helps keyboard users who might not be immediately aware that they’re dealing with a menu system.

One that doesn’t know about menus

And here’s another aspect that I intentionally left until last: Mobile doesn’t know about these old desktop concepts of menu bars and pull-down menus at all. So the user experience for such roles is even more unpredictable than on desktop. Buttons and links, on the other hand, are very well supported on mobile as well. Other pop-ups on mobile operating systems contain these normally, too, so this is a totally expected and consistent user experience.

So when you design your responsive application, be sure to also adjust what roles you might be using on mobile operating systems, and again, test, test, test, either yourself or by bringing in users who might be more proficient at certain assistive technologies. It is totally OK to not know everything and not be able to work every screen reader yourself.

An example

Here is a menu system that is well implemented and provides a useful means of navigation. But be aware, it is pretty hardcore in that it has two horizontal levels of navigation, and only from the second level you actually get full dropdown menus. The menu system starts below the search facility, and is introduced by some navigation hints for the menu. Go to The Morton Arboretum, tab to the menu system and start exploring and listening to what your screen reader tells you. If something feels weird, turn off virtual/browse mode. Thanks to Sina Bahram who provided me with this example of a good menu implementation.

Conclusion

This is one of those things that gets totally misunderstood by web developers who are not as experienced in the finer points of accessibility nuances, and their use of these roles is often misguided by thinking along the lines of “it’s a popup, or slide-out, has to be a menu”. The situation is quite similar to the potential misuse of the “application” role, which also isn’t justified by just the fact that a web application is being created. It does have its uses, but needs to be applied locally and with care, too, not as a blanket top-level attribute in almost all cases.

So as a TL;DR, I’d say: Think very carefully before using menu* roles, they’re quite volatile for historical reasons, and can cause more churn than a good user experience if applied the wrong way.

Advertisements

14 thoughts on “WAI-ARIA menus, and why you should handle them with great care

  1. Hello Marco,
    I respectfully disagree with you on this. As a screen reader user I find the menubar, menu & menuitem roles very helpful while constructing mega menus which we seem to see off late on most of the web properties. They are helpful in easy navigation & they are very intuitive. I agree it needs bit of learning on how to use them but once we understand they are easy to use. Developers need to be educated on how to use these roles & construct better menus, if we start discouraging them because some thing is complex then developers often say the idea of this whole web accessibility is complex itself…why don’t we build text only version as alternative.

    I strongly feel that as web accessibility practitioners & evangelists we need to focus on educating developers & designers….because something is complex & confusing we should not discourage them…

    Just my 2cents.

    Like

    1. Thank you for your comment! Here’s the problem I see with these mega menus. They are being implemented and are a barrier to many people besides screen reader users. In fact, if the menu roles are implemented properly, like on the example Sina gave me, screen reaer users are probably the only group that is able to use them. And even on that example, I am not sold. Here are the problems I see with it:

      The instructions provided are only visible to screen readers. They are hidden from sighted people who might want to try using this thing with the keyboard, so they have no clue about arrowing left and right through the top meu bar, dropping down a level with DownArrow, and on that level, having to use left and right again to navigate the sub menu bar.
      Speaking of that, this alone is confusing, since in other menu systems, you ordinarily open a dropdown menu from the menu bar, not a secondary menu bar like on the Morton Arboretum page. So even if you’re a screen reader user familiar with menus, which on Windows itself is no longer something you can count on reliably, this puts an additional cognitive load on people.
      And to make matters even more confusing, Escape steps back up all the way to the top menu bar. So if you’re in the actual sub menu, the one you drop down from the secondary menu bar, Escape doesn’t back you up to the previous level as you might expect, with things being symmetrical most of the time. But you are backed up to the primary one instead.

      Yes, a screen reader user is told all this in help messages. But the additional babble this causes in JAWS, for example, becomes quite unnerving, because in the default verbosity setting, you’re not only being told that help message over and over, but also the fact that you should press JAWSKey+Alt+R to read that help message, again, over and over.

      And I asked Mallory, who is a sighted keyboard power user, to test this one, too. Her response on Twitter was that she didn’t get these instructions and that using the arrow keys was indicated nowhere.

      In conclusion: While this particular mega menu is technically correctly implemented and uses all the menu roles correctly, the usability problems it creates are quite significant. It violates the “Do not make me think” rule in several places, see above.

      Like

  2. I was pretty startled when I read this. I really don’t agree with it, and I think following the advice can lead to a much less streamlined user experience. Many of our clients have complex menus for navigation, and they implement the roles correctly with arrow keys and enter.

    Like

  3. For example, a three-level navigation menu is the norm, not an exception to the rule, anymore, and to have that fully expanded or use a series of buttons is just completely unfair to a keyboard user VS a nicely talking menu system, IMHO.

    Like

  4. Additionally, from a keystroke perspective, we’re talking the difference between 5 VS 17 keystrokes to get to the same link with menus VS no-menus. These things behave like menus and are interactive. For sighted folks, they really are menu systems, why not for keyboard users?

    Like

  5. I just feel like there’s so much conflicting information on this topic, and you’re the person I like to send folks to when they need an argument settled, buddy, but I really don’t support this particular position. Just my $0.02, good sir. I do hope you’re doing well, by the way.

    Like

  6. Like I wrote in my blog post, there are situations where these menu roles are actually justified. That’s why I said they should not go away completely. It’s just, that I have seen so many wrong implementations, that I’d rather tell people to be cautious than to be bold.

    Like

  7. Interesting, and, I think, entirely fair. I don’t think we can deprecate them, for the reasons you expound quite clearly, but I am totally with you that they need to be understood better by developers and used properly.

    Every dev needs too close their eyes, or pop on a blindfold, if needs be, whack in some headphones, turn the screen reader speed to max and understand what the experience of their application is for users with restricted vision, and more project managers need to encourage it.

    Like

  8. Also, ARIA menus *must* follow the very restricted pattern specified in the ARIA spec. You can’t have a menu that is mostly a menu, but then includes something non-standard like a search box or where one menu opens a login form. As soon as you move beyond the “Windows 95” style menu paradigm, it’s unpredictable how browsers/AT will expose your non-standard bits. On Windows, once you’re in a real menu, AT will generally pass cursor keys straight to the page / disable reading keys…so if the “menu” contains anything else, it’ll likely be borked and AT users won’t even know / will be prevented from reaching the extra stuff. Incidentally, this is exactly why in Bootstrap I fought hard to remove any menu-related ARIA from the ready-made dropdowns, as authors use BS for all sorts of things that go well beyond straight menus.

    Like

  9. Marco, I agree we have some problems with ARIA menus in the wild, but find the tone of what you have written to be uncharacteristically negative and even damaging. I hope you might be willing to reconsider some aspects of it.

    You start with the statement:

    >The WAI-ARIA standard defines a number of related menu roles. However, in 99% of all cases, these should not be used.

    If I am understanding your problem statement correctly, you offer 4 primary reasons:

    1. Most developers who have used ARIA menu roles do not understand the purpose of the menu pattern. I agree with this point.
    2. Most developers who have used ARIA menu roles do not know how to correctly implement the pattern. I agree with this too.
    3. Screen readers and browsers do not provide consistently good quality support for the ARIA menu pattern. This is also mostly true.
    4. Due to the design of modern windows and mobile apps, fewer and fewer screen reader users have good understanding of menus. I am not sure I agree with this.

    After making these points, your solution statement is:

    >The solution is plain and simple: Generally, don’t use menu, menuitem, menubar, menuitemcheckbox, or menuitemradio.

    And:

    >In my opinion, these menu* roles should be deprecated in WAI-ARIA 2.0

    So, while I agree with 75% of your problem statement, I do not understand how you get to the conclusion that we should try to phase ARIA menus out instead of fixing the problems with them. It implies that you believe the benefits of menus are not worth pursuing. You almost imply that menus do not offer significant user benefits.

    When I look around the GUI world, even on native mobile, I see menus everywhere. Screen readers themselves do not shy away from them either. In fact, every desktop screen reader uses menu bars and menu buttons extensively in their own designs for both commands and navigation. While modern Windows programs do not use menu bars, they still use popup menus. That said, I haven’t met any screen reader users who prefer MWPs.

    I see plenty of evidence that menu buttons and menu bars, as well as other GUI patterns, offer all users, including screen reader users, significant benefits. That topic in itself is worth a blog post. And, for that reason, solving the problems that plague not just the ARIA menu roles but nearly all the ARIA roles is essential to creating a web that is as efficient, effective, and enjoyable for screen reader users as it is for other users. This is increasingly important as the trend for web content still leans toward being more and more like native software, making browsers more and more like operating systems.

    The problems you cite are readily solvable. We are on a path to making ARIA rendering by browsers and screen readers as reliable and robust as CSS rendering. We need that. Web engineers developing GUIs need to know that it is possible to write code that will work. The days when some users get tripped up over web GUIs because they fall apart in browser X with screen reader Y are numbered. I am commited to helping lead the accessibility and web engineering communities toward realizing this vision.

    To fix the problems with ARIA rendering by browsers and screen readers, we first needed reference examples that are both consistent with the intent of the ARIA specification and reliable. That is where the ARIA Authoring Practices Guide (APG) comes in. The APG task force started first by working on getting people to agree on correct ways of building these patterns and developing reference examples of them. It took a few years, but the current version of the APG finally has about 25 patterns with 60 examples. While they will always be a work in progress, the vast majority of them have been well-vetted by the community and are in a reasonably stable state.

    To help ensure the trustworthiness and reliability of the example library, we just completed building out a regression test suite that tests every ARIA and keyboard requirement documented on the example pages. We have an ava.js suite that runs webdriver integrated into our CI. This will help us move considerably faster and with more confidence as we work to keep improving the quality and breadth of the example library.

    So, we finally have ARIA examples that can be used as reliable test references. And, we have a growing community of people scrutinizing their accuracy. We can always use more people, especially engineers, who can help with the bug fixes and improvements aswell as adding more examples.

    We are next kicking off a project to publish assessments of screen reader and browser support of the APG patterns — something akin to a CanIUse for APG patterns. While this is a tricky and somewhat risky project, I have managed to gain W3C go-ahead. the repository is w3c/aria-at. There is nothing there now, but there will be before the end of the year. My near term goal is to experiment with assessment methodologies and approaches on 10 patterns in 6 or 7 combinations of browsers and screen readers. Menu buttons will definitely be in the first 10.

    While I agree that a huge portion of ARIA is not rendered reliably for screen reader users as well as users of other assistive tech, and I agree that misunderstanding of ARIA has wreaked much haboc, I do not agree that the way to make the web more accessible is to condemn one of ARIA’s important and beneficial patterns to a deprecation heap. Or, failing that, advising people to completely ignore it unless called upon by some unknown outsider.

    So, I hope you might consider revising this post to be more constructive. You could help people understand the problems that are caused when they use a technology they do not understand. The first principle we state in the APG is that no ARIA is better than bad ARIA. That is the first thing everyone needs to understand. You could also help people understand how support for ARIA is immature but improving and that there is work underway to radically speed up its maturation process. Perhaps you could convince some of your audience to chip in and speed up the solutions.

    In terms of offering advice to web developers, it would be helpful to explain the types of things they must understand to make a menu that works well. And, for those who are not ready to do that, offer some alternative patterns. For example, one alternative is to use the disclosure pattern instead of a menu button. Then, they do not need the Javascript to support arrow key navigation. However, if you are going to provide the arrow key Javascript, I would argue that it is best to go all the way and correctly use the menu button pattern. When done well, it really does work.

    For now, I agree most sites would be wise to use an alternative to the menu bar pattern even if it really is the pattern that best reflects the site’s functionality. There are at least some problems with every screen reader’s ARIA menubar experience. They can be used, but they will trip up some users until those problems are resolved. So, a series of disclosures or menubuttons could be used instead.

    By working together, we can solve the problems that are inhibitting fabulously accessible GUI experiences on the web (both desktop and mobile). Until those problems are solved, we need to help people understand how to use ARIA in the ways that best serve their audiences. That definitely includes discouraging incorrect and inappropriate use of menu roles. It definitely does not mean discouraging appropriate use.

    If anyone reading, especially if you are a web developer, wants to help the ARIA authoring practices task force solve these problems, please drop into the APG repo and let us know. Or, you can just email me (a11yThinker at gmail). You can find the repo at github.com/w3c/aria-practices.

    Like

  10. I wonder if a tree paradigm could be used instead of a menu paradigm. Tree roles work well, and as long as the keyboard navigation is correct, things will probably work well in modern browser / screen reader combinations.

    Like

Share your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.