Focus Trapping

Constraining keyboard focus within a component like a modal to prevent losing context.

stellae.design

Accessibility

Focus trapping (or focus containment) is a technique that restricts keyboard focus to cycle within a specific UI component, preventing users from Tabbing to elements outside it. This is critical for modal dialogs, slide-out panels, and any overlay that visually obscures the main page. WCAG 2.1 Success Criterion 2.1.2 (No Keyboard Trap, Level A) requires that users are never stuck — they must always be able to leave a trapped region via standard keys. The balance is: trap focus inside the modal to prevent confusion, but always provide an Escape key or close button to exit. Without focus trapping, keyboard users can Tab behind a modal into invisible content, creating a disorienting experience.

Why It Matters

Focus trapping is the accessibility technique of constraining keyboard focus within a specific region of an interface — typically a modal dialog, dropdown menu, or overlay panel — so that Tab and Shift+Tab cycle through only the interactive elements within that region rather than allowing focus to escape to the obscured content beneath, which would leave keyboard and screen reader users stranded in content they cannot see or interact with meaningfully. Without proper focus trapping, keyboard users who open a modal dialog and press Tab will find their focus disappearing behind the overlay, navigating invisible content while the modal remains visually active but inaccessible — they may not even realize their focus has escaped, leading to confusion, accidental form submissions, or an inability to close the dialog without a mouse. Focus trapping is required by WCAG 2.1 Success Criterion 2.1.2 (No Keyboard Trap) in conjunction with the WAI-ARIA dialog pattern, and its correct implementation is one of the most reliable indicators of whether a development team takes keyboard accessibility seriously.

Real-World Examples

E-commerce checkout implementing focus-trapped payment modal

An online store's payment modal activates a focus trap that constrains Tab navigation to the card number field, expiration date, CVV, billing address, a cancel button, and a submit button — when the user Tabs past the submit button, focus cycles back to the card number field, and pressing Escape closes the modal and returns focus to the "Proceed to Payment" button that opened it. The modal is announced to screen readers as a dialog with the label "Enter payment information," and the first form field receives focus automatically so keyboard users can begin entering data immediately without hunting for the starting point. The background content receives the inert attribute, preventing screen readers from accessing or announcing page content behind the overlay while the payment modal is active.

Cookie consent banner trapping focus appropriately before page interaction

A website implements its cookie consent banner as a focus-trapped dialog that appears on first visit, constraining keyboard navigation to the consent options — Accept All, Reject Non-Essential, and Customize Settings — so that keyboard users must make a consent choice before interacting with the page, matching the experience of mouse users who see the banner overlaying the content. The banner uses role="dialog" with an accessible label, the first option receives focus automatically, and once the user makes a selection, the trap releases and focus moves to the main page content's skip link or first interactive element. This implementation ensures that keyboard users encounter the same consent flow as mouse users rather than being able to Tab past the banner into page content without making a consent decision.

Counter-example

Modal dialog that allows focus to escape to background content

A web application opens a confirmation dialog when users attempt to delete their account, but the focus trap implementation only captures Tab events without handling Shift+Tab from the first element — pressing Shift+Tab on the cancel button sends focus behind the overlay to the navigation menu, where the user is now interacting with invisible content while the modal remains visually active, and pressing Tab repeatedly cycles through the entire background page before eventually returning to the modal. Screen reader users are particularly affected because they receive no indication that their focus has left the dialog context, leading to disorientation and potential accidental actions on the hidden page. The fundamental failure is testing focus trapping with forward Tab only, missing the Shift+Tab boundary condition that is equally critical for complete focus containment.

Role-Specific Guidance

Common Mistakes

• The most common implementation mistake is hardcoding the list of focusable elements when the trap initializes without updating it when the modal's content changes — if a validation error message adds a new link, or a form section expands to reveal additional fields, the focus trap's element list becomes stale and Tab navigation either skips new elements or breaks entirely. Another frequent error is failing to return focus to the triggering element when the modal closes, which causes focus to reset to the top of the page and forces keyboard users to navigate through the entire page again to return to where they were — this is especially frustrating in long pages or complex applications where the triggering element may be dozens of Tab stops from the top. Teams also commonly neglect to add the inert attribute or aria-hidden="true" to background content while the trap is active, which means screen reader users can still access and navigate the underlying page content using screen reader-specific navigation commands even though keyboard focus is trapped, creating an inconsistent experience where some navigation methods reach background content and others do not.