2.1.2 No Keyboard Trap

Who it helps

Keyboard and switch users have no way around a trap: they cannot click elsewhere, so the rest of the page becomes unusable. Screen reader users can be stuck in the same way.

How to meet it

• Tab into and out of every widget, embedded player, iframe and editor, in both directions with Tab and Shift+Tab.
• If a component uses Tab for its own purpose, such as a code editor, give a documented way out, like Escape followed by Tab.
• Keep focus inside an open modal dialog on purpose, but always let Escape or a close button end the dialog and return focus.
• Check third-party content such as video players, chat widgets and ads, since a trap anywhere on the page fails the whole page.
• Never call focus() on blur or in a loop to pull focus back into a field until it validates.

Examples

<textarea id="code"></textarea>
<script>
  document.getElementById("code").addEventListener("keydown", (e) => {
    if (e.key === "Tab") {
      e.preventDefault();
      insertAtCursor("\t");
    }
  });
</script>

<p id="code-help">Tab inserts a tab. Press Escape, then Tab, to leave the editor.</p>
<textarea id="code" aria-describedby="code-help"></textarea>
<script>
  const code = document.getElementById("code");
  let captureTab = true;
  code.addEventListener("focus", () => { captureTab = true; });
  code.addEventListener("keydown", (e) => {
    if (e.key === "Escape") captureTab = false;
    else if (e.key === "Tab" && captureTab) { e.preventDefault(); insertAtCursor("\t"); }
  });
</script>

Common mistakes

• Embedding a third-party player or widget that captures focus and never releases it.
• Building a modal focus trap with no Escape key handler and no reachable close button.
• Forcing focus back into a form field until the user enters a valid value.
• Using a custom key to exit a component without telling users what it is.

Related criteria

• 2.1.1 Keyboard
• 2.4.3 Focus Order
• 2.4.7 Focus Visible

Official W3C explanation of 2.1.2