What is a keyboard trap, and why is it a conformance failure rather than an inconvenience?

## What a keyboard trap is A **keyboard trap** is a region of a screen that keyboard focus can move *into* but cannot move *out of* using the keyboard alone. The user is not inconvenienced; they are stranded. Everything else -- the navigation, the submit control, the sign-out control -- is still there and now unreachable, and for someone with no pointing device at all the session effectively ends where the trap starts. Traps are almost never deliberate. The recurring causes are the same on a page and on a native screen: - A component **consumes the traversal key** for a purpose of its own -- a code editor or a nested grid that inserts indentation on Tab and never passes the key on. - A **loop with no exit**: focus returns to the first control of a region whenever it reaches the last one, and the region's only close affordance is pointer-driven. - **Validation that refuses to release focus**, returning focus to a field on every attempt to leave until the value is acceptable. - An **embedded region with its own input handling** -- a map, a media player, an embedded document -- that takes focus and never hands it back. - Focus moved into a region that is **visually hidden but still focusable**, so the user is somewhere they cannot see and cannot navigate out of. ## Why the standard treats it as severe **2.1.2 No Keyboard Trap (Level A)** requires that if focus can be moved to a component using a keyboard interface, focus can be moved away from that component using only a keyboard interface -- and that if leaving needs more than the unmodified arrow keys, the Tab key or another standard exit method, the user is advised of the method. Two things make a trap heavier than an ordinary failure. | | An ordinary criterion failure | A keyboard trap | | --- | --- | --- | | Blast radius | the component that fails | everything the user has not yet reached | | Workaround | often possible around the component | none at all without a pointer | | Effect on the claim | the part that fails | the whole page, conforming parts included | The last row is the one candidates miss. WCAG's conformance requirements include a **non-interference** rule: a small set of criteria apply to *all* content on a page, including content that is not part of the conformance claim, precisely because failing them blocks access to everything else. No Keyboard Trap is one of that set, alongside the criteria on audio that starts automatically, on moving or auto-updating content, and on flashing. So "that widget is a supplier's, and we never claimed it" does not rescue the claim: a trap anywhere on the page fails the page. The **complete process** requirement compounds it. Where a task spans several pages or steps, every step has to conform for any of them to be included in a claim, so a trap in step four of a six-step booking flow takes the whole flow down with it. ## What a correct escape looks like A region that *holds* focus is not automatically a trap. A dialog that cycles focus among its own controls is a deliberate and correct pattern, because it keeps focus out of content the user cannot currently see. It is correct as long as the loop has a door. The test has four parts: 1. **A standard exit works.** Focus leaves using the ordinary traversal keys in both directions, or the ordinary dismissal key closes the region. 2. **A non-standard exit is announced.** If a component genuinely needs its own exit gesture, that instruction reaches the user *before* they enter it, not in documentation they can no longer navigate to. 3. **Focus lands somewhere sensible on the way out** -- normally the control that opened the region, so the user resumes where they left off. 4. **Both directions work.** Escaping forward but not backward is still a trap for anyone who wants to review what they just passed. ## Living with a trap you cannot change A council waste-collection service embeds a supplier's collection-calendar component on 3 of its 41 public screens. The component takes focus on the day grid and never releases it; the supplier's next release is two quarters away and the contract says nothing about accessibility defects. Non-interference means those three screens fail whoever wrote the component, so every option is about the host screen rather than the supplier: - Provide an **equivalent route to the same outcome** -- a plain date entry that books the same slot -- and place it *before* the trap in the focus order, so a keyboard user meets the working path first. - **Wrap the region** so the host screen owns the exit, moving focus out itself on the dismissal key. - Take the component out of the focus order entirely and treat it as presentational, but only where the equivalent route is genuinely complete. - Replace it. Whichever you choose, record it as a Level A conformance failure with a date attached rather than as a polish item, and say so plainly in any accessibility statement while it stands. Traps are expensive precisely because they are cheap to introduce, invisible to anyone testing with a pointer, and total in their effect on the people who meet them.