AgentKit

Posted on May 3 • Originally published at blog.a11yfix.dev

Hamburger Menu Accessibility: Why Your Mobile Nav Locks Out Customers (And How to Fix It)

#a11y #webdev

Open a small-business website on your phone and tap the three lines in the corner. A menu slides in. You tap a link. The page loads. That is what is supposed to happen.

Now try the same thing without using your hands. Or with the screen reader your phone already has built in. Or with the screen zoomed to 200%. The hamburger menu that worked perfectly with a fingertip suddenly traps you, hides itself, or refuses to close. Roughly four out of five mobile sites we have tested have at least one accessibility issue inside that menu, and it is the single most common pattern that produces ADA demand letters and EAA complaints in 2026.

The good news is that the fixes are concrete, mostly invisible to the visual design, and almost all of them can be applied from inside your website builder's settings without editing a line of code. Here is what is going wrong on most hamburger menus, why each issue matters, and what you can actually do about it today.

Why the hamburger menu is a litigation magnet

Three reasons make this control a disproportionate target.

First, every visitor encounters it. Unlike a checkout flow or a contact form that only some users reach, the navigation is the gateway to the entire site. If it fails, the whole site fails for that user.

Second, the hamburger pattern is custom-built on most platforms. WordPress themes, Webflow templates, Squarespace styles, and Shopify themes each implement the menu slightly differently, and most implementations were copied from a template author who optimized for visual flair rather than assistive-technology support. Any platform-level accessibility fix Shopify or Squarespace ships does not retroactively patch your live site.

Third, automated scanners flag the failures clearly. axe DevTools, Lighthouse, and WAVE all surface hamburger-menu issues with screenshots and code snippets, which is exactly the kind of evidence that ADA plaintiff law firms attach to demand letters. A site that fails the menu typically fails it on every page, multiplying the violation count.

If you sell digital products to consumers in the EU and you fall under the European Accessibility Act, your obligations took effect in June 2025. A demonstrably broken navigation is one of the easiest issues for a complaint to surface.

Issue 1: The trigger button has no label

The classic hamburger icon is three horizontal lines and nothing else. Visually that works because you trained your users to recognize it. To a screen reader, that button is announced as "button" with no further description. Users hear "button" and have no way to know the button opens a menu.

The fix is a single attribute that takes a screen-reader user from confused to oriented: aria-label="Open menu". Every major website builder lets you set this from the UI:

Squarespace 7.1: Site Styles > Header > Menu Trigger > Accessibility label.
Wix: click the burger element > Settings > ARIA label.
Webflow: select the menu button element > Element Settings (D shortcut) > Accessibility > Aria label.
Shopify: most themes have a translation file (locales/en.default.json) with an accessibility.menu key. Update the value.
WordPress (most block themes): Site Editor > Header pattern > select the navigation block > Advanced > HTML element > add aria-label.

Verify your fix with the screen reader on your phone. iOS users can enable VoiceOver in Settings > Accessibility > VoiceOver. Android users have TalkBack in Settings > Accessibility. Tap the hamburger and you should hear "Open menu, button" instead of "button".

Issue 2: The trigger does not announce open or closed state

Even with a label, the trigger button needs to tell screen readers whether the menu is currently open or closed. The attribute that does this is aria-expanded, which should toggle between "true" and "false" when the user taps the trigger.

When aria-expanded is missing or stuck on a fixed value, screen-reader users hear "Open menu, button" both when the menu is closed and when it is already open. They tap the button repeatedly trying to figure out whether it worked.

This fix is more invasive in some platforms, because the toggle behaviour is governed by the theme's JavaScript. Workarounds:

Webflow: set the navigation menu element to use the built-in Nav component (not a custom interaction), which manages aria-expanded automatically.
Squarespace and Wix: their default mobile menus already toggle aria-expanded correctly. The issue appears mainly on heavily customized templates. If you injected a custom hamburger via Code Block, replace it with the platform default.
Shopify themes: every Online Store 2.0 theme released since 2022 handles this in the header.liquid template. If you are on an older theme, this is a strong reason to upgrade.
WordPress: the core Navigation block manages aria-expanded correctly. Custom menu plugins (UberMenu, Max Mega Menu) sometimes do not. Check by inspecting the trigger in your phone browser's DevTools.

Issue 3: The menu is a div, not a real navigation landmark

A menu inside a <div> is invisible to screen-reader users who navigate by landmark (the rotor on iOS, gestures on TalkBack). They skip your navigation entirely and assume your site has no menu, then leave.

