2.5.4 Motion Actuation

WCAG 2.2 · 2.5.4 A Operable

What it requires

When a function can be triggered by moving the device (tilting, shaking) or by gesturing at a sensor (waving a hand), two things must hold. First, the same function must also be operable through ordinary user-interface components — a button, link, or control you can tap or click. Second, the user must be able to turn the motion response off so accidental movement does not fire it.

Two exceptions apply: motion used through an accessibility-supported interface (for example a switch device driving the platform), and motion that is essential to the function and would invalidate it if removed — such as a pedometer or a shake-to-undo whose whole point is the movement.

  • People with motor impairments or tremors who cannot hold a device steady, or who mount the device and cannot tilt or shake it deliberately.
  • People who cannot perform a precise gesture in front of a sensor.
  • People who keep a device fixed to a wheelchair, stand, or surface.
  • Anyone who triggers motion features by accident and needs a way to disable them.

How to detect it

Concrete checks for Motion Actuation
Check How
Find motion features Manually inventory anything driven by tilt, shake, or a proximity/camera gesture (e.g. shake-to-undo, tilt-to-scroll, wave-to-dismiss).
Conventional alternative Confirm each such function also works via a visible button or control — reachable by keyboard and pointer.
Can be disabled Look for a setting or in-app control that stops motion from triggering the function. Verify it actually suppresses the response.
Keyboard / SR Operate the alternative control with keyboard only and a screen reader; it must be perceivable and actionable, not motion-only.
Automated tools Largely undetectable by axe and similar scanners — motion sensing is not visible in the DOM. Treat this as a manual check.

How to fix it

  1. List every function reachable through device motion or a motion gesture.
  2. Provide an equivalent, conventionally operable control (button or link) for each.
  3. Offer a setting to disable motion actuation so accidental movement is ignored.
  4. Respect platform motion/accessibility settings rather than overriding them.
  5. Keep the motion path only where it is essential to the function.

Pair a shake-to-undo gesture with a real button so motion is never the only way:

<!-- Conventional control alongside the motion gesture -->
<button type="button" onclick="undoLastAction()">Undo</button>

<!-- Let users switch the shake gesture off -->
<label>
  <input type="checkbox" id="shake-undo" checked> Shake to undo
</label>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule for 2.5.4. Whether a feature is triggered by device motion — and whether an accessible alternative and a disable option exist — cannot be detected by a scanner, so this criterion needs manual review using the console check and steps below.

Run this in the browser console

console — motion-actuation-suspects.js
// Read-only: surfaces code likely listening for device motion/orientation.
const re = /devicemotion|deviceorientation|DeviceMotionEvent|DeviceOrientationEvent|requestPermission|accelerationIncludingGravity|\.gamma|\.beta|\.alpha/;
const hits = [...document.scripts]
  .filter(s => s.textContent && re.test(s.textContent))
  .map(s => ({ src: s.src || '(inline)', sample: s.textContent.match(re)[0] }));
console.table(hits);
console.log('Inline/script motion listeners found:', hits.length);

What to check manually: confirm any motion-triggered action (shake, tilt) also has a conventional UI control that does the same thing, and that a setting exists to disable motion response. No script can verify the alternative actually works or that disabling it sticks.