Actually respecting prefers-reduced-motion

prefers-reduced-motion isn't a niche accessibility checkbox — it's a real operating-system setting that people turn on because motion genuinely causes them physical discomfort: vestibular disorders, migraines, motion sickness triggered by parallax and scaling effects. A site that ignores it isn't just failing an audit, it's making itself unusable for a specific set of real visitors. And "ignoring it" is often not a decision anyone made on purpose — it's just what happens by default, because nothing forces you to check.

ThesettingexistsattheOSlevel.Thebugisn'tforgettingitexists—it'scheckingitonceonmountandmissingeveryanimationaddedafterthat.

That toggle simulates the two states this site actually renders — not a CSS trick, a real branch in the component. With motion on, tapping the card plays a spring-driven scale-and-rotate entrance. With motion "reduced," the identical card just appears at its resting state, no animation at all, not even a fast version of the same motion. A shortened animation still moves; for someone who's turned this setting on, movement is the problem, not the duration.

tsx
const reduceMotion = useReducedMotion(); // Framer Motion hook

if (reduceMotion) {
  return <div className={className}>{content}</div>;   // no motion props at all
}

return (
  <motion.div
    initial={{ opacity: 0, scale: 0.4, rotate: -20 }}
    animate={{ opacity: 1, scale: 1, rotate: 0 }}
    transition={{ type: 'spring', stiffness: 260, damping: 16 }}
  >
    {content}
  </motion.div>
);

A single top-level check — read the media query once in a layout, store it in context — misses two things a per-component check doesn't. First, useReducedMotion() from Framer Motion subscribes to the media query live, so a visitor who changes the OS setting in another window sees this site respond immediately, without a reload. Second, and more important: every animated component on this site — the drag seam, the sheet stack, the kinetic type, the parallax scene — makes its own independent decision about what its reduced-motion fallback should look like, because "remove the motion" means something different for a spring-driven drag handle than it does for a scroll-pinned sequence. A single global switch can turn animation off; it can't know what each component should show instead.

The failure mode isn't usually "we never check prefers-reduced-motion" — it's checking it in the first three components you build and forgetting on the fifteenth. There's no compiler error for a missing useReducedMotion() call; the component just works fine for the vast majority of visitors who never turn the setting on, and silently fails the ones who did. The only real defense is treating it as a required part of writing any new motion component, the same way you wouldn't ship an image without an alt attribute — not a pass you do at the end.