No Keyboard Trap

Why it matters

A trap is not a delay or a detour. It is a dead stop, and the usual recovery is reloading the page, which throws away everything already typed. This one also carries the heaviest conformance consequence in the whole set. It is one of four rules that apply to every piece of content on the page, including content you did not write and are not relying on for your claim. So a trapped chat widget or consent banner is not the vendor's problem. It is yours, and it takes the whole page out of conformance rather than just its own corner.

Who this rule protects

This affects every keyboard-dependent visitor, including screen-reader users, switch-device users, speech-input users whose software sends keystrokes, and sighted people who simply prefer typing to clicking.

How to check it yourself

1. 1Tab into every modal, embed and widget, then keep tabbing to see whether you come back out. Do it in both directions, because Shift+Tab escapes some widgets that Tab cannot.
2. 2Where a widget needs a key of its own to release focus, check the page says so. On arrival is soon enough, and it is what W3C's example does. What fails is a widget with the key and no instruction anywhere.
3. 3Press Escape on every overlay and confirm it closes. Escape is the common exit on a physical keyboard, and the specification deliberately never defines what counts as a standard exit method, so treat it as the first thing to try rather than the whole test.
4. 4Test third-party embeds on their own terms, meaning chat, video, surveys and consent banners, since that is where traps live.

Failures we see most often

• A consent banner whose Accept button answers a mouse click and nothing else, so a keyboard user reaches the banner, cannot dismiss it, and cannot get past it to the site. The focus cycling inside the banner is not the fault. The mouse-only button is.
• An embedded video player that swallows every Tab press, with nothing on the page naming a key that gets focus back out.
• A modal a user can tab straight past into nothing, so focus lands somewhere invisible and the rest of the page becomes a guess.
• Two content formats stitched together, such as a scripted page wrapped around a plug-in, where focus crosses into the second format and the first one never takes it back.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

• Blind and screen reader userspeople who cannot see the screen
• Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
• Voice controlpeople who operate the page by speaking to it

How this one is tested

We list 3 ACT rules against 2.1.2. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.

• Focusable element has no keyboard trapA tool can check this
• Focusable element has no keyboard trap via standard navigationNothing implements this yet
• Focusable element has no keyboard trap via non-standard navigationA tool can check this

How to fix it

• Use the native <dialog> element opened with showModal(). It contains the tab sequence, handles Escape, makes the background inert and hands focus back to the trigger on close, without a line of code from you. The only choice left is where focus lands on opening, and the autofocus attribute sets that.
• Where a widget genuinely needs its own exit key, say so on screen at the moment focus arrives. That instruction is the second way to pass, not a nicety, and it is how a rich editor keeps Tab for indentation and still conforms.
• Keyboard-test every third-party embed before it ships, and wrap or replace any that trap focus. One trapped banner on page one keeps keyboard users off every page behind it.

Passes vs. fails