2.5.4 Motion Actuation
- Level A
- Operable
- Since WCAG 2.1
Summary
Shaking to undo, shaking to send feedback, tilting to scroll or steer: motion-operated features assume the user can move the device deliberately and precisely. Many users cannot. A phone mounted on a wheelchair or a desk stand cannot be shaken at all, and a user with a tremor may trigger a shake or tilt action constantly without meaning to. The same logic covers user motion detected by a camera, such as waving at the device. This criterion, introduced at Level A in WCAG 2.1, protects both groups with two separate requirements: every motion-operated function must also be operable through ordinary user interface components, and the motion response itself must be able to be switched off.
The auditor's mental model is a two-part checklist per motion feature. First, can I do this without moving the device (is there a button, menu item, or control that does the same thing)? Second, can I stop the device from responding to the motion (a setting in the app, or a system setting the app respects)? Both must be true to pass; a UI alternative alone does not help the tremor user who keeps triggering the action accidentally. Two exceptions exist: motion handled through an accessibility supported interface (typically system-level behaviour the OS already makes controllable), and motion that is essential to the function itself, where the test is strict: the motion must be the function, not merely a convenient trigger for it.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.2.5.4
- Software and native apps
- Clause 11.2.5.4
Clauses 9.2.5.4 (web) and 11.2.5.4 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Motion actuation is rare on the web, which makes it easy to miss when it does appear. The relevant plumbing is the DeviceMotion and DeviceOrientation APIs: in browser developer tools, search the page's scripts for devicemotion, deviceorientation, or DeviceMotionEvent listeners, or watch the console while moving a phone with the page open. Typical web uses are shake-to-clear a form, tilt-driven parallax that also changes state, motion-controlled games, and 360-degree viewers that pan as the device tilts.
For each motion-operated function found, verify both halves. There must be a conventional control that achieves the same result: a clear button beside the shake-to-clear form, pan buttons or drag support on the tilt-driven viewer. And there must be a way to disable the motion response, usually an in-page or in-account toggle; a page that keeps reacting to every tremor with no off switch fails even with a perfect UI alternative. Purely decorative tilt effects that operate no functionality (a parallax background that changes nothing) are out of scope: the criterion applies to functionality operated by motion, not to motion-flavoured decoration.
The European standard applies this criterion unchanged to both web content and software, so the same two-part test carries directly into app audits.
iOS
Distinguish system behaviour from app behaviour first. Shake to Undo is a system feature: when an app simply participates in UIKit's standard undo mechanism, the shake handling belongs to the OS, users can disable it system-wide under Settings, Accessibility, Touch, and undo remains reachable through standard interfaces. That is the accessibility supported interface exception doing its intended job, and you do not fail the app for it.
Custom motion features are a different matter. Apps implement their own shake detection through UIKit motion events (motionEnded and related overrides) or by reading the accelerometer and gyroscope through Core Motion. Common examples: shake to report a bug or send feedback, shake to shuffle, tilt to steer or scroll. For each one, test on a physical device (the simulator's Shake Gesture menu item helps confirm the feature exists, but grading needs the real sensors): perform the motion, confirm what it triggers, then hunt for the button or menu path that does the same thing, and for a setting that turns the motion response off. An app-level toggle is the usual pass; respecting the system Shake to Undo toggle only helps if the custom feature genuinely honours it, which you verify by disabling the system setting and shaking again.
Common iOS failure spots: feedback SDKs wired to shake with no visible alternative entry point, shake-to-shuffle with no shuffle button, and tilt-based interactions in onboarding or games added without any settings screen at all.
Android
Android has no system shake-to-undo, so almost every motion feature you meet is app-implemented: a SensorManager listener on the accelerometer or gyroscope, or a vendor feedback library that registers its own shake detector. Typical cases mirror iOS: shake to send feedback or report a bug, shake to refresh, tilt-controlled movement in games and viewers.
Test on a physical device. Trigger the motion and identify the function it operates, then apply the two-part check: a visible UI route to the same function (a Send feedback item in the overflow menu, a refresh control), and a toggle that disables the motion response, normally in the app's own settings since Android offers no global switch apps can defer to. Where a debug or feedback tool ships to production with shake detection enabled, grade it like any other motion feature: end users with tremors will trigger it, so it needs the alternative and the off switch. Layout Inspector and the developer options will not reveal sensor listeners; this criterion is tested by using the app, reading its settings screen, and, where you have build access, searching the code for sensor registration.
Common Android failure spots: feedback and bug-reporting SDKs left on their shake default with no settings entry, shake-to-refresh with no pull or button equivalent, and tilt games with no on-screen control option where tilt is a control scheme rather than the point of the game.
Pass and fail examples
Passes:
- An app uses shake to send feedback, and the same feedback form is reachable from a Help menu item, and Settings contains a "Shake to send feedback" toggle: both requirements met.
- A note-taking app supports undo via the system Shake to Undo and also shows an undo button in its toolbar: system shake handling falls under the accessibility supported interface exception, and the button covers the function anyway.
- A star-gazing app pans the sky as the device moves, and offers a drag mode plus a "Lock view" control that freezes motion response: alternative and disable both present.
- A pedometer counts steps from device motion: the motion is the function being measured, so the essential exception applies; a button cannot take a step for you.
- A driving game where tilting the device is the steering mechanic and the tilt experience is the activity itself: essential exception, provided the game is genuinely about motion control rather than merely defaulting to it.
Fails:
- Shake to report a bug is the only way to reach the report form, and there is no setting to turn the shake response off: fails both halves at once.
- A shake-to-shuffle music feature with a shuffle button but no way to disable the shake: the alternative exists, but a user with a tremor keeps shuffling mid-song; the disable requirement stands on its own.
- A tilt-to-scroll reading mode that can be disabled but has no non-motion scrolling equivalent within that mode: the disable exists, the alternative does not.
- A web page that clears its form when the phone is shaken, with no clear button and no toggle: motion actuation via DeviceMotion with neither requirement met.
Not a fail under this criterion:
- Content that reformats when the device rotates between portrait and landscape: orientation of the display is SC 1.3.4 Orientation, not motion actuation; nothing is being operated by movement.
- A two-finger pinch or a swipe path drawn on the touchscreen with no alternative: gestures made on the screen belong to SC 2.5.1 Pointer Gestures; this criterion is about moving the device or the user, not the pointer.
- A decorative parallax header that shifts with device tilt but operates no functionality: nothing actuated, nothing to grade here (check it separately under motion-related criteria such as SC 2.3.3 Animation from Interactions if it is distracting).
Commonly confused with
- SC 1.3.4 Orientation. Rotating the display is not operating a function by motion. 1.3.4 asks whether content restricts itself to portrait or landscape; 2.5.4 asks whether moving the device triggers functionality. "The app forces portrait" is a 1.3.4 finding; "shaking submits the form" is a 2.5.4 finding.
- SC 2.5.1 Pointer Gestures. The boundary is where the movement happens. A finger moving across the screen (pinch, multi-finger swipe, drawn path) is a pointer gesture under 2.5.1. Moving the device itself, or the user moving in front of a camera, is motion actuation under 2.5.4. A tilt-to-pan map is 2.5.4; a two-finger-drag-to-pan map is 2.5.1.
- SC 2.3.3 Animation from Interactions. Motion on screen triggered by interaction (parallax, zoom transitions) concerns vestibular safety and the ability to reduce animation. 2.5.4 concerns motion as an input method. A tilt effect can raise both questions, but they are graded separately with separate evidence.
- The essential exception, misapplied. Essential means the motion is the function: a step counter, a spirit level, a game whose activity is motion control. It does not cover motion used as a shortcut for something a button could do; shake-to-send-feedback is never essential, however central the feedback feature is to the app.
- System versus app shake behaviour on iOS. System Shake to Undo, disabled in the OS accessibility settings and operating through standard undo interfaces, sits under the supported interface exception. A custom shake handler the app wired up itself gets no such shelter and needs its own alternative and its own off switch.
How AUDITSU tests this
AUDITSU's audit walkthrough asks on each screen whether any functionality responds to device motion or user motion: shake, tilt, or camera-detected movement. Where a motion feature is present, the walkthrough splits the grading into the criterion's two halves, prompting you to record the conventional UI route to the same function and the setting that disables the motion response, and to check the two exceptions before failing (is the handling system-level through a supported interface, and is the motion genuinely the function itself). Each screen records a pass, fail, or not applicable result with evidence attached, so a shake feature found deep in a feedback flow is tied to the exact screen where it fires.
Because motion features are sparse, most screens grade not applicable quickly; the walkthrough's value is making sure the one shake-wired SDK or tilt interaction in the product does get caught and graded on both requirements, not just the more obvious missing button. For the full guided workflow, see the audit platform.