Focus Trap

A focus trap is a deliberate accessibility technique that constrains keyboard focus within a designated region of a web page. When a focus trap is active, pressing Tab or Shift+Tab cycles through only the focusable elements inside that region, preventing the user from accidentally navigating to content behind or outside the component. The most common use case for a focus trap is a modal dialog. When a modal opens, it overlays the main page content. Without a focus trap, a keyboard user could tab past the modal's last element and land on page content hidden behind the overlay, creating a confusing and broken experience. The focus trap keeps navigation contained within the modal until the user explicitly closes it. Focus traps are distinct from keyboard traps. A keyboard trap is an accessibility violation where users get stuck in a component with no way to leave. A focus trap, by contrast, always provides an escape route, typically through the Escape key, a close button, or completing the intended interaction.

Keyboard-only users and screen reader users navigate sequentially through focusable elements. Without focus traps in overlay components, these users face several problems. They may tab into background content they cannot see or interact with because a modal obscures it. They may lose their place in the dialog and be unable to find their way back. They may accidentally trigger actions on the underlying page. WCAG Success Criterion 2.1.2 (No Keyboard Trap) requires that keyboard users can always move focus away from any component using standard navigation. This might seem contradictory to focus trapping, but the criterion specifically allows focus to be confined as long as the user is informed of the method to release focus. A modal with an Escape key handler and a visible close button satisfies this requirement. Proper focus trapping is essential for usability. Sighted mouse users naturally interact only with visible overlays because they can see that background content is obscured. Focus traps provide the same boundary for keyboard users, creating an equivalent experience.

Implementing a focus trap involves several key steps: 1. **Identify focusable elements.** When the trap activates, query all focusable elements within the container, including links, buttons, inputs, selects, textareas, and elements with `tabindex="0"`. 2. **Set initial focus.** When the component opens, move focus to an appropriate element inside it, typically the first focusable element or the close button. 3. **Intercept Tab and Shift+Tab.** Add a keydown event listener that detects Tab key presses. When focus is on the last focusable element and the user presses Tab, redirect focus to the first focusable element. When focus is on the first element and the user presses Shift+Tab, redirect to the last element. 4. **Handle Escape.** Listen for the Escape key and close the component when pressed, releasing the trap. 5. **Restore focus on close.** When the component is dismissed, return focus to the element that originally triggered it. This ensures the user resumes navigation from a familiar position. ```javascript function trapFocus(container) { const focusable = container.querySelectorAll( 'a[href], button, input, select, textarea, [tabindex="0"]' ); const first = focusable[0]; const last = focusable[focusable.length - 1]; container.addEventListener('keydown', (e) => { if (e.key === 'Tab') { if (e.shiftKey && document.activeElement === first) { e.preventDefault(); last.focus(); } else if (!e.shiftKey && document.activeElement === last) { e.preventDefault(); first.focus(); } } }); } ``` Libraries like `focus-trap` (npm package) and frameworks such as React, Angular, and Vue provide built-in or community solutions for focus trapping. The WAI-ARIA Authoring Practices Guide documents the expected focus behavior for modal dialogs in detail. Additionally, using `aria-hidden="true"` on background content while a modal is open prevents screen readers from accessing that content, reinforcing the focus trap at the accessibility tree level.