Respecting prefers-reduced-motion in a design system

WHAT THIS TESTS This assesses whether you treat reduced motion as a first-class architectural concern across both styling layers and scripting, rather than a one-off CSS hack, since users with vestibular disorders can be harmed by unchecked motion.

A GOOD ANSWER COVERS Start from system architecture. Define motion as tokens, for example duration and easing values, so behavior is centralized. For CSS, gate decorative animation and transition declarations so they only apply under the prefers-reduced-motion no-preference query, or provide a global reduce override that collapses durations to near zero while keeping essential state changes. The intent is to reduce or replace motion, not necessarily eliminate every transition; a fade can replace a large slide. For JavaScript-driven animation, read the same preference at runtime with window.matchMedia for prefers-reduced-motion reduce, branch so you either skip the animation or jump to the end state, and attach a change listener so the experience updates if the user toggles the setting mid-session. Animation libraries often expose a reduced-motion option that you wire to this value.

COMMON WRONG ANSWERS Disabling all motion entirely can remove helpful affordances and even break components that rely on a transitionend event to fire. Handling only CSS leaves JS-driven parallax or spring animations playing. Reading the preference once and never listening for changes ignores users who toggle it. Hardcoding durations everywhere makes the policy impossible to enforce centrally.

LIKELY FOLLOW-UPS How do you keep functionality when a transitionend callback never fires under reduce? How do essential motion, like a loading spinner, differ from decorative motion? How do you test this across browsers? Should reduce mean no motion or less motion?

ONE CONCRETE EXAMPLE A toast slides in over 300 milliseconds by default. Under prefers-reduced-motion reduce, the CSS collapses the slide to a quick opacity fade, and the JS that schedules auto-dismiss reads matchMedia to skip the spring entrance and place the toast directly, while still firing the same completion callback so dismissal timing is unaffected.