A CSS Approach to Trap Focus Inside an Element

Modal dialogs and overlays are everywhere on the web, but many implementations trap keyboard users in an inaccessible experience. This guide covers how to properly trap focus within an element, ensuring your modals work for everyone.

Understanding Focusable Elements in HTML

Not all HTML elements can receive focus by default. The browser natively makes certain elements focusable because they have inherent interactivity: anchor tags (<a>) with href attributes, buttons (<button>), form inputs (<input>, <textarea>, <select>), and interactive elements like <details> and <summary>.

According to the CSS-Tricks focus trapping guide, understanding which elements are naturally focusable is the foundation for building accessible modals.

To programmatically identify all focusable elements within a container, you can query for these element types along with any element that has a tabindex attribute:

function getFocusableElements(container = document.body) {
 const elements = Array.from(
 container.querySelectorAll(
 `a, button, input, textarea, select, details,
 iframe, embed, object, summary, dialog,
 audio[controls], video[controls],
 [contenteditable], [tabindex]`
 )
 );

 return elements.filter(el => {
 if (el.hasAttribute('disabled')) return false;
 if (el.hasAttribute('hidden')) return false;
 if (window.getComputedStyle(el).display === 'none') return false;
 return true;
 });
}

This filtering step is crucial--elements that are disabled, hidden, or display:none cannot receive focus and should be excluded from your focus trap logic.

For keyboard-only focus management, you may want to further filter to elements with tabindex > -1, excluding elements that are focusable but not via keyboard navigation.

When building React components with accessibility, consider using libraries like focus-trap-react that handle these edge cases automatically. For advanced CSS techniques that complement accessible interactions, explore our guide on CSS Grid layout patterns to build sophisticated, accessible component structures.

Implementing a Custom Focus Trap with JavaScript

Creating a custom focus trap requires three key pieces: detecting keyboard navigation, identifying the boundary elements, and managing focus transitions. The implementation listens for Tab and Shift+Tab keypresses, intercepting them when focus is at the boundaries of your trapped element.

Detecting Tab Navigation

First, create helper functions to detect Tab and Shift+Tab key combinations:

function isTab(event) {
 return !event.shiftKey && event.key === 'Tab';
}

function isShiftTab(event) {
 return event.shiftKey && event.key === 'Tab';
}

These simple checks examine event.key for the Tab value and event.shiftKey to distinguish between forward and backward navigation.

Managing Focus Lifecycle

A complete focus trap implementation should also handle activation and deactivation:

function activateFocusTrap(container) {
 const focusables = getFocusableElements(container);
 if (focusables.length === 0) return;

 // Set initial focus to the first focusable element
 focusables[0].focus();

 container._focusTrap = {
 handler: createTrapHandler(container, focusables),
 container
 };

 container.addEventListener('keydown', container._focusTrap.handler);
}

function deactivateFocusTrap(container) {
 if (!container._focusTrap) return;
 container.removeEventListener('keydown', container._focusTrap.handler);
 delete container._focusTrap;
}

This pattern ensures your trap is active only when needed and properly cleaned up to avoid memory leaks or unexpected behavior.

For production applications, consider using established libraries like focus-trap that handle edge cases and browser compatibility for you. Explore more advanced CSS techniques in our article on CSS transitions and animations to create smooth, polished user experiences alongside accessible modal interactions.

The HTML Dialog Element: Modern Focus Trapping

The HTML <dialog> element, introduced in HTML5.2 and now widely supported, provides native focus trapping without JavaScript. When a modal dialog opens with .showModal(), the browser automatically traps focus within the dialog, prevents interaction with background content, and handles focus management automatically.

const dialog = document.querySelector('dialog');

// Open as modal - browser handles focus trapping automatically
dialog.showModal();

// Close the dialog
dialog.close();

When opened as a modal, the browser adds the dialog[open] attribute, applies aria-modal="true", and automatically inerts the background. Focus returns to the triggering element when the dialog closes, maintaining the user's context.

Accessibility Requirements for Dialog Elements

While the <dialog> element handles much of the accessibility work automatically, you should still provide proper ARIA attributes for maximum compatibility:

<dialog aria-labelledby="dialog-title" aria-describedby="dialog-description">
 <h2 id="dialog-title">Confirm Action</h2>
 <p id="dialog-description">Are you sure you want to proceed?</p>
 <form method="dialog">
 <button value="cancel">Cancel</button>
 <button value="confirm">Confirm</button>
 </form>
</dialog>

The aria-labelledby attribute references the dialog title, and aria-describedby can provide additional context for screen reader users.

