Motion Actuation: What WCAG SC 2.5.4 Requires for Tilt and Shake-Controlled Product Views

Two patterns have become routine on mobile shopping sites over the last few years: a 360°-spin product viewer that responds to tilting the phone instead of (or in addition to) swiping, and an AR “view in your space” feature where moving the phone moves a virtual product around the room on screen. Both rely on the device’s own motion sensors — the accelerometer and gyroscope — rather than a tap, a swipe, or a button press. That’s exactly the input category WCAG 2.1 SC 2.5.4 Motion Actuation exists to govern, and it’s a success criterion that shows up in essentially zero manual QA checklists because most reviewers never think to physically shake or tilt the device they’re testing on.

Quick answer: SC 2.5.4 Motion Actuation (Level A) requires that any functionality operated by moving the device — tilting it, shaking it, or responding to a gesture a sensor picks up — also be operable through a conventional interface component like a button or link, and that the user have a way to turn the motion-triggered response off. The criterion carves out two exceptions: when the motion is essential to the function itself (the Understanding doc’s own example is a pedometer, where counting steps is the feature), or when the motion input goes through an assistive technology’s own accessibility-supported interface. A tilt-controlled 360° product viewer is not essential motion — the same rotation can always be shown with drag or button controls instead — so it needs both the alternative and the disable option. A device-motion-based AR camera, which exists specifically to let someone look around a product by moving their phone, sits closer to the essential-function exception, and the practical answer there is nuanced enough to be worth walking through on its own.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for this pattern and how to meet it, not whether a specific implementation carries legal risk.

What the success criterion actually requires

The Understanding doc for SC 2.5.4 states the requirement in two parts. First, functionality that responds to device motion or user motion — tilting, shaking, panning a camera, waving a hand in front of a sensor — must also be operable through a “user interface component,” meaning an ordinary control like a button, link, or slider that doesn’t depend on moving anything. Second, the motion response has to be something the user can disable, so a person who can’t hold the device still, or whose device is mounted in a fixed position, isn’t stuck fighting unwanted activations.

The Intent section names two groups this protects: people who physically can’t perform the triggering movement (a tremor, a motor impairment) or whose device is fixed in place — mounted on a wheelchair, a desk stand, or a tripod — and so can’t tilt or shake it even if they otherwise could; and, in the opposite direction, people who can move the device but do so unpredictably or involuntarily, and need a way to stop accidental motion from triggering something they didn’t intend.

Two exceptions keep the criterion from applying to things it was never meant to touch. The essential exception applies when the motion itself is the entire point of the function — a pedometer counting steps, or a game that’s inherently about physical movement. If you removed the motion, there would be nothing left for the feature to do. The accessibility-supported interface exception applies when the motion signal is being generated by an assistive technology itself (for example, a switch device that simulates device motion as its own output), in which case the platform’s own accessibility layer is already handling the equivalence.

Where this shows up on e-commerce sites

Two patterns account for nearly every real-world instance of this criterion on a shopping site:

• Gyroscope-driven 360° product spin viewers. A growing number of product-gallery widgets let a shopper rotate a 360° product view by physically tilting their phone, as a supplement to — or sometimes a replacement for — dragging a finger across the image. If tilt is the only way to rotate the view, a shopper whose phone is mounted on a stand, or who can’t tilt the device steadily, loses that entire part of the product page with no alternative. WCAG’s own second worked example for this criterion is a device-tilt-controlled slider, paired with equivalent buttons and a setting to turn tilt response off — a 360°-spin viewer is the same pattern applied to a product image.
• Device-motion-based AR “view in your space.” AR product previews — the kind where the phone’s camera shows the product in your actual room, and moving the phone moves the virtual camera around it — are now common on apparel, furniture, and home-goods product pages. This one sits closer to the essential-motion exception, since spatial exploration via physical movement is the feature. That doesn’t mean accessibility stops mattering, though — most real AR viewers (Apple’s AR Quick Look, Android’s Scene Viewer) already pair device motion with finger-drag and pinch-to-rotate/zoom as a built-in alternative. If a custom AR/WebXR viewer strips that fallback out and leaves device motion as the only way to move the camera, treat it as a 2.5.4 gap rather than assuming the exception automatically covers it.
• “Shake to undo” or “shake to clear” shortcuts. Less common but still turning up in mobile-optimized shopping experiences — shaking the device to undo a cart action or clear a search field. This is the Understanding doc’s own flagship example: keep the shake shortcut as a convenience, but make the same undo/clear action reachable through a visible button too, and give the user a setting to turn shake-to-undo off.

