Accessible Dropdown Menus Revisited

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.

As we have progressed in our ability to create accessible menus, this need may be less relevant, but I still think it’s a good idea. There might still be some user who for whatever reason can’t trigger the dropdown menus (e.g., no JavaScript). A top-level menu item provides a gateway for them to access submenu content, even if not presented in 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.

Keyboard Model

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

Since a website navigation menu isn’t really a menu, we don’t use ARIA roles like “menubar”, “menu”, or “menu-item”. However, we still want to communicate the relationship between the top-level menu item and its submenu, as well as the submenu’s current state. Toward that end, Adobe’s menu includes the following ARIA markup, all of which is added using JavaScript (since without JavaScript, our dropdown menu would just be a non-interactive nested list, so none of these states and properties would be relevant):

ARIA on the Top-Level Link

• id
• aria-haspopup=”true”
• aria-owns=”id_of_subnav”
• aria-controls=”id_of_subnav”
• aria-expanded=”false” (changes to true when sub-nav is visible)

ARIA on the Submenu container

• id
• role=”group”
• aria-expanded=”false” (changes to true when sub-nav is visible)
• aria-labelledby=”id_of_top_level_link”

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.