Skip to main content
Accessibility.com, LLC
Category: Input and Navigation

No Keyboard Trap

Also known as: WCAG Success Criterion 2.1.2, SC 2.1.2, Keyboard Trap
Simply put

No Keyboard Trap means that people using only a keyboard should be able to move focus away from any part of a web page after moving to it, without getting stuck. A keyboard trap occurs when a user can navigate into a component but cannot leave it using the keyboard alone, which blocks people who rely on keyboards or keyboard-emulating assistive technology. Meeting this requirement is one part of making content usable without a mouse.

Formal definition

No Keyboard Trap is WCAG Success Criterion 2.1.2, a Level A criterion under the Keyboard Accessible guideline. It requires that if keyboard focus can be moved to a component of the page using a keyboard interface, then focus can also be moved away from that component using only a keyboard interface; and if moving focus away requires more than unmodified arrow or tab keys or other standard exit methods, the user must be advised of the method for doing so. The criterion appears in WCAG 2.0 and is carried forward in later versions (2.1 and 2.2). Common failure cases include modal dialogs, embedded plug-ins, or custom widgets that capture focus without providing a keyboard-operable way out. This criterion should be verified through manual keyboard testing and testing with assistive technology, as automated tools detect only a portion of keyboard-related issues; conformance with this criterion alone does not guarantee overall accessibility or legal compliance. This entry is informational and not legal advice.

Why it matters

Many people navigate the web without a mouse. This includes people with motor disabilities who use only a keyboard, people who rely on assistive technologies such as screen readers that emulate keyboard input, and people using alternative input devices that map to keyboard commands. When a component captures keyboard focus and provides no keyboard-operable way to leave it, these users can become stuck, unable to reach the rest of the page. In practical terms, a keyboard trap can render an entire page or task unusable for someone who cannot use a pointing device, even if every other part of the site is well built.

Keyboard traps commonly appear in modal dialogs, embedded plug-ins, and custom widgets that manage focus without giving users a standard way out. Because a single trapped component can halt progress entirely, this failure has an outsized impact relative to how contained it may look during casual review. WCAG treats No Keyboard Trap as a Level A criterion, the most basic conformance level, which reflects how fundamental keyboard operability is to overall accessibility.

Addressing keyboard traps is one part of making content usable without a mouse, but meeting this criterion alone does not guarantee an accessible experience or legal compliance. It should be considered alongside the broader set of keyboard and assistive technology requirements. This entry is informational and not legal advice; organizations with compliance questions should consult qualified legal counsel and current agency guidance.

Who it's relevant to

Keyboard and assistive technology users
People who navigate with a keyboard alone, or with assistive technologies that emulate keyboard input, are the users most directly affected. A single trapped component can prevent them from completing a task or reaching the rest of a page, making this criterion central to their ability to use a site at all.
Front-end developers and engineers
Developers who build modal dialogs, custom widgets, embedded plug-ins, and other interactive components are responsible for ensuring focus can always be moved away using the keyboard, and for advising users of any non-standard exit method. These components are the most common sources of keyboard traps.
QA testers and accessibility specialists
Those who evaluate conformance need to confirm SC 2.1.2 through manual keyboard testing and testing with assistive technology, since automated tools detect only a portion of keyboard-related issues. They play a key role in catching traps before release.
UX and interaction designers
Designers who specify how components such as dialogs and menus behave can prevent traps by planning keyboard-operable entry and exit paths, and by documenting any non-standard exit methods that must be communicated to users.
Compliance officers and legal counsel
Because No Keyboard Trap is a Level A criterion, it is often part of accessibility targets referenced in policies and settlements. Meeting it alone does not guarantee overall accessibility or legal compliance, so these stakeholders should treat it as one element of a broader program and consult current agency guidance where applicable.

Inside No Keyboard Trap

WCAG Success Criterion 2.1.2 (No Keyboard Trap)
A Level A success criterion under WCAG 2.0 (retained in 2.1 and 2.2) requiring that if keyboard focus can be moved to a component using a keyboard interface, focus can also be moved away from that component using only the keyboard.
Keyboard interface
The means by which a user operates content using key-based input, including standard keyboards, on-screen keyboards, and assistive technologies that emulate keyboard input. The criterion concerns whether such input can both enter and exit a component.
Keyboard trap
A condition in which a keyboard user can navigate into a component (such as a widget, embedded media player, or dialog) but cannot navigate back out using the keyboard alone, leaving the user stuck.
Standard exit methods
The criterion notes that if focus cannot be moved away using standard navigation keys (such as Tab or arrow keys), the user must be advised of the method for moving focus away. Where a non-standard exit method is used, the user should be informed of it.
Relationship to keyboard operability
This criterion works alongside SC 2.1.1 (Keyboard), which addresses whether functionality is operable by keyboard at all; 2.1.2 specifically addresses the ability to move focus out of components once it has entered them.

