prefers-reduced-motion is not an accessibility tax

Every front-end developer has met prefers-reduced-motion as a checkbox at the end of a project: bolt a media query on, collapse the animations, ship. I did it that way for years. The posture is wrong, and it’s wrong in a way that costs you twice — once in accessibility quality, and once in design quality.

Here’s the reframe that changed how I build: reduced motion isn’t a degraded mode. It’s a design constraint that produces better motion design — the same way designing for a cracked Android phone produces better layouts.

What reduced motion actually signals

The media query isn’t "this user hates fun". It’s a user telling you, unprompted, that movement on screen causes them real problems — vestibular disorders, motion sickness, migraines, and conditions nobody enumerates because the query doesn’t ask. That’s a startlingly high-trust piece of information, and honouring it fully — not partially, not "just the big ones" — is the entire job.

Parallax, autoplaying carousels, bounce-eased reveals, spinners with more than two rotations: these aren’t decoration for these users. They’re the thing that makes a site unusable.

The implementation pattern that scales

I’ve landed on three rules, applied everywhere:

1. The reduced-motion rule is global, not per-component. One media query in the base layer collapses animation durations to effectively zero across the whole site. Per-component opt-outs mean every new component is a fresh chance to forget.
2. The JS-driven animations check it too. A global CSS rule can’t stop a JavaScript animation loop — the scroll-reveal component on this very site checks the query before it animates. If your reveal library doesn’t, it’s the wrong library.
3. Opacity and color are the safe vocabulary. "No motion" doesn’t mean "no feedback" — fades and colour changes carry transition information without moving anything. The reduced-motion version of a component should still feel responsive; instantness is the goal, deadness is a bug.

What the constraint buys back

Here’s the part I didn’t expect: designing the reduced-motion version first makes the full version better.

When you start with "how does this feel with no movement", you’re forced to put the information and the hierarchy in the right place — because nothing is going to swoop in to compensate for a weak layout. Then the motion you add has to earn its place: does this movement explain something (where a panel came from, that an item was added), or is it just demonstrating that you can?

The honest answer, most of the time, is demonstrating. The motion that survives that question — a card lifting to show it’s interactive, a panel sliding from where it opened — is semantic motion, and it’s the motion worth keeping.

The posture, in one paragraph

Motion is a layer, not a foundation: the layout, hierarchy, and state changes must work with animation disabled, because that’s not a degraded state — it’s the state a meaningful fraction of your users experience all the time. Design the still frame first, earn every movement second, and honour the query everywhere, not just in the hero. It’s less work than retrofitting, calmer for everyone, and — consistently, in my experience — a better site.