2.5.4 Motion Actuation

What this rule means

WCAG 2.5.4 requires that any functionality triggered by device motion (tilting, shaking, or moving the device) or user motion (gestures detected by a camera) must also be available through standard user interface components like buttons, links, or form controls. Users must also be able to disable the motion-based response to prevent accidental activation.

For example, if shaking a phone triggers an "undo" action, there must also be an on-screen undo button. If tilting a device scrolls content, standard scroll controls must also be available. The only exception is when the motion is essential to the function (e.g., a pedometer counting steps).

Why it matters

Users who have their devices mounted on wheelchairs cannot tilt or shake them. Users with tremors or involuntary movements may trigger motion-based actions accidentally. Users with limited mobility may not be able to perform the required physical motion at all.

Additionally, some users operate devices in fixed positions — on a desk stand, mounted in a car, or secured to an assistive device holder. Motion-based functionality would be completely inaccessible to these users without an interface-based alternative.

Related axe-core rules

There are no automated axe-core rules for this criterion. Detecting motion-based interactions requires manual code review and testing to identify uses of the DeviceMotion, DeviceOrientation, or camera-based gesture detection APIs.

How to test

1. Review the application for any features that respond to device motion (shake, tilt, rotate) or user motion (camera gestures).
2. For each motion-triggered feature, verify that an equivalent on-screen control exists.
3. Check that a setting or preference exists to disable motion-based responses.
4. Search the codebase for DeviceMotionEvent, DeviceOrientationEvent, and camera/gesture APIs.
5. Test by keeping the device stationary and verifying all functionality is still accessible through UI controls.

How to fix

Provide UI control alternatives for motion-based features and a way to disable motion detection.

Shake to undo — bad practice

// Only shake gesture triggers undo, no UI alternative
window.addEventListener('devicemotion', (e) => {
  const acc = e.accelerationIncludingGravity;
  if (Math.abs(acc.x) > 15 || Math.abs(acc.y) > 15) {
    undoLastAction();
  }
});

Shake to undo — good practice

// Motion detection with preference check
let motionEnabled = getUserPreference('motionEnabled', true);

if (motionEnabled) {
  window.addEventListener('devicemotion', (e) => {
    const acc = e.accelerationIncludingGravity;
    if (Math.abs(acc.x) > 15 || Math.abs(acc.y) > 15) {
      undoLastAction();
    }
  });
}

// UI alternative always available
undoButton.addEventListener('click', () => {
  undoLastAction();
});

Settings toggle for motion features

<fieldset>
  <legend>Motion preferences</legend>
  <label>
    <input type="checkbox" id="motion-toggle" checked>
    Enable shake-to-undo and tilt-to-scroll
  </label>
</fieldset>

<script>
  document.getElementById('motion-toggle')
    .addEventListener('change', (e) => {
      setUserPreference('motionEnabled', e.target.checked);
      if (!e.target.checked) {
        disableMotionListeners();
      } else {
        enableMotionListeners();
      }
    });
</script>

Common mistakes

• Implementing shake-to-undo as the only undo mechanism without an on-screen button.
• Using tilt-to-scroll for content navigation without standard scrollbars or pagination.
• Camera-based gesture controls (wave to dismiss, nod to confirm) without button alternatives.
• Not providing a way to disable motion detection, causing users with tremors to trigger actions accidentally.
• Forgetting that motion-based features are completely unusable for devices mounted in fixed positions.