2.1.2 No Keyboard Trap

What does it mean?

A keyboard trap is a place where focus goes in but cannot come out: the user tabs into an embedded video player, a map or a rich text editor and from then on every key press stays inside it. The only way out is to reload the page, which a keyboard user may not be able to do comfortably.

Standard keys (Tab, Shift+Tab, arrow keys, Escape) should always lead out. If a component needs a different key to exit, the user must be told how, for example with a visible hint next to the editor.

Who does it help?

• Screen reader users who navigate entirely by keyboard
• People with motor impairments who rely on keyboard or switch access
• Anyone who cannot easily reach a mouse or reload the page

Common failures

• An embedded third-party player or widget that captures Tab and never releases focus
• A modal dialog that keeps focus inside but cannot be closed with Escape or a reachable close button
• A code or text editor that uses Tab for indentation and gives no other way to leave
• A script that moves focus back to a field whenever it loses focus (for example during validation)

How we test it

• evidence Evidence: our scanner collects material such as screenshots, lists and measurements.

Test question: Can focus always leave every component again with the keyboard (watch embedded players and dialogs)?

A person decides every criterion. No criterion ever passes automatically.

How to fix it

field.addEventListener('blur', () => {
  if (!field.value) field.focus(); // forces focus back
});

<p id="editor-hint">Press Escape, then Tab, to leave the editor.</p>
<textarea aria-describedby="editor-hint"></textarea>

<script type="module">
  const ta = document.querySelector('textarea');
  let escaped = false;
  ta.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') { escaped = true; return; }
    if (e.key === 'Tab' && !escaped) { e.preventDefault(); insertTab(ta); }
    escaped = false;
  });
</script>

The editor still offers its special behaviour, but there is a documented, keyboard-only way out.

Practical tips

• Tab through every embedded iframe (video, maps, booking widgets, chat) and confirm you can tab past it in both directions.
• In modal dialogs, keeping focus inside is fine, as long as Escape or a close button ends the dialog and returns focus.

Guides and patterns on this

• Getting there without a mouseMany people use the web without a mouse: with a keyboard, switches, voice control or a screen reader. Here is what has to work for them and how to manage focus properly in modern web apps.
• Cookie banners that lock no one outThe cookie banner is often the first thing visitors meet, and for some the last: if it cannot be used with a keyboard or screen reader, the site is closed to them. Here is how to get it right.
• Modal dialogFocus moves in on open, Escape closes, focus returns.

Official source

Understanding WCAG 2.2 at the W3C: 2.1.2 No Keyboard Trap