No Keyboard Trap ensures that users who navigate using a keyboard can move focus both into and out of components on a page. If users can move focus into a component, they must also be able to move focus away using only the keyboard.
Keyboard focus is the visual indicator (often an outline or highlight) that shows which element will respond to keyboard input. This criterion exists because many users rely entirely on keyboard navigation and may have no alternative way to escape an interaction once focus is trapped.
WCAG Success Criterion
2.1.2 No Keyboard Trap (Level A)
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.
If leaving a component requires more than standard navigation keys, users must be informed of the method for moving focus away.
Note:
Because keyboard traps can prevent users from accessing the rest of the page, all content must meet this criterion, even content used only to satisfy other success criteria. This is covered by Conformance Requirement 5: Non-Interference.
Why This Matters
Keyboard users cannot click elsewhere to escape an interaction. If focus becomes trapped inside a component, users may be unable to reach navigation, form controls, or critical actions such as submitting or cancelling a task.
This makes parts of the page unreachable and can effectively block task completion.
Keyboard traps commonly occur in:
- Custom widgets
- Embedded applications
- Modal dialogs
- Components that capture keyboard input without providing an exit
In screen readers, keyboard traps often prevent users from reaching landmarks, headings, or form controls outside the trapped region, even though that content still exists in the DOM.
Intent of the Criterion
This success criterion intends to ensure that content does not trap keyboard focus inside a subsection of the page.
Temporarily restricting focus can be appropriate, for example, within a modal dialog or interactive widget, but only if users can clearly and reliably exit using the keyboard.
When exiting requires a non-standard method (such as pressing Escape), users must be informed of that method before or when focus enters the component.
WCAG Criteria Affected
Keyboard traps primarily result in failures of:
- SC 2.1.1 Keyboard (Level A) — interactive content becomes unreachable
- SC 2.4.3 Focus Order (Level A) — focus order is interrupted or incomplete
These failures are about operability, not semantics themselves, although improper ARIA usage can contribute to keyboard traps.
Who This Helps
This criterion primarily supports:
- People who are blind and use screen readers
- People with motor or mobility impairments
- Users who cannot use a mouse or touch input
- Users of alternative input devices that rely on keyboard interaction
How Focus Normally Works
Keyboard focus typically follows the DOM order of focusable elements, such as links, buttons, and form controls. Users move through this order using Tab and Shift+Tab.
Keyboard traps often occur when scripts override this default behaviour without providing a way for focus to return to the normal tab sequence.
Examples
Calendar widget
A calendar widget allows keyboard navigation between dates and controls. Users can tab into the widget, interact with it, and continue tabbing to reach content that follows.
Puzzle or interactive applet
An applet captures keyboard input while active. Clear instructions explain which key (such as Escape) exits the interaction and returns focus to the page.
Modal dialog box
When a modal dialogue opens, focus moves into the dialog and remains there while it is active. Keyboard-accessible controls allow users to close the dialog and return focus to a logical place in the page.
Common Causes of Keyboard Traps
Keyboard traps are often introduced unintentionally, including when:
- JavaScript prevents the default behaviour for Tab or Shift+Tab
- Custom widgets manage focus internally but never release it
- Modals lack a keyboard-accessible close mechanism
- Embedded content (such as iframes or games) captures all keyboard input
- tabindex values are misused, especially
tabindex="-1"
Rule Description
Keyboard focus must not become trapped within any component. Users must be able to move focus away using standard navigation keys, or be clearly informed of the method for exiting when non-standard keys are required.
Standard navigation typically includes Tab and Shift+Tab. Arrow keys are only considered standard where they are already expected behaviour, such as in menus or radio groups.
The Algorithm (In Simple Terms)
- Navigate the page using only the keyboard
- Move the focus into each interactive component
- Attempt to move focus out using Tab or Shift+Tab
- If focus cannot leave:
- Check whether an alternative exit method (such as Escape) is provided and explained
- If not, the criterion fails
- If focus cannot be released at all, the criterion fails
How to Avoid Keyboard Traps
- Do not block Tab or Shift+Tab unless you also manage a clear focus exit
- Always provide a keyboard-accessible way to close modals
- Return focus to a logical element after exiting a component
- Avoid unnecessary use of tabindex
- Test custom components using only the keyboard
How to Test This
- Use only the keyboard to navigate the page
- Confirm you can tab into each interactive component
- Confirm you can tab out without using a mouse
- Verify Escape works where expected
- Check that focus returns to a logical location after exit
Wrapping Up
No Keyboard Trap is a foundational accessibility requirement. If users can enter a component but cannot leave it using the keyboard, the page fails basic operability. Temporary focus restriction is allowed, but only when users are clearly informed and can reliably escape. If users must reload, guess, or abandon the page to continue, the design fails this criterion.
