The reduced motion preference.
The operating system’s “reduce motion” setting is a signal that animations disturb the user, and a website can read that signal and change its behavior.
For some users motion is not an aesthetic layer but a source of physical discomfort. In people with vestibular disorders, large-scale motion — backgrounds dragged by scroll, zooming transitions, parallax layers — can produce dizziness, nausea and loss of balance. This is not a matter of taste; it is a matter of the user being unable to use the site.
Operating systems have therefore offered a setting for years, and browsers pass it to web pages. The signal is ready and reading it is a one-line job; the real question is what to do after reading it.
Toning down is not enough
The widespread practice is dropping all animation durations to zero, or near zero, when the reduced motion preference is detected. This one-line fix circulates widely and works in most cases — but it leaves two important gaps.
First: zeroing the duration does not stop the animation; it makes it infinitely fast. A scroll-bound effect still teleports elements during scrolling even at zero duration, and that can be more disturbing than a slow transition. The fix for scroll-bound motion is not duration — it is not setting it up.
Second: animation libraries keep running even at zero duration — computing, producing frames, consuming memory. The user sees no motion but their device pays motion’s price. On a low-powered device that means the page heating up and draining the battery for nothing.
Toning motion down is not enough; it must not be set up.
The full alternative flow
The sturdier approach treats the reduced motion preference not as a style setting but as a FLOW setting: with the preference on, the motion layer is never built. The scroll library is not started, scroll-bound timelines are not created, the shader does not run, the marquee stands still, the custom cursor is not installed.
That is the approach on this site, and the verification suite measures it in both directions: that no motion layer is built while the preference is on, and that all of them really run while it is off. The second measurement — the counter-proof — is critical, because a “calm with motion off” test also passes on a site where the motion was never written. A false green.
One more detail: the preference can change after the page has loaded. The user may flip the system setting while the tab is open, and the correct behavior is tearing the flow down and rebuilding it live. A preference read only at load time stays wrong for that user.
What must stop
The reduced motion preference does not mean “all animation forbidden.” What produces discomfort is motion that is large-scale, position-changing and outside the user’s control. Small, in-place, feedback-oriented transitions are usually fine.
- Must stop — parallax layers, scroll-bound dragging, zooming transitions, autoplaying video and background loops, marquees, large transitions sweeping the screen.
- May stay — color transitions, opacity changes, small scale changes, the focus ring appearing. Short, in place, not changing position.
- Must always be stoppable — automatic motion longer than three seconds must be pausable by the user (2.2.2, level A). This requirement is independent of the preference.
- Must never exist — more than three flashes per second (2.3.1, level A). It carries seizure risk and is acceptable under no circumstances.
The last two items are independent of the preference and sit at level A: they apply even if the user never turned on reduce motion. An autoplaying carousel without a pause control is a violation regardless of any setting.
The alternative needs designing too
Removing motion can remove the information the motion carried, and that is an overlooked risk. If a transition tells the user “you have entered a new section,” removing the animation loses that information too. If a loading indicator does not spin, nothing shows that something is in progress.
The right approach treats the motionless state as a separate design, not a deficiency. If motion carries information, that information must be given another way in the motionless state — a border, a color change, a text. In place of a video or loop, a still frame must be shown — not a gap.
On this site the live preview loops are handled exactly this way: with the reduced motion preference on, the video never loads and a static poster frame stands in its place. The user sees no motion but sees the content — and the suite separately measures that the poster frame really loads.
The general principle: reduced motion must not be a mode in which the site says less. It must be a mode that says the same thing without moving. The difference is whether the user who turned the preference on gets a second-class experience.
Testing: two directions
Testing reduced motion support in one direction is the most common mistake. The preference is turned on, the page looks calm, “it works” is declared. Yet that test gives the same result on a site where the motion was never written — it proves nothing.
The correct test is two-way and needs two separate measurements. With the preference on, verify the motion layers are not built; with it off, verify the same layers REALLY are. Without the second, the first is a false green.
- Turn the preference on, load the page — is the scroll library installed, is the shader running, are there timelines? None should exist.
- Turn the preference off, load the page — are all the same layers built? If not, the feature does not exist at all.
- Flip the preference while the page is open — does the flow tear down and rebuild live? A preference read only at load stays wrong for that user.
- Check the alternative — with motion removed, what stands in its place? A poster frame, or a gap? A gap means information was lost.
Testing without changing the operating system setting is also possible: browser developer tools allow forcing the preference per page. That speeds testing up but does not replace verifying once on a real device.
The performance side benefit
Answering the reduced motion preference with a full alternative flow has a concrete side benefit beyond accessibility: performance. When the motion layer is never built, no library runs, no frames are produced, no shader compiles, no memory is allocated.
That means the page is markedly lighter for users who turned the preference on — and considering the share of low-powered devices among those users, the benefit goes to those who need it most. This is one of the places where accessibility and performance coincide.
The reverse holds too: an implementation that only tones motion down charges the full cost even with the preference on. The user sees nothing, but their device keeps running the animation library. Battery spent on an invisible computation benefits no one.