# The accessibility failure your CI can't catch — and the media query that fixes most of it > Source: > Published: 2026-07-18 11:33:19+00:00 **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 pause | 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 pause button wired to `animation-play-state: paused` , 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 pause" 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.