For people with disabilities, it is important to have full functionality of a website through the keyboard. Assistive technologies like screen readers and alternative pointing devices such as haptic feedback and head pointers also benefit from full keyboard accessibility.
- Ensure no keyboard traps
- Make web content keyboard accessible
- Tab order
- WAI-ARIA landmark roles
Many people are accustomed to using pointing devices to navigate websites, but all modern browsers also allow content to be navigated and controls to be activated through the keyboard; mainly with control keys like Tab, Return and the arrow keys.
For people with disabilities, it is important to have full functionality of a website through the keyboard. Assistive technologies like screen readers and alternative pointing devices such as haptic feedback and head pointers also benefit from full keyboard accessibility. All alternative forms of input and control depend on keyboard input as the prime interface between user and computer. In addition, tablets and smartphones utilise some "keyboard" functions even through their keyboards are not physical devices. It is not uncommon for people with disabilities to connect keyboards or items that function like keyboards to these devices.
No other form of computer input is as flexible or widely supported as the keyboard input. This makes the keyboard a practical base for accessible input and interactions.
For these reasons, Success Criterion 2.1.1 Keyboard states:
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
There are several key points to understand this success criterion, which we will explore in turn.
- The point about specific timings is to ensure that people with cognitive disabilities, or people with slower or less accurate motor control are not placed at a disadvantage if they cannot complete a sequence of keystrokes in rapid succession.
- The exception that that depends on the path of the user's movement and not just the endpoints is to ensure that if the task is to, for example, draw a freeform line, that condition is exempt from requiring full keyboard operability.
Keyboard functionality relates to a website being operable, one of the four POUR principles that form the foundation of WCAG 2.0:
This does not mean that other forms of user control have to be ignored, such as mouse input or speech input, as long as full keyboard functionality is also available and accessible. This may cause some problem for functionality that depends on drag-and-drop events. The solution is to allow navigability by keyboard to the elements that can be moved by mouse, and allow them to copied, in order to be moved to their location (Copy > Paste).
Nor does it exclude computing devices that don't have physical keyboards, such as some smartphones or tablets. Those devices will have some way of accepting user input through keystrokes, through virtual keyboards, a number pad, or voice commands. This criterion applies to any hardware or software that generates keyboard or text input.