Motion Actuation

In brief

Shake to undo, tilt to scroll, wave to answer a call. Features triggered by moving the device or the body are clever, but they can be impossible for people whose device is fixed to a wheelchair, or who have a tremor and trigger them by accident.

This criterion requires that functionality operated by device motion or user motion can also be operated by user interface components, and that responding to the motion can be disabled to prevent accidental actuation, except where the motion is used through an accessibility supported interface or is essential for the function.

What does it cover?

• Device motion: Shaking, tilting or moving the device, detected by the accelerometer or gyroscope.
• User motion: Movements of the user detected by a camera or sensor, such as a wave or a head nod.
• A conventional alternative: Every motion-triggered function must also work through a visible control, such as a button.
• A way to switch it off: Users must be able to turn motion response off, to avoid accidental actuation. An application setting is the technique W3C describes (G213).
• Exceptions: Motion that is used through an accessibility supported interface, and motion that is essential, such as a pedometer counting steps.
• Not covered: Location tracking, aiming a camera at a code or document, and incidental movement such as typing, mouse use, touch gestures or operating assistive technology.
• Out of scope: Gestures on the screen are covered by 2.5.1 and 2.5.2.

Who does it affect?

People with motor disabilities who cannot make the motion, for example because the device is mounted on a wheelchair or a stand. People with tremors or involuntary movements who trigger the function by accident. People who use a device while walking, riding or travelling, where motion happens constantly.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Controls that do not depend on moving the device are part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.5.4 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.5.4 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Shake to clear, with a button

Pair the motion with a visible button.

window.addEventListener("devicemotion", e => { if (isShake(e)) clearForm(); });

<button type="button" id="clear">Clear form</button>
<script>
clear.addEventListener("click", clearForm);
// Shake remains an optional shortcut
</script>

2. A setting to turn motion off

Let users disable motion response, and respect the setting.

// Shake detection is always on

<label>
  <input type="checkbox" id="motion" checked>
  Shake to clear
</label>
<script>
window.addEventListener("devicemotion", e => {
  if (!motion.checked) return;
  if (isShake(e)) clearForm();
});
</script>

3. Tilt to scroll, with controls

Offer next and previous buttons as well as the tilt.

window.addEventListener("deviceorientation", e => scrollByTilt(e.gamma));

<button type="button" id="next">Next page</button>
<button type="button" id="prev">Previous page</button>
<!-- Tilt remains, but can be switched off in settings -->

4. Camera gestures

If a camera detects a wave or a head gesture, provide a button or key for the same function.

detectHandWave(video, () => answerCall());

<button type="button" id="answer">Answer call</button>
<!-- The wave remains an optional shortcut, and can be turned off -->

5. Ask for permission and explain

Browsers require permission for motion sensors. Offer the feature as an option, never as a requirement.

DeviceMotionEvent.requestPermission(); // blocks the app until granted

enableBtn.addEventListener("click", async () => {
  const state = await DeviceMotionEvent.requestPermission?.();
  if (state === "granted") enableShake();
});

6. The essential exception

A step counter needs the motion to do its job. No alternative is required, but explain it.

<!-- A tilt-based quiz with no other way to answer -->

<!-- Pedometer: motion is essential and does not need an alternative -->

Code examples for mobile

Native apps use motion most often. Offer a button for every motion feature, and a setting to turn the motion response off. Do not disrupt the system setting that lets users disable it.

iOS (SwiftUI)

import SwiftUI

struct NotesView: View {
    @AppStorage("shakeToUndo") private var shakeToUndo = true
    @State private var text = ""

    var body: some View {
        VStack {
            TextEditor(text: $text)
            // A visible control for the same action
            Button("Undo") { undoLastChange() }
            // A setting to turn the motion response off
            Toggle("Shake to undo", isOn: $shakeToUndo)
        }
        // Shake is delivered by the app's own motion handling (for example a
        // UIWindow subclass that posts a notification); respect the setting here
        .onReceive(NotificationCenter.default.publisher(for: .deviceDidShake)) { _ in
            if shakeToUndo { undoLastChange() }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.*
import androidx.compose.runtime.*

@Composable
fun NotesScreen(shakeEnabled: Boolean, onShakeChange: (Boolean) -> Unit, onUndo: () -> Unit) {
    Column {
        // A visible control for the same action
        Button(onClick = onUndo) { Text("Undo") }
        // A setting to turn the motion response off
        Row {
            Text("Shake to undo")
            Switch(checked = shakeEnabled, onCheckedChange = onShakeChange)
        }
    }
    // Register the SensorEventListener only while shakeEnabled is true
}

How to test

• List motion features: Find everything that responds to shaking, tilting, moving the device, or body movement seen by a camera.
• Look for a control: For each, is there a button, menu item or other control that does the same?
• Look for a setting: Can the motion response be turned off in the app or the system?
• Test with the device fixed: Place the device on a stand. Can you still use every function?
• Check for accidents: Walk or ride with the device. Does the motion feature trigger by mistake, and can you stop it?
• Check the exceptions: Is the motion essential, as in a pedometer?
• Use a checker as a starting point: Automated tools can find motion event listeners in code, but cannot judge alternatives. A person must test on a device.

Common mistakes

• Shake-only features: No visible control for the same action.
• Motion that cannot be switched off: Users who trigger it by accident cannot stop it (F106).
• Tilt-controlled navigation with no buttons: Impossible with a mounted device.
• Treating a setting as a replacement for controls: You need both.
• Disabling the system motion-off setting: Do not override it.
• Making motion a requirement to complete a task: Do not gate sign-up or checkout on a motion.
• Calling a feature essential for convenience: Essential means the function is the motion itself.
• Not testing on a device: Motion features cannot be tested in a desktop browser.

Sources

• Understanding SC 2.5.4: Motion Actuation (W3C), opens in a new tab
• G213: Provide conventional controls and an application setting for motion activated input (W3C), opens in a new tab
• F106: Failure due to inability to deactivate motion actuation (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.