Keyboard

About

Version:	WCAG 2.0 and up
Number:	2.1.1
Level:	A
Applicability:	Buttons Custom Controls Forms Inputs
Requirement:	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.
Guidance:	Understanding Success Criterion 2.1.1 How to meet Success Criterion 2.1.1
Techniques:	G90: Providing keyboard-triggered event handlers G202: Ensuring keyboard control for all functionality H91: Using HTML form controls and links SCR2: Using redundant keyboard and mouse event handlers SCR20: Using both keyboard and other device-specific functions SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons

Purpose

The purpose of this success criterion is to ensure that user that require a keyboard to access a publication have access to all functionality in the content, except where the required input cannot be replicated by keyboard.

How to Meet

Authors need to ensure that all controls and links are accessible by keyboard input and that the input is not time-based (e.g., that users must press keys a certain number of times or for a specific length of time to register).

This success criterion typically applies to custom controls and links that authors create through scripting. Native HTML elements for these functions are generally accessible, with authors only needing to ensure that they are clearly labeled.

Note that this success criterion does not apply to functionality where the full path of action is important, as keyboards typically cannot replicate this functionality. An example would be an embedded program that allows users to freehand draw.

Additional Information

The following knowledge base pages provide more information about how to address this success criterion for publishing content:

Keyboard Control