To create an accessible website, you’ll need to understand how your design decisions and development mistakes can influence your users' experiences. Accessibility barriers can be extremely frustrating, especially when they prevent a person from interacting with your content.
Keyboard traps are an especially significant issue. The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility, and the WCAG framework provides detailed information for creating better content. Here’s the full text of Success Criterion (SC) 2.1.2, “No Keyboard Trap:”
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
In other words, if a person accesses web content with a keyboard alone (without a mouse, touchscreen, or other peripheral device), they should be able to fully navigate the content. They shouldn’t become “trapped" in a certain form field — but unfortunately, keyboard traps are a common issue for websites with complex interactive elements.
Below, we’ll take a closer look at how keyboard traps affect the on-page experience. For more guidance, read our article: Avoid "Keyboard Traps" To Make Your Site More Accessible.
Keyboard traps prevent people from completing processes
Here’s a typical example of how a keyboard trap occurs: A developer adds a form to a webpage. The page uses Javascript, and the developer has misused onBlur, onChange or onFocus events; these events are intended to improve the user experience by prompting changes when the user enters information or interacts with the content in another way.
If the user does not enter information in one form field, then navigates to the next, they may be unable to return to the previous form field to input information. The poorly implemented JavaScript has locked them into a single form field, and they’re unable to navigate away. They may not be able to determine which on-page element has focus — an accessibility issue addressed in WCAG 2.1 SC 2.4.7, “Focus Visible" — and as a result, the user has no idea what they can do to regain control of their browser.
Escaping a keyboard trap can be difficult, especially if the site has other accessibility issues. Some users with mobility-related conditions may have access to mouse emulators, which can be operated with a keyboard or an eye-gaze monitor. However, developers shouldn’t require users to switch from their preferred method of navigation — and WCAG specifically states that a keyboard trap is still a “trap" if the visitor must use a mouse emulator to escape.
Imagine browsing a page and realizing that you can’t complete a process. In fact, you can’t even leave the page, and you’re not sure what you can do to fix the problem. How would you feel?
Read: What You Need to Know About Visual Focus and Accessibility
Keyboard traps require immediate remediation
If your content has a keyboard trap, it cannot be considered reasonably accessible. Keyboard navigation is a fundamental component of accessibility — and if keyboard navigation isn’t possible, your site needs to address the problem as quickly as possible.
Keyboard traps can create barriers in dozens of scenarios, including:
- Users access your content with screen readers. Screen readers are primarily designed for keyboard navigation, and users with vision-related disabilities reasonably expect websites to work with their screen reader software.
- Users with mobility-related disabilities may prefer to access your site with a keyboard. While a user may be able to operate a mouse, they may prefer not to do so — they may not be able to use the mouse with a high level of precision, and keyboards offer a more natural browsing experience.
- Many people who don’t live with disabilities prefer keyboard navigation. Keyboard commands may offer faster navigation; while these users may be less frustrated by keyboard traps, they’ll certainly recognize the problem.
Developers should test all content with basic keyboard commands. This is especially important when utilizing third-party apps, widgets, and embedded video players; if the third-party content doesn’t conform with WCAG, find an alternative.
Read: What is Keyboard Accessibility?
Test your website to identify keyboard traps
The simplest way to find keyboard traps is to browse your website without a mouse. Use the “Tab" key to navigate forward and the “Shift-Tab" command to navigate backward. Test thoroughly, and don’t make assumptions about user behavior. For forms, try leaving certain fields blank while filling in other fields. Make sure you can easily identify the element in focus.
Of course, basic testing can leave some barriers unresolved. Consider auditing your site for WCAG conformance regularly. Audits are particularly important if you’re redesigning your website or adding complex interactive elements. Testing should be performed with both automated and manual methods.
The Bureau of Internet Accessibility utilizes a four-point hybrid testing methodology, which ensures that major issues like keyboard traps are identified accurately. For more information, contact us or use our free, confidential website accessibility scan to determine whether your site conforms with the best practices of WCAG 2.1.
