prefers-reduced-motion Contracts

prefers-reduced-motion is an OS-level accessibility setting that browsers expose as a media query. About 25% of iPhone users have it enabled (Apple 2021 data). Ignoring it means your animated hero, page transitions, and skeleton shimmer are running uninvited for a significant portion of your audience.

The prefers-reduced-motion: no-preference media query targets users who have NOT set reduce motion — use it for "motion-optional" animations that are off by default:

/* Animation off by default; opt-in with no-preference */
.card { transition: none; }
@media (prefers-reduced-motion: no-preference) {
  .card { transition: transform 0.2s ease; }
}

Technically, the parallax effect used a scroll event listener updating transform: translateY() on three background layers, plus a CSS @keyframes animation on the logo running on page load. Neither was wrapped in a prefers-reduced-motion check. The OS setting was set; the site simply ignored it.

This is a WCAG 2.1 SC 2.3.3 (Animation from Interactions, AAA) violation. The standard requires that motion triggered by interaction can be disabled — and "interaction" includes scrolling.

Two changes were made. First, the CSS @keyframes animation on the logo was moved inside a no-preference guard. Second, the JavaScript scroll handler was gated: it reads window.matchMedia('(prefers-reduced-motion: no-preference)').matches before applying any transform. The fallback for reduced-motion users: a subtle opacity fade on scroll instead — communicates the same layered depth without vestibular risk.

/* Before: always animates */
.hero-logo { animation: bounce-in 0.6s ease; }

/* After: opt-in for non-reduced users */
@media (prefers-reduced-motion: no-preference) {
  .hero-logo { animation: bounce-in 0.6s ease; }
}

/* Reduced-motion alternative */
@media (prefers-reduced-motion: reduce) {
  .hero-logo { opacity: 0; animation: fade-in 0.2s ease forwards; }
}

The demo simulates the reduce-motion state. In real usage, the CSS media query reads the actual OS setting — no JavaScript needed for the basic case.

For JavaScript-driven animations, read the preference at runtime:

// Vanilla JS — check before animating
const prefersReduced = window.matchMedia(
  '(prefers-reduced-motion: reduce)'
).matches;

if (!prefersReduced) {
  element.animate([
    { transform: 'translateY(-20px)', opacity: 0 },
    { transform: 'translateY(0)', opacity: 1 }
  ], { duration: 300, easing: 'ease' });
}

// React hook pattern
function useReducedMotion() {
  const [reduced, setReduced] = React.useState(
    () => window.matchMedia('(prefers-reduced-motion: reduce)').matches
  );
  React.useEffect(() => {
    const mq = window.matchMedia('(prefers-reduced-motion: reduce)');
    const handler = (e) => setReduced(e.matches);
    mq.addEventListener('change', handler);
    return () => mq.removeEventListener('change', handler);
  }, []);
  return reduced;
}

Implementation notes:

• The change event fires if the user changes OS settings while the page is open — listen and react
• Framer Motion's useReducedMotion() does this for you in React
• Test in macOS: System Settings → Accessibility → Display → Reduce Motion
• WCAG 2.3.3 is AAA — but motion-related harm is real at any compliance level; treat it as AA in practice