Our series on the new WCAG 2.1 Success Criteria continues with the next success criterion within the new 2.5 Input Modalities guideline: 2.5.4 Motion Actuation.

Guideline 2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

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;
  • Essential: The motion is essential for the function and doing so would invalidate the activity.


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. 


Movement is essential in many games or applications that simulate musical instruments.  Shaking the phone to play the maracas requires movement of the device. 


This success criterion is about intentional movement to cause a specific action. This means moving the device itself or use of other sensors to detect user motion. It does not include geolocation or other sensors that determine movement across the earth surface. 

Examples of using motion to cause an action are:

Shaking the mobile device to undo the last action.
Tilting the device right to advance forward and left to move backward through a sequence of steps.
Gesturing towards the user-facing camera to move forward or backward through a sequence.

In all cases the user must be able to turn off the use of motion to complete an action. And, the author must provide another way to perform the action that does not need device movement. 

Who Benefits?

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. That is the goal of inclusive design and WCAG 2.1.


A common example is shaking the device to undo deleting an item from a list. A compliant application provides a mechanism to turn off the shake to undo feature. It must also provide another way to recover the deleted item.  That may be to add a button to undo the action. Or, the application may provide a way to find the deleted item and to restore it.  

A book reading application that uses the camera and eye tracking is another example. The application detects when the user has completed reading a page and advances to the next page. This application must also have another means to advance the page and a way to turn off the eye tracking.

Take Aways

Unless it is an essential part of the application purpose, don’t rely on device motion for functionality. If you use device motion to activate a feature:

  • Provide an alternative user interface for the feature.
  • Allow the user to disable the motion activation of the feature.