Why prefers-reduced-motion matters

Animation on the web serves three main purposes: giving users feedback that their actions were received, making experiences feel faster by shaping perception, and providing purely decorative effects like animated gradients or parallax scrolling. While many users enjoy these effects, for others they are distracting, disorienting, or outright nauseating. Parallax scrolling, in particular, can trigger vestibular disorders because background and foreground elements move at different rates. Reactions range from dizziness to migraines, and in severe cases, require bed rest.

The CSS media query prefers-reduced-motion gives developers a way to detect whether the user has asked their operating system to minimize the amount of animation or motion it uses, letting sites serve a calmer variant to those users.

Turning off motion at the operating system level

Operating systems have long included accessibility settings to reduce motion, such as macOS Mojave's Reduce motion and Android Pie's Remove animations. When these preferences are enabled, the OS suppresses decorative effects like app-launching animations. Well-behaved applications honor this setting too, and so should websites.

Media Queries Level 5 brings this preference to the web. The prefers-reduced-motion media query takes one of two values:

  • no-preference: The user has made no preference at the OS level. Evaluates as false in a boolean context.
  • reduce: The user's OS setting asks interfaces to minimize movement or animation, ideally removing all non-essential motion.

Checking the preference from CSS and JavaScript

Like all media queries, prefers-reduced-motion can be tested from either a CSS or a JavaScript context. Consider an attention-catching "vibrate" animation on an important sign-up button: a responsible approach plays that animation only for users who have not opted out of motion and whose browsers support the media query.

For CSS-driven animations, the browser automatically applies the correct rules when the user preference changes. JavaScript animations behave differently: you must listen for the change yourself and stop or restart your in-flight animations manually. Also remember that the parentheses around the media query are required:

Don't: matchMedia("prefers-reduced-motion: reduce")

Do: matchMedia("(prefers-reduced-motion: reduce)")

Choosing static images inside <picture>

The media attribute on <source> elements inside a <picture> tag can also respond to the preference. This is useful for animated AVIF, WebP, or GIF files: when (prefers-reduced-motion: no-preference) is true, the animated version is displayed; otherwise, a static image is shown instead.

Discovering the preference at request time

For performance-sensitive scenarios, the Sec-CH-Prefers-Reduced-Motion client hint header lets servers receive the user's motion preference at request time. This allows the server to inline the appropriate CSS from the start, rather than shipping styles the user won't use.

What to expect as user preference queries evolve

Motion preference is just one of several user-preference media queries being standardized by the CSS Working Group. Others include prefers-color-scheme for light or dark themes, prefers-reduced-transparency, prefers-contrast, and inverted-colors. Respecting these preferences is increasingly a baseline expectation for modern websites, not a nice-to-have.

Forcing reduced motion everywhere

Not every site will honor prefers-reduced-motion, or perhaps not to the degree you'd like. For users who want to stop motion everywhere regardless of a site's code, a user style sheet injected via a browser extension can drastically shorten all animation and transition durations until they are unnoticeable.

This is a safer approach than animation: none !important;, which can break sites that depend on the animationend event for their logic. Note that even this CSS-level hack cannot stop motion driven by the Web Animations API, so it's wise to disable the override when a site misbehaves.