Focus Traps: The Modal Bug That Locks Keyboard Users In

A focus trap, done correctly, is a deliberate and important accessibility feature: when a modal dialog opens, keyboard focus should stay contained within it — Tab and Shift+Tab should cycle only through the modal's own interactive elements, not escape into the page content sitting (invisibly, behind an overlay) underneath. Done incorrectly, the exact same concept becomes one of the most disorienting bugs a keyboard user can encounter: focus that gets stuck somewhere with no way out at all.

The correct version

A well-implemented modal does three specific things: moves focus into the modal the moment it opens (typically to the first focusable element, or to the modal's heading), keeps Tab/Shift+Tab cycling exclusively within the modal's own contents for as long as it's open, and — critically — returns focus to whatever element originally opened it once the modal closes, so a keyboard user isn't left disoriented, focus reset to the top of the page, after finishing an interaction in the middle of it.

The broken version, and how it happens

The bug version is a modal that traps focus correctly in one direction but has no working escape: Escape key doesn't close it, there's no visible or reachable close button in the tab order, or a close button exists but sits in a part of the DOM that the trap logic doesn't include in its focus cycle. A keyboard user who opens a broken modal like this is stuck — literally unable to leave it using the keyboard alone, with no recourse except reloading the entire page. This is a severe, blocking bug, not a minor inconvenience — it fully prevents task completion for anyone who can't reach for a mouse.

Where this usually comes from

Almost always, a broken focus trap traces back to a modal built from scratch — a set of styled <div>s with custom JavaScript managing visibility and focus — rather than using a native <dialog> element or a well-tested component library that already handles this correctly. It's the same trade-off as reconstructing a button's behavior with ARIA: more code, more ways to get it subtly wrong. Focus management is genuinely fiddly to get right by hand: it involves tracking every focusable element inside the modal, handling the edge cases at the first and last focusable element in the cycle, listening for Escape, and correctly restoring focus on close. It's exactly the kind of feature that looks simple, works fine in a quick mouse-driven test, and fails completely the first time someone actually tries to use it with a keyboard alone.

The test that catches it

Open a modal, then try to close it using only the keyboard — Escape, or tabbing to find a close button — without ever touching the mouse. If you can't get out, neither can a keyboard user in production, and that's a blocking bug worth fixing before anything else on the page. It's one specific check inside a broader ten-minute keyboard pass worth running on every new feature.