In a page or on a mobile device functionality that can be operated by device motion or user motion can also be operated by alternatives like buttons, links or other controls. There should be a way for disabling responding motion, unless the motion can operate in an accessible way or is essential
Why is this a problem?
This Success Criterion helps people who may be unable to perform tilting, shaking, or gesturing to use an interface – or the device may be mounted. Fixing this will ensure users can still operate all functionality by other means.
Notice how most of these following example are just about common sense alternatives to using motion to do things on a mobile device.
- A user can’t hold and move the device to navigate content. A control exists to navigate also.
- When inputting text – shaking a device shows a dialog where you can undo the text input. A cancel button next to the text field offers the same functionality.
- A user can tilt a device to advance to the next or a previous page. Buttons or links are also provided to perform the same function.
- A user can move the device to change the view of an image. A control is also available to do the same thing.
Accessibility Requirements for 2.5.4 Motion Actuation (A)
- Do not use the
devicemotionevent to activate content functionality.
- Ensure that alternative means of input exist when using device motion sensor input.
- Provide a user preference to disable motion actuation.
- Support OS features which allow the user to disable motion actuation.
- Use the new
prefers-reduced-motionCSS declaration. This will detect if the user would like to reduce animation or motion on the pages they visit.
Common mistakes for 2.5.4 Motion Actuation (A)
- Functionality that can only be activated via device motion events (e.g., shaking or tilting)
- The user is unable to disable motion actuation.
- The author has turned off system level features which allow the user to disable motion actuation.
Techniques for 2.5.4 Motion Actuation (A)
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the “Other Techniques” section.
Common Failure for 2.5.4 Motion Actuation (A)
The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.
FAQs for Motion Actuation (A)
What is Accessibility Supported Interface?
In this success criterion, an accessibility supported interface refers to an assistive technology that relies on motion. An example is eye tracking software that uses the camera to detect eye movement to move the cursor.
Who is benefited by this guideline?
People who have limited mobility may not be able to accurately move the device or perform gestures. Some users have their devices locked in a fixed position and cannot move it. Those with tremors may cause an action by moving their device by mistake. Someone in a public or unstable environment such as riding in a car or bus, may not be able to use movement or gestures. All users benefit when there are alternative ways to interact with applications.
What are the exceptions for this guidelines?
Motions implemented by assistive technology or used for accessibility purposes
Motions that are initiated by users to perform a function
Motions that are essential like in games where other alternatives would invalidate the tasks
Movements that are necessary and sensed by beacons and location sensors like walking in a fitness app or changing the direction of the device in a map.
1.Provide alternatives where motion actuation is used
2.Provide confirmation or cancelling mechanism
3.Allow system settings to deactivate motion detection