Focus Trapping: Guiding Keyboard Users, Not Caging Them
Focus trapping intentionally confines keyboard navigation to a component, like a modal. It's a feature, not a bug, when used to prevent users from interacting with the page behind an overlay.
Why it exists
Focus trapping solves the problem of keyboard focus leaking out of temporary UI contexts. When a modal dialog appears, a keyboard user shouldn't be able to tab to the main page content underneath it. This would be confusing and break the intended workflow, violating accessibility principles.
The mental model
Think of focus trapping like putting up temporary velvet ropes at an event. You're intentionally guiding guests (the user's focus) within a specific area (a modal dialog) and preventing them from wandering into restricted zones (the underlying page). The ropes must have a clear exit point, like the Esc key or a close button.
How it works
When a component like a modal is activated, JavaScript listens for keyboard events. When the user presses Tab on the last focusable element, the script programmatically moves focus back to the first focusable element. Pressing Shift+Tab on the first element moves focus to the last. This creates a "focus cycle" or "focus jail." A separate event listener for the Esc key or a click on a close button will dismantle the trap and return focus to the element that originally opened the modal.
When to use it
Use intentional focus trapping for any UI that overlays the main page and demands the user's full attention. This includes modal dialogs, lightboxes, and some complex popovers. The goal is to create a temporary, contained navigation scope so the user can only interact with the foreground component.
When not to use it
Never implement an unintentional focus trap. This is a critical accessibility failure (WCAG 2.1.2). If a user can tab into a custom widget, they must be able to tab out using standard methods (Tab, Shift+Tab, arrows). If a component must repurpose standard keys, like a rich text editor using Tab for indentation, you must provide clear, visible instructions on the alternative method for exiting the component (e.g., "Press Alt+F10 to exit").
One canonical example
A modal dialog for confirming an action. When it opens, focus is immediately moved inside it. The user can tab between the "Confirm" and "Cancel" buttons, but they cannot tab to the main page behind the modal. Pressing Esc or activating the "Cancel" button closes the dialog and returns focus to the element that opened it. This is a perfect, user-friendly implementation of focus trapping.
Interview question
For which scenario is intentional focus trapping most appropriately implemented?
- a.A multi-step form where users must complete each step sequentially before proceeding.
- b.A persistent sidebar navigation menu that should always remain in view and accessible via keyboard.
- c.A rich text editor where the Tab key is repurposed for indentation, requiring users to learn a new exit method.
- d.A modal dialog that temporarily overlays the main content and requires immediate user interaction.Correct
Why? this is the answer
Focus trapping is designed for UI components that overlay the main page and demand exclusive user attention, such as modal dialogs, to prevent keyboard focus from leaking. Repurposing standard keys, as in the rich text editor example, is explicitly warned against as an accessibility failure if not handled with clear instructions, not an appropriate use of intentional focus trapping.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles