by Matt May

 Comments (2)

Created

May 31, 2013

Creative Commons Attribution 3.0 License

Content in this blog post is licensed under a Creative Commons Attribution 3.0 License. Example code provided is licensed under Adobe’s Creative Commons Plus License.

Editor’s note: Recently, the adobe.com site switched over to a using a mega menu for global navigation. Adobe accessibility engineer Michael Jordan worked closely with our web team to build a menu system that brings great accessibility to a very design-sensitive site. Here, Michael explains his approach.

While mega menus, in many flavors, are fairly ubiquitous these days, thanks in part to the thumbs up given to them by Jakob Nielsen in his 2009 article Mega Menus Work Well for Site Navigation, we had a hard time finding many good examples for accessibility.

We think our approach strikes a decent balance between user expectation for global navigation, keyboard navigability, and screen reader access, and we felt that others might find it useful if we shared some of the thinking that went into our choices.

The adobe.com mega menu, with an item selected by keyboard

Our first major decision in implementing our Adobe.com mega menu was to respect user expectations for global navigation. As an accessibility engineer, it’s tempting to want always want to implement the appropriate WAI-ARIA design pattern for the widget I’m developing. In this case, working on a menu, I looked to the WAI-ARIA Menu or Menu bar (widget) design pattern which describes the keyboard interaction and WAI-ARIA roles, state and properties for a list of links presented “in a manner similar to a menu on a desktop application.” This would seem to fit the bill, but it’s somewhat problematic when implemented in its entirety for global navigation.

The design pattern specifies that the menu be treated as a single stop in the tab order, after which the arrow keys move between the menu and submenu items. This is the way application menus behave in desktop applications, and it improves accessibility for keyboard users because only one tab key press is required to move from the menu to the next focusable element in the application. However, for global navigation, we feel that most users still expect to be able to tab to at least the top level links in the navigation, and that the discovery of a jump in focus from the second link in the site to the search input, skipping all other top-level navigation items, could be confusing and would require unnecessary explanation.

Our implementation permits tab focus on each of the six top-level menu items. When one of the menu items has focus, pressing the Enter key, Spacebar or Down arrow will open the submenu panel, and pressing the Left or Right arrow key will shift focus to the adjacent menu item. Links within the submenu panels are included in the tab order when the panel is open. They can also be navigated with the arrow keys or by typing the first character in the link name, which speeds up keyboard navigation considerably. Pressing the Escape key closes the submenu and restores focus to the parent menu item.

The menu bar design pattern defines WAI-ARIA roles, state and properties. Some of these are also problematic when used in global navigation. If we use role=”menu” for the menu container and role=”menuitem” for each of the links therein, assistive technology will no longer interpret the links as links, but instead, as menu items. It is common for users of assistive technology to use a shortcut command to open a list of links in a web page. This allows them to quickly find a desired link without hunting through all the other content on the page. It’s a killer feature. If we use role=”menuitem” on links within our global navigation, they will no longer show up in the list of links identified by assistive technology. Cue the sad trombone.

We also want to maintain the semantic structure of the submenu panels in our mega menu, our links are organized into lists and separated by headings. Omitting role=”menu” and role=”menuitem” for the global navigation seems the safer way to go.

We still make use of the WAI-ARIA properties aria-haspopup, aria-owns, and aria-expanded to indicate which top-level links open submenus, the relationship between a link and its submenu, and the current state of the submenu.

We hope you find this useful, and we welcome any suggestions or comments you may have on the global navigation mega menu or other accessibility-related issues with adobe.com.

COMMENTS

  • By steve faulkner - 8:04 AM on June 1, 2013  

    be great to see the menu script available on github!

    • By g. bradford - 4:53 PM on June 18, 2013  

      I second mr. faulker’s comment!