WCAG 2.5.4 Motion Actuation: Making Motion-Based Controls Accessible

WCAG 2.5.4 Motion Actuation requires that functions triggered by device motion must have an accessible alternative. This article explains what the success criterion means, when it applies, and how to implement and test motion-based controls so people who cannot or prefer not to move a device can use your site or app.

What WCAG 2.5.4 Motion Actuation means

The success criterion covers user interface actions that start or stop because the user moves, tilts, or shakes a device. If a function is performed by device motion alone, an equivalent, accessible method must be provided. The goal is to ensure the same task can be completed without motion.

When this applies

• Controls or features that activate on tilt, shake, rotation, or similar sensor input
• Games or utilities that use motion to trigger actions
• Auto-advance or navigation that relies on motion input

Why it matters

Motion-based activation can block access for people with limited mobility, vestibular disorders, or those using assistive technologies like switch control. It also causes accidental triggers when a device moves in a pocket or bag. Providing alternatives reduces exclusion and prevents unexpected behaviour.

Core requirements (plain list)

• Do not rely on motion as the only way to perform an action.
• Provide an equivalent non-motion control that is perceivable and operable.
• Make motion activation opt-in when possible and clearly labelled.
• Ensure alternative controls work with keyboard, pointer, touch, and assistive tech.

How to implement motion alternatives

1. Provide a visible, operable alternative

Create a standard control that performs the same action. Examples include a button, toggle, or menu item. The control must be reachable by keyboard and visible to screen readers using accessible names and roles.

2. Make motion optional and discoverable

If motion improves experience, make it opt-in. Use a labelled toggle or setting called something like “Enable motion controls”. Keep motion off by default unless motion is essential and an equivalent exists.

3. Avoid instant effects on motion

Do not trigger irreversible actions on a single motion event. Require confirmation or provide a clear undo. This prevents accidental activation from pocket movement or brief tilts.

4. Use clear feedback and state

When motion is enabled, show state and instructions. Announce changes via ARIA, for example using aria-pressed or aria-checked on toggles, and update visible text so all users know what will happen.

5. Ensure semantic markup and ARIA where needed

Use native controls where possible. If you build a custom control, apply role attributes and keyboard handlers. For example ensure Enter and Space activate the control and focus order is logical.

6. Document and respect permissions

Some browsers require permission to read motion sensors. If you request permission, explain why, show how to revoke it, and fall back to the non-motion control when permission is denied.

Common mistakes and how to avoid them

• Relying on motion as the only activation. Fix: add a button that does the same thing.
• Hiding the alternative deep in settings. Fix: surface the alternative near the feature and label it clearly.
• Using motion for navigation without confirmation. Fix: require a tap or press to confirm navigation.
• Not testing with assistive tech. Fix: validate keyboard, screen reader, and switch control usage.

Developer checklist: step-by-step

1. Inventory features that use device motion.
2. For each, decide if motion is essential. If not, provide an equivalent control.
3. Implement an opt-in toggle and default to off where possible.
4. Ensure the alternative is keyboard and screen reader accessible.
5. Prevent accidental triggers and require confirmation for destructive actions.
6. Test on real devices and with assistive technologies.

Testing: cases and methods

• Keyboard: Can a keyboard user perform the same action without motion?
• Screen reader: Is the alternative control labelled and announced correctly?
• Switch control and scanning: Can a single-switch user activate the alternative?
• Touch and pointer: Does the control respond to touch and mouse clicks?
• Simulate motion in browser devtools or use a device to confirm motion is not required.

Simple code patterns

Pattern 1: Accessible toggle to enable motion. Keep motion handlers inactive until the toggle is true.

/* Pseudocode pattern */
<button aria-pressed="false" id="motionToggle">Enable motion controls</button>

// JS: do not add motion listeners until toggle is true
motionToggle.addEventListener('click', () => {
  const on = motionToggle.getAttribute('aria-pressed') === 'true'
  motionToggle.setAttribute('aria-pressed', String(!on))
  if (!on) startMotionListeners()
  else stopMotionListeners()
})

Pattern 2: Always-available non-motion button alongside motion activation.

<button id="actionButton">Perform action</button>
// Motion handler simply calls the same function
function performAction() {
  // shared code for the action
}

Edge cases and platform notes

On some platforms motion sensors are noisy. Consider debouncing and thresholds so small movements do not trigger actions. If your product asks for motion permission, provide clear instructions for users who need to turn it off later. Test on both iOS and Android as behaviour differs.

Quick reference

• Do not make motion the only activation method.
• Provide an accessible, keyboard operable alternative.
• Keep motion off by default when feasible and give clear controls to enable it.
• Test with assistive technology and real devices.

If you follow these steps you will meet the intent of WCAG 2.5.4 and make motion-enabled experiences usable for more people.