While some accessibility issues cause minor annoyances for users, others have more severe consequences: If your content fails certain success criteria outlined in the Web Content Accessibility Guidelines (WCAG), it may be completely unusable for people with certain disabilities.
For front-end web developers, keyboard traps pose a particularly significant concern. Many visitors use a keyboard alone to navigate the internet — no mouse. These visitors utilize shift and shift-tab to move the keyboard’s focus. The shift button moves the focus to the next subset of content, while the shift-tab command moves back one step. The enter or spacebar selects elements.
A keyboard trap occurs when a user cannot change the focus with typical commands and the website does not provide a navigational alternative. Here’s the full text of the Web Content Accessibility Guidelines standard, 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.
WCAG SC 2.1.2 is a Level A success criterion, which means that websites who fail this standard cannot be considered reasonably accessible under the WCAG framework. Remember, keyboard traps can render a site useless for some people — if visitors cannot navigate your site with a keyboard alone, you’ll need to address the issue as soon as possible.
Keyboard accessibility is important because many assistive technologies utilize keyboard commands to function. For example, blind users often use screen readers (software that converts onscreen text to audio or braille). The screen reader isn’t a standalone device; the user typically navigates with a keyboard.
Some users with mobility issues also prefer browsing with a keyboard, which can provide a faster experience with more precise control than a mouse. And many keyboard-only users don’t live with disabilities — they simply prefer using keystroke commands. While many users could switch back to a mouse after encountering a keyboard trap, great web design accommodates different browsing preferences. If your site forces people to use a certain set of peripherals, you’re alienating part of your audience.
Keyboard traps often occur within:
JavaScript implementations can pose especially serious issues; some JavaScript functions override the behavior of on-page elements, which can create a keyboard trap. Some of those functions can even create traps on apparently normal hyperlinks — you’ll want to test your site thoroughly when adding new elements or making major changes.
Per the WCAG standards, websites can address keyboard traps by providing clear guidance for escaping the “trap.” However, in most instances, the better (and easier) option is to fix the underlying problem.
Most keyboard traps occur accidentally, so if you’ve never audited your website for accessibility conformance, your site may have this issue. Fortunately, you can easily test individual pages by navigating without a mouse. Here’s a quick way to check:
If you’re able to navigate freely — and the site doesn’t redirect you to a different page — your page probably doesn’t contain any keyboard traps.
Read More: Give Yourself an Accessibility Test: Don't Use a Mouse
However, keyboard-only testing is limited, particularly for evaluating pages with interactive spreadsheets, text editors, and other complex features. Real users will want to take advantage of all of the features in your content, so don’t rely on a single test to evaluate accessibility.
We should also note that some users prefer browsing your site with touchscreens, eye-gaze controls, and other technologies. An accessible approach will accommodate all of these browsing methods. A full accessibility audit can help you identify barriers and maintain a better website.