Back in March 2012 I wrote a blog post titled Accessible Dropdown Menus summarizing my observations with various accessible dropdown menu models, including Suckerfish, Son of Suckerfish, Superfish, Dropper Dropdown, UDM4, Simply Accessible, YUI MenuNav Node Plugin, and the Menubar widget example developed by the Open Ajax Alliance. Of all these, I liked the Open Ajax Alliance (OAA) example the best.
Here’s the original OAA menubar, and my customized OAA Menubar.
Over the last 21 months, my thinking has evolved a bit, aand I’ve done quite a lot of further experimenting. Since lots of folks have stumbled upon and are referencing my earlier tests, I thought I should post an update documenting how my thinking has changed. Here goes…
A website navigation menu isn’t exactly a menu
The OAA Menubar is an example of a widget with an ARIA role of “menubar”. According to the ARIA spec, a menubar is “a presentation of menu that usually remains visible and is usually presented horizontally.” And menu is a “type of widget that offers a list of choices to the user.” Further, “A menu is often a list of common actions or functions that the user can invoke. The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application.”
A website navigation menu is similar to a menu on a desktop application, but it isn’t composed of a list of common actions or functions; it’s composed of a list of links. Therefore role=”menu” or role=”menubar” may not be the best choice. Perhaps enclosing the menu in a container with role=”navigation” may suffice.
Also, if links are tagged with role=”menuitem”, screen readers no longer handle them as links. For example they don’t show up in the JAWS Links List dialog or VoiceOver Links list in the Rotor.
Should top-level menu items be links?
Since the first drop down menus appeared on the web, an accessibility workaround for inaccessible menus has been to ensure each top-level menu item is a link to another page where users can access the submenu content. This way, all users are sure to have access even if for any reason whatsoever they are unable to trigger or access a submenu.
Also, a number of developers I’ve worked with want to preserve those top-level links, not solely for accessibility purposes but because these links reference important pages in the overall website hierarchy.
I still very much like the keyboard model that’s recommended by the DHTML Style Guide and adopted by the W3C in their WAI-ARIA 1.0 Authoring Practices, and I think it should be generally applied to website navigation menus, even if these aren’t really menus.
However, since they aren’t really menus, I’m more willing to take some liberties with the recommendation than I might be otherwise. Specifically, the DHTML Style Guide restricts the role of the tab key to entering and existing the menu. In this model, once the menu has focus, the arrow keys, not tab, are used to navigate between top-level menu items. This might be fine for a menu of actions or functions, but since my menu is a menu of links, I think visible links should be accessible using tab, as this is how the Web has always worked and how users therefore expect it to work.
The new, emerging keyboard model should work too: Trigger submenus with Enter or Space, move through menus in all directions using arrow keys, close menus with Escape, press the first character of a menu item to jump to that menu item, etc. But while users are discovering or otherwise learning about these new improvements, their traditional methods for getting around will still work.
Adobe’s Open Source Accessible Mega Menu
In May 2013 Adobe unveiled its new navigation menu on adobe.com, along with a blog post titled Mega menu accessibility on adobe.com, which explained many of their accessibility-related design decisions.
Adobe’s menu is now available as an open source Accessible Mega Menu on GitHub.
I created a simple test page using Accessible Mega menu, and I like it! This menu meets all of the needs I described above.
The Role of ARIA
ARIA on the Top-Level Link
- aria-expanded=”false” (changes to true when sub-nav is visible)
ARIA on the Submenu container
- aria-expanded=”false” (changes to true when sub-nav is visible)
I’m not clear on whether the developers are intentionally adding aria-expanded to both the top-level link and the submenu. I think it probably only needs to be used once, but according to the ARIA spec, aria-expanded “indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.” OK, sounds from that like it could be either. But notice that the definition uses the word “or”, so as I’m reading that it can be either, but not both. Anyway…
This ARIA markup is a bit different from other examples I’ve seen. For example, the OAA Menubar Example that was once my favorite menu does not use aria-owns or aria-controls on the top-level menu item, and it doesn’t use aria-expanded on either element. Instead it uses aria-hidden on the submenu and toggles that between true and false.
Hans Hillen’s Accessible jQuery-ui Menubar is similar to the OAA Menubar, although it uses both aria-expanded and aria-hidden on the submenu.
So which of these implementations is correct? Do these differences suggest that ARIA is extremely flexible or extremely confusing? Of course, maybe we shouldn’t compare Adobe’s menu with these others because the others are in fact menus with role=”menubar”, whereas the Adobe menu is a navigation menu (not a menu). Apples and oranges.
The real question for me is: How well does the menu work with screen readers? On my test menu, JAWS 14 announces the top-level About menu item as “About collapsed has popup link”. After expanding the submenu, it repeats this same announcement but as “expanded” rather than “collapsed”. Interestingly, both NVDA 2013.2 and VoiceOver on Mac OS X 10.8.5 interpret the dropdown menu as a menu despite our having avoided menu-related ARIA roles. VoiceOver announces “collapsed menu popup link About” and NVDA announces “About collapsed submenu link”. When I click with NVDA, it simply says “Expanded”. Without doing usability tests, it’s hard to say whether screen reader users will benefit from all these words or just perceive them to be noise. I suspect it’s probably a little of both, but in my opinion we should provide enough information so that users can be clear what sort of widget they’re dealing with.
On Grouping Lists into Columns
My test menu isn’t really a mega menu. The example menu at the top of the Accessible Mega Menu home page is a mega menu: It includes paragraphs and multiple lists, each with its own heading. In contrast, my test menu’s submenus consist entirely of lists of links. In the About menu I experimented with dividing my list of links into multiple columns since I see a lot of menus that do this.
Multi-column lists present some unique challenges though. Unfortunately HTML doesn’t provide a way to group list items. The only child elements allowed inside a list element are list item elements. So, we can’t group our list items in <div> elements and position them beside each other if we want our code to validate. The Accessible Mega Menu home page includes example code for a simple menu of Movies and TV shows. In this example, a multi-column layout is attained within the the submenus by dividing each list into multiple lists, so that’s what I’ve done on my test page too. However, I don’t like it. Unless there’s a semantically sound reason to divide a list into multiple lists, a list of twelve items is a list of twelve items, not three lists of four items. This matters because when screen reader users expand a submenu they hear (for example) “expanded, list of four items”. If there are actually twelve items in the list, users might overlook the final eight items.
There are several possible solutions described in Paul Novitski’s 2005 article CSS Swag: Multi-Column Lists in A List Apart, plus a more recent possible solution on Stack Overflow.
But that’s a problem for another day.
3 replies on “Accessible Dropdown Menus Revisited”
Thanks very much for this update. The demo you’ve created using Adobe’s open-sourced code is actually really nice, and also something I’ve been looking for for sometime myself. There has always been trade-off, but this is nice. Thanks again.
I stumbled across your page by accident while trying to figure out what some of the strange terms on Facebook meant. So I’m not someone trying to design an accessible site. I’m a blind person trying to use Facebook and getting frustrated fast. I just upgraded to JAWS 15 (from JAWS 10), and I’m having difficulty finding relevant information about things like “edit collapsed has popup.” Um, it’s an edit field. Why does it need a popup, how to I take it from collapsed to expanded, and how do I figure out what else it can do, much less activate whatever has popped up? My point, for your purposes, is to say that I would say this kind of menu or nonmenu or whatever it is supposed to be is terribly confusing. I’ve been Googling for an hour trying to find something (from Freedom Science Fiction or anyone else) that would explain this information to me, and I’m coming up empty. Another example from Facebook is the Sort “menu” for my newsfeed. I can find Sort, but I’ll be damned if I can figure out how to reliably find the options, much less select one. If I’m lucky and the gods have smiled on me, I can turn on the JAWS cursor and with a little help from the heavens I can find “most recent” and click it with the mouse before it disappears. After about the tenth try, I can make it work … usually. So yeah, I’m going with confusing. Thanks for listening, and if anyone has any brilliant ideas for me, I’m at facebook.com/xyk75
You raise an important issue. The Web is becoming more and more complex, which places a burden not only on web developers to be sure they’re practicing accessible development techniques, but also on assistive technology developers to support these techniques in ways that make sense for their users, and finally on users, who unfortunately must learn to understand and navigate the Web amidst all these changes. This blog post was written with web developers in mind, but I appreciate the greater problem. It has to be tackled from all angles, and there clearly is lots more work to do.