Anticode Open builder

Prefers reduced motion: what to turn off, what to keep, and the CSS

When someone turns on their device's reduce-motion setting, browsers report prefers-reduced-motion: reduce. Respect it by removing movement across the screen: parallax, scroll-triggered slides, zooms, auto-playing video and carousels. Small fades, colour changes and focus feedback can usually stay, because they don't move anything.

Updated · By the Anticode team

Who turns it on, and why

Every major operating system has a setting to reduce interface motion: Reduce Motion on Apple devices, Animation effects on Windows, Remove animations on Android. People switch it on for different reasons. For some with vestibular disorders, large movement on screen, especially movement that doesn't match their own scrolling, can cause dizziness, nausea or headaches that last well after they close the page. Others find motion distracting when concentrating, have migraines, or simply prefer a calmer interface.

The browser exposes the setting through the prefers-reduced-motion media feature, documented on MDN. It has two values: reduce when the person has asked for less motion, and no-preference otherwise. The name is precise: it asks for reduced motion, not for no visual change at all.

What to change

  • Parallax. Layers moving at different speeds as you scroll are the classic trigger. Turn them into still images.
  • Scroll-triggered movement. Sections that slide or fly in from the side, or rise 50px as they enter the viewport. Show them in place.
  • Scale and zoom. Images that grow on scroll, slow "Ken Burns" pans across a hero photo, zoom transitions between pages.
  • Scroll-jacking and smooth scroll. Pages that take over the scroll position or animate a long jump. Use instant scrolling instead.
  • Autoplay. Background video, auto-advancing carousels and looping animations. Show a still frame and let people start them.
  • Spinning and bouncing. Decorative rotation, springy overshoot on large elements, anything that wobbles.

What you can usually keep

Removing every transition isn't required, and it can make an interface harder to follow. A menu that appears instantly is fine; a state change with no feedback at all can be confusing. These are generally safe to keep, perhaps shortened:

  • Opacity fades for things appearing or disappearing in place.
  • Colour and background changes on hover, press and selection.
  • Focus outlines appearing, which keyboard users rely on.
  • Progress indicators, kept simple, so people know something is happening.
  • Small changes of a few pixels that confirm an action, such as a toggle's thumb moving across its track.

The CSS

There are two ways to write it. The first adds motion everywhere, then removes it for people who ask:

@media (prefers-reduced-motion: reduce) { .hero-img { animation: none; } html { scroll-behavior: auto; } }

The second, often better for new work, writes the still version as the default and adds movement only when there's no preference: @media (prefers-reduced-motion: no-preference) { .reveal { animation: rise .7s both; } }. Motion becomes an enhancement, and anything you forget to wrap simply doesn't move, which is the safer failure.

A common shortcut is a global rule that sets every animation and transition to none, or to a near-zero duration, under reduce. It's blunt but effective as a safety net. Watch for scripts that wait for an animationend or transitionend event that will now never fire; setting a duration of 0.01ms rather than none avoids that. In JavaScript, window.matchMedia('(prefers-reduced-motion: reduce)') gives you the same answer for script-driven motion, such as a carousel's autoplay timer.

Testing it

  1. Turn on your operating system's reduce-motion setting and reload the page.
  2. Or, in Chrome's developer tools, open the Rendering panel and emulate the reduced-motion preference. Firefox and Safari have similar options.
  3. Scroll the whole page. Nothing should slide, scale, pan or autoplay.
  4. Use the page normally. Menus, forms and buttons should still give clear feedback.

What WCAG says

Two WCAG 2.2 criteria apply. Pause, Stop, Hide (2.2.2, level A) requires a way to pause anything that moves automatically for more than five seconds alongside other content. Animation from Interactions (2.3.3, level AAA) asks that motion triggered by interaction can be turned off unless it's essential; honouring the reduce-motion setting is the usual way to meet it. Level AAA isn't usually a legal requirement, but this one is cheap to meet.

How Anticode handles it

Anticode's design gate blocks publishing a page that animates without a reduced-motion rule. Pages from the design engine go further than the minimum: under reduce, every animation and transition is switched off and smooth scrolling is disabled. The scroll effects you can add per element in the layout editor's inspector, a rise as a section enters and a gentle parallax, are written inside a no-preference query in the first place, so they never run for someone who has asked for less motion.

That blanket approach also removes the small, harmless fades listed above, a deliberate trade for safety. The gate checks that a reduced-motion rule exists, not that it covers every animation you might add by hand, so test your own additions with the steps above. The easing curves guide covers the motion that remains for everyone else.

Questions people ask

Does reduced motion mean no animation at all?

No. It means less movement. Fades, colour changes and focus feedback can usually stay; parallax, sliding, zooming and autoplay should go.

Is the reduced-motion media query supported in all browsers?

It's supported in all current major browsers. Where it isn't, the media query simply doesn't match, so write the still version as your default if that matters.

Do I still need a pause button if I respect reduced motion?

Yes, for anything that moves automatically for more than five seconds. Not everyone who is affected turns the setting on.

Sources

  1. prefers-reduced-motion, MDN Web Docs, checked
  2. Understanding Success Criterion 2.3.3: Animation from Interactions, W3C, checked