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:

• provide controls to achieve the same result as path-based or multipoint gestures

An example of this technique in the carousel mentioned earlier would be adding "previous" and "next" navigation buttons.

• provide single point activation for a control slider

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:

• 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 click or mouseup that trigger only when the pointer is released

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:

• 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-label where necessary and including the <label> content in the aria-label
• providing a title for <button> elements or an aria-describedby attribute
• providing a <legend> element for <fieldset>, with its first child describing the fieldset or providing an aria-label for the <fieldset>
• providing alt text for images
• providing <figcaption> for <figure> elements
• providing an aria-label for <iframe> elements

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:

• 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.