@media (prefers-reduced-motion)

A user with a vestibular disorder visits your site. Your hero section has a parallax scroll effect — layers moving at different speeds as the page scrolls. They've turned on "Reduce Motion" in their OS settings, but your CSS ignores it. Within seconds, they're dizzy. They close the tab.

The fix is four lines of CSS. The prefers-reduced-motion media query reads the OS setting and lets you serve different styles to users who've asked for less motion. Ignoring it isn't a UX choice — it's an accessibility failure.

Strategy 1: no-preference guard (conservative) — animations only run when the user has not set a motion preference. Motion is off by default; the OS preference to "no preference" enables it.

/* ✅ Strategy 1: only animate when no preference is set */
@media (prefers-reduced-motion: no-preference) {
  .hero {
    animation: slideIn 0.6s ease-out;
  }
  .card {
    transition: transform 0.2s ease;
  }
}

Strategy 2: reduce override (progressive) — animations are on by default; the reduce preference disables them. Requires a comprehensive override for every animation.

/* Strategy 2: animate normally, override in reduce */
.hero {
  animation: slideIn 0.6s ease-out;
}
.card {
  transition: transform 0.2s ease;
}

@media (prefers-reduced-motion: reduce) {
  .hero { animation: none; }
  .card { transition: none; }
  /* must remember every animated element */
}

A design team built an onboarding flow for a productivity app. Three animated arrows guided users through the steps: arrow 1 pointed to "Create a workspace," arrow 2 faded in to point to "Invite your team," arrow 3 appeared last to point to "Import your data." The sequence was clear, engaging, and well-tested. Before launch, a developer added @media (prefers-reduced-motion: reduce) { animation: none } — a one-line fix that seemed to handle accessibility.

What users with Reduce Motion enabled actually saw: all three arrows visible simultaneously, stacked in the same position, all pointing to the same UI area at once. The CSS had removed the animation timing — which was the only mechanism that gave each arrow its separate moment. Without the animation, all three rendered at full opacity in their final positions, overlapping and illegible. The "accessible" version was less usable than having no fallback at all.

The correct reduced-motion version replaced the three animated arrows with a static numbered list: "1. Create a workspace, 2. Invite your team, 3. Import your data." The animated version became the enhancement; the static list became the base layer. Users with Reduce Motion enabled received a clear, sequential, fully comprehensible onboarding experience without motion of any kind.

The implementation used the no-preference guard strategy: the animated elements only rendered inside @media (prefers-reduced-motion: no-preference). The static list was always in the DOM, hidden by CSS only when motion was permitted. This meant the animated version was an enhancement layered on top of working content — the correct architecture for any progressive enhancement.

"No guard" shows a slide animation that runs regardless of your OS motion setting. "Motion safe" wraps the animation in a no-preference query — if your OS has Reduce Motion on, no animation plays. Toggle your OS setting (System Preferences → Accessibility → Motion) to see the difference.