Overlays must capture focus and remain escapable

What it is

Once a dialog, drawer or popup menu is open, the keyboard should be locked inside that layer: focus containment, with a door still attached — Escape, a close control, or an equivalent that returns focus to whatever opened it. Containment is not a defect. It is modal semantics: the layer underneath is temporarily inoperable, so focus must not leak onto controls the overlay is blocking. Containment without a door is the blocking case judged next.

Modeless panels need not freeze focus; but if the layer is modal, the pair is mandatory: get in, and get out.

Why it happens

Modal means “only this layer may be answered now”. Pointer users dismiss by clicking the mask or the corner; keyboard users have no “click outside”. If focus stays on the trigger after open, Tab walks the page behind the mask — focus is invisible and the overlay’s fields cannot be reached. If focus enters the overlay but then cycles onto links behind the mask, containment has failed as well.

Correct containment does three things: on open, move focus to the first meaningful control in the layer (or to the layer itself); cycle Tab at the layer’s ends; on close, restore focus to the trigger. The minimum door is a focusable close control plus Escape. Missing any one, the modal does not hold for the keyboard — not “slightly worse UX”, a modal contract honoured only for the pointer.

Studying it

Open every overlay type (dialog, full-screen drawer, date panel, command palette). Note where focus is immediately, Tab a full cycle, press Escape, then confirm focus returned to the opener.

Three failures to log: focus never entered, the cycle leaked to the background, focus was lost on close (landed on body or the browser chrome). The last throws a screen-magnifier viewport into a meaningless corner.

Where it stops holding

Tooltips and purely informative bubbles must not capture focus; capture turns reading into detention. A modeless sidebar should let focus move between main content and the panel; do not apply a dialog lock. A mobile “swipe down to dismiss” is not a keyboard door; an external keyboard still needs Escape or a close button. Cookie walls and first-run coaches that open themselves are overlays too. The same pair applies; “it only appears once” does not waive capture or exit.

Applying it

• On modal open, move focus into the layer. Tab must not land on masked page controls.
• Provide a focusable close control inside the layer and honour Escape. On close, restore focus to the trigger.
• How to check: open a dialog, fill it, and dismiss it from the keyboard only. If focus stays on the original button after open, or cannot be found after close, capture and exit were not delivered as a pair.

Related

• Same group: J3.02.1 Focus order must match visual order · J3.02.3 An inescapable focus trap is a blocking defect · 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: E4.10 Modal dialogs · J3.01 Keyboard access · J2.06 Focus visibility
• Search terms: focus containment · modal focus · focus restore