WCAG 2.2 success criterion, Level A

WCAG 2.1.2 No Keyboard Trap

If the keyboard can move into a part of the page, it must be able to move out again with ordinary keys. If a different key is needed, the person must be told what it is.

Number: 2.1.2
Level: A
Added in: WCAG 2.2
Guideline: 2.1 Keyboard Accessible
Principle: Operable

What it asks

A keyboard trap is a place on a page that focus can enter and never leave. The person presses Tab and focus stays inside. They press Shift and Tab, and it stays. The rest of the page is still there, but they cannot reach it, and their only way out is to reload the page or close the tab. For someone who cannot use a mouse, the page has stopped.

The rule says that if focus can move to a component with the keyboard, it must be able to move away with the keyboard too. If leaving takes anything beyond the usual keys, unmodified Tab, Shift and Tab or the arrow keys, the person must be advised of the method, and advised before they need it, for example in text at the point where they enter the component.

This is one of four criteria WCAG lists as non-interference: it must hold for everything on a page, including content that is otherwise left out of a conformance claim, such as a third-party embed. The reason is plain. A trap anywhere on the page stops the whole page.

One trap is a serious failure, however small the component. A page with one trapped video player fails this criterion exactly as a page with ten does.

Its official name is success criterion 2.1.2 No Keyboard Trap, at Level A. It was added in WCAG 2.2, under guideline 2.1 Keyboard Accessible and the principle Operable. The W3C’s normative text says, in part:

“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.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.1.2 No Keyboard Trap.

Who it helps

Everyone who relies on the keyboard: screen reader users, people with motor disabilities, and people using switches, head pointers or voice control. A trap does not slow these people down. It stops them, and on a page they may have been halfway through completing.

What passes and what fails

These pass

A dialog that keeps focus inside while it is open, as dialogs should, and closes on Escape, returning focus to the page.
An embedded video player that focus can tab through and tab out of.
A rich text editor that uses Tab to insert a tab character, with text next to it saying "Press Escape, then Tab, to leave the editor", and that works.
A date picker that closes on Escape and lets Tab move on to the next field.

These fail

A modal with a focus loop and no Escape key, and no way to reach the close button.
An embedded third-party player that captures Tab and never passes it back to the page.
A rich text editor that swallows Tab with no hint about how to get out.
A custom widget where the only way out is an arrow key, with nothing on the page saying so.
A chat widget that moves focus back into itself whenever focus leaves.

Keeping focus inside an open dialog is not a trap, as long as the dialog can be closed from the keyboard and focus goes back to the page. A dialog that cannot be closed from the keyboard is one.

How to test it by hand

Press Tab from the top of the page to the bottom, then Shift and Tab back up. If focus ever stops moving forward, you have found a candidate.
Pay attention to embedded content: video and audio players, maps, chat widgets, code editors, rich text editors and anything in an iframe.
Open each dialog, menu and pop-up, then try to leave it with Tab, Shift and Tab, and Escape.
Where leaving needs some other key, check that the page says so at the point where you enter the component, in a way a screen reader would read.
Note every component focus could not leave, and whether any instruction was offered.

What automated testing can decide

What a machine can decide

Automated testing can show whether the keyboard can move through the whole page, from top to bottom and back again, or is held in one part of it. That is an observation of the page’s behaviour, not a reading of its code.

What it cannot

A component that holds focus against Tab can still pass, if another key gets out and the page says so. Whether an exit method is advised is a question about the page’s prose, not its scripts, and the same markup can appear on a page that passes and a page that fails. That last question always needs a person.

How Dreven handles it

Dreven checks whether the keyboard can move through your pages and out of every component it moves into, and shows you any component that held focus, with the element, the page and a picture of what was seen.

A reviewer decides each result, pass or fail, and the report records how.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

2.1.1 Keyboard (Level A). Everything must work from a keyboard in the first place.
2.4.3 Focus Order (Level A). Focus must move through the page in an order that makes sense.
2.4.7 Focus Visible (Level AA). The person has to be able to see where focus is, or they cannot tell they are trapped.
1.4.2 Audio Control (Level A). Another non-interference criterion: audio that starts by itself must be stoppable.

Questions people ask

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

Not on its own. Keeping focus inside an open dialog is expected. It becomes a trap when the dialog cannot be closed from the keyboard, usually because Escape does nothing and the close button cannot be reached.

Does a third-party embed that traps focus count against my page?

Yes. 2.1.2 is a non-interference criterion, so it applies to everything on the page, including content you did not write. A trapped embed fails the page.

Can a component use Tab for something else?

Yes, if there is another way out and the person is told what it is before they need it. A code editor that inserts a tab character on Tab can pass if text at the point of entry explains how to leave, such as pressing Escape first.

How serious is a single keyboard trap?

Very. A trap stops a keyboard user from reaching anything after it, so one trap is treated as a serious failure regardless of how small the component is.

All WCAG 2.2 criteria, in plain words