Ensure that users can control all functionality via their keyboard.
Ensure all controls are keyboard accessible. [WCAG 2.1.1 - A]
Ensure all links are keyboard accessible. [WCAG 2.1.1 - A]
Avoid keyboard traps. [WCAG 2.1.2 - A]
Avoid keyboard shortcuts that consist of only a single character. [WCAG 2.1.4 - A]
Ensure focus on active control is visible. [WCAG 2.4.7 - A]
Do not trigger events when a control recieves focus. [WCAG 3.2.1 - A]
Do trigger unexpected events when a user inputs values or changes settings. [WCAG 3.2.1 - A]
For many users, the primary or only way they can interact with content is via a keyboard or keyboard-like input device (e.g., voice recognition software, virtual keyboards). It is imperative for these users that all functionality be operable by keyboard.
The most common cause of keyboard interoperability issues is when authors add custom scripted controls and links to their pages. Using HTML-native elements such as buttons, sliders and hyperlinks generally avoids keyboard input pitfalls. In these cases, authors only need to ensure that the controls are created accessibly — for example, that they are clearly labeled and grouped according to their purpose.
For custom controls, authors need to ensure that their creations meet all the same requirements as native controls. Some examples include:
- that users are able to reach the control;
- that the purpose of the control is clear;
- that the control is operable by keyboard; and
- that users do not get trapped in the control.
When creating custom controls, it is also important to consider the effects of shortcut keys on their ability to use a publication. It may seem like a convenience to sighted readers to assign single-key printable character (letters, numbers, punctuation) as a shortcut for an operation, but readers trying to enter commands may have their input intercepted. The result may be that the user cannot complete a necessary function or may potentially activate an unwanted action in the content. Authors must always allow users to remap or turn off single-character shortcuts.
It is also important to not cause changes of context when focus changes to the element (e.g., the user tabs to it). Changing the context, such as opening a new window, submitting a form, or altering the content, can cause confusion for readers who cannot see what has occurred.
Similarly, entering input into a field or changing the setting of a control must not cause an unexpected change of context.
The keyboard requirement for Level A conformance excludes functionality where the full path of movement is essential, not just the start and end points. A program that allows a user to drag an object and drop it, for example, is not excluded because the path to the destination does not matter. A drawing program, on the other hand, would be exempt because full path affects the drawn object.