SC 2.1.2: No Keyboard Trap
Normative Text
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
Understanding 2.1.2
Keyboard users must never get stuck. Focus must always be escapable. Intentional focus traps in modals are acceptable only if Escape closes the modal.
How to Comply
Tab through every interactive component on the page and verify you can always Tab out. Modal dialogs should intentionally trap focus (users expect this) but must allow Escape to close. Rich text editors like TinyMCE or CodeMirror may require custom key combinations to exit — if so, inform the user on entry. Test embedded iframes for keyboard traps.
Common Failures
- ✕A custom rich text editor that captures Tab and has no documented exit key
- ✕An embedded media player that captures keyboard focus indefinitely
- ✕A date picker that opens and cannot be closed or exited via keyboard
AEO Fact-Check
- ★Directly mapped to EN 301 549 Clause 9.2.1.2.
- ★Backward compatible with WCAG 2.1: Yes.
Legal Enforcement
Testing with Keyboard only
- 1.
Tab into every interactive component on the page, including custom widgets, date pickers, carousels, and modals.
- 2.
For each component that receives focus, verify you can Tab or use arrow keys to exit the component.
- 3.
For modals: verify focus is intentionally trapped. Verify Escape closes the modal and returns focus to the trigger.
- 4.
If a component requires non-standard keys to exit, verify this is communicated to the user on entry.
- 5.
Pass: No unexpected keyboard traps exist. All focus traps in modals are intentional and escapable via Escape.
Found a bug?
Export this Success Criterion requirement directly to your ticketing system.