On each web page, can features that involve a movement of the device or toward the device also be performed in an alternative way (except in special cases)?
A user holds their phone fixed to their wheelchair, or essential tremors prevent them from controlling the device's movement with precision. If your application triggers actions via the accelerometer or gyroscope, this user is locked out. No escape hatch: access blocked.
This criterion covers two families of detection. Device motion itself: tilting, shaking, rotating the phone. Gestures directed at the device: detecting a hand approaching via a proximity sensor or camera, without touching the screen. In both cases, every functionality triggered this way must have an alternative via a standard interface component — button, link, or form field.
Test 13.12.3 goes further. Even when an alternative exists, someone suffering from spasms may trigger the functionality through involuntary motion. Motion detection must therefore be directly disableable from the interface. Once disabled, it must trigger nothing.
In practice: search your JavaScript for devicemotion and deviceorientation listeners. Each must be paired with a visible interactive component, and the whole must be switchable by the user without leaving the page.
3 tests to confirm that an alternative to device motion is offered
Alternative via interface component for motion-based features
- Identify all functionalities triggered by physically moving the device: shake to undo, tilt to scroll, rotate to zoom, etc.
- For each one, verify that a standard interface component accomplishes the same action: button, link, field, or any other interactive element usable without physical motion.
- If at least one functionality has no alternative: test fails. If all have one: test passes.
Alternative via interface component for device-directed gestures
- Identify all functionalities triggered by gesturing toward the device without touching it: waving a hand in front of the camera, approaching the hand to a proximity sensor, etc.
- For each one, verify that a standard interface component accomplishes the same action.
- If at least one functionality has no alternative: test fails. If all have one: test passes.
Disabling of motion detection in interface
- Identify all functionalities triggered by putting the device in motion (accelerometer, gyroscope).
- Verify that the interface provides a mechanism to disable motion detection: checkbox, toggle button, or preference directly accessible on the page.
- Activate this mechanism, then try to trigger each functionality through motion: none should respond.
- If the disable mechanism is absent, or if a functionality triggers despite being disabled: test fails.
Examples
❌ Non-compliant : Shake to undo — no alternative or disable option
<script>
window.addEventListener('devicemotion', function(event) {
var acc = event.accelerationIncludingGravity;
if (Math.abs(acc.x) > 15 || Math.abs(acc.y) > 15) {
undoLastAction();
}
});
</script>The « undo » function is only accessible by shaking the phone. A user with essential tremors cannot trigger it voluntarily, nor can they avoid triggering it accidentally. No equivalent button exists, no disable option is offered.
✅ Compliant : Shake to undo — with alternate button and disable toggle
<button type="button" id="btn-undo">Undo last action</button>
<label>
<input type="checkbox" id="toggle-shake" checked>
Enable « shake to undo » gesture
</label>
<script>
var shakeEnabled = true;
document.getElementById('toggle-shake').addEventListener('change', function(e) {
shakeEnabled = e.target.checked;
});
window.addEventListener('devicemotion', function(event) {
if (!shakeEnabled) return;
var acc = event.accelerationIncludingGravity;
if (Math.abs(acc.x) > 15 || Math.abs(acc.y) > 15) {
undoLastAction();
}
});
document.getElementById('btn-undo').addEventListener('click', function() {
undoLastAction();
});
</script>The same functionality is accessible via a visible button (test 13.12.1 passes). The user can disable motion detection directly from the interface (test 13.12.3 passes). Once unchecked, the gesture triggers nothing — involuntary tremors no longer activate the action.
Tips and pitfalls
⚠️ Confusing criterion 13.11 (touch gestures) with criterion 13.12 (physical motion)
Criterion 13.11 covers multipoint touch gestures on screen: pinching, two-finger dragging. Criterion 13.12 covers device motion in space or gestures detected without contact. A two-finger swipe falls under 13.11; shaking the phone falls under 13.12. In audits, this confusion leads to non-conformities being assigned to the wrong criterion.
⚠️ Motion is the core of the functionality
A pedometer counts steps, a digital level measures tilt, an augmented reality game requires pointing the device at a target: in these cases, motion is the functionality itself. Offering a button to « simulate a step » makes no sense. These cases are explicitly excluded from the criterion — document them in your report with explicit justification.
⚠️ Assistive interface controlling motion detection
If motion detection is controlled by an interface itself compliant with accessibility (for example, assistive technology using the gyroscope for augmentative communication), the disable obligation does not apply. Criterion 13.12 targets ordinary application implementations, not assistive devices.
💡 Spot devicemotion and deviceorientation in code
In technical audit, search for addEventListener('devicemotion', addEventListener('deviceorientation' and DeviceOrientationEvent calls in JavaScript. Their presence signals a functionality relying on physical motion. Then verify that a visible interactive element in the DOM fills the same role, and that a disable mechanism is accessible on the page.
⚠️ System-level disable is not enough
iOS and Android offer system settings to limit motion detection (« Reduce Motion », AssistiveTouch). This is not sufficient to pass test 13.12.3. The obligation is for a disable at the page or application level itself, directly accessible in the interface without leaving it.
Frequently asked questions
How do I test RGAA criterion 13.12 on a desktop computer without a mobile device?
Chrome DevTools allows you to simulate motion events via the « Sensors » tab (F12 → More tools → Sensors). You can manually trigger deviceorientation with angle values and devicemotion with acceleration values. For a complete audit, testing on a real device is still recommended, especially to validate behavior upon disabling and triggering thresholds.
What is the difference between RGAA criterion 13.11 and criterion 13.12?
Criterion 13.11 concerns multipoint touch gestures on screen: pinching to zoom, two-finger rotation. Criterion 13.12 concerns physical device motion in space (accelerometer, gyroscope) or contact-free gestures detected by proximity sensor or camera. Two distinct criteria, two separate test series to conduct.
Why is disabling motion at the system level not sufficient to pass RGAA criterion 13.12?
No. Disable must be offered at the page or application level, not in iOS or Android settings. Directing the user to system preferences is not compliant with test 13.12.3. The disable command must be directly accessible in the interface, without switching applications.
What conditions must a global accessibility mode meet to pass RGAA criterion 13.12?
Yes, provided this mode is easily discoverable from each affected page, without lengthy navigation. A link to « Accessibility preferences » visible in the header or near the functionality suffices. The criterion does not require a button on every page: it requires that the user can disable without excessive effort.
What alternative must a fitness app detecting movements offer under RGAA 13.12?
None. When motion is intrinsic to the functionality, the exception applies. A rep counter detecting squats via accelerometer cannot be replaced by a button without losing all utility. Document this case in your audit report with explicit justification: « motion is essential to accomplishing the functionality ».