WCAG 2.5.4 Motion Actuation says that any function you can trigger by moving the device (shaking or tilting) or by moving your body (a gesture a sensor reads) must also be operable with a normal control like a button — and the user must be able to turn the motion off so it never fires by accident. It is a Level A requirement.

What 2.5.4 actually requires

The official W3C wording is short and has two halves. Functionality 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” (Understanding SC 2.5.4, W3C/WAI). So you owe users two things, not one:

  1. An alternative control. Whatever the shake, tilt, or gesture does, a visible button, link, or form control must do the same thing.
  2. A way to switch motion off. Users must be able to disable motion response, either through an in-app setting or by honoring the operating system’s motion setting.

There are exactly two exceptions. Supported Interface: the motion drives an accessibility-supported interface itself — for example, head-tracking software that operates the whole device, where you should not interfere. Essential: the motion is the activity, so a button would invalidate it — a pedometer counting steps, or a bubble-level app measuring tilt. If you are not in one of those two buckets, both requirements apply.

Who it affects

This criterion is about physical movement, so it protects people who cannot reliably produce — or want to avoid — that movement:

  • People with tremors or limited motor control who can’t perform a controlled shake or precise tilt, and who may trigger motion sensors unintentionally. The W3C notes some users “accidentally activate sensors due to tremors or other motor impairments,” which is why the off-switch is mandatory.
  • People whose device is fixed in place — mounted to a wheelchair, an arm, or a desk. The phone physically cannot be shaken or tilted, so a motion-only feature is simply unreachable.
  • People using prosthetics, or holding the device in a fixed grip, who can tap a screen but not wave the whole device.
  • Anyone who has turned motion detection off at the system level and reasonably expects the app to respect that choice.

The assistive-technology angle matters too: a switch or head-pointer user operates the screen through their AT but cannot make the device shake. Without an on-screen control, that function does not exist for them.

Concrete failures and how to fix them

This is not an abstract rule. Here are the patterns that fail, and the fix for each.

Shake-to-undo with no button. A note-taking screen clears or undoes text when you shake the phone, and there is no on-screen Undo. A user with hand tremors triggers it by accident and cannot recover; a wheelchair-mounted user can’t trigger it at all. This is W3C failure F106 — “inability to deactivate motion actuation.” Fix: add a visible Undo/Cancel control and let the motion be switched off.

Tilt-to-pan map or photo viewer (web). A page uses the browser’s DeviceOrientation API so tilting the phone pans a 360° image. On a mounted device, nothing happens. Add real controls and gate the motion behind a toggle:

let motionEnabled = true; // user can flip this off in settings

// Buttons do the same job as tilting — required by 2.5.4
panLeftBtn.addEventListener('click', () => pan(-10, 0));
panRightBtn.addEventListener('click', () => pan(10, 0));

window.addEventListener('deviceorientation', (e) => {
  if (!motionEnabled) return;          // honor the off-switch
  if (prefersReducedMotion()) return;  // respect the OS setting
  pan(e.gamma, e.beta);
});

function prefersReducedMotion() {
  return window.matchMedia('(prefers-reduced-motion: reduce)').matches;
}

Gesture-only navigation. “Wave your hand to advance” read through the camera, with no Next button. Camera gesture input counts as user motion under 2.5.4. Fix: pair every gesture with a standard control (sufficient technique G213 — “provide conventional controls and an application setting for motion-activated input”).

Hijacking the system off-switch. Some apps re-enable motion even after the user disabled it at the OS level. That is a failure on its own — you must not disrupt the system feature that lets users turn motion off.

The common thread: never make motion the only path, and always leave a kill switch.

How to test for 2.5.4

You can audit this by hand in a few minutes per feature:

  1. Inventory the motion. List everything that responds to shaking, tilting, panning the device, or to camera/sensor-read gestures. On the web, grep your code for devicemotion, deviceorientation, DeviceMotionEvent, and Accelerometer.
  2. For each one, find the button. Can you complete the identical action with a visible on-screen control, using touch alone, without moving the device? If not — fail.
  3. Try to switch it off. Is there an in-app toggle, or does the feature respect the OS “reduce motion” / shake setting? If motion can’t be disabled — fail (that’s F106).
  4. Check for accidental triggers. Mount or rest the device and use it normally. Does anything fire that you didn’t intend?

Automated scanners almost never catch this — it needs hands-on testing of real device behavior, which is exactly the kind of thing a thorough accessibility audit covers and an automated overlay cannot.

Motion Actuation lives in the same family as keyboard access: the principle is that no function should depend on one physical method of input. That principle is now squarely in regulators’ sights for apps as well as sites.

In April 2024 the Department of Justice finalized its ADA Title II rule, which sets WCAG 2.1 Level AA as the technical standard for the websites and mobile apps of state and local governments — and 2.5.4 is part of that standard. Private-sector exposure is large too: industry trackers recorded over 4,000 ADA digital-accessibility lawsuits in 2024, the majority targeting the same companies’ web and app experiences (UsableNet 2024 report). Motion-only controls are most common in mobile apps, where shake, tilt, and gesture features proliferate — exactly the surface those rules and suits reach.

Because 2.5.4 is Level A — the floor below even AA — a failure here is among the more serious gaps an audit can surface; courts and the DOJ treat WCAG 2.1 AA as the practical benchmark, and AA includes every Level A criterion. This is general information, not legal advice; for your specific situation, consult a qualified attorney.

Get motion controls fixed properly

Curbcut is deliberately anti-overlay. A widget can’t add a button to a shake gesture or wire up a “disable motion” toggle — only changes in your actual code can do that. We add the missing controls, honor the OS motion setting, and document the result, by hand, for small-business sites and apps. Tell us where motion drives your interface and [EXPERT_NAME] on our team will map the exact fixes. Start with a free accessibility scan, or read how we approach remediation versus the overlay shortcuts that don’t hold up.