prefers-reduced-motion: what it doesn't solve

Most accessibility advice on motion says "respect prefers-reduced-motion."

That advice is correct, and it is not the whole answer.

The media query is a signal. It tells you one user's preference. What you do with the signal is a design problem, and most implementations of the problem are wrong.

What the media query actually is

prefers-reduced-motion: reduce is set when the user has asked the operating system to minimize animations. On macOS, that's System Settings → Accessibility → Display → Reduce Motion. On Windows, Settings → Accessibility → Visual Effects → Animation Effects. On iOS and Android, similar paths.

The browser exposes this as a media query. CSS or JavaScript can check it and adjust.

That is the full scope of what the media query provides. One boolean. The user has asked for less motion.

What it does not tell you

Everything else about the user.

Which condition they have. Vestibular disorders, migraine, ADHD attention fatigue, photosensitive epilepsy, Ménière's disease. Each has different motion sensitivities. The media query does not distinguish.
Whether they set it intentionally. Many users do not know the setting exists. Many have it on because they enabled it for another app and forgot.
What they consider "motion." Some users are fine with small UI transitions and broken by parallax. Others are broken by any transition.

The media query is not "here is a disabled user." It is "one subset of users who happened to find one specific OS setting and flipped it."

What it covers

prefers-reduced-motion is well-served by removing or replacing:

Parallax scrolling. Backgrounds moving at a different rate than foregrounds. Classic vestibular trigger.
Page-scale animations on scroll. Content flying in from off-screen, rotating, expanding as the user scrolls.
Auto-rotating carousels. Motion the user did not initiate.
Large zoom transitions between views. Zoom-and-fade page navigation.
Hover effects at page scale. Something that swings into view when you mouseover a large region.

Replace with: instant transitions, fade-only, or no transition.

What it doesn't cover

The media query is silent on motion sources you still have to consider.

Autoplay video. Not "motion" in the CSS sense. A pan across a landscape on a background video is the same vestibular trigger as parallax, and prefers-reduced-motion does not stop it. You have to handle it yourself.
Animated backgrounds. Canvas animations, WebGL scenes, CSS shader effects. None are covered by the media query unless you wire them up manually.
Animated GIFs and APNGs. Loop forever. Not stopped by the media query.
Pages that load progressively with content jumping. Layout shifts during load feel like motion to a sensitive user. CLS is an accessibility issue.
Scrolling itself at certain speeds and directions. Horizontal-scrolling pages. Infinite-scroll where content keeps appearing.

For each, you decide independently. The media query does not decide for you.

What designing for motion sensitivity actually looks like

Two principles.

Motion should be initiated, not ambient. User taps a button that expands. Fine. Content moves while the user is trying to read it. Not fine, regardless of the media query.
Default to restraint. If an animation is not load-bearing (the UI works identically without it), consider not adding it at all. Every animation is a small cost to some users and a decoration to others.

Those two cover most of what the media query misses.

The position

prefers-reduced-motion is a minimum. It addresses the most obvious cases for the most explicit users. It does not address the harder cases, and does not address the users who have the condition but not the setting.

Treat it as a floor. Design as if most of your users might be on the edge of a vestibular episode, because a meaningful fraction of them are. The common internet is full of motion they did not ask for.

All articles