Implementing prefers-reduced-motion in Scroll-Driven Animations

prefers-reduced-motion needs more than a blanket animation: none when your site uses scroll-driven timelines or the View Transitions API. Both APIs involve properties and behaviors that the animation shorthand does not control — most critically animation-timeline, which drives scroll-linked and view-linked timelines independently. This guide gives you the exact overrides, a CSS custom-property architecture, and a practical implementation checklist, all within the broader Accessibility & Inclusive Motion Standards framework.

Pages in this section

prefers-reduced-motion override decision flow A flow diagram showing how a scroll-driven animation or View Transition is intercepted by the prefers-reduced-motion media query. The left branch shows CSS overrides resetting animation-timeline to auto; the right branch shows a JavaScript guard skipping startViewTransition and firing an aria-live announcement. prefers-reduced-motion : reduce? NO Run full animation or transition YES CSS override animation: none animation-timeline: auto JS guard skip startViewTransition() fire aria-live region Static or instant-swap state — no perceptible motion

Syntax reference

The three properties you must override for every scroll-driven or view-transition animation:

Property Default Reduced-motion override Why
animation — none Stops @keyframes playback and clears the shorthand
animation-timeline auto auto animation shorthand does not reset this; without it, scroll timelines keep running
animation-duration (on ::view-transition-*) browser default 0.01ms Collapses pseudo-element crossfades while preserving animationend event dispatch

The reason 0.01ms is used rather than 0ms: browsers including Chrome skip animationend and animationiteration events for zero-duration animations in some code paths. Using 0.01ms makes the animation imperceptible while keeping the event pipeline intact for JavaScript cleanup callbacks.

Minimal working example

A self-contained pattern that covers scroll-driven animations and the basic media-query structure with no dependencies:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<style>
  /* Motion design tokens */
  :root {
    --motion-duration: 400ms;
    --motion-easing: cubic-bezier(0.2, 0.8, 0.2, 1);
  }

  /* Scroll-driven reveal */
  .card {
    opacity: 0;
    transform: translateY(2rem);
    animation: reveal linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 60%;
  }

  @keyframes reveal {
    to { opacity: 1; transform: none; }
  }

  /* Reduced-motion override — two properties, not one */
  @media (prefers-reduced-motion: reduce) {
    :root {
      --motion-duration: 0.01ms;
    }

    *, *::before, *::after {
      animation-duration: var(--motion-duration) !important;
      animation-iteration-count: 1 !important;
      transition-duration: var(--motion-duration) !important;
      animation-timeline: auto !important; /* critical: removes scroll binding */
    }
  }
</style>
</head>
<body>
  <div style="height: 200vh; padding-top: 60vh;">
    <div class="card">Revealed on scroll</div>
  </div>
</body>
</html>

Under prefers-reduced-motion: reduce, the animation-timeline: auto !important rule resets every scroll-driven element back to a normal time-based timeline, and the near-zero duration then makes that time-based animation imperceptible.

Timeline scoping for reduced-motion overrides

animation-timeline has two forms relevant here: named scroll timelines declared with @scroll-timeline (deprecated) or scroll-timeline-name, and anonymous timelines using scroll() or view(). Both must be reset explicitly:

/* Named scroll timeline */
.progress-bar {
  scroll-timeline-name: --page-progress;
  animation: grow linear;
  animation-timeline: --page-progress;
}

/* Anonymous view timeline */
.section-reveal {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 30%;
}

/* Override both forms with a single rule */
@media (prefers-reduced-motion: reduce) {
  .progress-bar,
  .section-reveal {
    animation: none;
    animation-timeline: auto; /* resets named AND anonymous timelines */
    opacity: 1;
    transform: none;
  }
}

The animation-timeline: auto override works because auto is the initial value — it detaches any scroll-linked or view-linked source and returns the animation to the default document timeline. If there is no animation to run at all (because you also set animation: none), the animation-timeline value is moot, but setting it defensively prevents future regressions if animation is re-introduced without a matching override.

For patterns using animation-range entry and exit keywords, the range values are similarly irrelevant once animation-timeline: auto removes the scroll source, so no separate animation-range override is needed.

Compositor-safe properties

Knowing which properties remain on the compositor thread helps you understand what still runs — and what stops — when motion overrides are applied:

