Category: Mobile Accessibility

Device Motion

Also known as: devicemotion event, DeviceMotionEvent

Simply put

Device motion refers to a device's ability to detect its own physical movement, such as being tilted, shaken, or moved, using built-in sensors. Web pages and applications can access this data to respond to how a user physically handles their phone, tablet, or other device. In an accessibility context, features that rely solely on device motion can create barriers for people who cannot easily perform the required movements.

Formal definition

Device motion, as exposed through the W3C Device Orientation and Motion specification, is represented by the devicemotion event, which reports the acceleration of a device expressed in Cartesian coordinates within a defined coordinate frame. The event is fired at a regular interval and can indicate the device's acceleration rate with or without the contribution of gravity, drawing on accelerometer and gyroscope sensor data. Per the specification and browser implementations (for example, MDN's documentation of DeviceMotionEvent), user permission may be required to access this sensor data. From an accessibility standpoint, practitioners should note that WCAG addresses motion-based operation, later versions of WCAG introduced success criteria concerning motion actuation, so interactions triggered by device movement should generally provide alternative input methods; consult current WCAG guidance for the applicable criteria and levels.

Why it matters

Device motion enables engaging, intuitive interactions, shaking a phone to undo an action, tilting a device to steer in a game, or moving a device to trigger a feature. However, when a function can only be operated through device movement, it can exclude people who cannot easily tilt, shake, or otherwise physically manipulate their device. Users with motor disabilities, those who mount their devices in fixed positions, or people using assistive setups may be unable to perform the required gestures, effectively locking them out of the functionality.

This is why WCAG addresses motion-based operation. Later versions of WCAG introduced success criteria concerning motion actuation, generally directing that functionality triggered by device movement also be operable through conventional user interface components and that users be able to disable motion-based activation to prevent accidental triggering. Providing an alternative input method allows people who cannot use motion gestures to access the same features, while also helping users who might inadvertently activate motion-based controls.

Beyond accessibility considerations, access to device motion data may require user permission in modern browsers, and relying solely on motion can create barriers for anyone whose device or context does not support the expected movement. Practitioners should treat motion as an enhancement layered on top of accessible baseline controls rather than as the only way to operate a feature. This entry is not legal advice; consult current WCAG guidance for the applicable success criteria and conformance levels, and qualified counsel for compliance questions.

Who it's relevant to

Front-end and mobile developers

Developers implementing motion-based interactions using the devicemotion event or equivalent framework APIs should provide alternative input methods so that any function triggered by device movement can also be operated with conventional UI controls. They should also account for the user permission that browsers may require before device motion data is accessible.

UX and interaction designers

Designers who incorporate tilt, shake, or other motion gestures should treat these as enhancements rather than the sole means of operating a feature, and consider users who cannot easily perform the required movements or who might trigger them accidentally. Offering a way to disable motion-based activation supports a wider range of users.

Accessibility specialists and QA testers

Those evaluating conformance should verify that motion-actuated functionality has accessible alternatives and can be disabled, referencing the applicable WCAG success criteria on motion actuation and confirming the version and conformance level in scope. Manual and assistive technology testing is needed, as motion-based barriers are not fully detectable through automated checks alone.

Compliance officers and legal counsel

Stakeholders assessing accessibility obligations should understand how motion-only interactions may create barriers and how WCAG addresses them. Because requirements evolve through regulation and case law and vary by jurisdiction and applicable authority, they should consult current WCAG guidance and qualified legal counsel rather than treating any single measure as ensuring compliance.

Inside Device Motion

Motion-Based Interaction

Functionality that is operated by physically moving a device, such as tilting, shaking, or rotating it, or by moving the user's own body as detected by sensors like accelerometers and gyroscopes.

Alternative Input Method

A non-motion way to operate the same functionality, such as on-screen buttons or standard controls, so users who cannot perform the required motion can still complete the task.

Motion Actuation Disabling

The ability for users to turn off device motion response to prevent unintended activation, which supports people who may inadvertently trigger motion (for example, due to tremors).

Essential Exception

Circumstances where the motion is fundamental to the activity and cannot reasonably be replaced, in which case the alternative-input expectation generally does not apply.

