WCAG 2.5.4: Motion Actuation

What This Rule Means

WCAG 2.5.4 — Motion Actuation addresses a specific but increasingly common scenario in modern web applications: functionality that is triggered by physical device motion, such as shaking a smartphone, tilting a device, or gesturing in front of a camera. The criterion establishes two parallel requirements that must both be met for conformance.

First, any functionality that can be operated by device motion or user motion must also be operable through a user interface component — meaning a button, link, form control, or similar interactive element that does not rely on motion. This ensures that people who cannot perform or cannot reliably perform physical motion gestures are not excluded from accessing that functionality entirely.

Second, users must be able to disable the motion response so that accidental or involuntary motion does not trigger unintended actions. This protects users who have tremors or other motor conditions that cause unintentional device movement from being constantly disrupted by unexpected application behavior.

The criterion applies to two distinct types of motion: device motion, which is detected through sensors such as accelerometers and gyroscopes built into smartphones and tablets (accessed via APIs like DeviceMotionEvent and DeviceOrientationEvent), and user motion, which is detected through cameras or other input sensors that track body movement or gestures rather than the device itself.

A passing implementation provides all motion-triggered functionality through a standard UI control (a button, link, or equivalent), AND allows the user to turn off the motion detection if they choose. A failing implementation either provides motion-only access to a feature with no alternative UI control, or provides an alternative but offers no way to disable the motion trigger so that involuntary movement does not cause problems.

WCAG 2.5.4 defines two important exceptions. Motion actuation is exempt if the motion is essential to the function and disabling it would fundamentally alter the activity — for example, a step-counting fitness application where motion tracking is the core purpose, or a game that is explicitly designed around tilting mechanics. The second exception applies when the motion is used to operate functionality through a supported accessibility interface, meaning the platform's own accessibility features handle the motion interaction in a way the user controls independently.

Why It Matters

Motion actuation barriers disproportionately affect people with motor and mobility impairments, but the impact is broader than many developers initially assume. Understanding who is affected — and how — helps teams prioritize this criterion appropriately.

People with tremor conditions — including essential tremor, Parkinson's disease, and multiple sclerosis — may experience constant or intermittent involuntary movement of their hands and arms. When they hold a smartphone, their natural tremor is enough to trigger shake-to-undo dialogs, refresh actions, or other motion-activated features repeatedly and unexpectedly. The World Health Organization estimates that approximately 1.3 billion people worldwide live with some form of significant disability, and conditions affecting fine motor control are among the most prevalent across all age groups.

People with paralysis or limb differences may use their devices mounted on wheelchairs or stands, or may use head pointers, eye tracking, or switch controls to interact with their devices. These users often cannot shake or tilt a device at all, making motion-only features completely inaccessible. If the only way to undo a text entry on a mobile web application is to shake the device, a wheelchair user with a mounted phone simply cannot access that feature.

Older adults are another significantly affected group. Age-related conditions including reduced grip strength, arthritis, and essential tremor become increasingly common with age, meaning that a growing segment of the population — who are also increasingly active digital users — may struggle with precise or intentional motion gestures.

Consider a concrete real-world scenario: a Turkish e-commerce site adds a "shake to shuffle" feature that shows users a random product recommendation when they shake their phone, making browsing more engaging. The feature is fun and novel, but there is no button equivalent to trigger the shuffle, and no way to turn off the shake detection. A user with Parkinson's disease who visits that site experiences constant, uncontrolled shuffle activations as their natural tremor triggers the gesture. They cannot browse calmly because the page keeps jumping to random products. This user is effectively locked out of a normal shopping experience — and under Turkey's accessibility regulations, this is not merely a UX problem but a legal compliance failure.

Beyond disability access, disabling or providing alternatives to motion features also improves the experience for users in environments where device motion is unreliable — on public transport, in offices, or in any setting where a user cannot freely move their device.

Related Axe-core Rules

WCAG 2.5.4 requires manual testing because automated tools cannot reliably detect the presence or absence of motion-based functionality by analyzing static HTML and CSS alone. Motion actuation depends on JavaScript event listeners and runtime behavior that automated scanners cannot fully introspect. The following explains why automation falls short and what manual evaluation must cover.

• No direct axe-core automated rule exists for 2.5.4. Axe-core and similar automated engines work by inspecting the DOM, ARIA attributes, and computed styles. They cannot observe whether a page has registered a devicemotion or deviceorientation event listener, nor can they determine whether an equivalent UI control exists for any motion-triggered functionality. A page could have extensive motion-based interactivity with zero DOM-visible indicators, making automated detection fundamentally unreliable. Axe-core therefore flags this criterion as requiring manual review rather than attempting automated detection that would produce high false-negative rates.
• Manual inspection of JavaScript event listeners is required. Testers must use browser developer tools to search for registrations of DeviceMotionEvent, DeviceOrientationEvent, and camera/vision APIs such as the Shape Detection API. The browser's Event Listeners panel in DevTools can reveal whether these events are attached to the window or document object.
• Functional equivalence cannot be automated. Even if a tool could detect a motion listener, it could not determine whether a button or link elsewhere in the interface provides the same functionality. Assessing functional equivalence requires a human tester who understands the application's features and can verify that every motion-triggered action has a reachable, operable UI alternative.
• Disable-ability cannot be automated. Determining whether a user can turn off motion responses requires interacting with the application's settings or preferences — a behavioral test that automated tools are not designed to perform comprehensively.

How to Test

1. Automated scan as a starting point: Run axe DevTools, Lighthouse, or the Accsible accessibility checker on the page. These tools will not flag 2.5.4 violations automatically, but they may surface related issues. Note any flagged items, then proceed to manual steps. The absence of automated flags does not mean the page passes 2.5.4.
2. Identify motion-triggered functionality: Open Chrome DevTools and navigate to the Elements panel. Search the page's JavaScript source files (using the Sources tab and global search with Ctrl+Shift+F) for the strings devicemotion, deviceorientation, accelerat, gyro, and shake. Document every instance found and the associated functionality.
3. Verify UI alternatives exist: For each piece of motion-triggered functionality discovered in the previous step, attempt to accomplish the same action using only keyboard navigation and mouse clicks — no device motion. Navigate through the interface using Tab, Enter, Space, and arrow keys. If you cannot find an operable UI control that achieves the same result, the criterion fails.
4. Verify motion can be disabled: Look for a settings menu, preferences panel, accessibility settings, or a toggle specifically for motion features. Attempt to disable motion actuation. If no such control exists, or if disabling motion also disables the UI alternative, the criterion fails.
5. Physical device testing: Load the page on an actual smartphone or tablet. Deliberately move the device gently (simulating involuntary tremor — small, continuous movements) and observe whether functionality is triggered unintentionally. Then attempt the same test after disabling motion via any available settings.
6. Screen reader and keyboard testing: Using NVDA with Firefox, VoiceOver with Safari on iOS, or JAWS with Chrome, navigate the page using only the keyboard and screen reader commands. Confirm that all functionality reachable through motion is also reachable through screen reader navigation, and that the motion disable control (if present) is itself keyboard accessible and properly labeled.
7. Browser DevTools device simulation: In Chrome DevTools, open the Sensors panel (More Tools > Sensors) and use the device orientation and accelerometer simulation controls to trigger motion events programmatically. This allows desktop testing of motion-triggered behavior without a physical device.

How to Fix

Shake-to-Refresh with No Alternative — Incorrect

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Shake-to-Refresh with No Alternative — Correct

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Tilt-to-Scroll Carousel with No Disable Option — Incorrect

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Tilt-to-Scroll Carousel with No Disable Option — Correct

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Camera-Gesture Feature with No Alternative — Incorrect

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Camera-Gesture Feature with No Alternative — Correct

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Common Mistakes

