prefers-reduced-motion: Respect Reduced Motion in CSS

Reduced motion is not simply a faster version of the same animation. A large zoom completed almost instantly can be more abrupt than the original effect. The goal is to preserve the information an effect communicates while removing movement that a user has asked to avoid.

Classify movement by purpose

Inventory entrances, parallax, progress indicators, autoplay illustrations, and navigation effects. Label each as informational, decorative, or directly controlled. An upload still needs progress feedback; a decorative background does not need to drift. This classification creates a motion policy rather than a collection of emergency overrides.

For an animated gradient, the reduced version can keep exactly the same colors without moving the background. For a drawer, show the destination immediately while retaining focus management. For a chart reveal, display the complete chart and its labels. Write these replacements before adjusting any durations.

Use the gradient generator to prepare a static visual reference before tuning movement. Export the relevant values into your prototype and keep them fixed during the first timing comparison. This separates appearance decisions from playback behavior and makes changes easier to judge. The tool prepares the artwork or layout; the animation code still owns the timeline.

Define a baseline state that works without animation. Check that its content, controls, and status remain understandable when no intermediate frames are shown. A successful effect connects valid states; it does not hide essential information inside a brief moment that users must catch.

Prefer a static default in CSS

A static-first stylesheet is easy to audit: the ordinary rule describes the useful destination, and a no-preference query adds optional movement. This avoids leaving elements invisible when an animation declaration is removed. It also makes the unsupported-query case predictable.

Do not use a global near-zero animation duration as your only strategy. That can trigger rapid flashes, interfere with event assumptions, and retain large spatial changes. Scope decisions to the effect. This example leaves the background attractive but motionless unless the user allows movement.

.hero { background-position: 50% 50%; }
@media (prefers-reduced-motion: no-preference) {
.hero { animation: drift 12s ease-in-out infinite alternate; }
}
@keyframes drift {
from { background-position: 35% 50%; }
to { background-position: 65% 50%; }
}

Treat this example as a focused implementation pattern, not a complete component. Connect its selectors and lifecycle to your actual application state, and preserve the same outcome when playback is skipped. For terminology and API details, consult MDN’s reduced-motion reference.

Apply the same policy to JavaScript

CSS queries do not automatically stop canvas, Web Animations API, or library-driven effects. Read the same media query through matchMedia and listen for its change event. If the preference switches while an effect is running, cancel nonessential movement and deliberately apply its meaningful end state.

Be careful with cancellation semantics. Canceling an animation may restore its underlying style rather than keep the last frame. Update the real component state so the final visual result does not depend on fill behavior. Remove query listeners during teardown, especially in single-page applications where components can mount repeatedly.

Use one-variable comparisons during review. Hold the distance constant while changing duration, then hold duration constant while changing the curve. Otherwise a reviewer may prefer the smaller movement rather than the timing change you intended to evaluate. Capture the chosen values beside the prototype so the production version does not rely on visual guesswork.

Related motion and animation guides can help place this effect in a wider motion vocabulary. Consistency should mean similar behavior for similar tasks, not forcing every component to travel the same distance or share one universal duration.

Retain feedback without substituting noise

Replace a spinning decorative mark with a static status label, not a blinking one. For determinate tasks, a numeric percentage or a nonanimated progress element can communicate completion. Avoid announcing every tiny percentage change to screen readers; report meaningful milestones or completion according to the task.

Reduced motion also does not authorize removing loading feedback altogether. A frozen spinner with no text can look broken. Pair the static treatment with a clear description such as loading results, and keep error and success states distinguishable. A brief opacity change may be acceptable in some contexts, but test it rather than treating every fade as harmless.

Review the relevant platform behavior in W3C guidance on animation from interactions. Where support is incomplete, prefer an immediately usable final state over a complicated fallback that introduces its own timing bugs. Feature detection should gate the enhancement, not access to the underlying task.

Test live changes and nested effects

Test the operating-system preference before loading the page and again while the page is open. Verify that a long-running illustration stops, newly inserted content does not animate, and changing back does not replay old entrances unexpectedly. Include embedded runtimes and third-party components in this audit.

A useful acceptance checklist includes route changes, menus, background loops, scroll effects, and loading states. Search source code for keyframes, animate calls, animation-frame loops, and autoplay options. Visual inspection alone may miss a canvas effect below the fold or an animation that starts only after a network response.

Run a production-content pass after the isolated demo succeeds. Use long labels, realistic images, narrow containers, and enough neighboring elements to expose overlap. Repeat with keyboard navigation and at least one touch device. A demonstration that works only when the pointer stays still is not a reliable interaction.

Record a short before-and-after trace using the guidance in web.dev’s animation guide. Compare the same interaction with motion enabled and disabled. Look for repeated layout, large paint regions, and delayed input rather than judging performance solely from a smooth recording on a powerful development machine.

Keep a concise acceptance note with the trigger, final state, cancellation policy, and reduced-motion behavior. The broader development collection is useful for implementation context, but the acceptance note should be specific enough that another developer can reproduce this effect without watching a video.

Key takeaways

• Define alternatives, not just shorter durations.
• Coordinate CSS, JavaScript, canvas, and embedded runtimes.
• Preserve status and final state when movement is canceled.
• Test preference changes without requiring a page reload.