Accessible drop down menus

A main navigation menu with expandable levels is compact, gives users an overview of all pages, and allows them to quickly reach a specific page.

An accessible dropdown menu can be used by anyone: with the use of a mouse or other pointer (even if they have less control over their movements), a keyboard, a screenreader, with voice recognition software, etc.

Ideally, an accessible dropdown doesn't get in the user's way: the user shouldn't be forced to display it, or to tab through all of its elements by keyboard when they don't need to.

General recommendations

• Don't confuse a dropdown list (select, combobox) with a dropdown menu. In a navigation menu, the submenus consist of lists of links.
• Don't use the menubar, menu and menuitem roles for navigation menus: these roles are meant for application menus of the type toolbar. They override the present semantics in the HTML-code (lists, links) and complicate the interaction for screenreader users.
• Structure the menu correctly in HTML:
  • Wrap everything in a nav-element
  • Structure the menu as a list with one or more nesting levels. The submenus will automatically follow right after the button that controls them in the source code
  • Use links to navigate to a page and buttons to control a submenu
  • Avoid all unnecessary ARIA-attributes, as they can cause clutter and confusion: aria-haspopup, aria-owns or aria-controls are not necessary
• Ensure that the focus is visible while tabbing through the elements of the menu, and that an element is visible when it is contained within the tabbing order. When the submenus are hidden, they don't need to be accessible by TAB
• Provide sufficient contrast for the links of the menu, in each possible state (default, focus, hover)
• Provide a version that is adapted to a mobile screen (or for use with zoom).

Different types of dropdown menus

The two methods used to display the dropdown menus with a pointer are:

• Clicking on the parent element
• Hovering over the parent element

In both cases, you must provide a similar behaviour for the keyboard:

• When the submenu appears by clicking on the parent elements, it must also work with ENTER,
• When the submenu appears by hovering over the parent element, it must also appear when the parent element receives the focus with TAB.

We prefer the first method (click and ENTER) because it gives more control to the user. However, the following list contains recommendations to make both menu types accessible.

Menus that appear with click and with ENTER

This type of menu is the easiest and the most accessible of our two options. The submenus appear only after a deliberate action of the user: a click or ENTER on the parent element.

Example: Disclosure navigation menu.

The big advantage of this solution is that keyboard users do not have to go through all levels of the menu list.

Each element of the menu must be implemented as a button that shows or hides a menu.

• The submenu appears when clicking on the parent element. A second click hides the submenu.
• The visible elements of the menu are accessible with TAB. This will automatically be the case if they are button elements.
• The state of each element of the menu (expanded or collapsed) is indicated with an aria-expanded attribute with a value true or false.
• When the focus is on a parent element, ENTER lets the submenu appear or disappear.
• The content of the submenu can be browsed with TAB.
• The submenus are hidden with display:none. This way, they are invisible to screenreaders and can't receive focus as long as they are hidden.

This works well when the main elements of the menu don't link to landing pages. If this is the case, a problem occurs because the same interactive element can't perform two different actions at the same time: navigating to a page and controling a submenu. Therefore, two elements are needed instead of one: a link to go to a page of the site, and a separate button to control the submenu.

Example of hybrid menu where each element of the menu is separated: a link, and a button that controls a submenu.

In this case, the buttons must also be implemented according to the design pattern of disclosures. Do not forget to give the button a meaningful name to signify its function.

Menus that appear on hover and with TAB

Example: responsive dropdown menu based on an example by Simply Accessible.

The disadvantages of this solution are:

• A keyboard user has to go through all submenus, even if they don't need to. This slows down keyboard navigation significantly. Adding a skip link at the top of the page (to content) can be a partial solution.
• Users of a pointer (mouse or other) can make the submenus appear unwillingly. The smaller the screen or the higher the zoom factor, the more of a nuisance this becomes. This is less problematic when the submenu can be hidden with the ESC key.
• Hover actions are more difficult to perform than a click with voice recognition software.

The expected behaviour of the menu is:

• The submenu appears when hovering over the parent element. Clicking on the parent element navigates to the corresponding page, if one exists.
• With the keyboard, the submenu appears as soon as the focus lands on the parent element (with TAB). ENTER on the parent element navigates to the underlying page if one exists.
• The content of the submenu can be accessed with TAB
• Don't hide the submenus with display:none, but with 'screenreader only'. This way, they are always visible for screenreader users, even when they are hidden.
• Don't use aria-expanded, as the submenus always remain visible for a screenreader user.
• Provide a way to hide the submenu without moving the pointer or the focus of the keyboard, e.g. the ESC key.

Note: normally, we would want to hide the submenus with display:none, but this can cause problems for certain screenreaders. The menu appears visually with an onFocus() event. The onFocus event is triggered when tabbing to the link. With a screenreader however, we may browse the content of a webpage by using the down arrow. With JAWS, and with the default settings of NVDA, this does not trigger the onFocus event. As a result, the menu won't appear when a user browses through the menu with JAWS or NVDA. As a workaround, we use a 'screenreader only' technique (offscreen or clipping) instead to hide the submenus. This means that, even if they only visually appear on hover and focus, the submenus are always visible for screenreader users.