Keyboard Trap

A keyboard trap occurs when keyboard users can enter a component but cannot move focus away using expected keyboard commands. Accessible interfaces must provide a predictable way to reach and leave every focusable region.

Keyboard navigation relies on predictable focus movement, commonly through `Tab`, `Shift+Tab`, and other standard keyboard commands. A component becomes a trap when its focus behavior prevents the user from reaching controls or content outside that component.

A common cause is JavaScript that intercepts keyboard events and continually redirects focus back into a component. Modals are a special case: focus is often intentionally constrained inside an open modal, but the modal must provide a keyboard-accessible way to close it and return focus appropriately when it closes.

When implementing custom widgets, avoid changing focus unnecessarily and do not prevent default keyboard behavior unless the component's interaction pattern requires it. If focus is deliberately managed, ensure users can still reach every intended control and can exit the interaction with an expected command.

Keyboard traps are especially problematic for users who rely on keyboards instead of pointing devices. Testing should include entering the component with `Tab`, moving through all controls, attempting to leave it, and verifying that focus remains visible and predictable.

Key points

• A keyboard trap prevents keyboard users from moving focus away from a component.
• `Tab` and `Shift+Tab` should normally allow predictable movement through focusable elements.
• Focus may intentionally be constrained inside an open modal, but users need an accessible exit mechanism.
• Avoid unnecessary `preventDefault()` calls and forced focus changes.
• Test custom components entirely with the keyboard, including both entering and leaving them.

Interview questions

What is a keyboard trap?

A keyboard trap occurs when a keyboard user cannot move focus away from a component using normal keyboard interaction. For example, pressing `Tab` might repeatedly return focus to the same control. This can make the rest of the page unreachable without a mouse. The fix is to provide predictable focus movement or an explicit keyboard-accessible way to exit the component.

How can you test a component for keyboard traps?

Start by using only the keyboard and enter the component with `Tab` or another expected command. Move through every interactive element, then continue trying to move focus beyond the component. Check that focus does not unexpectedly jump backward, disappear, or become stuck. Also test closing temporary UI such as dialogs and verify that focus returns to an appropriate element.

Are focus traps ever intentional?

Yes. A modal dialog can intentionally keep keyboard focus within the active dialog while it is open. This prevents users from accidentally interacting with content behind the modal. However, the focus constraint must still allow users to reach all relevant controls and leave the dialog through an accessible mechanism. When the dialog closes, focus should generally be restored to the control or context that triggered it.

What JavaScript patterns commonly create keyboard traps?

One common pattern is intercepting `keydown` events and calling `preventDefault()` without implementing equivalent navigation. Another is repeatedly calling `.focus()` on the same element, overriding the browser's normal focus movement. Custom widgets can also trap focus when their keyboard handling does not account for the boundary of the component. The key is to make any custom focus behavior intentional, bounded, and compatible with the expected keyboard interaction.

How would you design a keyboard-accessible modal without creating an accidental trap?

I would define the modal's focus behavior explicitly: move focus into the modal when it opens, keep navigation within the intended focusable controls while it remains active, and provide a reliable close operation. The implementation should account for `Tab`, `Shift+Tab`, and the component's supported keyboard commands without interfering with unrelated input. On close, I would restore focus to the triggering element when that element still exists and is appropriate. I would then test the complete lifecycle with keyboard-only interaction and assistive-technology-oriented checks.