Input modalities
WCAG Guideline 2.5 (AA) and success criteria
Learn how to make it easier for users to operate functionality through various inputs beyond a keyboard.
Last updated on
Make sure content can be used with both multi and single pointer gestures (Level A, 2.5.1)
A multi-point gesture involves using more than one finger (or pointer) to interact with content. For instance, pinch-to-zoom uses 2 fingers to zoom in or out. Any feature that needs multi-point gestures should also work with just one finger or a single pointer.
To do this, you can provide alternative input methods, such as:
- Buttons for zooming in and out, or
- Offer voice commands that allows users to access the same functionality
Use voice commands
To enable voice commands as an alternative, you need a voice user interface (VUI) that understands and responds to voice commands. One common method is to use a natural language processing (NLP) engine. The engine interprets spoken language and triggers the appropriate actions. Here’s what you should do:
- Choose an NLP engine
- Define a set of voice commands that map to the gestures you want to replace, like ‘Zoom in’
- Implement the VUI. This could involve using APIs or libraries provided by the NLP engine and integrating them into your website or app
- Test the VUI with various users, including diverse accents and speech patterns
Using path-based gestures
A path-based gesture means using your finger or a stylus to trace a specific path or shape on a touch-based device or interface. For example, scrolling down by holding your finger and tracing down on the screen.
For path-based gestures, provide alternative navigation options like a table of contents or a set of links. Allow users to navigate content without relying solely on path-based gestures.
Pointer gesture exceptions
The guideline allows for exceptions when path-based gestures are essential for functionality, such as:
- Signature capture which allows users to sign digital documents by tracing a path to create a signature
- Drawing or sketching apps which are designed for creating digital artwork or taking handwritten notes
- Navigating through complex visualizations or maps, where precise tracing is required to move around the interface
- Accessibility features: In some cases, path-based gestures might be essential for certain types of accessibility features, such as on-screen keyboards or other assistive technology that relies on touch input
Determining if it’s essential should be based on the specific website or application and the needs of its users.
How to provide alternatives to pointer gestures
- Identify interactive elements or features that rely on multipoint or path-based gestures, such as pinch-to-zoom or swipe gestures. For each one, ensure there is an alternative way to operate it using a single pointer, like a mouse or a single-finger touch gesture. This could involve:
- Additional controls
- Buttons, or
- Alternative interaction methods
- Test the alternative methods are fully functional and provide the same functionality as the multipoint or path-based gestures. Check users can effectively operate using a single pointer
- If there are specific cases where a multipoint or path-based gesture is essential for functionality or user experience, clearly communicate it to users. Provide instructions or prompts explaining the requirement for such gestures and why they’re essential
- Do user testing to identify any barriers or challenges that users may encounter when operating the functionality
Give users control when a single pointer is used for an action (Level A, 2.5.2)
When functionality can be operated using a single pointer (such as a mouse), at least one of the following must be true:
- The ‘down-event’, when you click or touch down without releasing the pointer, should not complete the action. The user should have to release the pointer to finish the action. For example, clicking on a link should not take you to the linked content until you release the click
- Allow users to interrupt an action before it completes during the ‘up-event’ (releasing the click or touch), such as by moving the pointer away from the element before releasing
- If the down-event triggers an action, like clicking a checkbox, users should be able to undo the action by clicking the checkbox again
- Implement up reversal functionality, where actions like tooltips only appear while the pointer is held down and disappear upon release
Pointer cancellation exceptions
Completing the function on the down-event may be essential for some types of time-sensitive interactions. For example a game where players need to react quickly and need to trigger an action without waiting for the up-event.
This success criterion applies to pointer-based input, such as mouse clicks and touch gestures. It does not apply to keyboard-based input where it’s common to hold down a key to repeat an action.
How to allow pointer cancellation
- Identify interactive elements or features that can be operated using a single pointer, such as buttons, links or form controls. Verify they meet at least one of the following conditions:
- No Down-Event: The function or action is not solely triggered by pressing down on the pointer, like a mouse click or touch on a touchscreen device
- Abort or Undo: Users are able to cancel or reverse the action if they change their mind or make a mistake
- Up Reversal: If the function or action is triggered by pressing down on the pointer, releasing the pointer undoes or cancels the action
- Essential: Completing the function on the down-event is essential. This applies to functions that emulate a keyboard or numeric keypad key press, such as typing characters or entering numeric values
- If the element or feature does not meet the above conditions, make the necessary changes to ensure compliance. This may involve:
- Adjusting event triggers
- Adding abort or undo mechanisms, or
- Modifying the behaviour of the function
- Test the interaction using a single pointer to ensure people can execute, cancel or reverse the actions
- Do user testing to identify any barriers or challenges users may face when interacting with the functionality using a single pointer
Use consistent names in labels (Level A, 2.5.3)
This guideline applies to all user interface (UI) components with labels that include text or images of text. This includes things like buttons, form fields, dropdown menus and links. Most controls are accompanied by a visible text label, they also have a programmatic label.
The text for both the visual and programmatic labels should match. This allows people who use speech recognition applications to navigate by speaking the visible text labels.
To do this, you need to determine which text on the screen is considered the label for the control. For left to right languages, the typical positioning is:
- To the left for controls such as dropdown lists, text inputs or combo boxes
- To the right for checkboxes or radio buttons
- Inside buttons or tabs, or immediately below icons which serve as buttons
Exceptions for label in name criterion
- Symbols: When visual labels are symbols rather than language, such as a bold capital ‘B’ indicating ‘bold’ in a text editor, the programmatic name should reflect the function (‘bold’) rather than the visible label (‘B’)
- Punctuation: Punctuation does not need to be included in the programmatic label. For example, if a visible form label says, ‘First Name:’, including the colon in the programmatic label may cause a failure for someone using speech-to-text
- Math symbols: Do not convert formulas to words in programmatic labels. For example, in a quiz with radio buttons offering options A>B, A=B, A<B, it’s best to use the symbols in the programmatic label, as speech can express the equation in multiple ways. Users’ familiarity with their speech software can help achieve a match
If a visible text label is absent for a component, this success criterion does not apply.
How to use consistent label names
- Review the labels associated with each UI component, such as buttons, links, form fields, checkboxes and radio buttons. Labels can be provided through various methods, including:
- Adjacent text
- Explicitly associated text
- By using the ‘aria-label’ or ‘aria-labelledby’ attributes
- For each component, make sure:
- The name or description contains the same text that’s presented visually, and
- The labels are correctly associated with the respective UI components
- Test the accessibility of the components with people who rely on assistive technologies, such as screen readers, to confirm the labels are accurately conveyed to them
Don’t make people move their devices or selves to use your content (Level A, 2.5.4)
Inclusive design allows users to operate device or user motion functionality, like shaking a device to ‘undo’, through alternative methods like user interface (UI) components. Because not all users can use motion-based interactions, it’s important to disable motion responses unless the product qualifies for one of the exceptions described below.
Exceptions when managing motion actuation
Motion can be helpful in operating features, especially in interfaces that support accessibility. For example, individuals who can’t use their hands may rely on tools like a mouth stick to interact with content using motion.
Motion can also be essential for the functionality of certain content. Disabling motion in these cases would make the content unusable or disrupt the intended activity. Examples include games where users tilt their device to control movement or fitness apps that monitor and analyze user movements.
How to manage motion actuation
- Check if any functionality depends on device or user motion, such as shaking, tilting, rotating or gesturing. If it does, follow these guidelines:
- Make sure the same functionality can also be operated using UI components like buttons, links, or other interactive elements
- Provide an option to disable motion response, either temporarily or permanently, unless specific exceptions apply:
- Supported Interface. If motion is used through an accessibility supported interface (such as specific accessibility features or assistive technology), you do not need to disable motion response. Clearly document and communicate the supported interface to users
- Essential Function. If motion is crucial for the function and disabling it would render the activity or purpose of the functionality invalid. For example, if a game relies on motion-based interaction as an integral part of gameplay
- Test the accessibility of the components by testing with people who rely on assistive technologies such as screen readers, switch devices and keyboard-only navigation