SC 2.1.1 Keyboard supports the Operable accessibility principle because users who have limited or are without vision, limited manipulation, or limited reach and strength may not be able to use a pointing device such as a mouse for interaction; they must have the ability to operate all content through a keyboard or keyboard interface.
Keyboard access is a key accessibility requirement. Without keyboard access, many users with different disabilities may have complete loss of access to a product. The intent of this SC is to ensure that all functionality available through a pointing device can also be accessed and executed using only a physical keyboard or keyboard interface (e.g., alternative input devices such as dictation software) and does not require specific timing for keystroke activation. Keyboard access can be considered as the default baseline level of access, with mouse and touch access as additional “above and beyond” baseline access.
One method of providing keyboard access is use of “shortcut keys.” Shortcut keys may be implemented to directly access application functions, such as TAB, ENTER, and CTRL+ C. Application-specific shortcut keys must not interfere with these standard [operating system (e.g., Windows)] shortcuts. Keyboard access can also be provided through a keyboard menu. For example, in almost all Windows programs, it is possible to tab to a button or icon and press ENTER to activate it. This is the same as moving the mouse pointer for focus and clicking the left mouse button. Also, it is often possible to navigate menus using the arrow keys.
For example, when you press ALT within Outlook, letters appear near each ribbon menu tab. Pressing one of these letters on the keyboard takes the user to the associated tab, such as pressing the H to go to the Home tab.
SC 2.1.1 Keyboard also states that along with content being keyboard accessible, the author must not implement specific timings for individual keystroke activation. Examples of specific timings for keystroke activation which would be nonconforming to this SC are:
- when a user is required to repeat or execute multiple keystrokes within a short period of time (e.g., press the Escape key seven times within 3 seconds or you will be logged out) or
- where a key must be held down for an extended period before the keystroke is registered (e.g., requiring a user to press and hold Enter for 10 seconds to accept).
This SC also has an exception that applies when the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. This is included to distinguish actions that cannot realistically be controlled with a keyboard only, such as freehand sketching a portrait or driving a virtual car through a simulated race track. These actions require a user to follow a specific path in order to reach the end result or achieve the expected outcome and thus are exempt from this SC.
It is important to note that this exclusion only applies when the path required to get to the end result is relevant. For actions such as drawing a rectangle, dragging and dropping items to a shopping cart icon on screen, or resizing a browser window, the path the user must take to reach the end result is irrelevant; only getting to the end matters. In these cases, the exception is not applicable.
An example of an irrelevant user path would be if a developer allowed a user to drag and drop the Calculator icon into the Recycle Bin to delete it. The path the user takes to drag the calculator in order to complete the action does not matter as long as they end with a drop in the Recycle Bin. Since the path to drag and drop the calculator is not relevant, the exception is not applicable and a keyboard-only method to perform the same action is required.
Impact of Nonconformance with SC 2.1.1 Keyboard
| Type of Disability | Description of Impact |
|---|---|
| 302.1 Without Vision | Users who are blind cannot use a mouse to interact with electronic content and typically use an assistive technology, such as a screen reader, to get audible or other alternative output for the information represented visually. To be able to navigate the content, understand its structure and relationships, and understand the meaning of content represented in graphics and images, the content must provide textual and programmatic cues in addition to the content presented purely visually. |
| 302.2 With Limited Vision | Users with limited vision may have widely different visual perception. Individuals with limited vision may or may not use assistive technologies. Therefore, in addition to textual and programmatic cues necessary for assistive technologies, ICT must also present content consistently and predictably. Users who view content with magnifiers may not pick up alerts, warnings, or other content if such content is presented outside of a consistent and predictable navigation pattern or if the content is not itself viewable at large magnification. Content that becomes distorted when magnified can also prevent some users with limited vision from being able to understand or interact with the content. |
| 302.7 With Limited Manipulation | Some users may not be able to perform actions that require fine motor control (clicking and dragging), path dependent gestures (pattern-based passcodes), or simultaneous actions (Ctrl + Alt + Del). Providing alternative means to perform the same actions, such as entering the size specifications in an input field to resize an object or allowing sequential key entries, can enable users with limited manipulation to interact with the same content. |
| 302.8 With Limited Reach and Strength | Some users may lack sufficient strength to perform actions such as squeezing, grasping, or depressing a hardware control. Some users, including those in wheelchairs or of shorter stature, may not be able to reach controls that are placed too high or too far away from where a user would access the device controls or interface. ICT designers and developers must consider a broad range of statures, strength and dexterity limitations, and the needs of wheelchair users in order to provide interfaces that are operable with limited reach and/or strength. |
Applicability of Success Criteria 2.1.1 Keyboard
| Technology | Applicability of S.C. 2.1.1. Keyboard |
|---|---|
| Web | Web developers must actively manage keyboard access by ensuring that all functionality available by mouse is also available by keyboard. Certain elements receive keyboard focus by default, but in others, a developer must make a component keyboard focusable by assigning a valid “tabindex” to the component. Similarly, when developers enable a function based on mouse events (e.g., onmouseover, onmouseup, onmousedown), they must also ensure that a keyboard can perform the same function. |
| Software | Software developers must actively manage keyboard access to controls and functionality. Certain software controls receive focus by default, based on the control type and control pattern. For custom controls, however, a developer may need to explicitly include the control in the tab order and/or ensure that the correct control type is assigned to the control to make it keyboard accessible. Similarly, when developers provide functionality via mouse events (e.g., mouse-over, mouse-up, mouse-down) they must provide the same functionality via analogous keyboard events. |
| Office documents | Text and standard objects inserted in the body of a document are generally keyboard-accessible be default in Office documents. Some practices, such as inserting meaningful content in watermark images or creating functions using embedded custom code can prevent keyboard users from being able to access and/or interact with the content. When using custom code in an Office document, content authors and developers must ensure keyboard access just as described under “Software,” above. Some Office versions also have mixed results for keyboard accessibility with their form controls. |
| PDF documents | Keyboard accessibility in PDF documents relies on proper PDF tag structure for all standard components of a document. Depending on the PDF authoring tool, some interactive elements, such as form controls, may be more keyboard accessible than others. It is also possible to embed custom code and controls to provide functionalities in PDF documents. In such cases, the PDF author must actively manage keyboard access to components and/or their related functions. |
| Mobile Native | Keyboard access in mobile-native software development has a slightly different connotation than for desktop applications. Mobile device users typically use touch interactions rather than a mouse to interact with content. Users with disabilities may also use touch in combination with voice inputs, rather than a keyboard, to interact with mobile content. However, someone who uses a mobile device’s screen reader to navigate and interact with mobile content typically uses touch gestures to sequentially navigate through and interact with content rather than visually identifying and taping on a specific location on the screen. Therefore, such sequential navigation and interaction using touch gestures serves the same purpose as keyboard navigation, and the underlying principle of keyboard access is the same. Individual interface components and/or their associated functions must be individually focusable and identifiable in order to provide access to AT users. Mobile-native software developers must, therefore, actively manage keyboard access to functionality just as described under the “Software” section above. |