Reduced Motion, Not Reduced Quality: prefers-reduced-motion Patterns That Still Feel Premium
Respecting motion preferences does not mean gutting the experience. Here are patterns that feel considered in both states.
The Binary Problem
Most implementations of prefers-reduced-motion treat it as an on/off switch. When the media query matches, all animations and transitions are disabled. The site goes from fluid and polished to flat and instant.
This is technically compliant. It satisfies WCAG 2.3.3 Animation from Interactions because motion is removed. But it creates a second-class experience for people who have the preference enabled. They get a version of the site that feels unfinished, like the design was built around animation and then the animation was turned off.
The better approach is to design two motion states: full motion and reduced motion. The reduced-motion state should not be an absence of design. It should be an alternative design that communicates the same transitions, hierarchy changes, and state updates through different means.
Who Uses Reduced Motion
As of 2026, roughly 25 to 30% of visitors have prefers-reduced-motion: reduce enabled, based on aggregate analytics across the studio sites we maintain. That number is higher than most developers expect.
Not all of those users have vestibular disorders. Many enable reduced motion because:
- They find constant animation distracting
- Their device is slow and animations stutter
- They prefer a calmer screen environment
- The OS-level setting was enabled by default or during initial setup
Regardless of the reason, these visitors deserve an experience that feels intentional, not degraded.
The Replace, Don't Remove Pattern
Instead of removing animation entirely, replace motion-based transitions with non-motion alternatives:
Full motion: A card entrance animation that slides up and fades in over 300ms.
Reduced motion: The same card appears immediately with a subtle opacity fade over 150ms.
Full motion: A page transition that slides the old page out and the new page in.
Reduced motion: A crossfade between pages over 200ms.
Full motion: A scroll-triggered parallax effect on a hero image.
Reduced motion: The hero image is static. No parallax.
Full motion: A hover effect that scales an image up 5% with a smooth transition.
Reduced motion: A hover effect that changes the image opacity from 90% to 100%.
The key principle: opacity transitions and instant state changes are generally safe for reduced-motion preferences. Transform-based motion (translate, scale, rotate) and continuous animation (parallax, marquees, looping) are what triggers discomfort.
Implementation Pattern
Start with the full-motion version as the default, then use the media query to override:
```
.card {
opacity: 0;
transform: translateY(20px);
transition: opacity 0.3s ease, transform 0.3s ease;
}
.card.visible {
opacity: 1;
transform: translateY(0);
}
@media (prefers-reduced-motion: reduce) {
.card {
opacity: 0;
transform: none;
transition: opacity 0.15s ease;
}
.card.visible {
opacity: 1;
}
}
```
In the reduced-motion version, the transform is removed entirely. Only the opacity transition remains, and it is faster. The card still has a visible entrance (fading in), but the spatial movement is eliminated.
Patterns That Work in Both States
Some design patterns naturally work well with and without motion:
Color transitions. Hover and focus states that change background color, border color, or text color via CSS transitions are motion-safe. A 150ms color transition is imperceptible as "motion" but provides clear state feedback.
Opacity changes. Fading elements in and out is the safest transition. It communicates state change without spatial movement. Keep the duration short (100 to 200ms).
Instant state changes. For interactive elements like toggles, tabs, and accordions, an instant state change (no transition at all) is perfectly acceptable in the reduced-motion state. The state feedback is still clear because the visual output changes.
Scale on hover (small). A very subtle scale change (1 to 1.02) on hover is generally acceptable even in reduced-motion mode because the spatial displacement is minimal. But this is subjective, and the safest approach is to replace it with an opacity or color change.
Patterns to Replace
Scroll-triggered entrance animations. These are the most common motion pattern on portfolio sites. Elements slide in from the bottom, sides, or with a parallax offset as the user scrolls. In reduced-motion mode, these elements should simply be visible from the start. No staggered entrance, no delayed reveal.
Page transitions. Slide or morph transitions between pages should be replaced with instant navigation or a brief crossfade. As we discussed in our motion article, page transitions are one of the highest-risk motion patterns for accessibility.
Loading animations. Spinning loaders, progress bar animations, and skeleton screen pulses should be simplified. A static progress indicator or a non-animated skeleton screen communicates the same state without continuous motion.
Background video. Autoplaying video should be paused or replaced with a static image when reduced motion is preferred. This is a significant change for some brand sites but essential for users who find continuous background motion disorienting.
Marquees and scrolling text. Any continuously scrolling text or image strip should be paused. Provide a static view of the content instead.
Testing Reduced Motion
In the browser
Chrome DevTools lets you emulate prefers-reduced-motion: reduce without changing your OS settings. Open the Rendering tab and select "Emulate CSS media feature prefers-reduced-motion: reduce."
On macOS
System Settings > Accessibility > Display > Reduce motion
On iOS
Settings > Accessibility > Motion > Reduce Motion
On Windows
Settings > Accessibility > Visual effects > Animation effects (turn off)
Test both states side by side. The reduced-motion state should feel deliberate, not broken.
The Design Process
Reduced motion should be part of the design specification, not an afterthought in development.
When designing a component with animation:
- Design the full-motion version
- Design the reduced-motion version
- Document both in the design system
- Specify which CSS properties change in each state
This prevents the common situation where the developer receives a comp with elaborate scroll animations and has to improvise a reduced-motion fallback under time pressure. The fallback is always worse when it is improvised.
FAQ
Does prefers-reduced-motion affect CSS scroll-behavior: smooth?
Yes. When reduced motion is preferred, scroll-behavior: smooth should be overridden to scroll-behavior: auto to provide instant scrolling.
Should I respect prefers-reduced-motion for micro-interactions?
Button press feedback, dropdown opens, and tooltip appearances are generally fine even in reduced-motion mode if they are brief (under 150ms) and do not involve spatial movement. Use judgment.
Can JavaScript read the motion preference?
Yes: window.matchMedia('(prefers-reduced-motion: reduce)').matches returns a boolean. Use this to conditionally start or stop JavaScript-driven animations.
The Standard
A premium brand experience is not defined by the amount of motion on the page. It is defined by the attention to detail in every state. The reduced-motion experience should receive the same design attention as the full-motion experience. When it does, the site feels considered for everyone, not just for users who happen to have motion enabled.