accessibility
Keyboard trap
What is a keyboard trap, and why is it a serious accessibility failure?
A keyboard trap is a spot where focus goes in but can't get out by keyboard - a widget, embed or dialog that swallows Tab so a keyboard or switch user is stranded, unable to reach the rest of the page. For someone who can't use a mouse, it isn't an annoyance; it's a dead end that can make the whole page unusable.
Also known as: keyboard trap, focus trap, keyboard accessibility trap
The demo
Put your mouse down and use Tab. With the trap on, try to Tab out of the box below - you can't. (Press Escape to free yourself; a real trap wouldn't let you.)
Custom widget
What this demo shows (text version)
A box represents a custom widget with a couple of buttons and a field, followed by a normal link. With the trap turned on, pressing Tab inside the box cycles focus around its own controls and never moves out to the link after it - so a keyboard user is stuck. Pressing Escape releases focus (a courtesy a real trap wouldn't offer). With the trap turned off, Tab leaves the box normally and reaches the link.
The lesson: anything focus can enter, it must be able to leave by keyboard. A keyboard trap is invisible to mouse users but can make an entire page unreachable for keyboard and switch users - it fails WCAG outright. Deliberately holding focus (as a modal does) is acceptable only when Escape and a close control always provide a way out. Test by tabbing through everything without the mouse.
Anything a keyboard can enter, a keyboard must be able to leave - by Tab, or by a documented key like Escape. Custom widgets, embeds and modals are the usual offenders: they grab focus and never release it. The deliberate version (a modal that holds focus while open) is fine only because Escape and a close button always free it. Test every component by tabbing all the way through with the mouse untouched.
Tab into the trap and Tab again, and again - and focus just cycled inside, with the rest of the page out of reach. For a mouse user that's a shrug; for someone navigating by keyboard alone it's being stuck in a room with no handle. Pressing Escape let you out - which is exactly the escape hatch a real trap is missing.
The harm is total for the people it hits. A sighted mouse user never notices; a keyboard-only or switch user who tabs into the trap cannot tab past it, so every link, button and field beyond it becomes unreachable. It fails WCAG's "no keyboard trap" criterion precisely because it can turn one bad component into a whole-page blocker.
Traps are usually accidental - a custom dropdown, a video embed, a third-party widget that captures Tab and forgets to pass it on. The fix is to ensure focus can always move forward and backward out of the component, and never to hijack Tab without providing a way through.
"Holding" focus on purpose is different from trapping it. A modal dialog should keep focus inside while it's open - but only because Escape closes it and focus returns to where it came from. The rule that separates the two: there must always be a keyboard way out. Test it the only reliable way - put the mouse down and Tab through everything.