prefers-reduced-motion: The 10-Line Fix for Animations That Make Visitors Sick

Ten lines of CSS make your website respect a visitor’s “reduce motion” setting — the switch people with vestibular disorders, migraines, and ADHD flip on their phone or computer so animation stops making them dizzy or sick. The prefers-reduced-motion media query detects that setting, and a single global override calms your CSS animations, transitions, and smooth scrolling for exactly those visitors while changing nothing for anyone else.

Here’s who those visitors are, the snippet itself, how to test it on a Mac, a Windows PC, and in Chrome DevTools, and an honest triage of which theme animations to keep, replace, or kill.

Who turns on “reduce motion” — and why

More people than you’d guess, and for medical reasons rather than taste. A large epidemiological study estimated that about 35% of US adults aged 40 and older — roughly 69 million people — have experienced some form of vestibular dysfunction, according to the Vestibular Disorders Association, citing Agrawal et al. in Archives of Internal Medicine (2009).

The vestibular system is the inner-ear machinery that tells your brain which way is up. When it misfires, motion on a screen can read as motion in the room. As Google’s web.dev guide to prefers-reduced-motion puts it, reactions “include dizziness, nausea, and migraine headaches, and sometimes require bed rest to recover.” That’s from a parallax hero, not a rollercoaster.

The W3C’s own guidance quotes an affected user directly: “Stop that extra movement! You are making me so dizzy I cannot concentrate. Now I have to turn off my computer and go lie down.” (Understanding WCAG 2.3.3) Motion sensitivity also overlaps with migraine sufferers and people with ADHD, for whom constant movement wrecks focus — part of the broader picture we cover in how different disabilities meet web barriers.

The good news: every major operating system ships a reduce-motion switch, and your CSS can listen for it.

What is the prefers-reduced-motion media query?

Per MDN, prefers-reduced-motion “is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion.” It has two values: no-preference (the default) and reduce (the visitor flipped the switch).

It behaves like any other media query. Just as @media (max-width: 600px) serves different rules to small screens, @media (prefers-reduced-motion: reduce) serves different rules to people who asked for less motion. Support is excellent: Can I use reports about 94% global browser support, covering Chrome 74+, Firefox 63+, Safari 10.1+, and Edge 79+. Browsers too old to understand it simply ignore the block — nothing breaks.

The 10-line fix: paste this into your stylesheet

Add this block at the end of your site’s CSS — the bottom of your stylesheet, or the “Additional CSS” / “Custom CSS” box in WordPress, Shopify, Squarespace, Wix, or Webflow:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

What each part does, in plain terms:

• The media query wrapper means everything inside applies only to visitors whose device reports a reduce-motion preference. For everyone else, this code may as well not exist.
• *, *::before, *::after targets every element on the page, including decorative pseudo-elements themes love to animate.
• animation-duration: 0.01ms makes every CSS animation finish near-instantly. We use a tiny duration instead of animation: none in our remediation work because some theme JavaScript waits for an animation to finish before continuing — an instant animation still “completes,” so those scripts keep working, while none can leave them hanging.
• animation-iteration-count: 1 stops infinite loops — pulsing buttons, floating icons — after one instant pass.
• transition-duration: 0.01ms makes hover and state changes immediate instead of eased.
• scroll-behavior: auto turns off CSS smooth scrolling, a common trigger because the whole page glides.

This is the same global pattern shown in web.dev’s reduced-motion guide and the CSS-Tricks almanac — both use a near-instant duration rather than zero, though the exact figure varies (they use 1ms and 0.001ms respectively; anything imperceptibly short works). It’s a safety net, not a scalpel — a well-built site would also design intentional reduced alternatives per component, but the net alone converts a nauseating page into a usable one.

How do you test prefers-reduced-motion?

Flip the real setting on your own device, then reload your site — animations should collapse to near-instant.

Setting paths per MDN’s compatibility notes.

No settings access, or want to toggle quickly? Chrome and Edge can fake the preference per Chrome’s DevTools documentation:

1. Open your site in Chrome, then press F12 (or right-click → Inspect) to open DevTools.
2. Press Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows), type rendering, and choose Show Rendering.
3. In the Rendering tab, find Emulate CSS media feature prefers-reduced-motion and select prefers-reduced-motion: reduce.
4. Reload the page and watch what still moves — anything still sliding, zooming, or auto-playing needs attention beyond the snippet.
5. Set the dropdown back to No emulation and confirm regular visitors still get the full design.

Keep, replace, or kill: triage for common theme animations

The snippet handles the emergency. Longer term, decide what each animation is for. Here’s the triage we apply during remediation:

Two things the triage can’t cover. Flashing content is a separate, stricter issue — anything that flashes more than three times per second risks triggering seizures under WCAG 2.3.1, and no media query excuses it. And background videos or animated GIFs ignore CSS animation properties entirely; they need a pause button or a reduce-motion swap in code.

What does WCAG actually require for motion?

Two different criteria, at two very different levels — and it’s worth being precise, because plenty of vendors aren’t.

WCAG 2.3.3 Animation from Interactions says: “Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.” It’s Level AAA — an aspirational tier beyond the WCAG 2.1 AA baseline that US courts and the DOJ generally reference. Nobody is likely to sue you over 2.3.3 alone.

WCAG 2.2.2 Pause, Stop, Hide is a different story. It’s Level A — the minimum tier — and the W3C’s official text requires that moving content which starts automatically, lasts more than five seconds, and sits alongside other content must offer a way to pause, stop, or hide it. Auto-playing carousels, tickers, and looping background motion land squarely here.

So the honest framing: the 10-line snippet isn’t legally mandatory on its own, but the auto-playing motion it tames often is a genuine Level A conformance gap. And the deeper reason to ship it has nothing to do with lawsuits — it’s that a measurable slice of your visitors gets physically ill on your homepage, silently, and leaves.

Where the snippet stops and real remediation starts

The media query governs CSS. It does not pause videos, freeze GIFs, or tame JavaScript animation libraries — those need window.matchMedia('(prefers-reduced-motion: reduce)') checks in code, a pattern web.dev’s guide walks through. Third-party embeds and app-injected effects bring their own motion your stylesheet can’t reach. And motion is one barrier among many: the same theme that ships a parallax hero usually ships missing labels, weak contrast, and keyboard traps too.

That’s the work behind our manual remediation service: fixing the actual theme code — motion preferences, markup, focus handling — instead of layering a widget over it. If you just pasted the snippet and want to know what else your theme is hiding, run the free scan — it takes about a minute and checks the code your visitors actually receive.