Motion Actuation

What it asks

If a feature is triggered by physically moving the device (shake-to-undo, tilt-to-scroll) or by moving the user’s body in front of a sensor (wave to skip), the same feature must also be operable through normal on-screen controls — buttons, menus, gestures on the screen itself. And the user must be able to turn the motion trigger off, so they don’t fire it by accident.

Exempt: when the motion is essential to the function (a pedometer, a level/tilt measurement app) or when motion is used through a supported accessibility-enabling interface that the user has explicitly opted into.

How to meet it

• Shake-to-undo on mobile: provide an Undo button in the UI as well.
• Tilt-to-pan in maps or games: pair with on-screen pan controls.
• Step counters and motion-based games: that’s essential motion, exempt — but still offer a settings toggle.
• For any feature that listens to device-orientation or motion events, add a per-feature toggle in settings, and respect the OS-level motion-reduction preference where it applies.
• Avoid making motion the only way to dismiss a notification or undo a destructive action.

Common failures

• “Shake your phone to report a bug” with no in-app feedback link.
• Photo carousel that pans on device tilt with no swipe or arrow alternative.
• Camera-based “wave to skip” gestures in video players with no on-screen skip button.
• Motion-triggered actions that cannot be disabled and fire constantly for wheelchair users, users on a bus, or anyone with involuntary movement.

Why it matters

Motion actuation excludes users who cannot move their device in the required way: people who mount their phone to a wheelchair, users with tremor that triggers motion sensors at random, users with limited range of motion, and amputees. The on/off requirement protects users whose body or device produces motion the system reads as input — a wheelchair-mounted phone on a textured pavement fires shake events all day.