Screen reader navigation: how blind shoppers experience your menu

A sighted shopper glances at a navigation bar and instantly understands the layout: logo on the left, five category links across the top, a search icon and cart icon on the right. A screen reader user has none of this visual context. They hear the page announced element by element—and the quality of that experience depends entirely on how the HTML is structured.

If the navigation uses semantic HTML (<nav>, <ul>, <li>, <a>), the screen reader user hears a clear, navigable structure. If the navigation is a stack of <div> elements with CSS styling and JavaScript click handlers, the screen reader user hears meaningless text with no indication that it’s navigation, that items are links, or that dropdowns exist.

What a screen reader announces: a walkthrough

Here’s what VoiceOver (Mac) announces when it encounters a well-structured navigation menu:

1. Navigation region: “Main navigation, navigation” — the <nav aria-label="Main navigation"> element tells the screen reader this is a navigation section, and the label distinguishes it from other navigation regions on the page.

2. List structure: “List, 5 items” — the <ul> element tells the screen reader how many top-level items exist. The user knows the scope of the menu before hearing individual items.

3. Link text: “Women’s Clothing, link” — each <a> element is announced with its text and its role. The user knows it’s a clickable link, not static text.

4. Dropdown indicator: “Men’s Shoes, collapsed, pop-up button” — a <button> with aria-expanded="false" and aria-haspopup="true" tells the user this item has a submenu that’s currently closed. They can press Enter to open it.

5. Expanded state: “Men’s Shoes, expanded, pop-up button” — after opening the dropdown, aria-expanded="true" tells the user the submenu is now visible. The screen reader then announces the submenu items.

6. Current page: “Sale, current page, link” — aria-current="page" tells the user this is the page they’re currently viewing.

This structured, predictable announcement lets the screen reader user understand the menu, navigate it efficiently, and know exactly where they are at every step.

What goes wrong: common failures

Now here’s what the same screen reader announces when the navigation is poorly structured:

No <nav> element: The screen reader doesn’t announce a navigation region. The user doesn’t know they’ve reached the menu. They can’t use landmark navigation to jump directly to it.

<div> instead of <a> or <button>: The screen reader announces “Women’s Clothing” as plain text. No “link” role. The user doesn’t know it’s interactive. They can’t activate it with Enter because it’s not a focusable element—it requires a mouse click on a JavaScript handler.

No aria-expanded on dropdowns: The screen reader announces “Men’s Shoes, button” with no indication that it has a submenu. The user presses Enter, the submenu appears visually, but the screen reader doesn’t announce the state change. The user doesn’t know the submenu is open.

No aria-label on navigation regions: The page has three <nav> elements—header, breadcrumbs, and footer. All announce as “navigation.” When the user lists landmarks to jump to a specific one, they see three identical entries with no way to distinguish them.

Hidden content in the DOM: A mega menu’s submenu panels exist in the HTML but are hidden with opacity: 0 or left: -9999px instead of display: none or the hidden attribute. The screen reader announces these hidden panels because they’re technically present in the accessibility tree. The user hears submenu items for every category even when no dropdown is open.

ARIA roles and attributes that matter

ARIA (Accessible Rich Internet Applications) provides attributes that bridge the gap between visual presentation and programmatic meaning. For navigation, these are the essential ones:

aria-label on <nav>: Provides a unique name for each navigation region. “Main navigation,” “Breadcrumb navigation,” “Footer links.” Required when a page has multiple <nav> elements.

aria-expanded on dropdown triggers: Set to "false" when closed, "true" when open. Must update dynamically via JavaScript when the dropdown opens or closes. Without this, screen readers can’t communicate dropdown state.

aria-haspopup="true" on dropdown triggers: Tells the user that activating this element will open a popup menu. Combined with aria-expanded, it gives complete context: “this button opens a submenu, and it’s currently closed.”

aria-current="page" on active links: Marks the link that corresponds to the current page. Screen readers announce “current page” alongside the link text, helping users orient themselves.

role="menubar", role="menu", role="menuitem": These ARIA roles create a menu widget pattern. When used, they change keyboard behavior—arrow keys navigate between items instead of Tab. This is appropriate for application-style menus but can be confusing if implemented incorrectly. For most ecommerce navigation, simple <nav>/<ul>/<li>/<a> with aria-expanded is more reliable than full menu roles.

Semantic HTML: the foundation that makes ARIA work

ARIA is designed to supplement HTML semantics, not replace them. The first rule of ARIA is: if you can use a native HTML element with the correct semantics, use it instead of adding ARIA to a generic element.

For navigation, this means:

• Use <nav> instead of <div role="navigation">.
• Use <a href="..."> for links instead of <span onclick="..." role="link">.
• Use <button> for dropdown triggers instead of <div onclick="..." role="button">.
• Use <ul>/<li> for lists of links instead of flat <div> structures.

Native HTML elements come with built-in keyboard behavior, focus management, and screen reader announcements. An <a> tag is automatically focusable, activatable with Enter, and announced as “link.” A <div> with role="link" requires manual tabindex="0", a keyboard event handler for Enter, and still may not behave identically across all screen readers.

Start with correct HTML. Add ARIA only for states and properties that HTML can’t express—like aria-expanded, aria-current, and aria-label.

Testing: how to hear what your users hear

The most effective screen reader test is simple:

1. Turn on a screen reader. VoiceOver: Cmd+F5 on Mac, triple-click Home on iOS. TalkBack: Settings > Accessibility on Android. NVDA: free download on Windows.

2. Navigate to your store. Don’t look at the screen—listen.

3. Find the navigation. Use the rotor (VoiceOver) or landmark list (NVDA) to jump to the navigation region. If it’s not listed, you’re missing a <nav> element.

4. Move through menu items. Listen for link roles, list structure, and dropdown indicators. If items announce as plain text or “group” instead of “link” or “button,” the HTML structure is wrong.

5. Open a dropdown. Does the screen reader announce “expanded”? Are submenu items announced? Can you close it with Escape?

6. Check the current page. Navigate to the link for the page you’re on. Does it announce “current page”? If not, aria-current is missing.

This test takes five minutes and reveals more about your navigation’s accessibility than any automated tool. Automated scanners catch missing alt text and contrast violations, but they can’t tell you whether a menu makes sense when you can’t see it. Only a screen reader test can do that.

This article is part of the larger guide on Navigation accessibility: why 15% of shoppers can’t use your menu.