Accessibility has been in the news quite a bit recently, and with good reason. As more people get online, it’s important to make sure that your website is accessible to people using screen readers and other adaptive devices. In many cases, not meeting accessibility standards can garner lawsuits, fines, and bad publicity. More importantly, creating accessible websites makes good business sense and shows all of your users that you care about them. In Part 1 of this post, we covered the basics of accessible menu navigation. In this post, we dive into the specific area of multi-level navigation.

Multi-Level Navigation for Content-Rich Websites 

Typically, content-rich sites that have hundreds or thousands of pages on a site require an elegant way of nesting content so that layouts are clean and intuitive. In order to do this, it is necessary to use multi-level navigation.

Multi-level navigation, with flyouts or accordions or any number of other methods for showing additional levels is so common, it is the default for what you may think of as a menu. Common as they are, multi-level navigations are also often created in a manner that makes them inaccessible if you’re not approaching the menu with a mouse and good vision. A lot goes on in a menu, and context, behaviors, and readability can all be major issues. 
For example, every developer’s first instinct is to use a hover at the second levels. But, how do you trigger hover from the keyboard or other non-pointer device?  Enter?  If so, then what opens the parent link? Double enter? Is that intuitive? What about for mobile? As you can see, hover creates more problems than it solves, and not just for accessibility, but also for usability. 
So how do you fix this? First, it’s important to understand that there are certain expected behaviors for specific keypresses in keyboard navigation. Knowing this will help you plan your menu behaviors. 
A typical multi-level menu will have several things that need to happen: 
1.    A way to follow links 
2.    A way to show child links that are hidden initially 
3.    A way to move through links 
4.    A way to close the menu 
We’re familiar with how all these things happen with pointer navigation – click, click/hover, move your pointer around, and click/hover outside the menu, in that order. But how do you make that work for the keyboard? 
1. Following links is easy – hitting Enter will do that for us.   
2. Showing child links is trickier, since you want to avoid hiding behaviors behind a double enter or some other unexpected action. To solve the issue of a link with children pulling double duty as both drop-down trigger and link, you can add a button (this shouldn’t be a link) beside the link (a down carat or a +; make sure it’s big enough to tap and has an aria-label clearly explaining what it does) that acts as the drop down trigger. Or, you can wrap the text itself in a button to use as the drop-down trigger and move the link into the dropdown.  

This can require some skill in naming. For example, the Harvard Library’s “Collections & Exhibits” trigger opens out to show a link to Collections and a link to Exhibits. Both of these methods have the bonus feature of working well in touch devices as well, and you can write the code to open the trigger via Enter and Space, as well as potentially the down arrow or left arrow as appropriate in context. 

Harvard Library website menu navigation, accessibility

3. Moving through links can be as straight forward as retaining tab behavior (typically in accordions, or when simply always displaying all links) or as complex as adding up and down arrow behaviors to move through lists of child links. What’s important here is to remember expected behavior. If you’re curious about typical keyboard menu behavior, try using a native menu in your operating system of choice – this is what you’re trying to emulate. 
4. Closing the menu is actually pretty easy as well – just make sure Esc is wired up to close it up and move your focus back to the trigger. 

Announcing a Menu 

Think about how you know a menu is a menu when visiting a website. Iconography, location, orientation – all these indicate the presence of a menu. Now consider the same site from the point of view of someone using a screen reader. How can they know that a menu even exists? 
In Part 1, we discussed about using landmarks to make it clear what certain parts of the page did, and that header, footer, aside, and nav are all used in conjunction to make it clear that navigation is there and easy to find. But what about the multi-level menu’s child links? There’s no way to tell that the triggers are anything but a button with text without a little additional work. 
Therefore, it’s necessary to find a way to describe to an individual who can’t perceive that a menu is a menu that there is something more hiding beyond the trigger. The Web Accessibility Initiative's Accessible Rich Internet Applications specification (WAI-ARIA) provides the key. ARIA attributes exist specifically to add semantic context to the page, and include options for a number of interactive elements, but the two we’re interested in for menus are aria-haspopup and aria-expanded.   
Aria-haspopup makes it clear that activating the element it’s on opens something – like a submenu, or a hamburger menu. Screen readers will read these items off as a pop-up, and depending on the value of aria-expanded, will tell if it’s currently open or closed. Clearly, this takes some Javascript to manage, but since most of today’s menus already involve scripting in some manner, it’s generally a quick add to toss the appropriate aria values on there while you’re opening and closing the menu. As a general warning, be careful of ARIA – a little goes a long way

Navigation on Mobile Using Alternative Devices

Believe it or not, your mobile hamburger menu (and all other menus) need to be keyboard navigable too, but not navigable by the on-screen keyboard as that would be odd. Instead, mobile users use plug-in alternative pointing devices that behave a lot like a keyboard, so the expected behaviors are much the same as mentioned above.

Successful Implementations for Wider Adoption

Multi-level navigation that is accessible to users on all devices including assistive technology is critical to meet accessibility standards. Meeting accessibility standards goes beyond merely avoiding fines and punitive damages; it opens your website up to a larger user base and indicates that your business is user-centric, creating solutions to make accessing your site easier and more effective to everyone. 

Is your website accessible? Do you have a content-rich site that has a lot of menus and submenus? We’re happy to answer any questions you may have about creating accessible websites. Reach out via twitter or email.