In this video, we’ll learn the critical differences between ARIA menus and standard website navigation, and why using ARIA roles on a typical nav bar often creates a confusing ‘guessing game’ for keyboard and screen reader users.
For more information, see our blog on this topic.
Transcript
Does your website navigation need an ARIA menu? Probably not.
Adding ARIA menu roles to regular navigation can create confusion for keyboard users.
In this video, we’ll show you what an ARIA menu is, how it behaves, how website navigation normally works, and why ARIA menus often cause problems when applied to site navigation.
Check out our resources linked below for more information on ARIA menus.
True menu demo
Let’s start with what a menu is because it’s different from website navigation.
I’ll demo what a menu is using Google Doc’s File, Edit, and View menu in the top left. I’m currently on the first menu item, which is File. If I tab, I leave the menu completely and go down to the tool bar below. I’ll press Shift+Tab to go back to file. Since I’m in a menu, I have to use the arrow keys to move between menu items. So, if I press the right arrow, I go to the Edit menu item, and the down arrow will open the submenu.
Left, right, up, and down arrows are how we navigate menus. And to get out of it, I’ll use Escape. This is very intentional behavior, and it’s correct for a menu.
But it comes with a big requirement: every single one of these interactions has to be implemented with JavaScript.
Context shapes expectations
Here’s the important part. When assistive technologies encounter roles like menu or menubar, screen readers typically announce that to users. For many experienced users, that announcement sets an expectation: “This will behave like a menu.” This signals the user to use arrow keys and escape.
In contrast, when screen readers encounter a typical website navigation, they announce it as a list of links. This cues the user that tab and enter are the main keyboard shortcuts.
Users rely on expected patterns for speed and predictability.
Traditional website navigation screen reader demo
Now let’s look at traditional website navigation with assistive technology. Notice how the screen reader announces the navigation items as links.
VoiceOver: visited link, image, Pope Tech, main, navigation.
I’ll press Tab as I navigate from link to link.
VoiceOver: link, Products, list two items.
This is exactly what keyboard and screen reader users expect on a website. They don’t expect to use arrow keys. Rather they expect behavior like Enter activating a link.
VoiceOver: Expanded link, Products
In dropdown menus, I still navigate through with Tab.
VoiceOver: Link, web accessibility platform, navigation. Link, Features. Link, Pricing.
And most of this behavior is built into the HTML. There is very little extra JavaScript needed.
Improper ARIA menu roles screen reader demo
Now, let’s look at what happens when we use ARIA roles without the required behavior. On this navigation bar, I’ve added role=”menu” and role=”menuitem” to the navigation.
Let’s listen to how a screen reader introduces this navigation bar as a menu now:
VoiceOver: Products, collapsed, submenu, two of four, menu bar four items
But when I press the arrow keys… nothing happens. The promise of the ARIA role is broken. I’m forced to go back to the Tab key.
VoiceOver: About, menu item, three of four, menu bar four items
Now I’m in a state of keyboard confusion. The code told me to expect a menu, but the functionality is a standard website. By adding these roles, we’ve taken a perfectly working HTML list and turned it into a guessing game for the user.
Even when it “works”
Now let’s say this navigation is fully implemented as a true menu: The arrow keys work, Escape works, and everything behaves exactly like a menu. This would be a technically correct menu, but for the vast majority of website navigations, it’s the wrong pattern. Most keyboard users expect to move through site links with Tab.
So even when an ARIA menu is fully functional in a navigation bar, it forces users into an interaction model they generally don’t need.
Native HTML navigation already does this job better, with less code and fewer failure points.
Key takeaways
The takeaway is that for standard website navigation, ARIA menu roles are usually not the right choice. They’re designed for true menus. For website navigation, keep it simple, and let native HTML do the heavy lifting.
Remember to subscribe for more accessibility videos.