Property Compositor thread Main thread recalc Notes
transform Yes No Safe to animate; reset to none in reduced-motion
opacity Yes No Safe to animate; reset to 1 in reduced-motion
filter (blur, drop-shadow) Yes (Chrome/Edge) Partial (Firefox) Safe in Chrome; test in Firefox
clip-path No Yes Forces paint; avoid in scroll-driven animations
width, height, margin No Yes Forces layout; always main-thread
background-color No Yes Triggers style recalc each frame
will-change: transform, opacity — — Promotes layer; remove when animation ends

When animation-timeline: auto is set under prefers-reduced-motion, the compositor no longer receives scroll-position updates for those animations. The GPU layer allocated by will-change should also be released:

@media (prefers-reduced-motion: reduce) {
  .scroll-driven {
    will-change: auto; /* release promoted layer — not needed if no animation runs */
  }
}

Common implementation patterns

Pattern 1: CSS custom property architecture

Centralizing motion settings in custom properties lets one @media block control the entire design system:

:root {
  --motion-duration: 400ms;
  --motion-easing: cubic-bezier(0.2, 0.8, 0.2, 1);
}

@media (prefers-reduced-motion: reduce) {
  :root {
    --motion-duration: 0.01ms;
    /* easing is irrelevant at near-zero duration; keep the variable intact */
  }

  /* Disable scroll-driven timelines globally */
  *, *::before, *::after {
    animation-duration: var(--motion-duration) !important;
    animation-iteration-count: 1 !important;
    transition-duration: var(--motion-duration) !important;
    animation-timeline: auto !important;
  }

  /* Suppress View Transition pseudo-elements */
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation-duration: 0.01ms !important;
    animation-delay: 0ms !important;
  }
}

Pattern 2: Per-component override with cascade layers

When your project uses @layer, the accessibility override must sit in a layer with higher precedence than your component and utility layers, removing the need for !important:

@layer base, components, utilities, accessibility;

@layer accessibility {
  @media (prefers-reduced-motion: reduce) {
    .hero__parallax-layer,
    .section-reveal,
    .sticky-progress {
      animation: none;
      animation-timeline: auto;
      opacity: 1;
      transform: none;
    }
  }
}

Pattern 3: View Transition fallback with ARIA announcement

When motion is suppressed, route changes happen as instant DOM swaps. Screen readers need an explicit announcement because there is no visual transition to prompt attention:

async function handleRouteTransition(targetUrl) {
  const prefersReduced = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

  if (!prefersReduced && document.startViewTransition) {
    const transition = document.startViewTransition(() => {
      updateDOM(targetUrl);
    });
    await transition.finished;
  } else {
    updateDOM(targetUrl);
    // Announce the navigation to assistive technology
    const liveRegion = document.getElementById('transition-announcer');
    if (liveRegion) {
      liveRegion.textContent = `Navigated to ${document.title}. Content updated.`;
    }
  }
}

Keep the aria-live="polite" region in your base HTML so it is always present:

<div id="transition-announcer" aria-live="polite" aria-atomic="true"
     class="sr-only"></div>

Pattern 4: Focus management after instant transitions

When transitions are suppressed, programmatic focus must happen without a visual animation to guide the eye. The focus call is deferred one frame to guarantee the DOM mutation has committed:

function restoreFocusAfterTransition(targetElement) {
  const prefersReduced = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
  if (prefersReduced) {
    requestAnimationFrame(() => {
      targetElement.focus({ preventScroll: true });
    });
  }
}

preventScroll: true avoids a sudden viewport jump that would itself be a vestibular trigger.

Browser support and @supports guard

prefers-reduced-motion has near-universal support (Chrome 74, Firefox 63, Safari 10.1, Edge 79). The animation-timeline property it needs to override is newer:

Feature Chrome Firefox Safari Edge
prefers-reduced-motion 74 (2019) 63 (2018) 10.1 (2017) 79 (2020)
animation-timeline: scroll() 115 (2023) 110 (2023) 17.2 (2024) 115 (2023)
animation-timeline: view() 115 (2023) 114 (2023) 17.2 (2024) 115 (2023)
::view-transition-* pseudos 111 (2023) 131 (2024) 18 (2024) 111 (2023)

Use @supports to isolate scroll-driven animations from browsers that do not implement animation-timeline, so that in those browsers the baseline content is always visible and the prefers-reduced-motion override never needs to reset a property that was never set:

/* Baseline: always visible — never hidden by animation setup */
.scroll-reveal {
  opacity: 1;
  transform: none;
}

