Loop Keyboard Traps — How the Detector Handles Them

WCAG 2.1.2 – No Keyboard Trap (Level A)

What a loop trap is

Some people navigate a website using only the keyboard — no mouse. They press Tab to move forward from one control to the next (links, buttons, form fields), and Shift + Tab to move backward.

A loop trap happens when the focus starts cycling through the same small group of controls over and over, and never continues to the rest of the page. The user keeps pressing Tab, the highlight keeps jumping between the same two or three items, and there is no way out.

Everyday example: you open a newsletter pop-up on a shop's website. Pressing Tab moves you between Email, Subscribe and Close — and then straight back to Email again. Pressing Shift + Tab does the same thing in reverse. The products, the menu and the rest of the page are now unreachable. For a keyboard-only user, the page is effectively over: the only remaining option is to reload or close the tab.

The rule we apply

A loop is reported as a keyboard trap only when the focus cannot break out in either direction — not with Tab, and not with Shift + Tab.

• Reported as a trap: the group cycles forward with Tab and cycles backward with Shift + Tab. The user is genuinely stuck.
• Not reported as a trap: the focus circles in one direction, but pressing the opposite key gets the user out of the group and on with the page. This is a normal, usable pattern (menus and carousels often behave this way), so we do not flag it.

When a real trap is found, the report names the controls that form the loop — for example "FAQs" → "Accessible directions" → "YouTube video" — so you can see exactly where the cycle begins and ends. Detection then resumes past the trapped group, so the elements sitting after it are not wrongly reported as "never focused".

The informed-alternative exception

A loop is also not reported as a trap when the focus can leave using a different key — most commonly Esc — and the user is told that this is possible.

The condition matters: an exit that exists but is invisible does not help anyone. If the dialog says something like "Press Esc to close", or the instruction is available to screen reader users, the pattern meets WCAG 2.1.2 and we treat it as valid. If there is no such hint, the user has no way of knowing the exit exists — and we report the loop as a trap.

Out of scope

Arrow-key navigation (↑ ↓ ← →) is not part of this check, and neither are unexpected context changes triggered by focusing an element. Those are covered by separate checks.