According to the W3C WAI ARIA Authoring Practices, proper ARIA labeling ensures screen reader users understand the dialog's purpose and can navigate it effectively.

Best Practices for Focus Management

Proper focus management extends beyond simply trapping focus. The W3C's ARIA Authoring Practices Guide specifies detailed requirements for accessible modals.

Initial Focus Placement

When a modal opens, where focus lands matters significantly. The W3C recommends placing initial focus on the first focusable element within the dialog, which is typically the first input, button, or link.

However, there are exceptions. When a dialog contains a lot of content and the first interactive element is not visible, consider focusing on a descriptive element first so users understand what the dialog contains before navigating to interactive elements.

Focus Restoration

When a dialog closes, focus must return to a logical location. The W3C specifies that focus should return to the element that triggered the dialog opening, preserving the user's place in the document:

function openDialog(triggerElement) {
 const dialog = document.getElementById('my-dialog');
 dialog.showModal();
 dialog._returnFocus = triggerElement;
}

function closeDialog(dialog) {
 const returnTarget = dialog._returnFocus;
 dialog.close();
 if (returnTarget && returnTarget.focus) {
 returnTarget.focus();
 }
}

Additional Considerations

• Nested dialogs: Each nested dialog should have its own focus trap
• Dynamic content: Re-evaluate focus trap boundaries when content changes
• Single-focusable element: Both Tab and Shift+Tab should cycle to that element
• Empty dialogs: Consider making a static element focusable

These accessibility patterns align with our commitment to building inclusive web experiences that serve all users effectively.

Performance Considerations

Focus trap implementations are generally lightweight, but poor implementations can impact performance, especially in applications with many modals or frequently changing content.

Efficient Element Selection

Querying for focusable elements can be expensive if done repeatedly. Cache the results when the modal opens and only re-query when the modal content changes:

function activateFocusTrap(container) {
 const focusables = container.querySelectorAll(
 'a, button, input, textarea, select, details, [tabindex]'
 );
 const focusableArray = Array.from(focusables).filter(el => {
 return !el.hasAttribute('disabled') &&
 !el.hasAttribute('hidden') &&
 window.getComputedStyle(el).display !== 'none';
 });

 container._focusableElements = focusableArray;

 if (focusableArray.length > 0) {
 focusableArray[0].focus();
 }
}

Event Delegation

Instead of attaching event listeners to every modal, use event delegation on the document for better performance. This reduces memory usage and simplifies cleanup.

Framework Considerations

When using React, Vue, or other frameworks, be mindful of how focus management interacts with the rendering cycle. Use lifecycle methods to set up and tear down focus traps, and avoid modifying focus during render to prevent infinite loops.

For Next.js applications, consider using the useEffect hook to manage focus trap lifecycle in combination with the native <dialog> element for optimal performance and accessibility. When implementing complex UI patterns, complement your accessible modals with AI-powered automation solutions to streamline user interactions and reduce cognitive load.

Testing Focus Trap Functionality

Thorough testing is essential for focus trap implementations. Manually test with keyboard navigation and use automated tools for regression prevention.

Manual Keyboard Testing Checklist

1. Open the modal using keyboard-only navigation (Enter/Space on the trigger)
2. Verify focus lands on the first focusable element
3. Press Tab repeatedly and confirm focus cycles within the modal
4. Press Shift+Tab and confirm focus cycles in reverse
5. Press Escape and verify the modal closes
6. Verify focus returns to a logical element after closing
7. Reopen the modal and test all interactive elements

Automated Testing with Playwright

test('modal focus trap', async ({ page }) => {
 await page.click('[aria-haspopup="dialog"]');
 await expect(page.locator('.modal button:first-child')).toBeFocused();

 await page.keyboard.press('Tab');
 await expect(page.locator('.modal button:nth-child(2)')).toBeFocused();

 await page.keyboard.press('Shift+Tab');
 await expect(page.locator('.modal button:first-child')).toBeFocused();

 await page.keyboard.press('Escape');
 await expect(page.locator('.modal')).toBeHidden();
});

Accessibility Auditing Tools

Use browser extensions and command-line tools to audit accessibility:

• axe DevTools: Browser extension for automated accessibility testing
• Lighthouse: Built into Chrome DevTools, includes accessibility audits
• Pa11y: Command-line accessibility testing tool

Incorporate accessibility testing into your CI/CD pipeline to catch regressions before they reach production.

Sources

1. CSS-Tricks - A Primer on Focus Trapping
2. W3C WAI ARIA APG - Modal Dialog Pattern
3. W3C WAI ARIA APG - Modal Dialog Example