WCAG 2.1.2 No Keyboard Trap (Level A) says that whenever keyboard focus can move into a part of your page, the user must be able to move it back out using only the keyboard. If leaving needs more than Tab or arrow keys, you have to tell the user how. In short: nothing on the page may strand a keyboard user.

What 2.1.2 actually requires

The official wording from the W3C Understanding document is precise:

“If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”

Two ideas are bundled here. First, every component you can enter with the keyboard must also be one you can exit with the keyboard — no dead ends. Second, if the exit isn’t the obvious Tab or arrow keys (say, a widget that needs Alt+F10), you must announce that escape method, because a stuck user can’t guess it.

Note what 2.1.2 does not demand. It doesn’t require logical focus order, visible focus, or that everything be operable — those are separate criteria. 2.1.2 is the narrow one: can the user get out? A page can fail it with a single broken widget while passing everything else.

Who this protects

The W3C Benefits section names the people affected directly: “People who rely on a keyboard or keyboard interface to use the web including people who are blind and people with physical disabilities.”

That covers more users than it sounds:

  • Screen reader users (JAWS, NVDA, VoiceOver) navigate almost entirely by keyboard. A trap can lock them out of the entire page.
  • People with motor disabilities who can’t use a mouse and rely on the keyboard, switch devices, sip-and-puff controls, or voice software that drives keyboard commands.
  • People with tremors or limited dexterity for whom precise mouse targeting is impossible.

For a sighted mouse user, a keyboard trap is invisible — they click past it and never notice. That’s exactly why it survives into production: the people building and QA-ing the site never feel it. See our keyboard navigation guide for how focus should flow.

Concrete failure examples (and the fix)

Keyboard traps almost always live in interactive widgets and third-party embeds. The classic cause, documented in W3C Failure F10, is combining content formats — like a plug-in or embedded app — in a way that swallows focus and won’t give it back.

1. The modal that only closes with a mouse. A “dialog” opens, correctly holds focus inside (good — that’s intended behavior), but the only way to close it is clicking the X. Tab cycles forever inside the dialog; Esc does nothing. The keyboard user is stuck.

The fix is a keyboard-operable exit. Wire up Esc and make sure the Close button is a real focusable element:

dialog.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') closeDialog();
});
// And the close control must be keyboard-reachable:
// <button type="button" aria-label="Close" onClick={closeDialog}>×</button>

2. The custom date picker you can enter but not leave. Focus drops into a calendar grid, arrow keys move between dates, but Tab is captured and never lands back on the page. Fix: let Esc close the picker and return focus to the input, and don’t preventDefault on the Tab key once focus reaches the last control.

3. The video or third-party embed that eats Tab. An embedded player or <iframe> widget grabs focus and the only documented way out is an obscure shortcut. If you genuinely must use a non-standard exit, 2.1.2 permits it — but only if you tell the user. W3C’s own examples include a rich text editor and a puzzle applet that announce “Press Alt+F10 to leave.”

4. The cookie/consent banner with no keyboard exit. A banner appears, traps focus, and offers only a mouse-clickable X. This pattern is rampant — and doubly bad, because the keyboard user can’t reach the page or record a consent choice. Give it an Esc handler and focusable Accept/Reject buttons.

The most reliable cause of all four: code that calls e.preventDefault() on the Tab key (or sets tabindex in a loop) without ever releasing it. The fix is rarely a workaround — it’s rebuilding the widget so focus can leave. That’s hands-on remediation, not a setting you toggle.

Why an overlay won’t save you

Accessibility overlay widgets are sold as a one-line fix, but a keyboard trap is structural — it lives in the JavaScript that captures the Tab key. An overlay can’t un-capture an event another script is already swallowing, and overlays frequently add their own focus problems. In 2024 more than 1,000 businesses with an accessibility widget installed were sued anyway — over a quarter of all cases. Curbcut is deliberately anti-overlay: we fix the trapping code itself.

How to test for keyboard traps

You don’t need expensive tools — you need your keyboard and a few minutes.

  1. Put the mouse away. Physically. The point is to feel what a keyboard-only user feels.
  2. Tab through the entire page from the top: header, nav, every widget, every embed, footer. Trigger the interactive things — open menus, modals, date pickers, the cookie banner, the chat widget, the video player.
  3. At each component, try to leave. Press Tab, then Shift+Tab, then Esc. If focus can’t escape any element it entered, you’ve found a trap.
  4. Watch the focus indicator. If you can’t tell where focus is, fix 2.4.7 Focus Visible first or you’ll miss traps.
  5. Test third-party embeds specifically — players, maps, chat, consent tools. These are where traps hide, and they’re often outside your own code.

Automated scanners are weak here: a tool can’t reliably feel being stuck the way a human tester can. This is exactly the kind of issue that demands manual testing — tab order and exit behavior have to be walked by a person.

This page is general information, not legal advice. For your specific situation, consult a qualified attorney.

Keyboard inaccessibility is one of the most commonly cited problems in ADA web complaints, and a trap is its most severe form — it can make a page completely unusable for a keyboard-dependent user. Per UsableNet’s 2024 Year-End Report, over 4,000 ADA digital-accessibility lawsuits and demand letters were tracked in 2024, with New York and Florida the most active jurisdictions. Plaintiff testers document keyboard barriers because they’re easy to capture and undeniable on video.

U.S. courts and the DOJ generally treat WCAG 2.1 AA as the practical benchmark under ADA Title III, and 2.1.2 is a Level A criterion — the floor, not the ceiling. A failure here is hard to defend because it’s binary: either a keyboard user can leave the widget or they can’t. For context on what’s being filed, see our settlements and costs breakdown and how to avoid an ADA lawsuit.

Get keyboard traps found and fixed

Traps are invisible to a mouse and to most scanners, which is exactly why they survive into production and into demand letters. Curbcut’s testers tab through your real pages by hand, flag every spot a keyboard user gets stuck, and our developers rebuild the offending widget so focus can always leave. Start with a free scan and we’ll show you where your site traps people — then remediate it by hand, no widget required.