---
title: "Motion Actuation"
url: "https://barrierefreihochzwei.de/en/wcag/2-5-4-motion-actuation"
language: "en"
description: "WCAG 2.5.4 requires regular controls and an off switch for anything triggered by shaking, tilting or gestures. Learn how to implement it properly."
published: "2025-01-01T08:00:00+01:00"
updated: "2026-10-15T09:42:00+02:00"
---

# Motion Actuation

When shaking doesn’t work for everyone.

- **Erfolgskriterium:** 2.5.4
- **Prinzip:** Operable
- **Konformitätsstufe:** Level A
- **Erklärung beim W3C:** [www.w3.org/WAI/WCAG22/Understanding/moti...](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html)

Success criterion 2.5.4

# 2.5.4 Motion Actuation

Level AOperable

When shaking doesn’t work for everyone.

## 1. What is the goal of this criterion?

Some apps feel like a magic trick: shake your phone and your last entry is undone. Tilt the tablet and you flip to the next page. Wave at the camera and you’ve “liked” something. Handy – for anyone who can make those movements.

But what about people whose phone is mounted on their wheelchair? Or who can’t move their device deliberately because of paralysis? Or who keep triggering actions by accident because of a tremor?

The goal of WCAG Success Criterion 2.5.4 is clear: every function that can be triggered by moving the device or by the user’s own movements must also be available through regular controls. And responding to motion must be something people can switch off.

## 2. What exactly does it require?

This criterion covers functions triggered by moving the device (shaking, tilting, rotating) or by the user moving in front of sensors such as the camera (for example, waving).

**The criterion requires two things:**

1. **Alternative controls:** every motion-based function is also available through regular controls such as buttons, links or menus.
2. **An off switch:** responding to motion can be disabled to prevent accidental activation.

**Exceptions apply when:**

- **a supported interface is used:** the motion operates functionality through an interface supported by assistive technology – for example when head or eye tracking translates movement into regular pointer input.
- **the motion is essential:** without motion, the function would make no sense – such as a pedometer that measures movement.

An example: a notes app that undoes your last entry when you shake the phone also needs an undo button – and a setting to turn “shake to undo” off.

**How it relates to other criteria:** whether a view adapts when the device is turned to portrait or landscape is covered by [Orientation](https://barrierefreihochzwei.de/en/wcag/1-3-4-orientation). Movements on the screen, meaning finger or mouse gestures, are covered by [Pointer Gestures](https://barrierefreihochzwei.de/en/wcag/2-5-1-pointer-gestures).

## 3. Why does it matter for accessibility?

Imagine trying to use an app where every important function requires shaking or tilting your device – while it’s firmly mounted on your wheelchair. Or you have a tremor and keep triggering actions you didn’t want.

Alternatives to motion control improve accessibility because they:

- let people with motor disabilities use every function
- don’t exclude people with mounted devices (on a wheelchair, in a holder)
- protect people with tremors or involuntary movements from accidental activation
- make the app usable in situations where moving the device is impractical, like on a bus or in a meeting

And finally: they make apps more robust – even when sensors are missing, disabled or permission hasn’t been granted.

## 4. How to meet the criterion

The good news: implementation is usually simple and even makes your app easier to use. Here are some proven strategies:

**Ground rules for motion-based functions:**

- **Always** offer an alternative: every shake, tilt or motion function has a button, menu item or other regular control.
- Provide **settings** to disable motion control – ideally per function.
- Make the alternative **equivalent**: not buried in a submenu, but just as easy to reach.

**Concrete tips:**

- **“Shake to undo”:** an extra undo button or menu item
- **“Tilt to turn the page”:** previous and next buttons
- **“Wave to like”:** a regular like button
- **“Rotate to steer”:** arrow buttons or a slider

```
// Only listen for motion if it’s enabled in the settings
if (settings.shakeToUndo) {
  window.addEventListener("devicemotion", checkForShake);
}
undoButton.addEventListener("click", undo);
```

**In your settings:**

- Clear labels: “Shake to undo”, “Turn off motion control”
- Fine-grained control: not all or nothing, but individual functions
- Persistence: settings survive a restart

## 5. Why this criterion matters for businesses

2.5.4 is part of WCAG 2.1 Level A and therefore part of EN 301 549, the standard behind the European Accessibility Act. In Germany, the EAA is implemented by the BFSG, which has applied since 28 June 2025 to online shops, banking services and other consumer services, among others. Public sector bodies must meet it as well. This section is general information, not legal advice.

### 1. Reach more people

Alternatives to motion control make your app usable not only for people with disabilities, but for anyone in a situation where moving the device is impractical or impossible: on a crowded bus, in a video call or with the device in a holder.

### 2. Robustness and reliability

Apps that don’t rely solely on sensors are more dependable. Missing hardware, denied permissions or power-saving modes can slow sensors down – an alternative control keeps everything working.

### 3. Better usability

Many people find regular controls more precise and predictable than motion control. People who get to choose are happier.

## 6. The success criterion in the W3C’s words

> **Success Criterion 2.5.4 Motion Actuation (Level A)**
> 
> Functionality that can be 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, except when:
> 
> - **Supported Interface:** The motion is used to operate functionality through an accessibility supported interface;
> - **Essential:** The motion is essential for the function and doing so would invalidate the activity.

In short: anything triggered by motion must also work through controls, and motion detection must be possible to switch off – unless the motion is essential or goes through a supported interface.

**Official explanation from the W3C**

The W3C explains every success criterion in depth – with intent, examples and techniques.

[Understanding 2.5.4](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html)

## More criteria from “Operable”

 [  2.1.1 Level A ### Keyboard

When every click can also be a keystroke.

 ](https://barrierefreihochzwei.de/en/wcag/2-1-1-keyboard) [  2.1.2 Level A ### No Keyboard Trap

When there’s no way out.

 ](https://barrierefreihochzwei.de/en/wcag/2-1-2-no-keyboard-trap) [  2.1.3 Level AAA ### Keyboard (No Exception)

When everything really has to work by keyboard.

 ](https://barrierefreihochzwei.de/en/wcag/2-1-3-keyboard-no-exception)