WCAG 2.5.4 Motion Actuation

What it asks

Phones and tablets can sense how they are moved. Some apps and sites use that: shake to undo, tilt to scroll or pan a map, turn the device to change the view, nod or wave in front of the camera. For someone whose phone is mounted on a wheelchair, who cannot hold it steady, or who has a tremor, those gestures are either impossible or set off by accident all the time.

The rule has two halves, and both must be met. Any function operated by device motion or user motion must also be operable through ordinary user interface components, such as a button. And responding to motion must be something the person can disable, so that a tremor or a bump does not keep triggering it.

There are two exceptions. The motion may be used through an accessibility supported interface, such as an operating system setting that lets people use motion in place of other input: that is a feature for them, not a barrier. And the motion may be essential to the function, where doing it another way would invalidate the activity, such as a pedometer counting steps.

On a desktop site with no motion handling at all, the criterion does not apply. It becomes relevant when a page listens for the device motion or orientation events, or uses the camera to read gestures.

Its official name is success criterion 2.5.4 Motion Actuation, at Level A. It was added in WCAG 2.2, under guideline 2.5 Input Modalities and the principle Operable. The W3C’s normative text says, in part:

“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:”

From WCAG 2.2, W3C. Full explanation: Understanding 2.5.4 Motion Actuation.

Who it helps

People who cannot move the device: it is mounted on a wheelchair, a desk or a bed. People with tremors or involuntary movement, who trigger shake gestures without meaning to. People with limited strength or range of motion, for whom tilting or turning a tablet is hard.

People who cannot make the body movements a camera-based gesture asks for.

What passes and what fails

These pass

• A note-taking app where shake to undo exists and there is also an "Undo" button, with a setting to turn motion off.
• A panorama viewer that pans as the device tilts and also pans with on-screen arrows and by dragging, with a "Disable motion" toggle.
• A step counter that uses device motion, because counting steps is essential to it.
• A page that uses no motion events at all. The criterion does not apply.

These fail

• Shake to undo as the only way to undo, with no button.
• A map that pans by tilting the device, with on-screen controls but no way to turn the tilt response off.
• A card game where tilting the device deals, with no button to deal.
• A fitness page that advances to the next exercise when the person waves at the camera, with no button and no way to disable the camera gesture.

How to test it by hand

1. Read the page’s scripts, or use the browser’s developer tools, to look for listeners on devicemotion and deviceorientation, and for use of the camera to read gestures.
2. On a phone or tablet, try shaking, tilting and turning the device on each page and note anything that responds.
3. For each motion-operated function, find a button or other control that does the same thing, and check that it does.
4. Look for a setting that turns motion response off, on the page or in the site’s settings, and check that it works.
5. For any function with no control or no off switch, ask whether the motion is essential or is provided through an accessibility feature of the operating system.

What automated testing can decide

What a machine can decide

A page that responds to motion has to ask the browser for it, and that shows in the page’s code. Automated testing can find it, and on a page with none it has positive evidence that the criterion does not apply, which is the common case on the web.

What it cannot

Knowing that a page responds to motion does not say what the response does, whether a button somewhere does the same, or whether a setting turns it off. The alternative control need not be named after the gesture, so matching them is a judgement. Whether motion is essential is one too. And user motion read through a camera leaves nothing in the page’s code to find.

How Dreven handles it

Dreven records whether each page in an audit responds to device motion or orientation and shows you what it found. Where a page does not, the report says the criterion did not apply and why.

Where a page does respond to motion, a reviewer sees the elements involved, decides each result, and the report records how.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.5.1 Pointer Gestures (Level A). Pinches, swipes and traced gestures need a single-pointer alternative.
• 2.5.7 Dragging Movements (Level AA). Dragging needs a single-pointer alternative.
• 2.1.1 Keyboard (Level A). Everything must also work from a keyboard.
• 1.3.4 Orientation (Level AA). Content must work in portrait and landscape, a different rule about turning the device.

Questions people ask

All WCAG 2.2 criteria, in plain words