Keyboard trap

A modal dialog implementing focus containment without an escape route, so focus cycles inside forever.

An embedded third-party widget — a video player, a map, a payment frame — that captures keys and never returns focus.

A custom control handling the tab key itself and preventing the browser's default behaviour under a condition that is always true.

An event handler calling focus on an element every time focus leaves it, which is usually an attempt to validate a field.

In each case the code is doing something deliberate, and the trap is the case the author did not consider.

A modal dialog is supposed to contain focus: letting it wander behind the overlay is a different defect.

The requirement is that a standard way out exists — the escape key, a close control reachable in the cycle, or both.

So the distinction is between containment with an exit and containment without one, and only the second is a trap.

Which is also why the correct implementation is well documented: contain focus, handle escape, and return focus to the trigger on close.

Detecting a trap means entering the component, attempting to leave it, and observing that focus did not move — which requires interaction.

A static reading of markup shows the component and nothing about what its key handlers do.

Even a rendering check does not exercise it, because triggering the component usually requires an action nobody performed.

Which is why any tool reporting an accessibility pass is reporting the absence of detectable failures, not the absence of failures.

Put the mouse away and tab through the whole page from the top, including opening every dialog and interacting with every embedded widget.

In each component, tab until focus either leaves or cycles back to where it entered, and try the escape key.

A component that cycles without an exit and ignores escape is a trap.

It takes a few minutes per page and it finds what no scan can, which is the argument for doing it on the templates rather than on every page.

Elements made interactive without the semantics that make them reachable are detectable, and they are a common neighbour of trapping behaviour.

Positive tab index values are detectable and reorder the sequence globally, which makes a trap harder to reason about when one exists.

Interactive elements hidden from assistive technology while remaining focusable are detectable and produce a related confusion.

The trap itself is not among these, and the honest report says so rather than implying keyboard operation was verified.