Reduced Motion: What prefers-reduced-motion Actually Changes, and What It Misses

A user with a vestibular disorder turns on reduced motion in their operating system, opens a storefront, and the hero banner still zooms, the product carousel still slides, and the parallax still moves. The setting exists. The site ignores it. The user leaves, and the analytics call it a bounce.

What prefers-reduced-motion actually does

prefers-reduced-motion is a media query that reflects a user setting in the operating system. When the user turns on reduced motion, the browser tells the page, and the page is supposed to respond by removing or reducing animation. The mechanism is simple: wrap the animation in a media query that only applies when the setting is off, and provide a still alternative when it is on. WCAG 2.3.3, Animation from Interactions, is the criterion behind it, at Level AAA: motion triggered by interaction can be disabled, unless the motion is essential to the function. It is not required for AA conformance, which is why most teams never implement it, and the users who need it notice immediately.

The setting exists because motion makes some people ill. Vestibular disorders, which affect balance and spatial orientation, can turn a parallax scroll or a zooming hero into nausea, dizziness, and disorientation. The user turned the setting on for a reason, and the site that ignores it is not making a design choice. It is overriding a medical preference with a carousel.

The parallax problem

Parallax is the worst offender, because it moves the background at a different speed than the foreground, which is exactly the kind of motion that triggers vestibular symptoms. A hero banner that zooms on load, a product image that slides in from the side, a background that shifts as the user scrolls: each one is a small animation on its own, and together they are a page that never stops moving. The fix is not to remove the animation for everyone. It is to remove it for the people who asked. Wrap the transition in the media query, set the end state as the default, and let the animation be the enhancement, not the baseline.

What it misses

The media query covers CSS animations, transitions, and script-driven motion. It does not cover autoplaying video, animated GIFs, or motion inside third-party widgets, because those are not CSS. A video that autoplays and loops is motion the setting cannot stop, unless the page pauses it when the setting is on. A chat widget that slides in from the corner is motion the theme cannot control, unless the widget honors the setting itself. The skip link that a sticky header covers is the same class of problem: a feature the page added, and a user need the feature ignores. Test the whole page with the setting on, including the widgets, and the gaps show themselves.

Implementing it without breaking the design

Start with the media query. Put every non-essential animation inside a block that only runs when prefers-reduced-motion is no-preference, and make the still state the default. Add a manual toggle in the site settings for users who cannot change their operating system setting. And test it the way the user experiences it: turn the setting on, load the page, and look. The parallax should be gone, the transitions should be instant or absent, and nothing should spin, zoom, or slide. If the page looks the same as with the setting off, the implementation is missing. The keyboard trap test is the same discipline applied to a different input: use the thing the way the user uses it, and the failure stops being theoretical.

Frequently asked questions

Does WCAG require honoring prefers-reduced-motion?

It applies to motion triggered by user interaction, like a parallax effect on scroll or an animation on hover. WCAG 2.3.3, Animation from Interactions, is Level AAA, which means it is not required for AA conformance, but honoring the setting is the simplest way to meet it.

Does prefers-reduced-motion stop autoplaying video?

Yes. Autoplaying video is not covered by the media query, because the query targets CSS and script-driven motion, not media playback. Pause autoplay when the setting is on, and always provide a pause control. The same applies to animated GIFs that loop.

Does the browser handle reduced motion automatically?

No. The setting is a request from the user, and the browser passes it to the page through the media query. The page has to respond to it. A site that ignores the query does nothing for the user who turned the setting on.

How do I test whether my site honors the setting?

Turn the setting on in your operating system, load the page, and look. The parallax should be gone, the transitions should be instant or absent, and nothing should spin, zoom, or slide. If the page looks the same as with the setting off, the implementation is missing.