Skip to main content
Accessibility.com, LLC
Category: Input and Navigation

Input Modalities

Also known as: WCAG Guideline 2.5, Guideline 2.5 Input Modalities
Simply put

Input Modalities is the name of a Web Content Accessibility Guidelines (WCAG) guideline focused on making it easier for people to operate content using inputs beyond a standard keyboard, such as touch, pointer, voice, or other assistive technologies. In practical terms, it means not forcing users to rely on complex gestures or a single specific device to interact with your content. This helps people who use alternative input methods, such as voice control or switch devices, complete the same tasks as anyone else.

Formal definition

Input Modalities is WCAG Guideline 2.5, part of the Operable principle, which aims to make functionality operable through a variety of inputs beyond the keyboard, including pointer, touch, and voice inputs. In human-computer interaction, a modality refers to an independent channel of input or output between a computer and a human; the guideline addresses concerns such as complex path-based or multipoint gestures, pointer cancellation, accessible names matching visible labels, motion-actuated functionality, and target size. The specific success criteria under Guideline 2.5 span multiple conformance levels: some are Level A and Level AA, while others, such as 2.5.5 Target Size and 2.5.6 Concurrent Input Mechanisms, are Level AAA. Practitioners should note that criteria and their versions differ across WCAG 2.1 and 2.2 (for example, 2.2 introduced additional target-size and related requirements), so the applicable criteria and levels should be confirmed against the targeted WCAG version. Conformance with these criteria supports, but does not by itself guarantee, an accessible experience for all users, and manual and assistive-technology testing (for example with voice control, which cannot perform certain gestures) remains necessary. This entry is informational and not legal advice.

Why it matters

Many people cannot operate content using a standard keyboard or a single pointing device. Users of voice control, switch devices, or other assistive technologies may rely on input channels that cannot reproduce complex interactions. As noted in the guidance, voice control cannot perform certain gestures, so functionality that depends on multipoint or path-based gestures, such as swiping, pinching, split taps, or long presses, can effectively lock these users out of tasks that others complete easily. Guideline 2.5, Input Modalities, addresses this by encouraging designs that do not force users to rely on complex gestures or a single specific device.

Who it's relevant to

UX and interaction designers
Designers make the day-to-day decisions that determine whether functionality depends on complex gestures or a single input device. Providing simple pointer or single-tap alternatives to path-based and multipoint gestures, and considering target size, helps ensure tasks remain operable across touch, pointer, and voice inputs.
Front-end developers and engineers
Developers implement the behaviors covered by Guideline 2.5, including pointer cancellation, ensuring accessible names match visible labels, and handling motion-actuated functionality. Because criteria and their conformance levels differ between WCAG 2.1 and 2.2, developers should confirm which version and criteria apply to their project.
Accessibility and QA testers
Testers verify that content works with alternative input methods. Because assistive technologies such as voice control cannot perform certain gestures, manual and assistive-technology testing is required beyond automated checks to confirm that all forms of input are possible.
Product managers and compliance leads
Those responsible for accessibility targets should understand that Guideline 2.5 includes criteria at Levels A, AA, and AAA, and that AA is most commonly cited as a target. Conformance supports accessibility but does not by itself guarantee an accessible experience or legal compliance; this entry is informational and not legal advice.

Inside Input Modalities

Input Modalities (WCAG Guideline 2.5)
A guideline under the Operable principle of WCAG (introduced in WCAG 2.1) intended to make it easier for users to operate functionality through various inputs beyond a keyboard, including touch, pointer, speech, and other assistive input methods.
Pointer Gestures (2.5.1, Level A)
A success criterion added in WCAG 2.1 requiring that functionality operated by multipoint or path-based gestures can also be operated with a single pointer without a path-based gesture, unless such a gesture is essential.
Pointer Cancellation (2.5.2, Level A)
A WCAG 2.1 success criterion providing that, for functionality operated using a single pointer, activation can be aborted or undone (for example, by using the up-event rather than the down-event), unless completing on the down-event is essential.
Label in Name (2.5.3, Level A)
A WCAG 2.1 success criterion requiring that the accessible name of a component containing visible text label includes that visible text, supporting users who operate the interface by voice.
Motion Actuation (2.5.4, Level A)
A WCAG 2.1 success criterion requiring that functionality triggered by device motion or user motion can also be operated through user interface components, and that responding to motion can be disabled, unless motion is essential.
Target Size (Level AAA / Enhanced considerations)
Target Size (Enhanced) is 2.5.5 at Level AAA in WCAG 2.1, addressing minimum sizes for pointer targets. WCAG 2.2 later introduced a separate Target Size (Minimum) criterion at Level AA, reflecting evolution across versions.
Concurrent Input Mechanisms (2.5.6, Level AAA)
A WCAG 2.1 Level AAA success criterion providing that content does not restrict use of input modalities available on a platform, so users can switch freely between input methods such as keyboard, touch, and pointer.
Conformance levels across the guideline
The success criteria under Guideline 2.5 span Levels A, AA, and AAA depending on the specific criterion and WCAG version; practitioners should confirm the level and version applicable to each criterion rather than assuming a single level applies.

