Success Criterion 2.5.4 Motion Actuation (Level A): 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;
The motion is essential for the function and doing so would invalidate the activity.
Off late, we have been witnessing motion based gestures or device movement based gestures to operate certain apps or certain functions like these ones:
Twist the wrist holding the phone to bring up the camera app
Show a thumbs-up in front of the device camera to like a post
All these gestures are innovative and sometimes intuitive too. But what about users who mount their devices on a wheel chair? What about people who have tremor in their hands and accidentally perform some gestures that would activate some controls or functions?
This success criterion aims to address these questions.
How to solve this problem?
- Use an alternative and traditional controls that do the same function like a “previous / next” buttons as an alternative to waving the hand to move between the content
- Provide a cancelling mechanism or a confirmation mechanism like the one that is displayed on iPhones when one shakes to undo typing
- Use system settings that allow the users to turn off the motion detection.
- 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.
Points to ponder
- Provide alternatives where motion actuation is used
- Provide confirmation or cancelling mechanism
- Allow system settings to deactivate motion detection