How Can I Create Accessible Navigation Menus on Websites?

There are many types of navigations including dropdown, mega-nav, slide out, etc. Meeting accessibility first starts with the capability of being keyboard navigable. Making sure that the tab key and arrow keys navigate the menu including drowdowns, and pressing space or enter actions the link is a majority of the need here. 

Quick reference: 

• Navigation capable through tabs and arrow keys
• Focus shows up on links when highlighted
• You can select the link by pressing enter or space
• Your color contrast is readable
• The HTML provides the right ARIA attributes and role

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.

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.

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"

Screen Reader Support

Screen reader users might choose to navigate to the menu using their screen reader's landmark shortcut key (e.g., semicolon in JAWS, the letter "D" in NVDA). When they do so, their screen reader will announce "Navigation Region", along with a name of the landmark if one is assigned (e.g., using aria-label). On each of my example menus, I've added aria-label="Main Menu", so JAWS (for example) announces "Main Menu Navigation Region".

From here, users will draw from their knowledge or experience in deciding what to do next. They might press down arrow to enter the menu, or they might press tab. Either way, I would expect their screen reader to announce that they've arrived on a menubar or menu, and to provide some meta data about that menubar, such the number of top-level items it contains. JAWS currently provides a more user-friendly experience than either NVDA or VoiceOver, although I only tested the latter in OS X Snow Leopard - I haven't upgraded to Lion yet. In JAWS, when a top-level menu item has focus, JAWS announces the name of that menu item, and announces that it has a submenu. It also says "To move through items press the up or down arrow". It only does this once per menubar widget, assuming it doesn't need to repeat itself with such a simple instruction. Overall, the interaction with the menu using JAWS is easy and intuitive, at least that's true of the YUI and custom OAA menu. Curiously, JAWS doesn't recognize the Simply Accessible Menu as a menu. Users can navigate through this menu with the tab key, and JAWS announces all the menu items as links. However, if users attempt to use the menu's supported keystrokes, it just doesn't work. Since the Simply Accessible Menu is coded very similarly to the others, I think these are probably just bugs rather than problems in design philosophy. The takeaway: Whichever menu you choose to implement, be sure to test carefully using mouse, keyboard, and if possible, multiple screen readers.