Skip to main content
Accessibility.com, LLC
Category: Mobile Accessibility

Motion Actuation

Also known as: WCAG Success Criterion 2.5.4, SC 2.5.4
Simply put

Motion Actuation refers to content that responds to physical movement, such as tilting or shaking a device, or gestures made toward a camera, as a way of triggering a function. This accessibility guideline generally asks that any function operated by such motion also be available through standard interface controls, like buttons, and that users be able to turn off motion-based operation. This helps people who cannot perform the required movements or who may trigger the motion accidentally.

Formal definition

Motion Actuation is WCAG 2.1 Success Criterion 2.5.4, a Level A criterion added in WCAG 2.1. It applies to functionality that can be operated by device motion (for example, tilting or shaking) or by user motion (for example, eye, face, or hand gestures interpreted by a camera). The criterion generally requires that such functionality also be operable through conventional user interface components and that the response to motion can be disabled to prevent accidental actuation, subject to the exceptions defined in the criterion. As a WCAG guideline published by the W3C Web Accessibility Initiative, it is a technical standard; whether and how it applies as a legal obligation depends on the applicable authority (such as Section 508, ADA Title II, or Title III) and evolving regulation and case law. This entry is not legal advice; consult qualified counsel for jurisdiction-specific requirements.

Why it matters

Motion Actuation matters because interfaces that rely on physical movement can exclude people who are unable to perform the required gestures. A user with a mobility impairment, tremor, or limited dexterity may not be able to tilt or shake a device reliably, and someone using a mounted device, a wheelchair, or an assistive setup may not be able to move the device at all. When shaking, tilting, or gesturing toward a camera is the only way to reach a function, those users are effectively locked out of that function.

The criterion also addresses accidental activation. Motion-based triggers can fire when a device is jostled during normal use, when a person has involuntary movements, or when someone simply picks up or carries the device. By generally requiring that motion actuation can be disabled and that conventional controls exist as an alternative, WCAG Success Criterion 2.5.4 reduces the risk that users trigger actions they did not intend and gives them a predictable, standard path to the same functionality.

As a Level A criterion added in WCAG 2.1, Motion Actuation is among the more foundational accessibility expectations. Meeting it, however, is one technical standard among many; conformance does not by itself guarantee an accessible experience across all users or contexts, and whether it applies as a legal obligation depends on the governing authority and current regulation and case law. This entry is not legal advice; consult qualified counsel for jurisdiction-specific requirements.

Who it's relevant to

UX and interaction designers
Designers who incorporate shake, tilt, or camera-based gestures should pair each motion-triggered function with a standard control and provide a way to turn motion operation off. Planning for these alternatives early avoids interfaces where movement is the only path to a feature.
Front-end developers and engineers
Developers implementing device motion APIs or gesture detection are responsible for exposing equivalent functionality through conventional UI components and for building a setting to disable motion response. They should also account for the criterion's defined exceptions when motion is essential.
Accessibility and QA testers
Testers should verify that motion-based functions have a working conventional alternative and that motion actuation can be disabled. Because automated tools detect only a portion of accessibility issues, manual testing and evaluation with assistive technology are needed to confirm this criterion is met in practice.
Compliance officers and legal counsel
Those assessing conformance should recognize Motion Actuation as a WCAG 2.1 Level A criterion and treat it as a technical benchmark rather than a codified legal rule. Whether and how it applies as an obligation depends on the governing authority, such as Section 508, ADA Title II, or Title III, and on evolving regulation and case law; consult qualified counsel for jurisdiction-specific requirements.

Inside Motion Actuation

Motion-Triggered Functionality
Refers to features that can be operated by device motion (such as shaking or tilting a device) or by user motion (such as a gesture captured by a sensor). Motion Actuation addresses ensuring these functions are not the only way to perform an operation.
WCAG Success Criterion 2.5.4 (Motion Actuation)
The success criterion commonly associated with this concept. It was added in WCAG 2.1 and is set at Level A. It generally requires that functionality operated by device or user motion can also be operated through conventional user interface components, and that responding to motion can be disabled.
Alternative Input Method
A conventional interface control, such as an on-screen button, that provides the same function otherwise triggered by motion, so users who cannot perform the motion or who may trigger it inadvertently can still complete the task.
Ability to Disable Motion Response
A setting or control that lets users turn off motion-based operation to prevent accidental actuation, which is a core part of the criterion's intent.
Exceptions
The criterion generally allows exceptions where the motion is used through an accessibility-supported interface, or where the motion is essential to the function and using it would invalidate the activity.

