Keyboard accessibility
WCAG Guideline 2.1 (AA) and success criteria
Learn how to ensure that all functionality can be accessed and operated using a keyboard.
Last updated on
Make websites keyboard accessible (Level A, 2.1.1)
Websites should be designed to ensure that users can navigate and interact with them using only a keyboard or alternate keyboard methods. Alternate keyboards or keyboard emulators may include:
- Speech input software
- Sip-and-puff software
- On-screen keyboards
- Scanning software
Individual keystroke time limits should be removed or adjustable to eliminate the need for users to hold down a key for an extended period before it registers.
Exceptions with keyboard accessibility
Some time limits may be necessary for specific interactions, such as typing tests, where the purpose is to measure typing speed and accuracy. In such cases, the time limit should be adjustable.
For interactions that rely on the user’s movement path, such as drawing or handwriting input, provide alternative input methods that enable keyboard users to achieve the same function or result whenever feasible.
How to ensure keyboard accessibility
- Make sure all interactive elements, such as links, buttons, form fields and controls, can be accessed and activated using only the keyboard
- Associate appropriate keyboard event handlers with interactive elements to capture and respond to keyboard input
- Include a ‘skip link’ at the start of the webpage to allow keyboard users to bypass repetitive navigation and directly access the main content
- Ensure there’s a clear and visible focus indicator around the currently focused element. This helps users understand which element they’re interacting with, especially when navigating using the keyboard. Make sure it meets the minimum contrast requirements specified in WCAG 1.4.11
- Set the tab order of focusable elements to establish a logical and intuitive order for keyboard navigation
- Test the content by using only the keyboard to navigate through the page and interact with all interactive elements. Verify you can reach and activate each element using keyboard navigation alone
- Validate the keyboard accessibility of the content by testing it with people who rely on assistive technology such as screen readers or other keyboard-only navigation tools
- Avoid keyboard traps. Ensure keyboard focus is managed properly when interactive elements are activated. When a person activates an element, such as a dropdown menu, make sure the focus is shifted to the relevant content. After completing an action or closing a dialog, return the focus to the expected location or provide clear instructions on where the focus will be moved
- Avoid time-based interactions or actions that require precise timing for successful completion
Prevent keyboard navigation traps (Level A, 2.1.2)
Keyboard traps are when a user’s input (from a keyboard or other input device), becomes trapped in a certain place in a program or website. It stops them from being able to perform other actions and traps them in the spot they’ve arrived at.
This can happen from a bug or design flaw which stops the program or website from properly handling user input. For example, a pop-up window with no option to close it using a keyboard.
This success criterion requires that any component that can be moved to using keyboard focus can be moved away from using only a keyboard interface. Users must be notified if the method for moving focus away is different than standard exit methods such as unmodified arrow or tab keys.
How to prevent keyboard traps
- Ensure keyboard focus can be moved to any component or interactive element on the webpage using a keyboard interface. This includes links, buttons, form fields and other controls
- Once the keyboard focus is on a component, make sure people can move the focus away from that component using only a keyboard interface. This is typically achieved using standard keyboard keys such as arrow keys or the ‘Tab’ key to navigate to the next focusable element
- If the component requires a non-standard method or specific keyboard command to move the focus away, provide clear instructions or notifications to the user about the method. They should be informed of the specific key or command to use
- Test your webpage or application using keyboard navigation alone to verify users can easily move the focus to and away from all components. Ensure there are no instances where they get trapped and are unable to move the focus away from a particular element
Make sure keyboard shortcuts can be controlled by users (Level A, 2.1.4)
Keyboard shortcuts are useful for many people. However, they can interfere with assistive technologies that use the same shortcuts for other purposes. To fix this, people need to be able to turn off or reconfigure shortcuts made up of only character keys.
Keyboard shortcuts for user interface (UI) components should only be active when the component is selected by the user (on focus). For example, if a button has a keyboard shortcut assigned to it such as the number ‘1’ key. The ‘1’ key should only activate the button if the button is selected (or on focus) by the user.
Any keyboard shortcuts essential to the way the website works must be documented and provided to users in a way that’s easy to understand.
How to allow customizable keyboard shortcuts
- Provide a mechanism that allows people to turn off the keyboard shortcut. This gives them the option to disable or deactivate the shortcut if it conflicts with their assistive technology or personal preferences
- Provide a mechanism that allows users to remap the keyboard shortcut to use one or more non-printable keyboard characters, such as ‘Ctrl’, ‘Alt’ or other modifier keys. This allows people to customize the shortcut to fit their needs or to avoid conflicts with other shortcuts
- Ensure the keyboard shortcut for a UI component is only active when that component has focus