2. Operable
2.1 Keyboard Accessible (Level A)
Contents
Guideline 2.1 Keyboard Accessible
User interface components and navigation must be operable.
Why must web pages be accessible without a mouse?
Some people cannot use or have difficulties using a mouse. For example:
- The mouse is designed to be guided by eye. Users who are totally blind cannot see the mouse pointer.
- Mouse pointers tend to be small. Individuals with low vision may have trouble spotting the mouse pointer on the screen.
- Someone with a learning disability may find the movements of the mouse pointer distracting, or they may lack the hand-eye coordination needed to reliably use a mouse.
- Some people have trouble remembering when to left-click, double-click, or right-click.
- A person who has hand tremors may be unable to hold the mouse steadily enough to click small screen objects. Some seniors who do not have hand tremors report difficulties holding the mouse steady enough to double-click.
Success Criterion 2.1.1 Keyboard
Level A
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.
Keyboard Explained
The computer mouse is ubiquitous today, but before 1984 most computer users did not use one. The mouse only became pervasive during the mid–1990s. In recent years, other mouse-like devices have been introduced, including trackballs, touchpads, and trackpoints. Now, a mouse (or a similar pointing device) comes with every computer, and most people would be lost without one.
Yet some people cannot use — or have difficulties using — a mouse. For example:
- An individual with low-vision may have trouble locating the mouse pointer on a screen
- A person who is totally blind cannot see the mouse pointer at all
- Someone with a learning disability may find the movements of the mouse pointer distracting
- A person who has hand tremors may be unable to hold the mouse steadily enough to click on small screen objects
In addition, there are individuals who find that pressing a few keys on the keyboard is faster, easier, and more accurate than pointing and clicking. Many “average” computer users know a few keyboard shortcuts, and some “power users” rarely touch the mouse at all.
Many tasks that are typically done with a mouse can be (or should be) easily keyboard accessible, including “clicking” hypertext links, drawing straight lines and regular geometric shapes, and resizing windows. There are even keyboard equivalents for dragging and dropping. But when a task cannot be performed without a mouse, some people will be prevented from taking full advantage of a site.
WCAG 2.1 acknowledges that some tasks cannot reasonably be done with a keyboard, such as real-time flight simulations. Tasks that depend on continuous, time-sensitive movements that do not have start and end points are excluded. But the highest conformance level that such a website can attain for Guideline 2.1 is Level A. To achieve Level AAA, all content must be keyboard accessible. Also, see SC 2.1.3 Keyboard (No Exceptions).
Many of the assistive technologies that people with disabilities rely upon emulate the functionality of a keyboard. Content that is accessible by keyboard can also be accessed by devices that emulate keyboards. For this reason, the ability to interact with web content using only a keyboard is core to web accessibility.
Key Point: SC 2.1.1 Keyboard is as important as SC 1.1.1 Text Alternatives. If neither are addressed, a website will have insurmountable barriers that some users with disabilities may have no way to work around.
Try This: Keyboard Accessible Drag-and-Drop
One common keyboard-inaccessible culprit around the Web is drag-and-drop widgets. Developers often have trouble making these accessible, though there are a number of strategies available to make them usable with a screen reader.
The following two examples of drag-and-drop sortable lists may look identical, but there is one difference. Mouse users will find that both function exactly the same way; however, for keyboard users, only the first one is accessible.
To test each sortable list:
- Open ChromeVox or your preferred screen reader.
- Using your mouse pointer (if you are able), grab one of the list items from each list and drop it in a new position.
- Listen to what the screen reader announces in each case.
- Now put your mouse away, and use your keyboard to complete the same task.
- Mac users use Command + arrow to select and move list items. Windows users use Ctrl + arrow.
Notice that there is no way to reorder the list using a keyboard alone in the second example below. The first example would pass, and the latter would fail accessibility testing.
Also, notice how the screen reader announces the accessible version. These semantics are created using WAI-ARIA. WAI-ARIA will be covered in more detail later in later unit and will be covered in great detail in our Web Accessibility for Developers book.
Example 1: Accessible Sortable List
Example 2: Inaccessible Sortable List
Suggested Reading:
Success Criterion 2.1.2 No Keyboard Trap
Level A
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface. If it requires more than unmodified arrow or Tab keys or other standard exit methods, the user is advised of the method for moving focus away.
No Keyboard Trap Explained
A “keyboard trap” is an area of a web page where a person gets stuck when navigating without a mouse. You can navigate to a spot by pressing a sequence of keystrokes, but you cannot leave — unless you use a mouse.
Keyboard traps usually occur when applications are embedded in web pages. The main culprits are text editors, spreadsheets, and media players. For example, on some online forums, it is possible to navigate to a built-in text editor by repeatedly pressing the Tab key but impossible to exit it without a mouse.
If there is a non-intuitive keystroke (or series of keystrokes) to escape a keyboard trap, let users know about it. One option would be to provide instructions within the embedded application: “To exit this spreadsheet, press Ctrl + W (Windows) or Command + W (Mac).”
Try This: Example Keyboard Trap
This example requires a Flash plugin be installed with your browser and enabled (right-click the space below to enable if the calculator does not appear).
Using two or more different browsers to view this page, use the keyboard’s Tab key to navigate to the Flash calculator below. Notice whether you are able to use the calculator without the aid of a mouse. Notice what happens when you try to navigate away from the calculator using just your keyboard.
Note: Current browsers will add a play button to the Flash object below. You may need to click the play button to make the Flash object available. Click the link below to open the calculator if it does not appear here.
[This Flash object is no longer supported]
Suggested Reading:
Success Criterion 2.1.4 Character Key Shortcuts
WCAG 2.1
Level A
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case), punctuation, number, or symbol characters, then at least one of the following is true:
- Turn off: A mechanism is available to turn the shortcut off.
- Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g., Ctrl, Alt, etc).
- Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.
Character Key Shortcuts Explained
This success criteria was introduced in WCAG 2.1 to take into account a growing awareness of the need for keyboard access on the Web, for both desktop and mobile applications. It is intended to address access via single, printable keyboard characters, including numbers, letters, and punctuation used to control websites and web application features. An example might be using the “F” key to open a File menu.
While these shortcuts can be very handy for keyboard-only users, they can be quite problematic for voice users, using speech recognition software to control their computer or mobile device. When using speech recognition software, it is typically possible to switch between command and dictation modes, which can be quite inefficient. Speech users will often use an all-encompassing mode, with pauses between dictation and commands. However, if the pause is too short, commands may end up being dictated into a form or document. These types of errors are typically easy to revert and are more an annoyance than a barrier.
Real problems occur when spoken words in command mode fire off a series of commands associated with the letters in a word. It can be even more problematic when spoken words are picked up in the background, especially from other speakers. The result can completely disorient a user. Watch the following video to see what happens when spoken words are interpreted as commands.
Video: Single key shortcuts affecting speech input by Kim Patch
To prevent these types of occurrences, keyboard commands programmed into websites and web applications can include a non-printable character key as a modifier, much like Alt, or Ctrl, or Alt + Ctrl together as the ChromeVox modifier keys. Or, if single characters are to be used, a feature is available to disable character keys or remap them, which allows users to define their own key combinations for various controls.
Key Point: This success criteria does not affect the use of HTML access keys because they will always include a non-printable character key as a modifier, such as Alt or Ctrl. It applies only when single character keys are used, typically keys that are scripted for controls in web applications.
