WCAG 2.2 - Success Criterion
2.1.2 No Keyboard Trap
Description
If keyboard focus can be moved to a component using a keyboard interface, then focus must be able to be moved away from that component using only a keyboard. If moving focus away requires more than standard navigation keys, users must be informed of the method. This ensures that keyboard users cannot become stranded inside a widget or page region with no way to escape.
How To Test
- Navigate to the page using only the keyboard (Tab and Shift+Tab).
- Tab into each interactive widget, embedded iframe, media player, and modal dialog.
- After entering each component, attempt to exit by pressing Tab, Shift+Tab, and Escape.
- Verify that focus moves away from the component without requiring mouse interaction.
- If a component uses a non-standard exit key, check that this is communicated to the user through visible instructions or an accessible announcement.
- For modal dialogs, confirm that Escape closes the dialog and returns focus to the element that opened it.
Testing Tools
- axe DevTools — Browser extension. Install from official page, open DevTools, go to axe tab, run scan. Look for focus order, keyboard trap, and focus visible violations.
- NVDA — Free screen reader for Windows. Download and install, then open Firefox and navigate the demo using Tab, Shift+Tab, arrow keys, and Enter. Listen for focus announcements.
- Browser DevTools Accessibility Inspector — Built into all browsers. Right-click on a focused element, select "Inspect", open DevTools, go to Accessibility tab to see the accessibility tree and focus properties.
Demo
This code demonstrates a keyboard trap pattern. A live implementation would be unsafe for keyboard users — do not interact with it. The modal below only has a "Yes" button and no Escape handler:
This code demonstrates the safe pattern. The modal has both a "Yes" button and an explicit "Cancel" button, plus an Escape key handler:
Code
Code
This code uses positive tabindex values to force a specific focus order. When tabbing, focus skips to these elements and can become difficult to predict. Do not implement this pattern:
This code uses the natural tab order (elements in DOM order). Focus moves predictably through the page in the order elements appear in HTML:
Code
Code
This code demonstrates a text editor that traps Tab key for indentation. Users cannot reach the submit button using only the keyboard:
This code demonstrates a text editor that allows Tab to exit when at the content boundary. Instructions inform users how to exit:
Code
Code
WCAG Techniques
- Failures: F55 (Using script to make a control unrecoverable when focus is moved away), F85 (Using nested interactive form controls)
- Success Techniques: H4 (Creating a logical tab order through links, form controls, and objects), G21 (Ensuring that users are not trapped in content), ARIA6 (Using aria-label to provide labels for objects), ARIA11 (Using ARIA landmarks to identify regions of a page)
Fail Explanation
A keyboard trap occurs when a user tabs into an element - such as an embedded media player, a third-party widget, or a custom dialog - and cannot move focus out using Tab, Shift+Tab, Escape, or any other standard key. For keyboard-only users, including many screen reader users, a trap makes the rest of the page permanently inaccessible during that session. Even a single trapped component is a critical blocker because it forces the user to refresh the page and lose their context.
Pass Explanation
A passing implementation ensures that pressing Tab, Shift+Tab, or Escape always allows focus to leave any component and continue navigating the page. When a modal dialog is open, focus may be intentionally constrained within the dialog, but a clearly labeled close mechanism (such as an Escape key handler and a visible Close button) must still allow the user to dismiss the dialog and return focus to the triggering element.
Notes
An intentional focus lock inside a modal dialog is acceptable - and often desirable - as long as the dialog itself is dismissible via keyboard. The failure condition is a component from which there is no keyboard escape at all, not one that constrains focus to a logical region while still providing an exit.
Techniques
WCAG techniques used in this demo: G21
Suggested Solutions & References
Curated from 9 real-world audit findings and official WCAG guidance.