The Menu That Wouldn't Let Go
He navigates entirely by keyboard. No mouse, no trackpad — a motor disability makes precise pointing painful and unreliable, so every website he uses gets operated the same way: Tab, Shift+Tab, Enter, Space, Arrow keys, Escape.
He lands on a site with a "modern" mega-menu — the kind with nested categories, promotional tiles, and a dozen links fanning out under a single nav item. He tabs forward to reach it. The menu opens. He tabs again to move into it, working his way through the submenu links.
Then he tries to leave.
Tab does nothing. Shift+Tab does nothing. Escape does nothing. His focus is somewhere inside a dropdown that was clearly built with a mouse user in mind — hover to open, click away to close — and there is no keyboard-operable way out. He's not stuck because he did something wrong. He's stuck because nobody tested what happens when a real keyboard user, not a QA script clicking through a checklist, tries to get out the way they got in.
This is a keyboard trap. It's one of the oldest, best-documented failure types in web accessibility, and it is still showing up on new sites shipped this year.
Why Keyboard Access Is the Foundation, Not a Feature
Before focus indicators, before trap-free menus, there's a more basic requirement underneath all of it: 2.1.1 Keyboard, a Level A success criterion. It states that all functionality must be operable through a keyboard interface, without requiring specific timing for individual keystrokes.
Translate that out of spec-language: if a sighted mouse user can do it, a keyboard-only user must be able to do it too. Opening a menu. Dismissing a modal. Submitting a form. Dragging a slider. Every one of those needs a keyboard equivalent, because keyboard input isn't a secondary access method — it's the primary one for a large population of users, including many people with motor disabilities, some users with low vision who pair a keyboard with a screen magnifier, and power users who simply navigate faster without a mouse.
Level A is the floor. Not the aspiration — the floor. A site that fails 2.1.1 isn't falling short of an advanced accessibility goal; it's failing the most basic tier of the standard.
The Trap Nobody Notices Until Someone's Stuck In It
Keyboard access alone isn't enough. You also need 2.1.2 No Keyboard Trap, another Level A criterion, which states that if keyboard focus can move into a component, there must be a way to move focus back out using only the keyboard — commonly Tab or Shift+Tab, or a documented alternative like Escape.
The mega-menu in the story above is the textbook example, but it's far from the only one. The most common sources of keyboard traps are:
- Custom modals — a dialog box built without proper focus management, where Tab cycles endlessly inside the modal, or worse, escapes the modal but leaves it visually open and confusing.
- Embedded third-party widgets — a chat widget, a video player, a map embed — that capture focus internally and never hand it back.
- Rich-text editors — WYSIWYG components that intercept every keystroke, including the ones meant to leave the field.
None of these are exotic edge cases. They're common patterns, built by teams who tested with a mouse and never once tried to leave their own component with nothing but a keyboard.
The Fix Nobody Sees Because It Was Deleted
Here's the failure that's almost certainly on your site right now, and it takes about thirty seconds to confirm: 2.4.7 Focus Visible, a Level AA criterion, requires that whenever an element receives keyboard focus, there's a visible indicator showing where focus is.
The single most common way sites break this rule is almost comically simple. A developer applies a CSS reset early in the project — often just to get rid of the browser's default blue outline because it "looked bad" — and writes something like:
:focus { outline: none; }
And that's it. That one line removes every native focus indicator from every interactive element on the entire site, and nothing replaces it. The link is still focusable. The button still receives keyboard focus. Tab still moves through the page in order. But there's no visual signal telling anyone where they are. A sighted keyboard user — including that same man from the mega-menu story, on a page that doesn't trap him but also doesn't show him anything — has to guess, or Tab blindly and hope.
The fix is not "add the outline back and accept it looks ugly." It's "replace it with a focus style that's actually visible and fits your design" — a colored ring, a background shift, a border, anything with sufficient contrast against its surroundings. The requirement isn't aesthetic minimalism versus accessibility. It's simply: focus must be visible. How it looks is your call.
Order Matters Too — Even When Everything Is "Reachable"
A site can pass 2.1.1 and 2.1.2 — every element is reachable, nothing traps focus — and still fail 2.4.3 Focus Order, a Level A criterion requiring that the sequence in which elements receive focus preserves meaning and operability.
This one sneaks in through CSS. A layout gets visually rearranged — a sidebar moved to display before the main content, a form field reordered with order or flex-direction — but the underlying DOM order never changes. Visually, the page reads top to bottom, left to right, in a sensible sequence. But Tab follows the DOM, not the rendered layout. A keyboard user tabbing through hits fields in an order that makes no visual sense: the submit button before the fields it submits, a confirmation checkbox before the terms it refers to. Every element is technically reachable. The experience is still broken.
New in WCAG 2.2: Don't Let Sticky Elements Eat the Focus
WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum), a Level AA criterion addressing a problem that didn't really exist at the scale it does now until sticky headers and footers became standard: a focused element must not be entirely hidden behind a sticky header, sticky footer, or cookie-consent banner.
Picture a long form with a sticky header pinned to the top of the viewport. A user tabs down through the fields. Eventually, the field that currently has focus scrolls up underneath that sticky header and disappears completely — still focused, still receiving input, but invisible. The user is typing into a field they can't see. This is now an explicitly named failure under WCAG 2.2, and it's extremely common on modern sites that layer sticky navigation on top of long pages without checking what happens to focus as the page scrolls.
The Five-Minute Test You Can Run Right Now
You don't need a screen reader or specialized tools to catch most of what's covered here. Do this:
- Put the mouse down. Actually move it away from your hand.
- Tab through your entire homepage, top to bottom, using only Tab and Shift+Tab.
- Tab through one key conversion flow — a contact form, a checkout, a signup.
- At every step, ask three questions:
- Can I see exactly where focus is right now?
- Can I reach and activate every interactive element — every link, button, menu, and form field?
- If I tabbed into something (a menu, a modal, a widget), can I always get back out?
If the answer to any of those is no at any point, you've just found a real WCAG failure — not a theoretical one, one you personally just experienced.
Why This Is the Highest-Leverage Fix on Your List
Keyboard issues deserve to be first on your remediation list, not because they're the only issues, but because of the return on effort:
- They're fast and cheap to fix — usually CSS for focus styles, sometimes a bit of JavaScript for focus management in modals and menus.
- They're caught by automated scanners and found by real users in the exact same testing session — including the kind of manual testing that shows up in litigation.
- They benefit far more people than a narrow "disability checkbox" suggests — power users, anyone with a temporary injury (a broken wrist, a hand in a cast), and every motor-disabled visitor who, like the man in the mega-menu, just wants to get in and back out again.
Where to Go From Here
Keyboard navigation and visible focus are not advanced accessibility topics. They're the basics — Level A and Level AA criteria that have existed since WCAG 2.1, reinforced by a new WCAG 2.2 criterion built specifically for the sticky-header era. And they're still failing on a huge share of live sites, because a CSS reset quietly deleted an outline, or a mega-menu was only ever tested with a mouse.
The test takes five minutes. The fixes are usually measured in hours, not weeks. There's no good reason to leave this one unresolved.
If you want a proper audit of your keyboard experience — every trap, every missing focus style, every out-of-order tab sequence, checked against 2.1.1, 2.1.2, 2.4.3, 2.4.7, and 2.4.11 — start here.