Level AOperable
2.1.2

No Keyboard Trap

If keyboard focus can move into something, it must be able to move back out, so no one gets stuck in a widget or popup.

In plain English

This is the natural partner to the keyboard rule: not only must you be able to Tab into things, you must be able to Tab back out. If focus goes into a modal, a video player, or a menu and then gets stuck cycling forever inside it, a keyboard user is trapped, with no mouse to rescue them.

The fix is usually straightforward: let Tab move out normally, and make Escape close overlays and return focus to where it was.

Who this is for

  • Keyboard and screen-reader users, who have no mouse to click their way out of a stuck widget.
  • Everyone, occasionally, when a poorly built popup hijacks the keyboard.

What “good” looks like

Focus enters, moves around, and can always leave.

Open a modal → Tab cycles through its buttons → Escape closes it
  and returns focus to the button that opened it.        ✓

Tab into a video player → Tab continues past it to the
  next link on the page (not stuck on the controls).     ✓

Where stores get it wrong

Custom modals that loop focus with no Escape, third-party chat or review widgets that swallow the keyboard, and embedded players that never let Tab move on. If you find focus stuck anywhere during a keyboard pass, it is on the common failures list and needs fixing before checkout can be completed by keyboard.

How to meet it

Techniques the W3C accepts as sufficient (summarized). Follow a link for the full method.

Common mistakes

Patterns the W3C lists as failures of this criterion. Avoid these.

Frequently asked questions

What is a keyboard trap?+

A keyboard trap is any part of a page you can Tab into but cannot Tab out of using the keyboard. Success Criterion 2.1.2 (Level A) forbids this: focus must always be able to move away using standard keys (Tab, or documented keys).

What commonly causes keyboard traps?+

Modal dialogs that keep focus cycling inside them with no way out, embedded media players or third-party widgets that capture the keyboard, and custom date pickers or menus with broken focus handling.

How do I test for a keyboard trap?+

Tab through the whole page. If focus enters a widget (a modal, a video player, a menu) and you cannot Tab or Escape your way back out to the rest of the page, that is a trap and it fails.

Reference

This is a plain-language explainer. The authoritative source is the W3C Web Content Accessibility Guidelines (WCAG) 2.2.

WCAG 2.2 © W3C. Excerpts are paraphrased; see the linked documents for the normative text.

Not sure if your store passes 2.1.2?

A human auditor checks this and every other criterion against your live store, and documents the result.

Book an audit