Loading...
Loading content...
Loading content...
Don't require device motion (shaking, tilting) without an alternative.
Why it matters: Users with motor disabilities may not be able to move the device.
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 invalidating it would impact the function.
What This Means: This success criterion requires that any functionality triggered by device motion (like shaking, tilting, or rotating the device) must also be available through standard user interface controls (buttons, menus, etc.). Additionally, motion controls must be able to be disabled to prevent accidental activation.
Why It's Important: Users with motor disabilities may not be able to move their device. Devices may be mounted in fixed positions (like on wheelchairs or desks). Some users may experience motion sickness or have conditions that make device movement difficult. By requiring UI alternatives, you ensure all users can access functionality regardless of their ability to move the device.
If you implement shake-to-undo, also provide an Undo button. If you use tilt-to-scroll, provide scroll buttons or keyboard alternatives. Make motion controls optional and easily disableable through settings. The key is that motion should enhance functionality, not be the only way to access it.
This criterion ensures that users with motor disabilities can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that device mounted users can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
Undo only works by shaking device, no button alternative.
window.addEventListener("devicemotion", (e) => { if (isShake(e)) undo(); });Undo works by shaking device AND has an Undo button.
window.addEventListener("devicemotion", (e) => { if (isShake(e) && motionEnabled) undo(); });<button onclick="undo()">Undo</button><button onclick="toggleMotion()">Disable Shake</button>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 2.5.4 Motion Actuation are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
Motion controls are a nice enhancement, so alternatives aren't needed.
If functionality can be triggered by motion, it MUST also be available through UI controls. Motion cannot be the only way to access functionality.
Games and apps that require motion are exempt.
While some motion may be essential to the function, you should still provide alternatives when possible, or clearly indicate that motion is required.
Shake-to-undo or tilt-to-scroll without button alternatives.
Add UI controls (buttons, menu options) that provide the same functionality. Ensure motion can be disabled.
Motion controls that cannot be disabled, causing accidental activations.
Provide settings to disable motion controls. Make disabling easy and discoverable.
Motion-activated features without clear alternatives.
Always provide UI controls alongside motion controls. Make alternatives prominent and easy to find.
Note: These are official W3C resources for 2.5.4. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 2.5.4 Motion Actuation correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Operable PrincipleGuideline
2.5 Input Modalities