A chart's transition animation should back off when the operating system's reduced-motion setting is on

What it is

Major operating systems and browsers offer a "reduce motion" setting, and enabling it is the user's declaration "I need less motion." A chart's transition animations (positional animations on data updates, fly-in/fly-out elements, parallax scrolling) should read this preference and respond: in reduced mode, replace large displacements with cross-fades or direct switches. Respecting the system preference means the user declares the need once and it takes effect system-wide—provided applications actually read it.

Why it happens

Responding to the preference works through conditional motion strategy: technically, detect the setting via the media query (prefers-reduced-motion) or system API, then switch motion plans accordingly. The design crux is the correct semantics of "reduce": reduced motion does not mean removing all feedback—vestibular-stimulating motion (displacement, scaling, parallax) is replaced or removed, while low-motion-stimulus transitions like opacity fades can usually remain, since they convey state change without provoking motion discomfort. A fully silent switch (no transition at all) is an acceptable simplification but may lose the "old-new continuity" cue (the same group's jumping-distraction knowledge); cross-fade is the balance point between "no motion" and "perceptible continuity." Common implementation mistakes: writing the preference check as a one-time read that misses runtime changes (the user enabling reduce motion mid-session should take effect immediately), and handling CSS animations while missing JS-driven ones (chart libraries' animation engines often bypass CSS media queries)—the latter requires explicitly passing the preference into the animation engine.

Where it stops holding

The reduced-motion boundary is "non-essential motion": motion that is part of the interaction itself (a dragged element following the pointer, direct-manipulation feedback from a slider) is intrinsic and not subject to reduction; what is reducible is decorative and transitional motion. The motion-information-equivalence principle still applies (the same group's static equivalents): if reduced mode removes the only route to information the motion carried (progress shown by an animation), a text or static alternative is required. A note on the default value: no preference set does not mean "the user loves all motion," only "the user has not declared"—design should keep even full-motion mode within comfort bounds, treating the preference as an enhancement for special needs rather than the bar to clear.

Applying it

• Wire chart libraries and custom animations uniformly to prefers-reduced-motion: in reduced mode, replace displacement transitions with fades or direct switches.
• Handle runtime preference changes (listen for change events) so reduce motion takes effect immediately.
• Audit JS-driven animation engines (canvas chart libraries) to ensure the preference signal reaches them, not relying on CSS alone.
• Verification: enable the system's reduce motion and observe the chart's data-update transitions; any remaining large-displacement animation means the preference is not being honored.

Related

• Same group: U11.03.1 Auto-playing animations must be pausable and support frame stepping · U11.03.2 States existing only during playback need static equivalents · U11.03.3 Rapid flashing and high-contrast motion can trigger discomfort or seizures · U11.03.5 Too-short animation duration leaves intermediate states unreadable
• Nearby: U11.03.3 Rapid flashing and high-contrast motion can trigger discomfort or seizures · U7.09.1 Data jumping disrupts reading
• Search terms: prefers-reduced-motion · reduced motion · motion accessibility