Input Modalities
Last modified on Fri 17 Mar 2023

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 <input type="range">.

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:

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:

Find out more examples, techniques, and failures for this Success Criterion

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 aria-label and aria-labelledby attributes.

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:

  1. If aria-label or aria-labelledby are present, they'll be used in accordance with the algorithm described in Accessible Name and Description. Computation
    1. In short, aria-labelledby is preferred by the algorithm.
    2. However, this is a very complex algorithm. Read through it and/or use the accessibility tree to validate your assumptions.
  2. If an associated label element is present, their accessible names will be used, as determined by the Accessible Name and Description Computation algorithm.
    1. If more than one label is associated with the element, the labels will be concatenated by DOM order, delimited by spaces.
  3. The element's title attribute will be used if present.
  4. The element's placeholder attribute will be used if present.
  5. 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:

You can fail this Success Criterion if:

To provide good labeling, we suggest the following:

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.

Find out more details about labels and this success criterion in Understanding WCAG

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:

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:

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.