Common questions

Answers to the questions practitioners most commonly ask about Input Modalities.

Does supporting keyboard input alone satisfy the WCAG success criteria related to input modalities?
No. Keyboard operability is addressed primarily under Guideline 2.1, while the input modalities success criteria under Guideline 2.5 address concerns such as pointer gestures, pointer cancellation, motion actuation, target size, and concurrent input mechanisms. Supporting one input method does not by itself satisfy the criteria that address others. Designs generally should not assume a single input method, since users may rely on touch, mouse, stylus, voice, switch devices, or other assistive technologies. Meeting these criteria also does not guarantee an accessible experience overall; manual and assistive technology testing remain necessary.
Are all of Guideline 2.5's success criteria at Level A or AA?
No. The success criteria under Guideline 2.5 span multiple conformance levels. Some fall at Level A and some at Level AA, but Target Size (2.5.5) and Concurrent Input Mechanisms (2.5.6) are Level AAA in WCAG 2.1. WCAG 2.2 later introduced Target Size (Minimum) (2.5.8) at Level AA, which is distinct from the AAA Target Size criterion. Readers should confirm the specific criterion, version, and level rather than assuming a uniform level across the guideline.
How can a design accommodate users who cannot perform complex pointer gestures?
The Pointer Gestures success criterion generally calls for functionality operable with multipoint or path-based gestures to also be operable with a single pointer, unless the gesture is essential. In practice, this often means providing a simple tap or click alternative to actions such as pinch, swipe, or drag. Confirm the exact requirement against the applicable WCAG version and level, and validate with users of different input methods.
What is the difference between the Target Size criteria in WCAG 2.1 and WCAG 2.2?
WCAG 2.1 includes Target Size (2.5.5) at Level AAA. WCAG 2.2 adds a separate Target Size (Minimum) criterion (2.5.8) at Level AA, which is often the more commonly cited target because AA is the level most frequently referenced. These are distinct criteria with different thresholds and conformance levels, so implementation teams should identify which version and criterion apply to their goals.
How should motion-activated features be handled for accessibility?
The Motion Actuation success criterion generally addresses functionality triggered by device motion or user motion, such as shaking or tilting. It commonly calls for such functionality to also be operable through conventional user interface components and for the motion trigger to be able to be disabled, with limited exceptions where motion is essential. This helps users who cannot perform the motion or who may trigger it inadvertently. Verify the precise wording and applicable level for your target WCAG version.
What testing is needed to confirm that input modality requirements are met?
Automated tools detect only a portion of potential issues and are limited in evaluating gesture alternatives, pointer cancellation, and target sizing in real interaction contexts. Manual testing across multiple input methods, including touch, mouse, keyboard, and assistive technologies such as switch devices and voice control, is generally required to assess whether the input modalities criteria are met in practice. This guidance is not legal advice; for compliance determinations, consult qualified legal counsel and current agency rulemaking.

Common misconceptions

All Input Modalities success criteria are Level A or AA, so meeting a common AA target automatically covers this guideline.
The criteria under Guideline 2.5 span multiple levels. Several are Level A (such as Pointer Gestures, Pointer Cancellation, Label in Name, and Motion Actuation), while others are Level AAA (such as Target Size (Enhanced) 2.5.5 and Concurrent Input Mechanisms 2.5.6 in WCAG 2.1). A specific criterion's level and originating version should be verified individually.
Input Modalities is only about keyboard accessibility.
Guideline 2.5 was introduced in WCAG 2.1 to address inputs beyond the keyboard, including touch, pointer, speech, and device or user motion. Keyboard operability is addressed primarily under a separate guideline.
Passing automated checks for these criteria means the interface is fully accessible for all input methods and legally compliant.
Automated testing detects only a portion of potential issues. Criteria such as pointer gestures, pointer cancellation, and motion actuation generally require manual and assistive technology testing. Conformance also does not by itself guarantee an accessible experience for all users or immunity from legal claims; consult qualified legal counsel for compliance questions.

Best practices

Verify the conformance level and WCAG version for each Input Modalities criterion individually, recognizing that they span Levels A, AA, and AAA rather than assuming a single level.
Provide single-pointer alternatives to multipoint or path-based gestures so functionality is operable without complex gestures, unless the gesture is essential.
Design activation so users can cancel or reverse pointer actions, favoring up-event completion over down-event completion where feasible.
Ensure that a component's accessible name includes its visible text label to support voice-controlled operation.
Offer user interface controls as alternatives to motion-based actuation and allow motion response to be disabled, unless motion is essential.
Include manual and assistive technology testing across touch, pointer, speech, and motion inputs, since automated tools capture only some Input Modalities issues, and treat this guidance as general information rather than legal advice.