2 features for usable-accessible megamenus

I believe that most organisations hold one of two common views of what implementing web accessibility means. The first is that making content technically accessible to assistive technologies (AT) is enough to ensure an accessible experience. Although this isn’t a bad place to start it’s a strategy that falls far short of the mark.

The second view includes an understanding that technical accessibility by itself is not enough, and that a designers goal should be to produce a usable-accessible experience for users of AT. It goes without saying that I believe in the second view.

So, when designing implementing a megamenu, providing a usable-accessible navigation experience for users of AT poses some tough design challenges.

Considering the kind of users who may visit your site you’ll find that some users may have perfect sight but be unable to operate a mouse, while some may have partial sight but be able to mouse effectively and others may be completely without sight and thus restricted to a screen reader an keyboard-only navigation.

Ensuring a usable accessibility solution for this audience requires that we first understand the usability issues the a conventional megamenu design will present to people in this group.

For sighted, mouse-capable users, interaction with a megamenu may be a component in the process of achieving a task, be it seeking a definite article of information or completing a transaction. For example, on a local authority website: Pay a council tax bill, or, find out about local recycling programs. Observing a sighted, mouse-capable user interacting with a mega menu the user journey may appear to be:

• Based on their goal, the user will decide which top level item will most likely lead them towards achieving their goal.
• They will move their mouse cursor to that item. They may understand from a triangle graphic that hovering or clicking the item will disclose a dropdown men. Regardless, the act of hovering over the item shows the user’s intent to explore the content beyond the menu item.
• After a short timeout the menu panel will be disclosed, and the user will see that this has happened.
• Pre-attentive visualisation and Gestalt principles of perception define that even before the user begins to scan the panel they will already have perceived that the content of the menu is grouped into distinct areas.
• The user will begin to scan the menu for a link that will most likely allow them to proceed further towards achieving their goal. They may initially scan the category titles then move onto scanning links within a specific category, but it’s most likely that they will scan only part of the menu and click the first link that appears to be a good bet.
• If the next page seems relevant to their task they will continue to scan headers, local navigation and associative navigation within the page for the information they require or a link which will take them further towards their goal. If they find page is not relevant to their task the user may click the back button or re-open the initial menu panel and chose another link.

For many disabled users the actual user journey will be the much same as it is for sighted users. But unless care is taken, a technically accessible implementation may not be provide the same level of usability the visual and interaction design affords to non-disabled users.

For instance: The HTML of the menu items and panels will be coded in a way that places the links in the menu panel directly after its parent top-level item. For sighted users this isn’t a problem, the panels will be hidden until they show the intent to open them. Yet for keyboard-only users this best-practice coding will result in having to tab through every sub-item in a panel before they eventually reach the next menu item. Imagine having to press tab more than 100 times in order to reach the menu item form the Recycling section – what would that feel like?

Although without a doubt this experience would be tedious and frustrating for sighted keyboard-only users, imagine further that a completely blind user wouldn’t actually know the Recycling menu item existed until they reached it and the link was read aloud by their screen reader. In a list of 100-plus links, the single word ‘Learn’, isn’t going to mean much. A sighted user would see that Recycling is a top level item, a screen reader user would not. They will not have the benefit of visual design to help guide their decision making process.

A solution to these usability issues is to provide users of assistive technology the same affordances and experience the visual and interaction design provides to non-disabled users – but in a format that can be communicated through AT.

Lets look at two features which would help out our the users of our megamenu.

Feature 1: Screen reader-only content

A sighted user can see the top level menu items are top level menu items, and see that they belong to a group of top level menu items that that form the global navigation bar. A sighted user can see that a menu panel has been disclosed. A sighted user can see that the menu panel is organised into categories and that links are children to the category.

These same affordances can be passed to screen reader users by providing screen reader-only labels that describe links, and and add cues to help them explore the megamenu.

Consider these examples of what needs to be read aloud to clearly translate the context, which the visual design otherwise provides, into a format suitable for screen reader users.

Item type	What is visible	What is read
Top-level menu item	Waste management	“Waste management. Top-level menu item”
Category header	Recycling	“Managing your portfolio. Menu category”
Category item	Recycling programmes	“Recycling programmes in Camden”

So, navigating the Learn section with a keyboard and a screen reader would sound like:

• “Waste management. Top-level menu item”
• “Household waste. Menu category”
• “Collection schedule”
• “Removal of bulky items”
• “Disposal of chemicals”
• “Recycling. Menu category”
• “Recycling programmes”

And so on.

The additional content should not frustrate returning screen reader users, as many will only listen to the full text of a link if they are unfamiliar with the interface. New users will listen to the full link and description, users familiar with the interface will listen to only the first few syllables before clicking or skipping the link.

Feature 2: Enhanced keyboard navigation

Enhancing keyboard navigation can help improve the navigation experience for keyboard-only and screen reader users who would otherwise have to tab through the full contents of menu panels to reach the menu item beyond.

The solution is an enhancement rather than an override of what would be expected behaviour. This is important as overriding expected behaviours would result in an unpredictable experience that could ultimately confuse and frustrate the very users the solution was designed to support.

So, as would be expected, focusing on the first menu item will disclose the associated menu panel and pressing the tab key at this point will move focus to the first link in the panel.

The enhancement comes into play by allowing users to move the focus directly through items by holding shift and pressing the left and right cursor keys.

Two key requirements which will help make this enhancement discoverable are:

• The functionality must be explained in the accessibility help section of the website.
• The functionality must be integrated into the spoken labels. So the browser would read, “Waste management. Top-level menu item. Press tab to explore, or shift plus cursor right for the next menu item.”

This enhancement is becoming more common on the web. High-profile implementations of this behaviour can be found in the tabbed dialogs of Microsoft Windows and Apple Mac OS X. On the web it can be seen in an ARIA enhanced tab menu on the Yahoo! homepage.