When building website navigation, it’s common for developers to reach for ARIA menu roles, thinking they provide a more accessible experience.
But this is often a misconception. ARIA menu roles are meant for true menus, like the File, Edit, and View drop-down menus you often see in Word, Google Docs. It’s not for standard site navigation.
In this post, we’ll explain what a true menu actually is, how it differs from traditional website navigation, and why that difference matters for people using keyboards and assistive technologies.
What is a menu?
A menu is a custom widget meant to behave like an Operating System application menu.
Menus are often built using ARIA roles such as menu, menubar, and menuitem. When keyboard or screen reader users come to a true menu (like the File, Edit, and View drop down menus), they expect that keyboard functionality works primarily with the arrow keys.
Simply adding ARIA roles like menu, menubar, and menuitem does not add the keyboard functionality. Menus require JavaScript to handle keyboard input, manage focus movement, and ensure the widget responds in ways assistive technology users expect.
Review W3C’s ARIA menu and menubar pattern to understand the specific keyboard interactions and necessary ARIA roles, states, and properties that a custom menu needs.
How is a menu different from a website navigation?
Now that you know what a menu is, it’s easier to see why it’s usually the wrong choice for website navigation. The confusion often comes from the fact that we call both of them “menus” in casual conversation, but they actually represent two different ways of moving through a digital space.
Website navigations are typically a relatively simple list of links. Users expect to move through them linearly using the Tab key. This behavior is mostly built in the native HTML.
A menu is a specialized widget. It is designed for high-density interfaces where using the Tab key would be exhausting. By using an ARIA menu role, you are telling the user: “Stop tabbing; start using your arrow keys.” (Even if the functionality wasn’t built with JavaScript).
Now, the first rule of ARIA is if you can use a native HTML element or attribute with the semantics and behavior required already built in, then do so. Cue the standard website navigation built with HTML5 landmarks and links.
Standard navigation links and buttons already have built-in keyboard functionality. They typically aren’t a complex interface where custom keyboard functionality is needed, so they don’t need much additional ARIA or JavaScript.
Expected keyboard behavior: Menu vs website navigation
Here’s a high-level comparison of how keyboard interaction differs between an ARIA menu and a traditional website navigation.
| Shortcut | ARIA Menu (with JavaScript) | Traditional Nav Menu |
|---|---|---|
| Tab | Moves focus in or out of the menubar container | Moves focus sequentially through every single link |
| Arrow Keys | Moves focus: Up/Down for submenus, Left/Right for the main bar | Not used for navigation; standard page scrolling only |
| Character Keys | Jumps focus to the next item starting with that letter | Usually ignored or triggers browser shortcuts |
| Home / End | Jumps to the first or last item in the current submenu or menubar | Jumps to the top or bottom of the entire webpage |
| Enter / Space | Activates focused item or opens submenu | Enter activates links; Space scrolls (unless on a button) |
| Escape | Closes submenu and returns focus to parent | Closes submenu (if using our custom JavaScript) |
Try it yourself
To see the difference in practice, and so you know how to test menus vs. navigation, try operating these examples with keyboard shortcuts and a screen reader.
Note the difference in complexity: Compare the 100+ lines of JavaScript needed to make the ARIA menu work versus the minimal code needed for the traditional navigation.
Example 1: A menu widgit
This example shows a menu widget where movement happens with arrow keys, character keys, Home/End, and Escape.
Example 2: Traditional website navigation
This example shows a traditional website navigation where you use Tab to move between links and Enter or Space to open dropdowns.
To see demos for menus vs website navigation, see our video.
What happens when you put an ARIA menu role on your website navigation?
When you add ARIA menu roles to your site navigation, screen readers announce those roles to users. That announcement sets an expectation: this will behave like a menu. Screen reader users then might try to use menu-style keyboard commands. But in many website navigations, that behavior isn’t actually implemented with JavaScript. So the user hears “menu,” tries to use menu interactions, and nothing works the way they expect.
Even when developers do implement the full menu keyboard behavior for a website navigation, the experience can still be problematic. Keyboard and screen reader users are now forced into a menu interaction model in a place where they expected standard web navigation. Instead of making the site easier to use, it makes navigation feel unfamiliar and harder than it needs to be.
ARIA menu WAVE results
WebAIM’s recent survey found that about 7% of home pages use an ARIA menu, but over a quarter of these cause detectable accessibility issues.
There are two WAVE results related to menus you could get:
For either of these results, you should:
- Decide if ARIA is even needed. Is it a true menu or a navigation? If it’s a navigation, remove the ARIA.
- If it is a true menu, make sure it has the JavaScript needed to function like a menu.
Learn how to use the free WAVE extension to check your website for detectable accessibility issues. Or, try Pope Tech’s free account to get results on up to 25 pages at a time: free for life and no credit card required.
Takeways
- Verify with Testing: If you see ARIA menu WAVE results, either remove the ARIA or make sure it follows the ARIA menu pattern.
- Prioritize Predictability: Most users expect to move through website navigation using the Tab key. ARIA menu roles break this expectation.
- Respect the First Rule of ARIA: Native <nav>, <ul>, and <a> elements are more accessible by default. Don’t replace them with ARIA roles and JavaScript unless you are building an interface that truly requires complex arrow-key navigation.
- Don’t Over-code: ARIA menus require extensive JavaScript to manage focus and keyboard events. Native HTML navigation works out of the box with minimal extra code and fewer failure points.