Keyboard trap

A keyboard trap is a one-way door. Tab moves focus into some region and then no combination of Tab, Shift Tab, or Escape gets it out again, so anybody driving the page from a keyboard is finished: they cannot reach the rest of the form, the navigation, or the browser’s own chrome without picking up a mouse. WCAG 2.1.2 states the rule in one sentence: if focus can be moved into a component with a keyboard, it must be possible to move it away with a keyboard, and where that takes something other than the arrow or tab keys, the user has to be told how.

Almost all of them are accidental. Embedded third-party content is the classic source: a video player, a map, an ad frame, or an old plug-in that swallows Tab and cycles its own controls forever. Hand-written trapping code is the other one, usually a dialog whose focus loop was never released when it closed, or a keydown handler that calls preventDefault() on Tab to insert a tab character in an editor. Rich text editors, code editors, and spreadsheet grids all want Tab for themselves, and every one of them needs a documented way to give it back, usually Escape first and then Tab.

This is the opposite of the term it looks like. A deliberate focus trap in a modal dialog is correct behaviour: holding focus inside the dialog is what makes it modal, and it satisfies 2.1.2 because Escape and a visible close button are both there and both work. So the criterion is not “never hold focus”. It is “always publish an exit, and honour it”. A trap is what you have when the exit is missing, is undocumented, or exists only as a pointer target.

Traps survive review because a pointer never meets one. Finding them costs a minute: tab from the top of the page to the bottom, then Shift Tab back up, and watch for the ring going in circles or vanishing. Never handle Tab without leaving a way out, keep Escape working in everything that captures keys, and tab through embedded frames rather than assuming somebody else tested them.