Common questions

Answers to the questions practitioners most commonly ask about No Keyboard Trap.

Does meeting the No Keyboard Trap requirement mean my site is fully keyboard accessible?
No. No Keyboard Trap (WCAG 2.0 Success Criterion 2.1.2, Level A) specifically addresses whether keyboard focus can move away from a component, so that a user is not trapped in one part of the interface. It does not guarantee that all functionality is operable by keyboard, that focus order is logical, or that focus is visible. Those concerns are covered by separate success criteria such as Keyboard (2.1.1), Focus Order (2.4.3), and Focus Visible (2.4.7). Passing this one criterion is necessary but not sufficient for overall keyboard accessibility, and manual testing with a keyboard and assistive technology is generally needed to confirm a usable experience.
If a keyboard user can escape a component using a standard key like Tab or Escape, is that always enough to satisfy No Keyboard Trap?
Not necessarily. The criterion allows movement away from a component using an unmodified standard method such as Tab or arrow keys, but where a non-standard exit method is required, the user must be advised of that method. If a component traps focus and the way out is not a standard key and is not communicated to the user, the requirement is generally not met. The key point is that a user relying on a keyboard must be able to move focus out of a component and must know how to do so if the method is unusual.
How can I test a page for keyboard traps?
A common approach is to set the mouse aside and navigate the entire page using only the keyboard, typically the Tab and Shift+Tab keys, along with arrow keys and Escape where relevant. Move focus into each interactive component, then confirm you can move focus back out again without becoming stuck. Pay particular attention to custom widgets, modal dialogs, embedded media players, and third-party or plugin content. Because automated tools detect only a portion of accessibility issues and often cannot reliably identify keyboard traps, manual keyboard testing, ideally combined with assistive technology testing, is generally recommended.
Which components are most likely to cause keyboard traps?
Keyboard traps commonly arise in custom or scripted components where default browser behavior has been overridden, such as custom modal dialogs, date pickers, rich text editors, carousels, and menus. Embedded third-party content, including some media players and plugins, can also trap focus. Modal dialogs that intentionally hold focus can become traps if they do not provide a clear, standard way to close and return focus to the page. Reviewing these interactive patterns with keyboard-only navigation is often where testing effort is best concentrated.
How should a modal dialog handle focus to avoid a keyboard trap?
A modal dialog generally needs to allow the user to close it and move focus back to the underlying page, commonly through the Escape key or a clearly reachable close control. While focus is often intentionally confined within an open modal so users do not interact with obscured background content, this confinement should not prevent the user from dismissing the dialog and continuing. If a non-standard method is required to exit, the user should be informed of it. Designers should distinguish deliberate focus management within a modal from a genuine trap where no exit path exists.
What should I check when embedding third-party or plugin content?
Third-party embeds, such as media players, ads, and interactive widgets, can introduce keyboard traps that are outside your direct control. It is generally advisable to test each embedded component by moving keyboard focus into it and confirming you can move focus back out again. Where an embed traps focus, options may include configuring the component, choosing an alternative that supports keyboard exit, or working with the vendor. Because these components can change over time, periodic re-testing is often warranted. This guidance addresses the technical criterion and is not legal advice; requirements and interpretations may vary by jurisdiction and evolve through regulation and case law.

Common misconceptions

If a component can be operated with the keyboard, it automatically satisfies No Keyboard Trap.
Operability (SC 2.1.1) and the absence of a trap (SC 2.1.2) are distinct. A component may be fully operable by keyboard yet still trap focus if there is no keyboard method to move away from it.
Passing automated accessibility checks confirms there are no keyboard traps.
Automated tools detect only a portion of issues and often cannot reliably identify keyboard traps. Manual keyboard testing, ideally with assistive technology, is generally required to confirm that focus can enter and exit every component.
Providing any exit method is enough, even if the user isn't told what it is.
When a non-standard method is needed to move focus away, the criterion expects the user to be advised of that method. An undocumented, non-obvious exit can still leave users effectively trapped.

Best practices

Test every interactive component by navigating into and out of it using only the keyboard (Tab, Shift+Tab, arrow keys, and Escape where applicable) without relying on a mouse.
Prefer standard navigation keys for entering and exiting components so users can rely on familiar behavior rather than undocumented shortcuts.
Where a non-standard exit method is unavoidable, clearly communicate the method to the user through visible or programmatically available instructions.
Pay particular attention to custom widgets, modal dialogs, embedded third-party content, and media players, which are common sources of keyboard traps.
Include manual keyboard testing and testing with assistive technologies in your process, since automated tools capture only part of the potential issues.
Verify focus management when content changes dynamically, ensuring newly opened components do not strand keyboard focus and that closing them returns focus to a logical location.