Guideline 2.5 - Input Modalities
Make it easier for users to operate functionality through various inputs beyond the keyboard.
Success Criterion 2.5.1 - Pointer Gestures
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture unless a multipoint or path-based gesture is essential.
Some people can't perform gestures in a precise manner or may use a specialized input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator. Some pointing methods lack the capability or accuracy to perform multipoint or path-based gestures.
Multipoint gestures include multiple fingers to operate and are usually impossible to perform with a traditional mouse. They include "pinch to zoom", three-finger taps, and similar gestures. Path-based gestures depend on the pointer path, not just the endpoints. For instance, a carousel may offer swipe gestures, and a slider might offer to drag the thumb to change the value. If other single-pointer, non-path-based mechanisms to trigger the same functionality aren't available, this is a violation of this Success Criterion.
Single pointers are defined as follows:
Pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures.
To implement this Success Criterion, you can:
An example of this technique in the carousel mentioned earlier would be adding "previous" and "next" navigation buttons.
An example of this technique would be to make sure users can set control slider values by tapping or clicking on the point to which they want to move the thumb.
This is natively supported by
Success Criterion 2.5.2 - Pointer Cancellation
For functionality that can be operated using a single pointer, at least one of the following is true:
- the down-event of the pointer is not used to execute any part of the function
- the function completion is on the up-event on a pointer, and a mechanism is available to abort the function before completion or undo the function after completion
- the up-event reverses any outcome of the preceding down-event
- completing the function on the down-event is essential (such as in on-screen keyboards)
Down events (such as
mousedown) occur when the pointer trigger is depressed, such as the user touching the screen (and not lifting their finger) or pressing the mouse button (and not lifting their finger). Up events (such as
mouseup) occur when the pointer trigger is raised, such as the user lifting their finger from the screen or releasing the mouse button that was pressed.
To implement this Success Criterion:
- ensure drag-and-drop actions are cancellable, for instance, by releasing a dragged item outside the target, by asking for confirmation, or by allowing reversal
- using appropriate events, such as
mouseupthat trigger only when the pointer is released
Success Criterion 2.5.3 - Label in Name
For UI components with labels that include text or images of text, the name contains the text that is presented visually.
Most controls have a visible text label, but they also have a programmatic accessible name, determined through semantic
<label> elements or
Sighted users using screen readers have a better experience when these match or the visible label is contained in the accessible name. Furthermore, if these don't match, users using speech-to-text navigation won't be able to navigate to the content.
The accessible name for
input elements of the types
text, password, search, tel, url and the
textarea element is determined as follows, stopping if an accessible name has been produced in any of the steps:
aria-labelledbyare present, they'll be used in accordance with the algorithm described in Accessible Name and Description. Computation
- In short,
aria-labelledbyis preferred by the algorithm.
- However, this is a very complex algorithm. Read through it and/or use the accessibility tree to validate your assumptions.
- In short,
- If an associated
labelelement is present, their accessible names will be used, as determined by the Accessible Name and Description Computation algorithm.
- If more than one
labelis associated with the element, the labels will be concatenated by DOM order, delimited by spaces.
- If more than one
- The element's
titleattribute will be used if present.
- The element's
placeholderattribute will be used if present.
- If none of the steps above yield a usable text string, there is no accessible name.
Similar algorithms apply to other elements. See the HTML Accessibility API Mappings specification for more information on how accessible names and descriptions are computed.
To sum up, to follow this success criterion, you can:
- include the text of the visible label as part of the accessible name
- match the accessible name to the visible label
You can fail this Success Criterion if:
- the accessible name does not contain the visible label text
- the accessible name contains the visible label text, but not verbatim:
- the words on the visible label are not in the same order as they are in the visible label text, or
- one or more other words are interspersed in the label
To provide good labeling, we suggest the following:
- providing a single
<label>element for all form controls
- overriding it with
aria-labelwhere necessary and including the
<label>content in the
- overriding it with
- providing a title for
<button>elements or an
- providing a
<fieldset>, with its first child describing the fieldset or providing an
alttext for images
- providing an
For more information on how labels are calculated for HTML elements and guidance on other elements not mentioned here, see the HTML Accessibility API Mappings specification.
Note that if you're already providing labels and
alt text using semantic HTML practices, you're probably already following this success criterion. This suggests that if there is a visible label and a different accessible name (which can happen if you're overriding it with ARIA or not using
<label> properly), the accessible name should contain the visible label.
Success Criterion 2.5.4 - Motion Actuation
Functionality that can be operated by device motion or user motion can also be operated by UI components, and responding to the motion can be disabled to prevent accidental actuation, except when:
- the motion is used to operate functionality through an accessibility-supported interface
- the motion is essential for the function, and doing so would invalidate the activity (such as in games or sensor demo apps)
For instance, users with tremors might often trigger "shake to undo" or "shake to send feedback" gestures by accident. Users with motor impairments might not be able to trigger them at all.
To follow this success criterion:
- provide conventional controls and an application setting for motion-activated input
- users should have a mechanism that doesn't rely on a sensor to perform the same functions
- users have a setting to disable motion detection
- support system-level features that allow users to disable motion actuation
You can fail this success criterion if users aren't able to deactivate motion actuation or if system-level features which allow the user to disable it are disrupted or disabled by your web app.