WCAG 2.1 Success Criterion 2.5.4 (Motion Actuation)

The success criterion, added in WCAG 2.1 at Level A, that addresses functionality triggered by device or user motion; it is commonly cited as the relevant benchmark for this concept.

Common questions

Answers to the questions practitioners most commonly ask about Device Motion.

Does meeting the WCAG motion actuation criterion mean my app is fully accessible for all users?

No. Satisfying the relevant WCAG success criterion addresses a specific barrier related to motion-based operation, but it does not guarantee an accessible experience for all users. Conformance with individual success criteria is not the same as overall usability or legal compliance. Automated testing detects only a portion of potential issues, so manual testing and testing with assistive technologies are generally required to evaluate real-world accessibility.

Is providing device motion controls itself a violation of accessibility guidelines?

Not inherently. Motion-based operation is not prohibited. The commonly cited concern is that functionality operated by device motion or user movement should also be operable through conventional user interface components, and that users should generally be able to disable motion actuation to prevent accidental activation. Motion input may be retained where it is essential to the function or where the motion is used through an accessibility-supported interface. The guidance addresses how motion is offered, not whether it may exist at all.

How can I provide an alternative to a feature that is triggered by device motion?

A common approach is to expose the same functionality through standard interface controls, such as buttons or menu items, so the action can be performed without moving or shaking the device. The alternative should be discoverable and operable using assistive technologies. Manual testing with keyboard, screen reader, and other assistive technologies is generally recommended to confirm the alternative works as intended.

Should users be able to turn off motion-based controls?

Allowing users to disable response to device motion is commonly recommended, particularly where unintended movement could trigger actions accidentally. Providing a clear setting to turn off motion actuation helps users with tremors, limited motor control, or those who may move the device inadvertently. Exceptions may apply where the motion is essential to the function or is achieved through an accessibility-supported interface.

How do I test whether motion-based features have accessible alternatives?

Testing generally combines manual evaluation with assistive technology checks. Reviewers can attempt to perform each motion-triggered action using only conventional controls, verify that any option to disable motion is present and functional, and confirm the behavior with screen readers and other input methods. Automated tools may not reliably detect motion-related issues, so manual and assistive technology testing are typically necessary.

Does supporting device motion controls affect users who mount their device or use it in a fixed position?

It can. Users who mount a device, use it on a stand, or have limited ability to move it may be unable to perform motion-based actions. Providing an equivalent control that does not depend on physical movement helps ensure these users can access the same functionality. Considering a range of usage contexts is generally advisable when implementing any motion-dependent feature.

Common misconceptions

Motion-based controls are inherently inaccessible and should never be used.

Motion-based interaction can be acceptable when an alternative input method is provided and users can disable motion response. The relevant guidance generally focuses on offering alternatives rather than prohibiting motion outright, and motion may be permitted where it is essential to the function.

If motion is essential to the app, no accessibility considerations apply.

The essential exception may relieve the requirement to provide a non-motion alternative, but it does not eliminate all responsibility. Practitioners should still evaluate whether the reliance on motion is genuinely essential and consider broader usability for people with disabilities.

Meeting Success Criterion 2.5.4 guarantees the interaction is accessible and legally compliant.

Conformance with a WCAG success criterion is not the same as an accessible experience for all users or immunity from legal claims. Automated checks detect only a portion of issues, and manual and assistive technology testing are generally needed; legal obligations depend on jurisdiction, regulation, and case law.

Best practices

Provide a conventional, non-motion alternative (such as on-screen buttons or standard controls) for any function that can be triggered by device or user motion, unless the motion is essential.

Give users a setting to disable motion actuation to prevent accidental triggering, which supports people with tremors or limited motor control.

Critically assess whether a motion trigger is truly essential before relying on the essential exception, rather than assuming it is.

Test motion-based features with assistive technologies and through manual evaluation, since automated tools detect only some issues.

Document the alternative input methods and disabling options you provide so they can be verified during accessibility reviews.

Treat WCAG 2.1 Success Criterion 2.5.4 (Level A) as a commonly cited benchmark, and consult qualified legal counsel and current agency guidance for obligations that vary by jurisdiction.