The two-part fix, directly from WCAG’s own technique

Technique G213 lays out the sufficient fix as two conditions that both have to be true:

1. A conventional control performs the identical function. For a tilt-controlled 360° viewer, that means visible prev/next or rotate-left/rotate-right buttons (or continued support for drag) that do exactly what tilting does — not a reduced or secondary version of the feature.
2. A setting exists to disable the motion response. This doesn’t have to be a prominent toggle on every page; a single accessible setting (in a site-wide preferences panel, or as simple as “tap to pause tilt rotation” directly on the viewer) satisfies it, as long as it’s discoverable and actually turns the sensor-driven behavior off.

G213’s own two named examples: a text field with Shake to Undo also offers a backspace/clear-button alternative and a settings toggle to disable shaking; a tilt-operated slider also offers plus/minus buttons and a checkbox to turn tilt response off. A 360°-spin viewer that keeps drag-to-rotate always working and adds a small “pause tilt” control on the widget meets both conditions with minimal extra UI.

<!-- Fails 2.5.4: tilt is the only way to rotate the view, no alternative, no disable control -->
<div class="product-360-viewer" data-tilt-only="true"></div>

<!-- Passes: drag/buttons work regardless of tilt support, and tilt can be turned off -->
<div class="product-360-viewer" data-tilt-enabled="true">
  <button aria-label="Rotate product left">‹</button>
  <button aria-label="Rotate product right">›</button>
  <button aria-pressed="true" data-tilt-toggle>Tilt to rotate: On</button>
</div>

Can an automated scanner catch this?

No. A direct check of axe-core’s own rule descriptions turns up nothing related to motion actuation, device motion, shake, tilt, or gyroscope input — there’s no rule for this criterion at all. That tracks with what the criterion actually asks: whether a 360°-viewer’s rotation is also reachable by a button, and whether a settings toggle actually disables the sensor listener, are both runtime behavioral questions. A static scan can see that a <div> exists and maybe that it has an accessible name; it has no way to know whether removing tilt input leaves the feature fully usable, or whether a “disable motion” checkbox actually does anything when checked. This is squarely a manual-review question — pick the device up, tilt it, then set it down flat on a table and check whether the same product view is still fully reachable without moving it at all.

FAQ

Is this the same as WCAG 2.5.1 Pointer Gestures or 2.5.7 Dragging Movements? No, though all three live under the same Input Modalities guideline. SC 2.5.1 Pointer Gestures covers touch-gesture complexity — a single-pointer alternative to a two-finger pinch or path-based swipe. SC 2.5.7 Dragging Movements (a WCAG 2.2 addition) covers whether a drag-operated control has a non-drag, single-pointer alternative. SC 2.5.4 is a different input channel entirely — device sensors, not finger input on the screen. A 360°-viewer could pass 2.5.1 and 2.5.7 (drag already works with one finger) and still fail 2.5.4 if tilt is the only way to reach rotation at all.

Does adding a “pause tilt” button automatically satisfy the criterion? Only if it both disables the motion response and leaves an equivalent conventional control in place. A pause button that stops tilt input but removes the only way to rotate the product (no drag, no arrow buttons) doesn’t satisfy G213’s first condition — the conventional alternative has to perform the identical function, not a lesser one.

Does this apply to desktop as well as mobile? In practice, motion actuation is almost exclusively a mobile-device concern, since desktop and laptop computers don’t typically expose accelerometer/gyroscope input to the browser the way phones and tablets do. The criterion itself isn’t device-specific — it applies to any device-motion or user-motion input, whatever the hardware — but e-commerce implementations of it are a mobile-web story.

Get a human-reviewed audit, not just a scan

Whether a motion-triggered feature has a real conventional-control equivalent — and whether a “disable motion” setting actually works — only shows up when someone physically tests the device, not when a script crawls the page. Quietramp’s audits pair an automated scan with a manual review that checks exactly this kind of interaction, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.