F106: When Motion Controls Trap Users Who Can't Stay Still

WCAG 2.0 turned 16 years old this month. Motion actuation — a capability that didn't even exist in that specification — is now baked into everyday web interfaces. And we're still shipping it without an off switch.

Failure F106 (opens in new window) in the official W3C WCAG 2.2 techniques catalog documents a specific, preventable exclusion: motion-controlled interfaces that offer no way to disable the motion detection. It's a narrow technical failure with a wide human cost.

The Failure

F106 applies to any content that uses device or user motion — shaking, tilting, gesturing — as a means of input, when that motion actuation cannot be turned off. The W3C document is precise about scope: this covers intentional gesturing detected by the device, not geolocation movement through space, not keyboard operation, not pointer or assistive technology input.

The canonical example in the specification is a slider controlled by device tilt. The value changes as the user tilts their phone. There is no setting, no toggle, no alternative — just tilt to control.

The problematic pattern looks something like this:

// F106 failure pattern: motion actuation with no deactivation mechanism
window.addEventListener('deviceorientation', function(event) {
  const tiltValue = Math.round(event.beta); // -180 to 180 degrees
  slider.value = mapTiltToRange(tiltValue, slider.min, slider.max);
  updateDisplay(slider.value);
});
// No user preference check. No disable toggle. No alternative input.

This fails WCAG 2.5.4 Motion Actuation (opens in new window), a Level A success criterion introduced in WCAG 2.1. Level A. The baseline. The floor.

Why This Matters

The W3C document names the affected population directly: people who may accidentally activate sensors due to tremors or other motor impairments. That's not an edge case. Essential tremor affects an estimated 10 million people in the United States alone. Parkinson's disease, multiple sclerosis, cerebral palsy, and dozens of other conditions produce involuntary movement that a device accelerometer cannot distinguish from intentional input.

For these users, a tilt-controlled interface isn't inconvenient — it's chaotic. The slider value shifts without intent. Forms submit prematurely. Navigation triggers unexpectedly. The interface responds to the user's body in ways the user cannot control, which is a particular kind of digital indignity: the technology treating involuntary movement as instruction.

What does it mean for the field when we build interaction patterns that are literally responsive to the user's disability? Not responsive in the assistive sense — responsive in the way that makes the disability itself an obstacle to use. That's worth sitting with.

Switch users and users with limited motor control who rely on mounted devices — phones in wheelchair mounts, tablets on desk stands — face a compounding problem. Their device position is often fixed for accessibility reasons. Motion input designed for handheld casual use becomes permanently active and permanently triggering in their context.

The Fix

SC 2.5.4 requires one of three things: the ability to turn off motion actuation, an alternative input method that achieves the same function, or the motion being essential (a very narrow exception — think "shake to undo" on iOS, where the motion is the only reasonable way to expose that function).

The corrected pattern addresses all three requirements:

// Fixed pattern: motion actuation with user control and alternative input
let motionEnabled = false; // Default OFF — safer starting point
// User toggle
const motionToggle = document.getElementById('motion-toggle');
motionToggle.addEventListener('change', function() {
  motionEnabled = this.checked;
  if (motionEnabled) {
    startMotionDetection();
  } else {
    stopMotionDetection();
  }
});
function startMotionDetection() {
  window.addEventListener('deviceorientation', handleOrientation);
}
function stopMotionDetection() {
  window.removeEventListener('deviceorientation', handleOrientation);
}
function handleOrientation(event) {
  if (!motionEnabled) return;
  const tiltValue = Math.round(event.beta);
  slider.value = mapTiltToRange(tiltValue, slider.min, slider.max);
  updateDisplay(slider.value);
}
// Alternative: standard range input always available
slider.addEventListener('input', function() {
  updateDisplay(this.value);
});

The toggle itself needs to be keyboard accessible and clearly labeled. The alternative input — a standard range slider in this case — must be present regardless of whether motion is enabled. Respecting the operating system's "Reduce Motion" preference via prefers-reduced-motion is a strong complementary practice, though it doesn't substitute for an in-interface control.

media (prefers-reduced-motion: reduce) {
  /* Disable motion-driven animations as a baseline */
}

// Also check OS-level preference
const prefersReducedMotion = window.matchMedia(
  '(prefers-reduced-motion: reduce)'
).matches;
if (prefersReducedMotion) {
  motionEnabled = false;
}

Applying This

F106 is one of the failure modes that automated testing tools are least equipped to catch. A linter can flag deviceorientation event listeners, but it cannot determine whether a disable mechanism exists or whether an alternative input is present. This belongs in manual audit scope — specifically in the mobile and interaction testing phase.

For code review, flag any deviceorientation or devicemotion event listener and require documentation of the corresponding disable mechanism before merge. For QA, test on a physical device with Reduce Motion enabled — emulators don't always surface motion behavior accurately.

Design-side: if a motion interaction appears in a prototype, the disable toggle should appear in the same prototype. Don't defer it to engineering as an afterthought. The compliance framework pressures that push teams toward feature velocity over accessibility review are real — but a Level A failure is not a tradeoff worth making.

CORS Perspective

From a community input lens, F106 is a visibility problem before it's a technical one. People with tremors and involuntary movement are rarely in the room when motion-controlled features are designed, and the gap between what organizations build and what disabled users actually experience shows up exactly here: a feature that reads as delightful in a demo becomes an obstacle for the user whose hand shakes. Operationally, the fix is low-cost — a toggle and an alternative input — which makes the failure harder to justify. The risk calculus is straightforward: SC 2.5.4 is Level A, meaning it's among the minimum requirements for conformance claims under WCAG 2.2 (opens in new window), and it carries weight in both Section 508 contexts and emerging state digital accessibility mandates. Strategically, defaulting motion to off and requiring opt-in is the move that protects the broadest population while still offering the feature to users who want it — that's not a concession, it's better design.