WCAG 2.1.2: No Keyboard Trap

Who this helps

A keyboard trap does not just inconvenience one group — it can lock the entire page for anyone who does not, or cannot, use a mouse. When focus cannot escape, there is often no recovery short of reloading the page.

What the requirement covers

The criterion is best remembered as one sentence: you may move focus in, but you must always be able to move focus out using the keyboard alone. “Standard exit methods” are the keys users already expect — Tab and Shift+Tab to leave in either direction, and very often Escape to dismiss a layer. If those work everywhere, you pass with nothing more to do.

• →Focus can move in. It is fine — and normal — for keyboard focus to enter a component: a menu, a dialog, a date picker, an editor, an embedded player.
• →Focus must move out. From wherever focus lands inside that component, the user must be able to move it away again using only the keyboard, without resorting to a mouse.
• →Standard exits should just work. Tab and Shift+Tab should carry focus out of the component in the natural reading order; for overlays, Escape should dismiss them and return focus to a sensible place.
• →Non-standard exits must be advertised. If — and only if — leaving requires something other than Tab, Shift+Tab, arrow keys, or Escape, the component must tell the user which key to press to get out.

Focus containment vs. a keyboard trap

There is an important distinction that trips people up. Deliberately containing focus inside an open modal dialog — so Tab cycles through the dialog's own controls instead of reaching the page behind it — is the recommended pattern for modals, and it is perfectly compliant as long as the user can leave the dialog with the keyboard. Provide Escape and a keyboard-reachable Close button, and the containment is a feature, not a trap. Remove every keyboard exit and the same code becomes a violation. The test is always the same: can the user get out with the keyboard alone?

How it relates to nearby criteria

2.1.2 sits alongside 2.1.1 Keyboard, which is about being able to operate functionality with the keyboard at all, and 2.4.3 Focus Order, which is about focus moving in a sensible sequence. 2.1.2 is narrower and specific: it is only about being able to leave a component you have entered.

Pass and fail examples

Code examples

The trap vs. the escapable modal

The failure is almost always a keydown handler that blocks the exit keys. The fix is to let Escape close the layer and let Tab wrap within the dialog while a Close button provides an obvious way out.

<!-- ✗ Trap: Escape is blocked, Tab is preventDefaulted, no way out -->
<div class="modal" role="dialog">
  <input type="text" placeholder="You're stuck here" />
  <button>Can't escape</button>
</div>
<script>
  modal.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') e.preventDefault()  // blocks the exit
    if (e.key === 'Tab') e.preventDefault()     // no way forward or back
  })
</script>

<!-- ✓ Compliant: focus is contained but Escape and Close both leave -->
<div class="modal" role="dialog" aria-modal="true" aria-labelledby="t">
  <h2 id="t">Settings</h2>
  <button class="close" aria-label="Close dialog">×</button>
  <input type="text" />
  <button type="submit">Save</button>
</div>

A reusable focus-trap that still lets users out

A good focus trap only wraps Tab at the boundaries of the dialog; it never intercepts Escape, and it restores focus to the element that opened the dialog when it closes.

function trapFocus(container, onClose) {
  const previouslyFocused = document.activeElement
  const focusables = container.querySelectorAll(
    'a[href], button:not([disabled]), input:not([disabled]),' +
    'select, textarea, [tabindex]:not([tabindex="-1"])'
  )
  const first = focusables[0]
  const last = focusables[focusables.length - 1]
  first?.focus()

  container.addEventListener('keydown', (e) => {
    // Escape ALWAYS leaves — never block it
    if (e.key === 'Escape') { onClose(); return }

    if (e.key === 'Tab') {
      // Only wrap AT the edges; normal Tab moves freely inside
      if (e.shiftKey && document.activeElement === first) {
        e.preventDefault(); last.focus()
      } else if (!e.shiftKey && document.activeElement === last) {
        e.preventDefault(); first.focus()
      }
    }
  })

  return () => previouslyFocused?.focus() // restore focus on close
}

Advising the user of a non-standard exit

If a component genuinely needs a special key to leave — some embedded editors capture Tab to insert indentation — the criterion still passes as long as you tell the user how to get out, both visibly and to assistive technology.

<div role="group" aria-labelledby="editor-label"
     aria-describedby="editor-exit">
  <span id="editor-label">Code editor</span>
  <textarea aria-describedby="editor-exit"></textarea>
  <!-- The advisory the criterion requires -->
  <p id="editor-exit">
    Tab inserts a tab character. Press Escape, then Tab,
    to move focus out of the editor.
  </p>
</div>

Interactive demo

Try both widgets below with your keyboard. The trapped one blocks Tab and Escape so focus cannot leave — a genuine 2.1.2 failure — while the accessible one contains focus for usability but lets you press Esc or use the Close button to get out. A Release control outside the trap is always available so the real page never actually locks up.

Common failures

• ✗A modal or overlay that loops focus internally with no Escape handler and no keyboard-reachable Close button.
• ✗A custom widget whose keydown listener calls preventDefault on Tab without providing any alternative exit.
• ✗Calling element.focus() on blur to force focus back — for example on a validation error — so the user can never leave the field.
• ✗Embedded third-party content (legacy Flash, some PDF/plugin embeds, or an iframe widget) that captures the keyboard and never releases it.
• ✗Dropdown menus, date pickers, and rich text editors that swallow Tab and Escape, stranding focus inside them.
• ✗Requiring a non-standard key to exit a component without ever advising the user which key to press.
• ✗A media player whose controls trap focus so Tab never reaches the content after the player.
• ✗Blocking the Escape key globally 'to prevent accidental closes', which removes the standard exit from every layer at once.

How to test for 2.1.2

1. 1

   Put the mouse away entirely

   Unplug or ignore the pointer and drive the whole page with Tab, Shift+Tab, arrow keys, and Escape. Testing keyboard traps only works if you truly cannot fall back to clicking.

2. 2

   Tab into and out of every component

   Reach each menu, dialog, widget, embed, and media player with Tab, then confirm Tab and Shift+Tab carry focus back out again. If focus never leaves, you have found a trap.

3. 3

   Open every modal and try Escape and Close

   For each overlay, confirm that Escape dismisses it and that a Close button is reachable by keyboard and returns focus somewhere sensible on the page.

4. 4

   Exercise embedded and third-party content

   Tab into iframes, video players, date pickers, and any plugin or widget you did not build. These are the most common traps because their exit behaviour is outside your code.

5. 5

   Watch for forced focus and blocked keys

   Look for fields that snap focus back on blur (e.g. on validation) and for handlers that preventDefault on Tab or Escape. Both silently remove the standard exit.

6. 6

   Verify any non-standard exit is advertised

   If a component legitimately needs a special key to leave, confirm the instruction is actually presented to the user — visibly and via an accessible description — not just buried in documentation.

Automated tools such as axe DevTools, Pa11y, and Lighthouse can flag some suspicious focus patterns, but keyboard traps are fundamentally a manual test — a human pressing Tab is the only reliable check. For a structured audit, work through the full WCAG 2.2 checklist.

Frequently asked questions