WCAG 2.5.4: Motion Actuation

Who this helps

Motion controls create two mirror-image barriers: people who cannot produce the required motion, and people who cannot avoid producing it.

The design pattern that satisfies everyone is the same one that works for 2.5.1 Pointer Gestures: build the feature on ordinary buttons first, then layer motion on top as an optional, user-controllable enhancement.

What counts as motion actuation

The criterion covers functionality your content operates in response to:

• →Device motion — shaking, tilting, or rotating the device, read from the accelerometer or gyroscope. On the web this arrives through the devicemotion and deviceorientation events and the Generic Sensor API.
• →User motion sensed by the device — gestures detected by a camera or other sensor, such as waving a hand to advance slides or nodding to confirm.

Out of scope: pointer movement across the screen (covered by 2.5.1 and 2.5.7), keyboard and switch input, and motion your content merely reacts to visually without operating functionality — although gratuitous motion-driven animation raises its own issues under 2.3.3 Animation from Interactions (Level AAA).

The two exceptions are narrow. Supported Interface covers motion used as an assistive input method — a user whose AT converts head movement into clicks. That is their input device, not your feature. Essential covers functions that are motion by definition — a pedometer counting steps — where a button alternative would falsify the activity itself.

Pass and fail examples

Code examples

Shake-to-undo done right

The motion listener drives the same function as a visible button, and a user preference gates the listener entirely.

<!-- ✓ The function is always available as a plain control -->
<button type="button" id="undo">Undo</button>

<label>
  <input type="checkbox" id="motion-toggle" />
  Enable shake to undo
</label>

<script>
  document.getElementById("undo").addEventListener("click", undoLastAction);

  const motionToggle = document.getElementById("motion-toggle");

  function onShake(event) {
    // ✓ Motion response is gated behind the user's opt-in setting
    if (!motionToggle.checked) return;
    const a = event.accelerationIncludingGravity;
    if (Math.abs(a.x) > 25 || Math.abs(a.y) > 25) undoLastAction();
  }

  window.addEventListener("devicemotion", onShake);
</script>

A motion-controls preference in React

Attach the sensor listener only while the preference is on. Removing the listener is the cleanest form of “disabled” — accidental motion can no longer actuate anything.

function useShake(onShake, enabled) {
  useEffect(() => {
    if (!enabled) return // ✓ motion fully off when disabled

    function handle(e) {
      const a = e.accelerationIncludingGravity
      if (a && (Math.abs(a.x) > 25 || Math.abs(a.y) > 25)) onShake()
    }
    window.addEventListener("devicemotion", handle)
    return () => window.removeEventListener("devicemotion", handle)
  }, [enabled, onShake])
}

function Editor() {
  const [motionEnabled, setMotionEnabled] = useState(false) // opt-in
  useShake(undoLastAction, motionEnabled)

  return (
    <>
      <button type="button" onClick={undoLastAction}>Undo</button>
      <label>
        <input
          type="checkbox"
          checked={motionEnabled}
          onChange={(e) => setMotionEnabled(e.target.checked)}
        />
        Enable shake to undo
      </label>
    </>
  )
}

Tilt-driven 360° viewer with button fallback

<!-- ✓ Rotation works by buttons; tilt is an optional extra -->
<div role="group" aria-label="Rotate product view">
  <button type="button" onclick="rotateView(-15)">Rotate left</button>
  <button type="button" onclick="rotateView(15)">Rotate right</button>
  <button type="button" id="tilt-toggle" aria-pressed="false"
          onclick="toggleTilt(this)">
    Tilt to rotate: off
  </button>
</div>

<script>
  function toggleTilt(btn) {
    const on = btn.getAttribute("aria-pressed") !== "true";
    btn.setAttribute("aria-pressed", String(on));
    btn.textContent = on ? "Tilt to rotate: on" : "Tilt to rotate: off";
    if (on) {
      window.addEventListener("deviceorientation", tiltHandler);
    } else {
      window.removeEventListener("deviceorientation", tiltHandler);
    }
  }
</script>

Common failures

• ✗Shake, tilt, or rotate as the only way to trigger a function — undo, shuffle, refresh, easter eggs that reveal real functionality.
• ✗Providing a button alternative but no way to disable the motion response, leaving tremor-prone users exposed to constant accidental triggers.
• ✗Providing a disable toggle but no UI alternative — turning motion off then removes the feature entirely for that user.
• ✗Camera-gesture controls (wave to advance, nod to confirm) with no on-screen equivalent controls.
• ✗Tilt-based panning of maps, panoramas, or 360° images with no drag or button-based panning.
• ✗Burying the motion toggle where users who need it cannot find it, or resetting it on every visit.
• ✗Claiming the essential exception for features where motion is a stylistic choice (tilt steering in a game, shake to submit feedback) rather than the thing being measured.

How to test for 2.5.4

1. 1

   Find every motion listener in the code

   Search for devicemotion, deviceorientation, deviceorientationabsolute, the Generic Sensor API (Accelerometer, Gyroscope), and camera/gesture-recognition libraries. Each hit marks functionality that responds to motion.

2. 2

   Trigger each motion feature on a real device

   Shake, tilt, and wave as the feature intends, and note exactly what each motion does. Browser DevTools sensor emulation (Chrome DevTools > Sensors) can simulate orientation if hardware is inconvenient.

3. 3

   Achieve every motion outcome without moving the device

   For each function found, perform it using only on-screen controls: an Undo button, rotate buttons, next-slide buttons. If any outcome is reachable only by motion, it fails (unless a documented exception applies).

4. 4

   Disable motion and confirm silence

   Find the setting that turns motion response off (yours or a respected system setting). Enable it, then shake and tilt vigorously: nothing should actuate. If no such setting exists, the criterion fails even with perfect button alternatives.

5. 5

   Review claimed exceptions

   For anything left, verify the motion is genuinely essential (the motion is what is being measured) or arrives via the user's own accessibility-supported input method. Convenience, delight, and branding do not qualify.

Motion features are rare enough that this test is quick — but invisible to automated scanners, so it must be on your manual pass. The full WCAG 2.2 checklist keeps it alongside the other input-modality checks.

Frequently asked questions