Common questions

Answers to the questions practitioners most commonly ask about Motion Actuation.

Does the Motion Actuation success criterion prohibit all use of motion-based controls in an interface?
No. The criterion, WCAG 2.1 Success Criterion 2.5.4 (Level A), does not ban motion-based controls such as shaking, tilting, or gesturing a device. It requires that functions triggered by device motion or user motion can also be operated through conventional user interface components, and that users be able to disable the motion response to prevent accidental actuation. Motion may remain available as an optional or supplementary method.
Is Motion Actuation only relevant to mobile apps and not to websites or other content?
Motion Actuation applies to any content covered by WCAG that responds to device motion (such as sensor input from an accelerometer or gyroscope) or to user motion detected by a sensor. While these capabilities are commonly encountered on mobile devices, the criterion is written to apply wherever such motion-triggered functionality exists, not exclusively to native mobile apps. There are exceptions where the motion is essential to the function or is used through an accessibility-supported interface.
How can a function that is triggered by motion still meet this criterion?
Provide a conventional, non-motion alternative for the same function, such as an on-screen button or standard control that performs the identical action. This generally allows users who cannot perform the required motion, or who may trigger it unintentionally, to complete the task through an equivalent method.
What does it mean to allow users to disable the motion response?
It means offering a setting or control that turns off the motion-triggered behavior so accidental device or user movement does not activate a function. This is particularly relevant for users with tremors or limited motor control who may move a device involuntarily. The disable option and the alternative control work together to support the criterion.
Are there situations where motion actuation without an alternative is acceptable under this criterion?
The criterion includes exceptions. Where the motion is used to operate functionality through an accessibility-supported interface, or where the motion is essential to the function such that supporting it another way would invalidate the activity, the requirement may not apply. Determining whether an exception applies requires evaluating the specific function against the criterion's stated conditions.
Does meeting Motion Actuation guarantee the interface is accessible or legally compliant?
No. Conformance with a single success criterion addresses only one aspect of accessibility. Meeting WCAG criteria generally supports broader accessibility goals but does not guarantee an accessible experience for all users or immunity from legal claims. Automated tools detect only a portion of issues, so manual review and testing with assistive technology are commonly needed. For questions about legal obligations, consult qualified legal counsel; this entry is not legal advice.

Common misconceptions

Motion Actuation only concerns physically moving the whole device, like shaking a phone.
It covers both device motion (such as tilting or shaking) and user motion detected by sensors, such as gestures. The common concern is that any such motion-triggered function should have an alternative and be able to be disabled.
Because it is a lower-numbered mobile-oriented criterion, Motion Actuation is only a AAA or optional enhancement.
The criterion commonly associated with Motion Actuation (2.5.4) was introduced in WCAG 2.1 and is at Level A, which is the most foundational conformance level rather than an optional one.
Meeting this criterion guarantees the motion-based feature is fully accessible and legally safe.
Satisfying a WCAG success criterion does not by itself guarantee an accessible experience for all users or immunity from legal claims. Manual and assistive technology testing are needed, and this guidance is not legal advice.

Best practices

Provide a conventional user interface control, such as an on-screen button, for any function that can be triggered by device or user motion.
Offer a setting that lets users disable response to motion so that features are not activated inadvertently.
Reserve motion-only operation for cases where the motion is genuinely essential to the function, and document the justification.
Test with users and assistive technologies, since automated checks detect only a portion of issues related to motion-triggered functionality.
Consider users with tremors, limited mobility, or those who may drop or knock a device, all of whom may trigger motion actions unintentionally.
Treat conformance with the associated success criterion as a baseline rather than a guarantee of accessibility or legal compliance, and consult qualified legal counsel for jurisdiction-specific obligations.