Drop-down navigation menus
In a drop-down navigation menu, only the main menu items are visible. These usually stand for the main sections of the site. Activating a main menu item opens a sub-menu.
There are many different ways a drop-down menu can be implemented. Sometimes the sub-menu only opens when the mouse cursor hovers over the main menu item. Sometimes it also opens when users TAB to the menu item with the keyboard.
In other cases, the submenu opens only when a main menu item is activated by clicking (or pressing ENTER when the menu item has focus).
A drop-down navigation menu in action
This is a typical drop-down menu, with sub-menus on just one level.
Using a navigation menu on the website of the American National Parks Conservation Association with the keyboard.
- tabs to the navigation menu
- opens the first submenu with ENTER
- tabs through to the second submenu, and
- selects one of the navigation options
Typical usability problems with drop-down navigation menus
Drop-down navigation menus pose all sorts of usability problems, not just for users with disabilities.
One problem of drop-down menus is that they hide the menu options. A permanently visible listing of options provides an overview of content that can be viewed at leisure to pick the right one. If that listing gets tucked away behind main menu items, users have predict (or recall) where to find the content they are looking for, and interact with the menu to find it.
If there is little space for menu listings as on mobile screens, hiding options behind a menu button can be a reasonable choice.
Problems for mouse users
Mouse users with motor impairments struggle to activate menu items in drop-down navigation menus. The same is true for elderly users. The menu items are often small, and there is little space between them. Contrast is often poor. When dropdown menus have submenus, use becomes even more difficult. Often, sub-menus suddenly disappear when users move the mouse over to the sub-menu.
The use of drop-down menus is often more difficult on touchscreens. The finger is a less precise pointer than a mouse cursor and covers part of the screen.
Problems for keyboard users
Keyboard and focusing problems are also very common. Many drop-down menus are made for pointer input only and are not keyboard-accessible at all. When they can be tabbed through, it is often difficult to see the current focus position. Often, users have to traverse huge menus before getting to the content of the page.
A recognition of these problems, and the fact that traditional drop-down menus don't work well on small screens, have led many sites to abandon them, with the exception of one pattern: the menu behind one button.
Accessiblity issues of hamburger menus
The so-called hamburger menu sits behind an icon with three horizontal bars that resemble the layers of a hamburger. It often replaces the horizontal main navigation menu when a website is viewed on mobile devices. The menu button very often responds only to touch. Users who connect a keyboard to a tablet or mobile phone are out of luck. The same goes for keyboard users who magnify content with the browser's zoom function. This usually causes the mobile version of the site to be shown, including the inaccessible hamburger menu button.
The following examples show typical usability problems when interacting with drop-down menus.
1 Keyboard use: Menu cannot be opened (works only with mouse)
Often, drop-down navigation menus work for mouse users, but cannot be focused with the keyboard.
The test shows a keyboard user trying to open the main navigation menu of the website Hannover.de
- The focus indication is hard to see, so the user selects a Force Focus" bookmarklet to better see the focus.
- The main navigation menu cannot be focused with the keyboard - the focus jumps to content after the menu.
- A mouse user then takes over and shows that it is possible to open the menu with the mouse.
2 Keyboard use: Nested and long dropdown menus, weak focus
Nested drop-down navigation menus are often difficult to use. When every menu item takes focus, these menus take a long time to traverse for keyboard users. The difficulty is compounded if the current keyboard focus is difficult to detect.
Mouse users also often encounter problems: Opening the submenu and further submenus requires fine motor control. The menu can accidentally close before the intended menu item can be reached.
A keyboard user tries to operate the main navigation on the website Magdeburg.de. On reaching the menu,
- a dropdown submenu opens
- a second-level submenu opens when tabbing further
- a third-level submenu opens when tabbing further
- a fourth-level submenu opens
Traversing the menu takes a lot of time. It is difficult for keyboard users to see which menu item is currently focused.
3 Keyboard & screen reader use: Unexpected keyboard behaviour
When a navigation menu has been implemented as a tab panel but looks like a regular navigation menu, keyboard users will expect to be able to use the tab key to traverse the menu items. But this will not work if the tab panel supports the keyboard behaviour for this component. Users will have to use the arrow keys → ← instead.
An additional problem for blind users is that this tab panel does not use the ARIA roles
tabpanel to make the meaning clear and indicate that arrow keys must be used.
The test shows the behaviour when accessing the main navigation menu familyreunion-syria.diplo.de in the Firefox Browser with the screen reader NVDA turned on, using the keyboard.
- When tabbing into the main navigation menu, the first menu item Startseite is focused.
- Tabbing further to focus the next menu item fails. Instead, the focus moves to the content underneath.
- The user moves the focus back to the main menu item and tries the right arrow key → instead.
- But now the screen reader reads the single letters of the link text.
4 Low vision use: Sub-menu controls difficult to discover and associate with menu items
Low vision users often find it difficult to associate labels and controls if these are far removed from each other.
A low vision user tries to open a submenu in the responsive view of the main navigation menu on the website Existenzgründer.de.
- she opens the main navigation via the hamburger button
- she fails to notice the control to expand the main menu item "Unternehmen führen"
- she activate the main menu item which leads to another page - the main menu closes
- she opens the main navigation again via the hamburger button and discovers the plus control
- she opens the wrong plus control (because the control is far removed from the menu item)
5 Low vision use: Hamburger menu button is not discovered
On many sites, the user switches to the responsive view of the main navigation when the window is not so wide or the user has zoomed in a bit.
On the website of GKV Spitzenverband, a low vision user is asked to locate the main menu, which has shrunk to just one button, the "hamburger" button.
- The user searches for the main navigation and thinks to have found it when he discovers a tabbed interface in the middle of the page,
- He us given the hin that another main menu exists.
- He then searches along the top of the page for the menu.
- He zooms in on the search and menu button, but does not identify it as the main menu, but as search.
- He carries on searching, until he is given the hint that it is next to the search function.
- He finds the menu button, activates it, and checks that the menu has really opened.
6 Speech input use: Menu items cannot be activated
Interacting with menus can cause problems for speech input users when menu items aren't marked up in a way that they respond to speech commands.
A speech input user interacts with Eurowings.com, an airline website.
- The command „Klick Buchen“ opens the drop-down navigation menu.
- The command „Klick Flüge Buchen“ opens the flight search page.
- The command „Klick Abflughafen“ opens another drop-down menu.
- The command „Klick Deutschland - Nord“ fails - because this menu item is not implemented as a link.
7 Screen reader use: Other page content interferes with using the menu
Especially for screen reader users, dynamic content like auto-playing animations or carousels can make it difficult or impossible to use the navigation. The sound and the video captions reproduce the output of the screenreader. The blind user can also be heard.
A blind user tries to use the navigation of the website of GKV Spitzenverband. A carousel is active in the background, and the constant screenreader output of carousel contents prevents the output of the navigation menu.
Accessibility tips for drop-down navigation menus
- Make the menu keyboard-accessible. Use link mark-up for navigation menu items and ensure that users can TAB through the main menu.
- Make the hidden sub-menu options available to keyboard users. Ensure that the sub-menu opens when the main menu item gets focus or is activated with ENTER, or make main menu items link to section pages that list the same items as the sub-menu.
- Clearly show the currently selected focus position in main menu and sub-menus. Keyboard users need to know what they will activate.
- Do not use long sub-menus when the submenu opens on focus. Keyboard users should not be forced to tab through long sub-menus.
- Generally, don't make the sub-menus too long. When long lists go beyond the bottom of browser window, the lower items are difficult to reach. This gets worse for users who magnify content.
- Check that in responsive versions of navigation menus (e.g., on mobile phones), all content can be reached - possibly via landing pages or submenus.
- Indicate the state of submenus. When sub-menus open on click or ENTER, make the state of the sub-menu (visible or closed) available to blind users.
COMPARE cases with accessibility ratings
- Tap panel as main navigation (familyreunion-syria.diplo.de)
- Menu elements cannot be activated by speech input (eurowings.com/)
- Mobile menu, good example (funka.com)
- Drop-down navigation menus (transports-lia.fr)
- Hierarchical drop-down menu (gkv.de)
- Deeply nested hierarchical dropdown menu (magdeburg.de)
- Dropdown menu, mouse only (hannover.de)