Wrap the menu container in a <nav> element and add an aria-label="Main" to distinguish it from any secondary navigation (footer menu, breadcrumbs). Most modern themes already do this, but custom-built sites and older themes often do not.

The check is fast: open your site on your phone, open the browser's developer tools (Safari on Mac connected via USB, or Chrome remote debugging), and look at the menu container. If the outer element is <div> instead of <nav>, you have work to do.

Issue 4: The menu opens but does not move keyboard focus

Tap the hamburger and the menu slides in from the side. Visually that works. Now imagine you reached the trigger by pressing Tab on a Bluetooth keyboard. After you press Enter to open the menu, where does your focus go?

In most broken implementations, focus stays on the now-hidden trigger button. Pressing Tab takes you to whatever was after the trigger in the DOM (often a logo or a search field underneath the menu) rather than into the menu itself. Keyboard users are stuck navigating around their own open menu.

The accessible behaviour is for focus to move to the first link inside the menu when it opens, and for Escape to close the menu and return focus to the trigger. This is harder to fix from a no-code interface because it requires JavaScript. On the major platforms:

Squarespace, Wix, and Shopify default mobile menus generally manage focus correctly.
Webflow custom interactions and WordPress custom menu plugins frequently do not.
If you are on a custom-coded site, this is a 30-line JavaScript fix your developer can apply in less than an hour.

Issue 5: The close button is invisible to keyboard users

Once the menu is open, the user needs a way to close it. Screen readers and keyboard users navigate by tab order, not by visual position, so a close button that is positioned absolutely at the top-right of the screen is not necessarily reachable in a sensible tab order.

What works:

Place the close button as the first focusable element inside the menu, so the moment focus enters the menu the close action is immediately available.
Make sure Escape closes the menu in addition to the close button.
Give the close button a descriptive label: aria-label="Close menu".

A common shortcut on platforms that do not let you reorder the close button is to make the trigger button itself toggle: when the menu is open, the same icon (often morphed into an X) closes it. Make sure the aria-label updates with the state ("Open menu" when closed, "Close menu" when open).

Issue 6: Submenu chevrons are unreachable on touch and keyboard

Many hamburger menus include nested categories that expand when tapped. The expand control is often a small chevron icon to the right of the parent label. Three failures stack here:

The chevron is too small to tap reliably (less than the WCAG 2.5.5 recommended 44x44 pixel target). Mobile users with motor impairments, including older users with arthritis, cannot hit it.
The chevron is rendered as an icon font with no accessible name. Screen readers announce "button" with no indication that it expands a submenu.
The chevron is positioned in a way that conflicts with the link text, so users who want to expand the submenu accidentally activate the parent link.

The cleanest fix is to make the entire row tappable as a "expand submenu" action, with a separate, clearly labelled "Go to Section Name" link inside the expanded submenu. If your platform does not support that pattern, expand the chevron's hit area to at least 44x44 pixels via CSS and add aria-label="Expand SectionName submenu" plus aria-expanded to the chevron button.

Issue 7: The menu does not respect device settings

The final issue is the easiest to overlook because it does not show up in axe or Lighthouse. Many hamburger menus animate in with a slide or scale effect, ignoring the user's prefers-reduced-motion setting. For users with vestibular disorders, that quick slide can trigger nausea or migraine.

If your platform offers an "animate menu open" toggle, set it to a static fade or no animation at all. If you must keep the slide animation for users without reduced-motion preferences, wrap the animation in a CSS media query so only those users see it. Most modern themes do this correctly; older custom themes and template-marketplace purchases often do not.

A 10-minute self-check

You do not need to read a 60-page WCAG document to identify whether your hamburger menu is in trouble. Try this on your own phone:

Enable VoiceOver (iOS) or TalkBack (Android).
Tap the hamburger trigger and listen. You should hear something like "Open menu, button". If you hear just "button", you have Issue 1.
Open the menu. The screen reader should automatically read "Close menu" or jump to the first item. If it stays on the trigger, you have Issues 2 and 4.
Try to swipe-navigate through the menu items. If the screen reader skips items or reads icons aloud as "image", you have Issue 6.
Try to close the menu. If the only way out is to reload the page, you have Issue 5.

If your menu fails on three or more of these checks, it almost certainly contributes to the 80% of failed Lighthouse audits that we see on small-business sites. The good news is that the fixes are concrete and platform-specific, and most of them can be applied from inside your website builder without writing a single line of code.

DEV Community