TL;DR
prefers-reduced-motion
guard (a best-practice gap, Disclosure: I build MotionSpec, a tool for this exact problem, and I used AI assistance to help draft this post. So the method is fully open and every number is reproducible from published rules — don't trust me, check it. Platforms are anonymized as cohorts A–E; this isn't a vendor scoreboard.
Your CI probably runs an accessibility check — axe, Lighthouse, maybe WAVE. Those are good tools. They also basically don't look at motion. They audit structure and content: contrast, alt text, labels, ARIA. Animation behaviour — reduced-motion support, pausable loops, off-budget motion — falls through, because automated scanners don't reliably evaluate it and visual-regression tools freeze animation on purpose to diff screenshots.
That's why the field's biggest census, the WebAIM Million 2026 (n = 1,000,000 home pages, 95.9% with detectable WCAG failures), lists contrast/alt/labels as the recurring top failures and never mentions motion — not because motion is rare, but because it's unmeasured. So I measured it, on the output that's growing fastest: apps built by AI app-builders.
| Cohort | Apps | ≥1 unguarded motion | ≥1 loop, no | Median score |
|---|---|---|---|---|
| A | 45 | 100% | 71.1% | 15 |
| B | 45 | 100% | 80.0% | 35 |
| C | 45 | 100% | 77.8% | 35 |
| D | 21 | 100% | 81.0% | 43 |
| E | 40 | 85.0% | 25.0% | 55 |
| All | ||||
| 196 | ||||
| 96.9% | ||||
| 66.3% | ||||
| 35 |
Four of five cohorts hit 100% unguarded — that's a default, not carelessness. Cohort E is the outlier: the only one below 100%, a quarter of the loop-failure rate, and the only one with clean apps. Translation: the gap is a design-system default, not a technical ceiling. One platform already ships the guard often enough to move the numbers.
(The 0–100 "score" is my own heuristic, not a WCAG conformance rate — I report it because it's reproducible, but the load-bearing numbers are the WCAG-mapped percentages.)
Two rules are in play:
prefers-reduced-motion
guard" lives. It's best practice, interaction-scoped, and For someone with a vestibular disorder, this isn't cosmetic — sweeping parallax and infinite loops cause real dizziness, nausea, migraine. The OS-level Reduce Motion switch only helps if the page listens.
1. Guard non-essential motion.
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: .01ms !important;
animation-iteration-count: 1 !important;
transition-duration: .01ms !important;
scroll-behavior: auto !important;
}
}
Blunt safety net; a real implementation guards specific animations. 2. Give loops an off switch — a button wired to animation-play-state: d
, or a finite animation-iteration-count
. That's what moves an app out of the 66.3%.
If you generate UI with AI — an app-builder, a design-to-code tool, or your own LLM pipeline — add "respect prefers-reduced-motion
and don't ship infinite loops without a " to your system prompt or your component defaults. Cohort E proves defaults are the lever.
Static scan of each page's linked CSS + inline styles only → a lower bound (runtime JS/GSAP/WAAPI motion not measured; one page per app). 196 apps, 21–45 per cohort, collected 2026-07-16, provenance recorded, robots.txt respected, login-walls excluded. Neither criterion is fully machine-checkable ("essential" motion is a human call), so these are automatable failure patterns, not a conformance verdict.
How does your stack handle prefers-reduced-motion
today — a global reset, per-component guards, or nothing yet? And if you generate UI, does your pipeline know the rule? Curious what people are doing — drop it below.