Definition for WCAG 2.0 success criterion 2.1.1
2.1.1 Keyboard: 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.
- Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
- Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
The intent of this Success Criterion is to ensure that, wherever possible, content can be operated through a keyboard or keyboard interface (so an alternate keyboard can be used). When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip-and-puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find the use of software much easier (or only possible) if they can control it from the keyboard.
Examples of "specific timings for individual keystrokes" include situations where a user would be required to repeat or execute multiple keystrokes within a short period of time or where a key must be held down for an extended period before the keystroke is registered.
The phrase "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints" is included to separate those things that cannot reasonably be controlled from a keyboard. Most actions carried out by a pointing device can also be done from the keyboard (for example, clicking, selecting, moving, sizing). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes. Free hand drawing, watercolor painting, and flying a helicopter through an obstacle course are all examples of functions that require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input.
Note: for success criteria involving keyboard testing, ensure that your browser/OS is set to allow for full keyboard navigation. In macOS in particular, go to System Preferences > Keyboard > Shortcuts and ensure that the "Full Keyboard Access" option is set to "All controls".
Testing success criterion 2.1.1
Input into spreadsheet
- Fail
- Content not operable using the keyboard-alone. Record the nature of the failure:
- A mouse is required to navigate to or to operate some or all active elements or to trigger specific functionality.
- Sequences of keystrokes require the user to perform keystrokes with a specific timing.
- Pass
-
- The keyboard can be used to navigate to and operate all active elements and trigger all functionality that can be operated/triggered with a mouse.
- Keystrokes do not require any specific timings.
How to test
Test with the keyboard to verify that there are keyboard equivalents for all actions. All actions that can be executed using a mouse can also be executed using the keyboard alone.
At a minimum, the following keyboard operations must be tested:
- Using keyboard alone, navigate to and operate every interactive element (buttons, links, widgets, etc.) in web pages and dialog boxes, including complex controls like TreeViews. Keyboard navigation/operation of widgets should follow the keyboard interaction for the appropriate WAI-ARIA Authoring Practices - Design Patterns and Widgets.
- If tabs are present, verify that tabs can be switched using the keyboard alone, and navigation continues from the currently selected tab.
- Use the keyboard to open, interact with and close modal dialogs or overlays.
- Use the keyboard to open non-modal dialogs and to switch keyboard focus between non-modal dialogs and the primary page content.
- Wherever a mouse can be used to select elements or objects (checkboxes, radio buttons, comboboxes, autocomplete listboxes, etc.), make sure the same selections can be made using keyboard alone.
- Verify that features invoked via direct manipulation using the mouse are available from the keyboard. For example, if an object can be resized using the mouse by drag and drop, it must also be able to be resized by setting the size attributes explicitly on a dialog or properties sheet.
- Verify that the correct keyboard operation does not depend on "specific timings", i.e. that sequences of keystrokes do not depend on the user's ability to enter the sequence within a certain timeframe / that the operation is not aborted if the user takes "too long" between key presses.