Web Accessibility Criteria - Keyboard Traps

• Introduction
• Best Practices
• Examples
• How to Test for Keyboard Traps
• WCAG 2.1 and References 

 Introduction

To ensure keyboard accessibility keyboard traps mustn't be present on a web page. Keyboard traps occur when a keyboard user cannot move focus away from an interactive element. Traps can occur in input boxes, drop-down menus, or even on hyperlinks. This forces the keyboard user to be stuck inside the input box or forces them to activate a hyperlink without having the option to go past the link.

Why are Keyboard Traps a Problem? 

Keyboard traps are a huge problem for those who use keyboards to navigate the web. If there is an element that does not allow the user to continue through the page, the user will not have the ability to access all of the information on the page. A simple keyboard trap can ruin an entire page.

 Best Practices

The best practices for keyboard tab order include:

• If a popup dialogue box appears on the web page users should have the ability to navigate to it and be able to exit the dialogue box using a keyboard only.
• Ensure that the keyboard function for advancing focus within content (commonly the tab key) exits the subset of the content after it reaches the final navigation location.
• Provide a keyboard function to move the focus out of the subset of the content.
• NOTE: Third-party adverts and widgets are often not accessible.

 Examples

Example 1: Loop Trap

The link below is an example of a keyboard trap loop on the General Service Administration website. The keyboard users are in a continuous loop when they try to navigate through a set of links. Users can disable the keyboard trap by selecting one of the links on the page.

General Service Administration Keyboard Trap: Forever Loop

Example 2: Stuck on an Element

The link below is an example of a keyboard trap from the Interactive Accessibility website. Keyboard users can navigate to the first form field "Last Name" and the second form field "Last 4 digits of your Tax ID." After the user reaches the second form field, they are unable to navigate between the first form or the third form. The user is unable to move forward with the form fields, leaving the user stuck on the second form.

Interactive Accessibility Trap: Frozen Element

Example 3: Cannot Navigate Below Element

The link below is an example of a keyboard trap from Github. On the page, there are two links, the first link is "Trap" the second link is "Honey". When the keyboard users have the focus on the first link and try to shift the focus away from the link, the link is activated. Users are unable to move the keyboard focus away from the first link, leaving the second link not navigable.

Github Trap: Unreachable Information/Link

 Back To Top 

 How to Test

Testing for keyboard traps requires a keyboard accessibility evaluation. The basic functions to use for a keyboard accessibility evaluation are:

• Tab key to navigate through links and form controls.
• Enter (and /or Spacebar) to select an element.
• Arrow keys are sometimes used for other navigation.

General Test

1. Start at the browser address bar. (This forces focus to start at the top of the page)
2. Take your hand off your mouse and use only your keyboard.
3. Using the Tab button, navigate until you’ve reached the bottom of the page. (You can use Shift+Tab to navigate back one step.)
   • For elements like radio buttons, checkboxes, etc. the arrow keys should be used to check that all interactive elements have visual focus.

Verify that:

1. There are no instances when you become trapped in an element.
2. There are no instances when an element redirects you to a different page without letting you tab past that element.
3. There are no instances of "Roundabouts" where you are suddenly taken to the top of the page and are unable to navigate past that element.

 Back To Top 

 WCAG 2.1  and References