• Providing a UI alternative button but forgetting the motion disable toggle: Many developers add a button equivalent but never implement a way to turn off the motion listener, leaving tremor-affected users still experiencing unwanted activations even though the feature is technically operable by other means.
• Hiding the motion-disable option inside a hamburger menu or buried settings page: The control to disable motion must itself be easily reachable. If a user with a tremor triggers shake-to-refresh repeatedly before they can navigate five menu levels deep to disable it, the disable option is not practically accessible.
• Assuming the OS-level "reduce motion" preference satisfies 2.5.4: The prefers-reduced-motion media query and OS accessibility settings address animation and vestibular concerns, but they do not automatically disable device motion event listeners in web applications. You must handle this in your own code.
• Setting motion thresholds too low: Using very sensitive thresholds for DeviceMotionEvent acceleration values means minor, involuntary tremors can cross the threshold. Thresholds should require deliberate, high-magnitude motion, and even then a disable option is required.
• Registering motion listeners globally on window without ever removing them: Attaching a listener and never providing a code path to remove it with removeEventListener means the disable toggle can only suppress behavior conditionally — if the toggle itself fails or resets on page reload, the motion remains active.
• Making the disable-motion checkbox inaccessible: Implementing the disable toggle as a styled <div> or <span> with a click listener instead of a proper <input type='checkbox'> or ARIA-enhanced control means keyboard and screen reader users cannot reach or operate the very control meant to help them.
• Not persisting user motion preferences across sessions: If a user disables motion actuation but the preference is not saved (e.g., via localStorage or a user account setting), they must re-disable it on every visit, creating a repeated burden for users who are most affected.
• Applying the essential-function exception too broadly: The "essential" exception is narrow. A product gallery that uses shake-to-shuffle is not essential — the shuffle feature is not the core function of a shopping site. Teams sometimes misapply this exception to avoid doing implementation work.
• Not testing on a real physical device with actual motion: Relying solely on desktop simulation tools or automated scans means that real-world motion sensitivity issues — including how the feature behaves when a user has a natural tremor — are never discovered until users report them.
• Forgetting that motion features added by third-party SDKs or analytics libraries must also comply: Motion listeners embedded in third-party chat widgets, gamification SDKs, or A/B testing tools are still part of the page's conformance responsibility. If a third-party script registers a devicemotion listener without providing an alternative, the page fails 2.5.4.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular No. 2025/10, published in the Official Gazette (No. 32933) on June 21, 2025, establishes mandatory web accessibility requirements aligned with WCAG 2.2. WCAG 2.5.4 Motion Actuation is a Level A criterion, which means it sits at the highest priority tier of mandatory compliance under this circular.

The circular covers a broad range of public and private sector entities. Public institutions — including all central and local government bodies, ministries, and public agencies — must achieve full Level A conformance within one year of the circular's publication. Private sector entities in covered categories must achieve the same standard within two years. The covered private sector categories include e-commerce platforms and marketplaces, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transportation companies, and private schools operating under authorization from the Ministry of National Education (MoNE).

Motion actuation is particularly relevant to Turkish digital services because mobile internet usage in Turkey is very high, with the majority of web traffic arriving from smartphones. Mobile-first and mobile-only web applications are therefore extremely common across all covered sectors. Any Turkish e-commerce site, banking application, or government portal that has implemented shake-to-refresh, tilt navigation, gesture-based interactions, or similar motion features without providing UI alternatives and disable controls is in direct violation of a mandatory Level A requirement under Presidential Circular 2025/10.

For covered entities preparing compliance roadmaps, motion actuation should be assessed as part of a broader mobile accessibility audit. Because automated tools cannot detect 2.5.4 violations, organizations should include manual testing by qualified accessibility specialists as part of their conformance verification process. Given that the circular does not include a grace period for features that were implemented before its publication — only a timeline for achieving conformance — any motion-based functionality currently deployed on covered sites must be remediated within the applicable deadline.

Entities that fail to comply with the circular's requirements may face administrative sanctions and are subject to enforcement by the relevant supervisory authorities for their sector. Beyond regulatory risk, non-compliance with 2.5.4 on a high-traffic Turkish mobile site represents a real usability failure for millions of users who may experience motor impairments, tremors, or use assistive technology — a population whose needs are explicitly recognized and protected by the circular's adoption of WCAG 2.2 Level A as the baseline standard.