Focus Trap Implementation

Focus trap implementation contains keyboard focus within a specific region of the interface, preventing users from accidentally navigating to content behind modals or overlays. Proper focus traps enable accessible overlay experiences while ensuring users can always escape.

What Is Focus Trap Implementation

A focus trap constrains Tab key navigation to a subset of the page. When focus reaches the last focusable element within the trapped region, pressing Tab moves focus back to the first element rather than continuing into the surrounding page. Shift+Tab at the first element moves to the last.

Focus traps are essential for modal dialogs, drawers, and other overlay patterns. Without trapping, keyboard users could Tab behind the overlay into obscured content they cannot see. This creates confusion and potentially allows interaction with elements that should be blocked.

WCAG Success Criterion 2.1.2 (No Keyboard Trap) requires that users can navigate away from any component using the keyboard. Focus traps must provide escape mechanisms, typically the Escape key or explicit close controls.

How Focus Trap Implementation Works

Focus trap implementation involves several components: identifying focusable elements within the trap region, intercepting Tab key events, managing focus movement, and handling activation and deactivation.

Identifying focusable elements requires querying for interactive elements: links, buttons, form inputs, and elements with tabindex. This query should account for visibility, disabled states, and negative tabindex values that remove elements from tab order.

Tab key interception catches Tab and Shift+Tab events on the trapped container. When the user presses Tab on the last focusable element, the handler moves focus to the first element instead of allowing default behavior. The reverse applies for Shift+Tab on the first element.

Activation occurs when the overlay opens. Focus should move into the trapped region, typically to the first focusable element or a specific target like a close button. The trap begins intercepting Tab events.

Deactivation occurs when the overlay closes. Focus should return to the element that triggered the overlay. The trap stops intercepting events, allowing normal page navigation to resume.

Design systems typically provide focus trap utilities or components that encapsulate this logic. A modal component might automatically implement focus trapping, abstracting the complexity from developers using the component.

Key Considerations

• Provide Escape key handling to close the overlay and release the trap
• Return focus to the triggering element when the trap releases
• Handle dynamic content that may add or remove focusable elements within the trap
• Ensure at least one focusable element exists within the trapped region
• Consider users who navigate with screen readers, which may have different navigation modes
• Test focus trap behavior with actual keyboard navigation
• Prevent scroll of content behind the trap to maintain visual context

Common Questions

How should focus traps handle dynamic content?

Focusable elements within a trapped region may change dynamically. A form might conditionally show additional fields. Content might load asynchronously. The focus trap must account for these changes.

Implementations can re-query focusable elements on each Tab event rather than caching the list. Alternatively, mutation observers can update the cached list when the DOM changes. Either approach ensures the trap correctly identifies current first and last elements.

What happens if a focus trap contains no focusable elements?

A focus trap with no focusable elements would trap the user with no navigation options, violating WCAG requirements. Design systems should ensure trapped regions always contain at least one focusable element, typically a close button.

If content might load asynchronously, the trap should initially focus a loading indicator or the close button. The trap should never activate on a region that currently lacks focusable elements.

How do nested focus traps work?

Nested overlays (a modal opening another modal) require nested focus trap management. The inner trap should constrain focus while active. When the inner overlay closes, the outer trap should resume.

Implementation typically uses a stack of active traps. Opening a new overlay pushes its trap onto the stack. Closing pops the stack and reactivates the previous trap. Focus returns to the appropriate triggering element at each level.

Summary

Focus trap implementation constrains keyboard navigation to overlay regions, preventing users from interacting with obscured content. Through Tab interception, proper activation and deactivation, and escape mechanisms, design systems provide accessible modal experiences that comply with WCAG requirements.