WCAG 2.1.2 No Keyboard Trap: How Keyboard Traps Affect Website Accessibility

What WCAG 2.1.2 No Keyboard Trap requires

WCAG 2.1.2 No Keyboard Trap is a Level A success criterion in WCAG 2.1. It says that when keyboard focus moves to a component, the user must be able to move focus away using only a keyboard interface. If leaving the component requires keys other than Tab, Shift+Tab or unmodified arrow keys, the page must tell the user which keys to use.

Why keyboard traps matter

Keyboard traps stop people who cannot use a mouse. That includes people with motor impairments and many screen reader users. A trapped user can become stuck on a dialog, a widget or embedded content. That blocks access to site navigation, forms or critical controls.

Common keyboard-trap examples

• Modal dialog with no keyboard-close control or no Escape handler.
• Custom widgets that capture Tab or arrow keys and never release focus.
• Interactive content inside an iframe that prevents Tab from leaving the frame.
• Focus moved to an off-screen element with tabindex values but no visible way out.
• Third-party components that intercept keys without exposing exit instructions.

How to test for a keyboard trap

Manual testing finds most traps. Use a plain keyboard. Do not use a mouse or touch.

Quick test steps

1. Load the page and press Tab repeatedly to reach the interactive area.
2. Try Shift+Tab to move focus back to the previous focusable element.
3. Press Tab and Shift+Tab from every focusable control inside the component.
4. Try Esc, Enter, Space and arrow keys where relevant.
5. If focus does not leave the component, note the exact sequence that traps focus.

What counts as failure

Fail if focus cannot be moved away using only keyboard operations. Also fail if the user must press nonstandard keys without on-screen instructions.

Root causes to look for

• JavaScript handlers preventing default for Tab or Shift+Tab.
• Misuse of tabindex (for example permanently setting tabindex=“-1” on many elements).
• Moving focus programmatically without offering a keyboard-accessible close or exit.
• Embedding third-party widgets that override keyboard behaviour.

Practical fixes and patterns

Fixes focus on behaviour, not only code. The goal is simple: the keyboard user must always be able to leave.

For modals and dialogs

• Provide a visible and keyboard-focusable close button. It must be reachable by Tab and have a clear label such as “Close dialog”.
• Allow closing with Escape. Add a keydown handler that closes the dialog and restores focus to the element that opened it.
• When you move focus into a dialog, set focus to the dialog container or the first focusable control. When closing, return focus to the activator.

For custom widgets

• Avoid globally capturing Tab and Shift+Tab. If you customise arrow keys, document the behaviour on-screen.
• Keep a clear focus order. Use natural document order where possible. Minimise use of positive tabindex values.
• Provide an obvious way to exit the widget, such as a focusable control labelled “Exit” or a keyboard shortcut that is described in the UI.

Minimal JavaScript example: close on Escape

This pattern ensures a keyboard way out. Attach a keydown listener while the dialog is open. On Escape, close and restore focus.

openButton.addEventListener('click', () => {
  openButton.setAttribute('aria-expanded', 'true');
  dialog.show();
  previousFocus = document.activeElement;
  dialog.querySelector('button.close').focus();
  document.addEventListener('keydown', onKeydown);
});

function onKeydown(e) {
  if (e.key === 'Escape') {
    document.removeEventListener('keydown', onKeydown);
    dialog.hide();
    previousFocus.focus();
  }
}

Use this as a simple starting point. The important parts are focus placement, a keyboard-close action and restoring focus when done.

Testing across browsers and assistive tech

Different browsers and screen readers can expose different focus behaviours. Test in the browsers your users use. Also test with at least one screen reader or speech access method used by your audience. Typical combinations include NVDA or JAWS on Windows and VoiceOver on macOS.

Developer and QA checklist

• Can a keyboard-only user reach and leave every interactive component?
• Does every modal or widget include a keyboard-accessible close or exit?
• Are nonstandard keys required documented in the UI?
• Are tabindex values limited and used consistently?
• Do focus moves restore to the activating element after close?
• Have you tested with common screen readers and different browsers?

Summary

WCAG 2.1.2 No Keyboard Trap focuses on one simple promise: keyboard users must always be able to move focus away. Find where code or widgets stop Tab, Shift+Tab or Esc from working. Then add clear, keyboard-accessible ways to exit and restore focus. That removes traps and keeps your site usable for people who cannot use a mouse.