Motion Actuation
Tier 1 · The normative floor
Baseline compliance
What the normative text of WCAG 2.2 requires, and nothing more. Only a failure of this tier is a WCAG failure.
The bare minimum
Functionality operated by device motion (such as shaking or tilting) or user motion can also be operated through interface components, and responding to motion can be turned off. Exceptions: the motion works through an accessibility-supported interface, or it's essential and doing it another way would invalidate the activity.
Normative text
Verbatim from WCAG 2.2, W3C Recommendation 12 December 2024. Underlined terms are defined below.
Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:
- Supported Interface
- The motion is used to operate functionality through an accessibility supported interface;
- Essential
- The motion is essential for the function and doing so would invalidate the activity.
Not required by the normative text
Common claims that this criterion does not support. Don't log these as WCAG failures.
- Avoiding motion-based features.
Definitions used (4)
Glossary definitions are normative. Their notes are informative.
- functionality
-
processes and outcomes achievable through user action
- user interface component
-
a part of the content that is perceived by users as a single control for a distinct function
Informative notes (3)
Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.
User interface components include form elements and links as well as components generated by scripts.
What is meant by "component" or "user interface component" here is also sometimes called "user interface element".
- accessibility supported
-
supported by users' assistive technologies as well as the accessibility features in browsers and other user agents
To qualify as an accessibility-supported use of a web content technology (or feature of a technology), both 1 and 2 must be satisfied for a web content technology (or feature):
The way that the web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,
AND
The web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:
-
The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);
OR
-
The technology is supported in a widely-distributed plug-in that is also accessibility supported;
OR
-
The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;
OR
-
The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
- does not cost a person with a disability any more than a person without a disability and
- is as easy to find and obtain for a person with a disability as it is for a person without disabilities.
-
Informative notes (5)
The Accessibility Guidelines Working Group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a web technology in order for it to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)
Web technologies can be used in ways that are not accessibility supported as long as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4 and Conformance Requirement 5.
When a web technology is used in a way that is "accessibility supported," it does not imply that the entire technology or all uses of the technology are supported. Most technologies, including HTML, lack support for at least one feature or use. Pages conform to WCAG only if the uses of the technology that are accessibility supported can be relied upon to meet WCAG requirements.
When citing web content technologies that have multiple versions, the version(s) supported should be specified.
One way for authors to locate uses of a technology that are accessibility supported would be to consult compilations of uses that are documented to be accessibility supported. (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported ways of using web content technologies. However, all ways of using technologies in the documentation would need to meet the definition of accessibility-supported Web content technologies above.
- essential
-
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
Tier 2 · The gap
Usability & user impact
Where content can meet this criterion and still make things harder for people with disabilities. These are not failures of SC 2.5.4, so raise them as usability defects. Known failures, including failures of related criteria, are listed in Tier 1.
A motion setting that is off only once the user finds it means people with tremors may trigger actions by accident on first use.
Tier 3 · The golden path
Recommended best practice
The pattern that meets the floor, closes the gap, and avoids audit disputes. A recommendation, not a requirement.
Keep motion features opt-in, with an on-screen control as the primary way to do the same thing.
W3C's Understanding document and techniques for SC 2.5.4 ↗ are informative: sufficient techniques show ways to pass, and documented failures show common ways to fail, but neither changes what the criterion requires.
How SC 2.5.4 maps to the WCAG 3 draft
From this site's reviewed map to the WCAG 3 editor's draft. It's an interpretation: W3C has not published a mapping.
Successor provisions
From WCAG 2.2, section 5.1: “The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.”