prefers-reduced-motion

Chrome, Firefox and Safari have all supported the query for a year, and the code is shorter than the argument about whether to bother.

#css #accessibility #small-print

---

Somebody has already told their operating system that motion makes them sick. The browser will pass that along if you ask.

motion.css

@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;
  }
}

CSS

That blanket version is crude and I use it anyway because in practice the alternative is nothing at all. It goes to near-zero instead of none because some code waits on animationend and never hears it if the animation doesn’t run.

For a while I got this wrong and thought it was about tasteful fades. It isn’t.

The animations that cause actual harm are the large ones: parallax, full-screen scroll-jacking, a big element flying across the viewport, anything with real distance in it. A 150ms fade on a button is nobody’s problem. A hero that moves at a different rate from the page is somebody’s whole afternoon.

So the honest answer is to do both. Run the blanket query, then go through anything on the page that moves more than a few pixels and ask whether it earns its distance.

Reduce isn’t remove. The user asked for less, not for a static document. A cross-fade in place of a slide is usually the right answer if you have time to do it properly.