Animation and accessibility: prefers-reduced-motion done properly

Operating systems let people turn on "reduce motion". Browsers pass this to websites as the prefers-reduced-motion media query. People use it for many reasons: dizziness and nausea from parallax or zooming, vestibular conditions, migraines, attention difficulties, or simply a dislike of animated pages. For some it is a health matter, not a taste.

Honouring it is part of building an accessible site. The Web Content Accessibility Guidelines (WCAG) have related rules: content that moves on its own for more than five seconds needs a way to pause, stop or hide it (success criterion 2.2.2), and a level-AAA criterion asks that motion triggered by interaction can be turned off (2.3.3).

The principle: the page must say and do the same thing, just with less movement. A pinned scroll sequence becomes a normal stack of sections. A word-by-word reveal becomes the finished headline. A 3D scene becomes a still image. If a person with reduced motion on would miss information, you removed too much.

1. In CSS, wrap motion in the media query: write the animated version normally, and in a prefers-reduced-motion: reduce block set animation and transition durations to near zero and remove transforms.
2. In JavaScript, read the same setting with matchMedia("(prefers-reduced-motion: reduce)") before you create animations, and listen for changes, because people can switch it while the page is open.
3. Do not start smooth-scroll libraries or scroll-scrubbed timelines when it is on. Render the final state instead.
4. Make sure nothing depends on an animation finishing: no content that stays hidden until a timeline runs.
5. Keep keyboard focus visible and unchanged. Reduced motion does not mean fewer focus styles.

We treat it as a rule, not a bonus. Here is what is actually enforced and what we found in the library on 26 October 2026:

• Every effect must declare a reduced-motion fallback. The library's validation fails any effect that does not set reducedMotionFallback to true.
• The demo host sets a MotionLab.reducedMotion flag and a reduced-motion class on the page when the visitor prefers reduced motion. It does not start Lenis smooth scrolling in that case.
• Every demo is loaded once with reduced motion on in the quality gate, which fails on any console error or page error, and checks that the demo registers its cleanup.
• Of our 316 demos, 312 contain a prefers-reduced-motion rule in their CSS, 128 also read the reduced-motion flag in JavaScript, and every one of them references reduced motion in its demo files.

The gate proves that a demo loads and runs without errors under reduced motion. It does not prove that every fallback is a perfect experience, so we still check each template by eye, and we say so rather than overclaim.

1. Turn on reduce motion in your operating system (on a Mac: System Settings, Accessibility, Display; on Windows: Settings, Accessibility, Visual effects; on iOS and Android there is a matching option).
2. In Chrome DevTools, open the Rendering panel and set "Emulate CSS media feature prefers-reduced-motion" to reduce. This lets you test without changing your system.
3. Reload the page and scroll through all of it. Is every piece of content still there and readable?
4. Tab through the page with the keyboard. Is focus visible and does it move in a sensible order?
5. Switch the setting off and on while the page is open, to see that it responds.

• Content never depends on an animation finishing.
• Large movement has a still alternative.
• Autoplaying motion can be paused or is off by default.
• Smooth scrolling is off when reduced motion is on.
• You have tested with the setting on, on a real device.

If you build with an AI tool, ask for this in your prompt, and check the result. Our prompts include the reduced-motion behaviour and an acceptance checklist, and the help page has a fix prompt for the case where the AI changed the motion values. The scroll effects guide shows which patterns need the most care.