/* Enhancement: apply the animation only if the browser supports it */
@supports (animation-timeline: scroll()) {
  .scroll-reveal {
    opacity: 0;
    transform: translateY(2rem);
    animation: fade-up linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 60%;
  }

  @media (prefers-reduced-motion: reduce) {
    .scroll-reveal {
      animation: none;
      animation-timeline: auto;
      opacity: 1;
      transform: none;
    }
  }
}

Nesting the @media inside @supports ensures the override only applies in browsers where the animation was actually enabled — no orphaned animation-timeline: auto overrides on browsers that never used scroll timelines. For more on @supports progressive enhancement patterns, see the browser support and progressive enhancement guide.

Gotchas and failure modes

  1. Resetting animation without resetting animation-timeline: animation: none clears the keyframe name, duration, fill-mode, and other shorthand sub-properties, but it does not reset animation-timeline. A scroll-driven animation with animation: none and no explicit animation-timeline: auto may still receive scroll-position updates from the compositor, silently keeping the connection alive. Always pair animation: none with animation-timeline: auto.

  2. !important in the wrong layer: In a layered cascade (@layer), !important reverses layer precedence. An !important rule in base beats an !important rule in accessibility. Prefer placing reduced-motion overrides in the highest-precedence layer without !important, or use a global * { } block in a @layer that wins.

  3. View Transitions still snapshotting when only CSS duration is reset: Setting animation-duration: 0.01ms on ::view-transition-* pseudos stops the crossfade, but document.startViewTransition() still allocates GPU snapshot buffers for every element with a view-transition-name. On large DOM trees, this has measurable memory cost. Skip startViewTransition() in JavaScript entirely when prefers-reduced-motion: reduce is active.

  4. ARIA live regions not announcing on instant transitions: When the view transition is skipped and the DOM updates instantly, screen readers may not notice the content change because no focus shift or live region update was triggered. This is the silent failure most commonly missed in automated testing. Always explicitly update a aria-live region after an instant DOM swap.

  5. prefers-reduced-motion not updating at runtime: window.matchMedia(...).matches is a snapshot — if the user changes their OS motion preference while your SPA is open, the cached value stays stale. Use addEventListener('change', handler) on the MediaQueryList object to react to runtime changes, or re-query the value inside each transition handler.

  6. requestAnimationFrame focus timing: Calling element.focus() synchronously after an instant DOM swap can focus an element before React, Vue, or Svelte has committed its virtual-DOM diff. Wrapping in requestAnimationFrame (or queueMicrotask for micro-task level precision) guarantees the DOM is stable before focus is moved.

Performance checklist

  • Animate only transform, opacity, and filter — these are compositor-thread properties that do not trigger layout or paint recalc during scroll playback.
  • Set will-change: transform, opacity before animation begins; reset to will-change: auto when the animation is finished or when prefers-reduced-motion is active.
  • Use a single global @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-timeline: auto !important; } } rule as a safety net, then override per-component only for cases that need a non-zero fallback state.
  • Skip document.startViewTransition() in JavaScript rather than relying solely on CSS duration overrides — this prevents GPU snapshot allocation on large pages.
  • Keep concurrent view-transition-name assignments to the minimum set of elements that need morphing; each one allocates a GPU layer buffer even when the transition duration is zero.
  • Run document.getAnimations().filter(a => a.playState !== 'idle') in the DevTools console after emulating prefers-reduced-motion: reduce — the result should be an empty array.
  • Profile with the Performance panel; the Compositor track should show no animation events for scroll-driven elements while the preference is active.
  • Consider motion scaling rather than binary elimination for users who need reduced but not zero motion — continuous scaling keeps spatial context while respecting the OS preference.

Debugging and DevTools verification

  1. DevTools → Rendering tab → Emulate CSS media feature prefers-reduced-motion → set to reduce.
  2. Performance panel → record a scroll and a route change; verify the Compositor track shows no animation events for scroll-linked elements.
  3. Elements → Computed → confirm animation-timeline reads auto on any element that was previously scroll-driven.
  4. Console: document.getAnimations().filter(a => a.playState !== 'idle') — expect an empty array.
  5. Simulate a route change and verify the aria-live region’s text content updates.
  6. Lighthouse → Accessibility audit → confirm no motion-related violations.

For automated testing, Playwright’s page.emulateMedia({ reducedMotion: 'reduce' }) and Cypress’s cy.emulateMedia({ reducedMotion: 'reduce' }) both emulate the preference before page load, letting you assert that animation-timeline computes to auto and that ARIA live regions receive the expected text after navigation.

Up: Accessibility & Inclusive Motion Standards