Digital Accessibility Index: Learn where the world’s leading brands fall short on accessibility.

See Report

Avoid "Keyboard Traps" To Make Your Site More Accessible

Sep 17, 2021

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 traps create major usability issues 

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: 

  • Form fields, drop-down menus, and other user input areas
  • Embedded media players
  • Third-party widgets like calendars and CAPTCHAs

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. 

To find keyboard traps, test your website without a mouse

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:

  1. Open the page you’d like to test, then use your tab button to move through the page. 
  2. Once you’ve reached the bottom of the page, use shift-tab to move back up. 
  3. If your page contains a form, make sure you can complete the form without your mouse. Select different options within the form to make sure they’re all usable.

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.

Use our free Website Accessibility Checker to scan your site for ADA and WCAG compliance.

Powered By

Recent posts

What's Next for US Web Accessibility Laws?

Jun 14, 2024

How the HTML Element Improves Accessibility

Jun 13, 2024

How Information Security and Digital Accessibility Can Coexist

Jun 10, 2024

Not sure where to start?

Start with a free analysis of your website's accessibility.