How to Respect prefers-reduced-motion

For some people, movement on the screen can be distracting, uncomfortable, or even physically unpleasant. That is why browsers support the prefers-reduced-motion media feature: it lets a website detect when a user has asked their device to reduce non-essential motion. MDN describes it as a way to detect whether the user has enabled a system setting to minimize motion, and web.dev notes that the preference exists specifically to help reduce problematic animation on the web.

If you build SVG animations, this matters a lot. Many common effects in SVG and UI animation—like large movement, zooming, parallax, or dramatic transitions—can be exactly the kinds of motion some users want to avoid. MDN’s transform docs specifically warn that scaling and zooming can be problematic for accessibility, and WCAG’s guidance on motion from interactions says motion animation triggered by interaction should be able to be disabled unless it is essential.

What prefers-reduced-motion really means

A common mistake is thinking reduced motion always means no motion at all.

That is not always true. web.dev explicitly points out that reduced motion should not automatically mean removing every transition, because motion can still help communicate what changed. In many cases, the better approach is to replace strong movement with something calmer, like a quick fade or a simpler state change.

That is the right mindset for SVG too. If a full sliding, rotating, or drawing animation feels too intense, you do not always need to remove it completely. Sometimes the better solution is to reduce the distance, shorten the effect, or swap it for a subtle opacity change. MDN’s accessibility guidance for media queries recommends providing an experience with fewer animations and transitions for users who have asked for reduced motion.

The simplest way to support it in CSS

The most direct way is with a media query.

.animated-icon {
  animation: float 1.8s ease-in-out infinite;
}

@media (prefers-reduced-motion: reduce) {
  .animated-icon {
    animation: none;
  }
}

This works because prefers-reduced-motion is a CSS media feature with values like reduce and no-preference. MDN documents those values directly, and W3C’s WCAG technique C39 specifically recommends using this kind of CSS query to prevent motion for users who request it.

A better pattern: reduce, do not always remove

In real interfaces, a softer alternative is often better than turning everything off.

For example, instead of moving an SVG icon across the screen on hover, you might keep the interaction but replace the movement with a small opacity change.

.icon {
  transition: transform 180ms ease, opacity 180ms ease;
}

.button:hover .icon {
  transform: translateX(4px);
  opacity: 0.85;
}

@media (prefers-reduced-motion: reduce) {
  .icon {
    transition: opacity 120ms ease;
  }

  .button:hover .icon {
    transform: none;
    opacity: 0.85;
  }
}

This is often a much more respectful solution. The interface still feels responsive, but the stronger movement is removed. That aligns well with web.dev’s recommendation to offer an alternate, more subtle animation instead of assuming the only options are “full motion” or “nothing.”

Apply it to the kinds of motion most likely to cause problems

Not all animation is equally risky.

Large-scale movement, zooming, parallax-like effects, fullscreen transitions, and aggressive scroll-linked motion are much more likely to cause discomfort than a quick fade or a simple color change. MDN’s transform page calls out scaling and zooming as common migraine triggers, and web.dev highlights fullscreen animation as a common reason users request reduced motion.

So if you are working on SVG animation, the first things to review are usually:

• big entrance animations
• looping motion that never stops
• hover effects with strong movement
• line draws or path reveals that are long and dramatic
• page or component transitions with sliding and scaling

Those are the places where reduced-motion support matters most. This follows the spirit of WCAG’s guidance to eliminate unnecessary motion effects and support user preferences for motion.

Do not forget JavaScript-driven animation

If your animation is controlled by JavaScript, you should respect the same preference there too.

W3C’s WCAG technique SCR40 specifically covers using the reduced-motion query in JavaScript to adjust or disable scripted animations. In practice, that usually means checking the media query with matchMedia() and changing your animation behavior accordingly.

const reducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)');

if (reducedMotion.matches) {
  // Use a simpler effect or skip motion-heavy animation
} else {
  // Run the full animation
}

This is especially important if you use JavaScript libraries for SVG timelines, scroll-triggered effects, or interactive transitions. CSS alone will not protect users if the motion is being driven elsewhere.

Reduced motion is not your only accessibility tool

Supporting prefers-reduced-motion is important, but it is not the whole story.

MDN’s animation docs also recommend providing a mechanism to pause or disable animation, and WCAG’s guidance on moving content explains that ongoing motion can be distracting and should sometimes be pausable or stoppable. That matters especially for looping decorative animation, autoplaying effects, or anything that keeps moving while the user is trying to read or interact.

So the best approach is usually layered:

• respect the system preference
• avoid unnecessary motion in the first place
• provide a calmer fallback when possible
• consider pause or disable controls for persistent animation

That creates a much more accessible result than relying on one media query alone.

A good rule for SVG websites

If motion is decorative, reduce it aggressively.

If motion helps explain a state change, keep the meaning but simplify the effect.

If motion is essential to understanding the interface, make sure it is as restrained as possible and does not rely only on dramatic movement. This matches current accessibility guidance: support user preferences, eliminate unnecessary motion, and preserve clarity without forcing strong visual movement.

Final thoughts

Respecting prefers-reduced-motion is not just about compliance. It is about designing motion more thoughtfully.

A good animation system does not assume everyone wants the same experience. It adapts. It keeps what is helpful, removes what is excessive, and makes the interface easier to use for more people. For SVG animation, that usually means replacing dramatic movement with simpler transitions, checking both CSS and JavaScript-driven motion, and treating reduced motion as part of the design from the start, not as an afterthought.