WCAG 2.1.2 No Keyboard Trap

Success criterion 2.1.2 protects everyone who navigates with a keyboard — screen reader users, people with motor disabilities, people using switch access — from getting stuck inside one part of a page. It is level A and part of EN 301 549 (clause 9.2.1.2).

What the criterion requires

If keyboard focus can be moved into a component using the keyboard, it must be possible to move focus away from it using only the keyboard.

If leaving needs more than unmodified arrow keys, Tab or other standard exit methods, the user must be told how to leave (for example "press Ctrl+M to exit the editor").

WCAG adds a note: because a trap can stop someone using the whole page, all content on the page must meet this criterion, including embedded third-party content (this is Conformance Requirement 5, non-interference).

Containing focus on purpose is allowed. A modal dialog that keeps Tab inside it while it is open is fine, as long as the user can close it from the keyboard.

Typical failures on an online shop

• an embedded video, 3D product viewer or map that captures Tab and never releases it;
• a chat or support widget in an iframe where focus enters and cannot return to the page;
• a "focus trap" script on a popup (newsletter, discount wheel, age gate) with no keyboard way to close it;
• a rich text field for reviews that uses Tab to insert indentation without telling the user how to leave;
• a date picker in checkout that keeps focus in the calendar grid.

How to check it

Automated: there is no axe-core rule for this criterion. Whether focus can leave a component depends on how scripts react to keys, which a scan cannot reliably simulate, so it needs a manual check.

By hand: start at the top of the page and press Tab repeatedly until you reach the footer, then Shift+Tab back up. Make sure you pass through every embedded player, iframe, popup and widget in both directions. Open each dialog and try Esc and the Close button. If you get stuck, note where; if the component offers a special exit key, check that it is explained on screen.

How to fix it

• Do not intercept Tab and Shift+Tab unless you are deliberately containing focus in an open modal.
• Every modal or popup needs a focusable Close button and should close on Esc; then return focus to the control that opened it.
• Test third-party embeds before adding them, and replace or wrap ones that trap focus.
• If a component really needs Tab for itself (a code or text editor), show a short instruction on how to exit.

Related criteria

• 2.1.1 Keyboard — every function must work from the keyboard.
• 2.4.3 Focus Order — focus must move in a logical order.
• 2.4.11 Focus Not Obscured (Minimum) — the focused element must not be fully hidden.

Frequently asked questions

What is a keyboard trap?

A place on the page where keyboard focus can get in but cannot get out using the keyboard, for example an embedded video player or a widget that swallows the Tab key. The user is stuck and often has to reload the page.

Is a modal dialog that keeps focus inside a keyboard trap?

No, as long as the user can leave it, for example with Esc or a reachable Close button. Keeping focus inside an open modal is a recommended pattern; the trap is when there is no way out.

Why does 2.1.2 apply to every part of the page?

Because one trap can block the whole page. WCAG lists 2.1.2 under its non-interference requirement, so all content must meet it, even content you do not rely on for conformance.