Focus Traps
Temporary UI should keep keyboard focus inside the overlay — and always offer a way out.
01 — Purpose
Keep focus inside temporary UI
Focus traps prevent keyboard users tabbing into dead content behind a modal — when done right, they preserve orientation.
Dialogs, drawers, and mobile menus are temporary. While open, focus should cycle within the overlay — not leak to the page underneath where interaction is blocked or confusing.
See the modal / dialog pattern for platform-first approaches and when a full page beats an overlay.
02 — Principles
Contain without imprisoning
Users should never tab into inaccessible background content — and must always have a way out.
- trap focus only while the overlay is open and modal in behaviour
- Escape closes the overlay and restores focus — every time
- tab order inside the trap is logical — close control reachable early
- visible focus on every stop in the loop
03 — Practice
Good focus trap behaviour
Native dialog helps; custom traps need the same guarantees.
-
prefer
<dialog>where supported — focus management built in - move focus to the dialog container or first focusable control on open
- wrap Tab from last to first focusable — and Shift+Tab the other way
- inert or aria-hidden on background content while modal — not only visually dimmed
- restore focus to the trigger element on close — see focus management
04 — Avoid
Trap failures
A broken trap is worse than no trap.
- trapping users with no Escape, close button, or cancel path
- broken tab loops — focus escapes to browser chrome unpredictably
- hidden or zero-size focus targets inside the trap
- trapping on non-modal panels that should allow background interaction
05 — Close
Preserve orientation
Open, tab through, Escape out, land back where you started.
Test every overlay: open from a known button, cycle focus twice, close with Escape, confirm focus returns to that button. If you land somewhere else, users lose their place in the flow.
Related: modal / dialog, focus management, and accessibility standard.