Hamburger Menu Accessibility: A 5-Minute Test You Can Run From Your Phone

Hamburger menus are not inherently inaccessible — but the way most of them are built is. The whole pattern hinges on one small toggle button, and if that button has no name, no announced open/closed state, or can’t be operated by keyboard, your entire mobile navigation is invisible to a screen reader user. The good news: you can test yours in about five minutes with nothing but your phone and a Tab key.

That’s what this post is. Not a coding tutorial — a self-check for a business owner or a marketer who wants to know whether the little three-line icon on their site is quietly locking people out.

Are hamburger menus accessible?

Yes — when the toggle is built correctly, a hamburger menu can fully meet WCAG. The Bureau of Internet Accessibility says as much in its post “Are Hamburger Menus Bad for Accessibility?”: the pattern “can be implemented without creating usability issues or accessibility barriers,” provided you use semantic HTML, label the button, expose its expanded state, and make it keyboard-operable.

There’s an honest caveat, though. Even a perfectly coded hamburger menu hides your navigation behind a tap, and hiding things has a measurable cost for everyone. In Nielsen Norman Group’s 2016 study of 179 participants across six sites, people used hidden navigation only 57% of the time on mobile, versus 86% for navigation that was at least partly visible — and mobile users were 15% slower completing tasks with hidden menus. Accessible and discoverable are different bars. This post covers the first; keep the second in mind when you redesign.

Why the mobile menu is the test that matters

On a phone, the hamburger menu isn’t one navigation option among several — it’s the only one. StatCounter’s platform data puts mobile at 51.51% of global web traffic as of June 2026, ahead of desktop. For most small-business sites, the majority of visitors never see your desktop menu bar at all.

That changes the stakes. A broken dropdown on desktop is an annoyance; a broken hamburger menu on mobile means a blind or keyboard-only visitor cannot reach any page beyond the one they landed on. No services page, no menu, no booking form, no phone number. Navigation barriers are what turn one bad component into a site-wide barrier — which is exactly the kind of failure that shows up in ADA website lawsuits.

The 5-minute hamburger menu test

You need your phone, a laptop with a browser, and your own website. One minute per check.

1. Minute 1 — Look at the button. Open your site on your phone. Is the hamburger icon reasonably big — comfortably tappable without zooming? WCAG 2.2’s Target Size (Minimum) criterion, a Level AA rule, sets the floor at 24 by 24 CSS pixels. Bonus points if the word “Menu” appears next to the icon. Tiny, unlabeled, tucked in a corner? Note it.
2. Minute 2 — Keyboard: open it. On your laptop, shrink the browser window until the hamburger icon appears (most sites swap to the mobile menu at narrow widths). Put the mouse down. Press Tab until the icon shows a visible focus outline — if focus never lands on it, that’s a WCAG 2.1.1 Keyboard failure and you can stop here; the test is failed. If focus reaches it, press Enter. The menu should open.
3. Minute 3 — Keyboard: use it and escape it. With the menu open, Tab through the links. Can you see where you are at every step? Can you press Enter on a link and actually go there? Now reopen it and press Esc — a well-built menu closes and puts focus back on the button. If you Tab into the menu and can’t get out, that’s a keyboard trap, which WCAG prohibits outright.
4. Minute 4 — Screen reader spot-check. On your iPhone, turn on VoiceOver (Settings → Accessibility → VoiceOver; on Android, TalkBack). Swipe to the hamburger button and listen. You want to hear something like “Menu, button, collapsed.” Double-tap and listen again — it should now say “expanded.” If you hear just “button” — or nothing focusable at all — the button has no accessible name or state.
5. Minute 5 — The closed-menu check. Turn the screen reader off, go back to the laptop, and with the menu closed, keep pressing Tab. If focus disappears into invisible territory — you’re tabbing but nothing on screen highlights — the “closed” menu’s links are still in the tab order. Sighted keyboard users get lost in a menu they can’t see.

Write down what failed and on which check. That list is exactly what a developer needs.

What each failure means in WCAG terms

Your developer (or ours) will want the failures mapped to actual success criteria. Here’s the translation table:

Notice how much of that table is one criterion. WCAG 4.1.2 — a Level A requirement, the most basic tier — says that for every interactive component, “the name and role can be programmatically determined” and that states the user can change must be exposed to assistive technology. A hamburger toggle is the textbook case: it needs a name (“Menu”), a role (button), and a state (expanded or collapsed). Miss any of the three and a screen reader user is operating your navigation blind.

The mistakes behind most failing menus

Almost every failing hamburger menu we audit traces back to the same handful of shortcuts.

The button isn’t a button. Developers wire a click handler to a div or a bare icon. A real button element is keyboard-focusable and announces its role for free; a div does neither, and every ounce of that behavior has to be rebuilt by hand — usually incompletely. This is the single most common root cause, and it’s the same class of problem we cover in ARIA’s most misused tool: recreating native HTML badly instead of just using it.

No state on the toggle. The fix is one attribute. The W3C’s ARIA Authoring Practices disclosure-navigation example shows the pattern: the toggle carries aria-expanded="false" when the menu is hidden and aria-expanded="true" when it’s shown, plus aria-controls pointing at the menu container. Notably, the W3C example does not use ARIA’s menu role — plain site navigation is a list of links behind a disclosure button, and over-ARIA-ing it creates new problems. More on when ARIA helps and hurts in our ARIA labels and roles guide.

The menu hides visually but not structurally. CSS tricks like sliding the panel off-screen leave every link focusable while invisible. Hiding needs to be real — display: none, the hidden attribute, or visibility: hidden — so the closed menu leaves the tab order entirely.

Focus is never managed. Open the menu and focus should move somewhere sensible; close it and focus should return to the toggle. Skip this and keyboard users are dumped at the top of the page after every interaction. Our guide to accessible navigation and focus walks through the full pattern, landmarks included.

What to send your developer

If your menu failed any check, forward this paragraph:

The mobile nav toggle should be a native button element with an accessible name (visible text “Menu” or aria-label="Menu"), aria-expanded toggling between true and false, and aria-controls referencing the nav container, per the W3C APG disclosure-navigation pattern. The panel must be truly hidden when closed (not just off-screen), Esc should close it and return focus to the toggle, and all of it must work with keyboard alone.

That single sentence-cluster resolves most of the table above. It is genuinely a small fix — usually hours, not weeks — which is what makes a failing hamburger menu so frustrating to find in a demand letter.

Five minutes told you something — here’s the rest

This check covers one component. It won’t tell you whether your images have alt text, whether your forms announce errors, or whether your colors pass contrast — and passing it is not a legal clearance; this article is general information, not legal advice.

But if your menu failed, that’s rarely the only thing wrong, because the shortcuts that break a menu button break other components too. A free accessibility scan takes about a minute and gives you the automated baseline — missing button names and ARIA states included — so you can see whether the menu is a one-off or a pattern. Run it, then keep your five-minute findings handy: together they’re the start of a real fix list.