Designing for Reduced Motion

The prefers-reduced-motion media query is well understood as a compliance mechanism: detect the preference, strip the animations, done. What is less commonly understood is that reduced motion is a design problem, not a CSS problem. The challenge is not suppressing transitions — it is ensuring that an interface designed around motion still communicates clearly when that motion is absent.

The compliance approach vs the design approach

The compliance approach treats reduced motion as subtraction: take the existing animated interface, remove the animations, verify nothing breaks. This produces an accessible interface in the minimum technical sense, but often a degraded experience — state changes that were communicated by motion are now communicated by nothing, sequences that relied on timing now feel abrupt, and onboarding flows designed around animation reveal their informational dependence on motion.

The design approach starts from a different premise: the static interface is a first-class design. Build the interface to communicate clearly without any animation. Then identify the specific transitions and sequences where motion adds genuine clarity — state changes that are faster to perceive through animation than through colour or text, spatial relationships that motion reveals without requiring description. Those are the animations worth adding.

This inversion — static first, motion as enhancement — produces a reduced-motion experience that is not a stripped-down version of the animated one. It is the foundation the animated version is built on.

What animation communicates, and what replaces it

Before deciding what to remove under reduced motion, identify what each animation is communicating:

Continuity — two views contain the same object. A shared-element transition shows it is the same element changing context. The static replacement: show it in both views with the same visual treatment. The user connects them through visual recognition rather than watched movement.

State change — a control moved from one state to another. A toggle animation shows the direction of the change (on to off). The static replacement: change the colour, icon, and label simultaneously. Make the new state visually unambiguous without relying on the motion between states.

Spatial relationship — a panel slides in from the right, implying it lives to the right of the current view. The static replacement: a breadcrumb, a back button, or a clear heading that names the location. State the spatial context in language rather than demonstrating it in motion.

Hierarchy and sequence — elements stagger in, reinforcing that items later in the sequence are subordinate. The static replacement: use size, weight, and position to communicate hierarchy statically. The order of appearance in the DOM establishes sequence.

Progress — a progress bar fills, a loading indicator spins. These communicate something is happening, not spatial motion. Keep them under reduced motion. A static progress indicator communicates nothing; even a simple colour fill without animation is preferable to removal.

Populations who need reduced motion

Two distinct populations benefit from reduced motion, and they have different needs:

Vestibular disorder users are affected by spatial motion — translation, rotation, scale, and parallax. These trigger balance system responses: dizziness, nausea, and sometimes vertigo severe enough to make an interface unusable. For this group, the critical motion to remove is spatial. Opacity transitions, colour changes, and simple cross-fades are generally safe — they change properties without moving anything in space.

Cognitive and attention considerations include users who are distracted by any animation, or who find motion increases cognitive load in contexts requiring concentration — data-dense dashboards, form completion, reading. For this group, even opacity transitions may be unwanted. Some products offer a “minimal animation” mode alongside the system’s reduced-motion setting, giving users more granular control.

The prefers-reduced-motion: reduce query serves both groups with a single signal. Design the reduced-motion experience to serve the vestibular case (remove spatial motion, preserve opacity and colour). If the product serves a population with higher attention or cognitive sensitivity, consider a separate product-level setting.

Designing two modes intentionally

The highest-quality motion design produces two parallel experiences that are each complete:

The standard experience uses motion where it adds genuine clarity — entrance sequences that orient the user to a new context, state transitions that confirm actions, spatial navigation that maintains location awareness. Every animation has a communicative purpose; decorative motion is absent.

The reduced experience communicates the same information through static means — labels, colour, position, and text make every state and relationship explicit. Spatial motion is replaced with instant state changes or opacity-only transitions. The information is intact; the modality is different.

When these two modes are designed in parallel from the start, the reduced experience is not a stripped interface. It is the interface that the motion enhances, not depends on.

Testing the reduced-motion experience as a design artefact

The test for a well-designed reduced-motion experience is to use the interface with the OS reduced-motion setting enabled for an extended period — not just check that nothing breaks. Does every state change communicate clearly without motion? Is it obvious what just happened after every interaction? Does the absence of entrance animations leave the user disoriented, or does the static layout provide sufficient orientation?

If the answers reveal failures — state changes that are ambiguous, spatial contexts that are unclear, sequences that lose meaning — those are design problems that need design solutions, not CSS adjustments. Add a label, strengthen colour contrast, make the before/after states more visually distinct.

Enable reduced motion for testing on macOS at System Settings → Accessibility → Display → Reduce Motion. On iOS at Settings → Accessibility → Motion → Reduce Motion. Chrome and Firefox DevTools expose it in the Rendering panel under “Emulate CSS media feature prefers-reduced-motion.”

The takeaway

Reduced motion is not a compatibility mode. It is a design mode that should be as well-considered as the animated version. Start with a static interface that communicates correctly without animation. Add motion where it serves communication. Design the reduced-motion experience explicitly, not as a residue after stripping CSS. Test it as a complete experience, not as an absence of something. The motion system in the previous article provides the technical vocabulary; this article provides the design frame.