An inescapable focus trap is a blocking defect

What it is

Getting in with no way out is not “focus handling could be more elegant”. For someone who uses only a keyboard, an inescapable focus trap (keyboard trap) is a product halt: the rest of the page, the rest of the tasks, even the browser’s address bar, drop out of the operable set. Severity is blocking — a task walkthrough must stop here, not file an UX suggestion.

An overlay locking focus inside itself can be correct behaviour. This leaf applies only when the door is missing, cannot be found inside the layer, or does nothing when used.

Why it happens

Pointer users always have a physical escape: move the pointer out of the component and click elsewhere, or hit the browser Back. Keyboard escape has to be provided by the page: Tab must be able to leave the region, or Escape / close must send focus out. If a control preventDefaults Tab and Escape internally and offers no leave command of its own, and user-agent navigation keys are swallowed too, the person is locked in a subtree.

Embedded players, rich-text editors, maps and payment iframes are typical manufacturers: they intercept every key to “own shortcuts” and never hand focus back to the host. Switch-scanning users are harder still — when scan focus is locked in the subtree, even the system-level retreat to browser chrome may be gone.

Studying it

One criterion: after entering the region, is there a way out that does not depend on the pointer, and does it succeed within a bounded number of keys. Ways out: Tab past the region, Escape, an explicit Close or Done. Failure is blocking. Do not award partial credit for “you can still click outside”.

Sample third-party embeds, video players, custom dropdowns left open, full-screen viewers first. Record keys needed to leave. If the tester finally reaches for the pointer, the trap holds.

Where it stops holding

A modal dialog that cycles focus while open is not this trap if Escape or close ends it. Temporarily locking focus in a canvas for one continuous manipulation (nudging an object with arrows) can be acceptable if the exit key is documented and does not collide with “cancel this nudge” so badly that leaving is impossible. A browser-extension layer that traps focus is still blocking for the user — responsibility sits on the whole-page experience, not only first-party code.

Applying it

• Any component that intercepts Tab or Escape must offer a separate leave command, visible inside the layer.
• Before embedding a third-party player or editor, walk in with the keyboard and try to walk out. If you cannot, do not embed, or give the host a “skip this embed” entry.
• How to check: enter a player, editor or open custom list from the keyboard, do not touch the pointer, and return to the rest of the page within thirty seconds. If that fails, log a blocking defect — do not park it as “polish next sprint”.

Related

• Same group: J3.02.1 Focus order must match visual order · J3.02.2 Overlays must capture focus and remain escapable · J3.02.4 Dynamically inserted content desynchronizes focus unless it is moved on purpose · J3.02.5 Focus order must update as content expands or hides · J3.02.6 Focus-order failures are found by walking with a keyboard, not by inspecting source order · J3.02.7 Nested overlays that each capture focus can deadlock
• Nearby: J3.08 Switch access and scanning · J5.05 Switch and eye-gaze input · J3.01 Keyboard access
• Search terms: keyboard trap · no keyboard trap · inescapable focus