Some web content allows users to trigger actions by moving a device (such as tilting or shaking) or by gesturing toward it (for example, using a camera). These interactions can prevent users from operating content if they cannot move the device reliably or if motion triggers actions unintentionally.
WCAG 2.5.4 ensures that motion-based interaction is optional, not required.
WCAG Success Criterion
2.5.4 Motion Actuation (Level A)
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:
- The motion is used through an accessibility-supported interface, or
- The motion is essential to the function, and removing it would invalidate the activity.
Success Criterion Simplified
If your app does something when the user moves their device or body:
- You must also provide a normal, visible on-screen control that does the same thing
- Users must be able to turn off motion-based activation
- Motion must never be the only way to trigger functionality unless it is essential
If motion triggers an action and there is no visible, operable control that performs the same action, the content fails WCAG 2.5.4.
Intent of the Success Criterion
This criterion intends to ensure that users are not required to perform physical motions to operate content.
Some users:
- Cannot move a device because it is mounted or fixed
- Have motor impairments that make motion imprecise or tiring
- Experience tremors that cause accidental activation
- Use assistive technologies that do not support motion input
These users must still be able to operate all functionality.
What Counts as Motion Actuation
Motion actuation includes functionality triggered by:
- Shaking or tilting a device
- Rotating a device to change state or navigate
- Moving a device to pan or scroll content
- Gesturing toward a camera or sensor to trigger actions
If content responds directly to sensor input (accelerometer, gyroscope, camera-based gesture detection), it falls under this success criterion.
Two Separate Requirements (Commonly Confused)
1. Provide an Alternative Control
If motion triggers an action, there must be a visible user interface control that performs the same action.
Examples:
- Buttons
- Links
- Menu items
- Toggles
Keyboard support alone does not satisfy this requirement.
The alternative must work with assistive technologies such as screen readers, switch devices, and voice control.
2. Allow Motion to Be Disabled
Users must be able to disable motion-based activation to prevent accidental triggering.
This can be done by:
- Providing an in-app setting, or
- Respecting operating system–level motion settings only if those settings reliably disable the author’s motion handling
Respecting OS-level settings satisfies WCAG 2.5.4 only if motion input in the web content actually stops responding when the setting is enabled. Many web apps ignore these settings. In those cases, the requirement is not met.
Accessibility-Supported Interface Exception
The success criterion allows an exception when motion is used through an accessibility-supported interface.
This means:
- The input method itself is designed to work with assistive technologies
- It is reliable, documented, and interoperable
In practice, motion-based input via assistive technology is rare.
This exception is narrow and should not be relied on for general interaction design.
Essential Motion Exception
Motion is allowed when it is essential to the activity.
Examples:
- A pedometer that counts steps
- Applications where motion data is the purpose
If removing motion would invalidate the activity, the exception applies.
Common Failures of SC 2.5.4
“Shake to refresh” with no button
Fails because motion is the only way to trigger the action.
Tilt-to-steer game with no on-screen controls
Fails because users cannot operate the game without motion.
Camera-based gesture navigation with no fallback
Fails because there is no conventional UI alternative.
Alternative hidden only in settings
Fails because the primary interaction still depends on motion.
Common Developer Mistakes
- Relying on keyboard shortcuts instead of visible controls
- Assuming “Reduce Motion” OS settings automatically satisfy WCAG
- Providing an alternative control that is not discoverable
- Treating motion as an enhancement but implementing it as a requirement
Examples That Pass
- Tilting a device changes pages, and visible Previous/Next buttons do the same.
- Shaking a device opens an Undo dialog, and a visible Undo button is also available.
- Moving a device pans an image, and on-screen controls allow panning.
- Users can turn off all motion-based actions via a settings toggle.
Developer Checklist
- Is there a visible control that performs the same action as motion?
- Can users disable motion-based activation?
- Does the alternative work with screen readers and switch devices?
- Does disabling motion reliably stop sensor-based input?
- Is motion required only when it is truly essential?
Benefits
This success criterion benefits:
- Users who cannot move or tilt devices
- Users with tremors or limited motor control
- Users whose devices are mounted or fixed
- Users who experience accidental motion activation
Wrapping Up
WCAG 2.5.4 is not about banning motion-based interaction. It is about ensuring that motion is optional.
Content passes this criterion only when:
- Motion is not the sole means of operation, and
- Users can disable motion-based activation
When these conditions are met, motion can enhance interaction without excluding users.
