Nav Menu Accessibility

This Accessibility Weekly is all about navigation menus. Can people with disabilities use the nav menus on the websites you build?

Navigation menus are arguably one of the most essential parts of a website for accessibility. If your navigation menus are not accessible, they create a significant barrier for people to use the website and do what you want them to do on it – whether that’s purchase a product or fill out a contact form.

Unfortunately, this is also one of the most common areas for WordPress themes to fail to get right.  Keep reading for how to test a website menu for accessibility and information on how accessible your theme’s or builder’s nav menus are.

Key Features of Accessible Navigation Menu

Accessible navigation menus can be used without a mouse and with other assistive technology like screen readers. Using the navigation without a mouse seems like a no-brainer, but one of the most common problems with navigation menus is that there is no way to access or see the submenu dropdowns without a mouse.

Here’s a list of everything I look for in a navigation menu when doing an accessibility audit:

• All elements on the menu can be reached by hitting the tab key.
• Tab order follows the visual order on the page.
• There’s a clear focus outline for each element when it receives focus.
• There’s adequate color contrast between the text and background.
• There are visual indicators (with adequate color contrast) for both active pages and on hover.
• The navigation is wrapped in a <nav> tag (or some other HTML tag like a <div> with role=”navigation” in it).
• The nav tag is labeled as Main or Primary (or another accurate name to describe where it is, such as “footer”) using an aria-label or aria-labelledby.
• The nav menu is contained within an unordered list with each element in a <li> tag.
• When using the Tab key to navigate, the submenus open visually on the page.
• Arrow keys can be used to navigate left and right in horizontal menus and up and down in vertical menus.
• In horizontal and vertical navigation, when using the arrow keys and the user reaches the end of the menu (e.g., pressing right when at the last menu item), the focus should wrap back to the first item (or vice versa).
• There are no links that are not actually links, such as menu items where a # was filled in as a placeholder or to create a heading, etc.
• Users are not forced to tab through the submenus to reach the next top menu item and can bypass the submenus completely if desired.
• There are separate buttons (actually coded as buttons) to open sub-navigation menus.
• Buttons for sub-navigation menus are adequately labeled for screen readers, saying not just “submenu” but what it’s a submenu of, such as “about submenu.” These labels should match any visible text next to the button exactly so people using voice control will know how to trigger it.
• Submenu buttons include aria-expanded with the correct true/false value indicating if the dropdown is open or closed.
• Submenu buttons have aria-haspopup.
• Subnav dropdowns can be closed with the escape key.
• Closing the sub-nav with the escape key returns focus to the button that opened it.
• When zooming the website to 400%, the navigation menu can still be used with a keyboard (typically the mobile nav).
• Open/close buttons for the mobile nav are coded as buttons (not links), are adequately labeled, and include aria-expanded and aria-haspopup (just like sub-nav buttons).
• When opening the mobile menu, the keyboard focus shifts to the mobile nav.
• There is a focus lock on the mobile nav, so users cannot accidentally tab out of it without closing it (I.e., treat it like a popup).
• Headings in mega menus are labeled as headings and have the correct heading order (typically H2 unless there’s a hidden H2 for the nav itself, then H3)
• Any other elements in mega menus (images, videos, etc.) are accessible.

How does your theme stack up?

TAB Member, Adam Lowe, has two excellent YouTube videos where he tests and compares navigation menus. I recommend checking them out if you want to see a visual demo of testing navigation menus for accessibility or to see how many popular WordPress themes and page builders shake-up when it comes to navigation menu accessibility.

• WordPress Menu Accessibility Part 1: Theme Comparison video discusses accessibility in:
  • Twenty-Two (block and classic)
  • Elementor
  • Bricks
  • Oxygen
  • Breakdance
  • GeneratePress
  • Kadence
  • Max Megamenu
  • My Menu
• WordPress Menu Accessibility Part 2: Detailed Requirements and Final Test Video

At the time this article is being written, those videos are about 9 months old, so it’s possible the accessibility in the themes and builders he tested may have changed, so if you’re using one of them, you’ll still want to test them for accessibility yourself.

Some other very popular themes that I have tested recently that need remediation include:

• Astra: The dropdowns are keyboard accessible and include a separate way of opening them that doesn’t require users to tab through each dropdown, but these toggles are not coded as buttons and are missing the expected ARIA attributes. All nav tags use the same label, “site navigation,” even if you have multiple on the page, making it impossible for screen reader users to distinguish between multiple navigation menus.
• Beaver Builder: Beaver Builder is missing separate buttons to open the sub-navigation menus, but they can be accessed with the Tab key. If using the nav search, it receives focus out of visual order. There are hidden elements that receive focus in the mobile navigation.
• Divi: There are many accessibility problems in Divi, including navigation menus that are utterly nonfunctional with a keyboard and screen reader. The Divi Accessibility plugin from CampusPress can help to resolve some of these issues. Never use Divi without it.
• Genesis: There are no separate buttons for sub-navigation menus, but they can be accessed with the Tab key. Some child themes, depending upon the developer, may fail to make the sub-nav openable with a keyboard alone or may have inaccessible mobile menus.

How to Fix Navigation Accessibility Problems

In most cases, you can fix navigation menu accessibility problems with code added in a child theme. Typically this is done with JavaScript and some PHP if you’re replacing the menu entirely. In some extreme cases, it’s easier to abandon the component (if you’re using a mega menu plugin or third-party menu add-on for a page builder like Elementor, for example).

My partner, Steve, gave a presentation at WordPress Accessibility Meetup, Anatomy of an Accessible Nav, that shows how he replaced the navigation menu on the Equalize Digital website (an older custom Genesis child theme) with a more accessible navigation menu. There are links in the resources to example code on GitHub that may be helpful even if you’re not using Genesis.

Have you tested your website’s navigation for accessibility? What about those in the builder or theme you use for client sites? If not, do it right now. If it’s not accessible, plan for fixing it and roll those fixes into your starter so that every website you build moving forward will have an accessible nav. It’s well worth the time investment, and your users will thank you.