The setting your visitor already made, and your site never read

A colleague opens the site we have just finished, on her own machine. The gradient in the background drifts slowly. Cards rise into place as she scrolls past them. Everything works exactly as designed.

She scrolls through a couple of screens, looks away for a while, and says she will come back to it later.

She is not complaining that it looks bad. She genuinely does not feel well. And on her machine, the setting that says so was switched on over a year ago. The site simply never read it.

This is not a preference about taste

prefers-reduced-motion is how an operating system tells a web page that the person using it has asked for less movement. Almost nobody turns it on because animation annoys them.

People with vestibular disorders — conditions of the inner ear's balance system — can experience real nausea, dizziness and disorientation from large moving backgrounds and from parallax, where layers slide at different speeds. That is not irritation. It is a physical response that can outlast the visit by a long way.

People who get migraines use the setting too, since movement and flicker are well-known triggers. Some people with epilepsy avoid rapidly changing imagery for reasons that need no elaboration. And some people with ADHD switch it on because anything that keeps moving pulls attention off the sentence they are trying to read.

What they have in common is that they already made the decision, on their own device. They are not waiting to be asked again by every site they visit.

Where the switch actually lives

On iOS and iPadOS: Settings, then Accessibility, then Motion, then Reduce Motion.

On macOS: System Settings, then Accessibility, then Display, then Reduce motion.

On Windows 11: Settings, then Accessibility, then Visual effects, then turn off Animation effects.

On Android: Settings, then Accessibility, then something along the lines of Remove animations — the wording and the position vary by manufacturer, and it is worth saying so rather than pretending every phone is identical.

What does not vary is the outcome. Every one of these systems passes the preference to the browser, and the browser exposes it to CSS directly. The signal is already there to be used.

What the right response looks like

The wrong reading is that a request for less motion is a request for less site.

Nobody who enables this setting is asking for a degraded experience. They are asking for the same page, holding still. The content stays. The states stay — this button is loading, this panel is open, this row is selected. The affordances stay: whatever looked clickable still looks clickable.

The workable rule is to keep the meaning and remove the movement. A card that used to fade in simply appears. A ticker that used to scroll on its own stops, and becomes something you can scroll by hand instead. The same information reaches the reader; nothing travels across their field of view to deliver it.

Not hidden — never created

This site has a lighting effect that follows the pointer, and a glow inside whichever card the pointer is over. Before it does anything at all, the code checks two things: whether the device actually has a fine pointer and true hover, and whether the visitor has asked for reduced motion. If either check fails, it returns immediately and nothing further happens.

That distinction matters more than it looks. The easier approach is to let the effect run as normal and hide it with CSS. On screen the two are indistinguishable. Underneath they are not, because an effect that has been created and then hidden still has a pointer listener attached, still spins an animation frame loop, still writes values onto the document. All of that occupies the main thread and drains the visitor's battery to produce something nobody will see.

Because the component never mounts, the attribute that switches the CSS on is never set. The effect is not sitting at zero opacity. It never paints a single frame.

Why no-preference is the safer place to write

The query has two sides. reduce means the person asked for less. no-preference means they did not ask.

The common approach is to write the animation normally and then add a reduce block that turns it off. That works when everything behaves, but the default is on the wrong side. If a browser does not understand the query, or runs somewhere the operating system reports no preference at all, the block that switches things off never applies — while the animation written outside it runs anyway. The person who should have got a still page gets a moving one.

Writing the animation inside no-preference inverts the risk. The browser plays it only when it understands the query and can positively say the visitor has not asked for less. Every uncertain case falls to the still side, which is the side that is safe to be wrong on.

On this site, all three layers of the drifting background gradient live inside a no-preference block, and so does the scroll reveal that brings content in. Where a browser knows nothing about any of it, the result is content sitting in place, fully readable — which is what should happen regardless.

What this means for your own product

If you want to try this on your own work, turn reduced motion on for your test device and open your product's main screen. If nothing changes at all, the setting is not being read.

Then check three things. First, what moves without the user asking — backgrounds, tickers, autoplaying video, carousels. Second, whether a person can still tell what the system is doing once the movement is gone; a spinner that only communicated through spinning leaves nothing behind. Third, whether the code you believe you disabled is disabled, or merely invisible.

None of that takes long. It is the difference between a site that respects a decision its visitor already made, and one that simply never found out they had made it.

The next piece in this series covers something adjacent: what a page owes a visitor who is not using a mouse at all.

If you would like to talk about your product, get in touch.