Goal
Prevent keyboard users from getting stuck.
Success Criterion · WCAG 2.1.2
No Keyboard Trap
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.
Level AWCAG 2.0Operable2.1 · Keyboard Accessible
Copy button ready
What to do
If focus can move into a component via keyboard, users must also be able to move focus out using keyboard.
Why it matters
Keyboard traps make pages unusable for keyboard-only users and screen reader users.
Success criterion
What WCAG 2.1.2 requires
Summarized directly from the official Understanding document so teams can quote the requirement accurately.
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.
Intent
Why WCAG created this requirement
- Keyboard traps block navigation and task completion.
- Traps commonly occur in custom widgets, embedded content, and poorly implemented modals.
- Users must have a clear and reliable way to exit components.
Benefits
Who gains when you pass
- Keyboard-only users can navigate freely through the page.
- Screen reader users can recover from entering complex widgets.
- Users with motor impairments avoid forced, frustrating navigation loops.
Why it matters
User impact when this criterion fails
Summaries drawn from the Understanding document help you socialize impact statements with product stakeholders.
Users may be unable to reach essential controls like Submit or Close.
Users may need to refresh/leave the page to recover, causing data loss.
Screen reader users may be stuck inside an embedded widget with no exit.
Overview
Users must never get “trapped” inside a widget, modal, iframe, or other component. Focus must be able to leave the component using standard keyboard mechanisms (typically Tab/Shift+Tab, Escape, etc.). If a non-standard exit method is required, users must be told.
- Ensure modals trap focus intentionally but allow Escape/close and restore focus to trigger.
- Avoid custom key handling that prevents Tab/Shift+Tab from moving focus.
- If an iframe or embedded widget traps focus, provide a bypass or clear exit control.
- Announce non-standard exit methods in visible text and for screen readers.
Reference: All summaries and highlights originate from Understanding WCAG 2.1.2 and the W3C quick reference.
Fast facts
- Conformance level
- Level A
- WCAG version introduced
- WCAG 2.0
- Principle
- Operable
- Guideline
- 2.1 · Keyboard Accessible
Examples
Make success tangible for teams
Share pass/fail snapshots to coach designers, engineers, QA, and content authors.
Modal dialog
Pass
Tab cycles inside modal, Escape closes, focus returns to the “Open modal” button.
Fail
Focus enters modal but cannot reach the close button or exit the modal using keyboard.
Custom widget
Pass
Widget allows Tab to move to next focusable element outside the widget.
Fail
Widget intercepts Tab and keeps focus cycling with no escape.
Embedded iframe
Pass
Iframe has a clear “Skip embedded content” link before it.
Fail
Iframe traps focus with no way to return to the host page.
Evidence to keep
Document conformance decisions
Capture artifacts for VPATs, procurement reviews, and regression testing.
- Document modal focus management standards (open focus target, trap rules, return focus).
- Record known third-party widgets and how keyboard escape is handled.
Official resources
Deep dives and supporting material
Keep these links handy when writing acceptance criteria or responding to audits.
Implementation checklist
Capture progress and blockers
- Audit custom components for key handling that blocks Tab/Shift+Tab.
- Implement accessible modal behavior: focus trap inside, Escape closes, focus returns to trigger.
- Ensure menus, popovers, and widgets support Escape to close (where appropriate).
- Avoid capturing keyboard events globally in ways that prevent standard navigation.
- Provide a visible and keyboard-accessible “Close” or “Exit” control.
- If a special exit method is required, present instructions next to the component.
Testing ideas
Prove conformance with evidence
- Tab into each interactive component and verify you can tab out (forward and backward).
- Test modals: open, tab through controls, close with Escape and with Close button, confirm focus returns.
- Test embedded widgets/iframes to ensure there is a keyboard path out.
- Use a screen reader to verify navigation is not trapped.
Related success criteria