Skip to main content

Accessibility: Implementing Focus Traps

A quick guide to implement focus traps in web frontend design

I decided to write about focus traps because they are an essential aspect of keyboard accessibility, yet many sites and developers do not implement them.

Introduction to Web Accessibility (A11y) #

Web Accessibility basically means making websites easy to use for everyone, including people with disabilities.

I will probably write more about it in the future, but since I'm no expert at it, if you would like to dive deeper, I definitely recommend checking The A11y Project and the most recent Web Content Accessibility Guidelines (WCAG), which at the time of this writing is version 2.2.

Understanding Focus Traps #

A focus trap is a design element that keeps a user's attention within a specific area of a webpage, commonly used to ensure keyboard navigation remains within certain interactive components like modals or menus.

Focus traps are important for accessible web design because they prevent keyboard users, including those with disabilities, from unintentionally navigating away from important interactive elements, ensuring a smoother and more predictable user experience.

Some examples of components that often benefit from focus traps are:

  • Modal or dialog
  • Dropdown menus
  • Contextual menus
  • Popovers with interactions
  • Lightboxes or overlays
  • Tabs or tabbed interfaces

Design considerations for Focus Traps #

  • Ensure focus traps are easily discoverable and navigable, with clear visual indicators for focused elements.
  • Avoid hindering the user experience for screen readers or other assistive technologies.
  • Provide instructions for custom key navigation, in addition to the usual Tab and Shift + Tab.
  • Ensure users can navigate into and out of the focus trap easily.

Implementing Focus Traps #

Most likely, you already use a UI library and some external packages. However, before recommending specific implementations using libraries, let's discuss how to implement focus traps from scratch and key considerations. Understanding these fundamentals will help visualize what happens under the hood.

Implementation Overview #

Implementing a focus trap from scratch requires event handling, such as listening to the "keydown" event and preventing the default behavior of certain keys, such as Tab, when the focus is at the boundary of the trap.

In addition to Tab and Shift + Tab, provide a clear method for users to exit the focus trap by pressing the Escape key.

Focus management is also important. Set the focus to the first focusable element within the trap when it is activated, and then trap focus within the trap by redirecting focus back to the first element when attempting to move outside the trap.

Utilize ARIA roles and attributes to enhance accessibility. For example, apply the role attribute with a value of dialog to signify the purpose of the focus trap to assistive technologies.

Ensure all interactive elements within the focus trap, such as buttons, links, and form fields, are focusable using keyboard navigation and have a clear indication when they are focused.

Implementation using Libraries #

The suggested libraries will all depend on what packages your project already uses. I will leave some examples, but always make your research and check the official docs.

You can also implement a Focus Trap yourself, without any library, just make sure to follow a11y best practices.

Libraries for React #

If you use a UI library, such as Material UI, check for an existing component. For instance, MUI has its own FocusTrap component.

If you do not use a UI library, or the one you use does not have a Focus Trap component, consider these libraries:

Or even get the base for the component you need from shadcn/ui, which is not a library by itself but will provide some code for your component while accounting for a11y.

Libraries for Angular #

If you use a UI library, such as PrimeNG, check for a Focus Trap component. PrimeNG has its own pFocusTrap directive.

Angular Material, which uses the @angular/cdk (Component Dev Kit), also has a FocusTrap directive.

Other library Options #

The focus-trap package seems to work well, based on the demo, although I haven't personally tested it.

If you use Vue, Svelte, Solid, or another library, search for "<Library> Focus Trap" to find available options.

Accessibility Testing and Validation #

  • Keyboard Testing: Manually test the focus trap using only keyboard navigation. It's also a good idea to ask others to do the same.
  • Screen Reader Testing: Test the focus trap with a screen reader, such as NVDA (NonVisual Desktop Access) or VoiceOver. Use the screen reader to navigate through the focus trap and verify proper announcements and navigation.
  • Accessibility Inspection Tools: Use browser developer tools or dedicated accessibility inspection tools, such as Axe, to analyze the focus trap implementation for accessibility issues.
  • User Testing: Conduct user testing with individuals who rely on assistive technologies or keyboard navigation. Gather feedback from users with disabilities to identify usability issues or barriers encountered while interacting with the focus trap.
  • Official Guidelines: Ensure compliance with web accessibility standards, such as WCAG "No Keyboard Trap", which is Level A, meaning it is the minimum level of accessibility compliance.

Common pitfalls to avoid #

  • Inadequate keyboard navigation
  • Lack of visual focus indicators
  • Unintuitive focus order
  • Unclear exit mechanisms
  • Ignoring screen reader compatibility

Real-world examples #

Next time you navigate a website, try navigating using only the keyboard. Usually, Tab selects the next focusable element, Shift + Tab the previous one, Enter or Space trigger the element, and Escape exits a focus trap.

In well-known sites, it will probably work mostly fine, but it shouldn't be too hard to find sites that lack visual indication of focusable elements or even focus traps.

If you are looking for a benchmark, a site I think does an amazing job is Airbnb. Try navigating keyboard-only, and you will see what I mean.

Conclusion #

In conclusion, focus traps are critical to ensure accessible web design, particularly for keyboard users and individuals with disabilities. Implementing focus traps requires careful consideration of design principles, keyboard navigation, and compatibility with assistive technologies. Next time you design or develop a component, remember to think about keyboard interactivity and consider implementing a focus trap where appropriate.

To dive deeper into web accessibility, here are some great resources:

  • The A11y Project: A community-driven resource that offers articles, guides, and tools to help developers create accessible web experiences.
  • Web Content Accessibility Guidelines (WCAG): The official guidelines published by the World Wide Web Consortium (W3C) listing the requirements for accessible web content.