The accessibility failure your CI can't catch — and the media query that fixes most of it

A developer found that 96.9% of 196 AI-generated apps lack a prefers-reduced-motion guard, violating WCAG accessibility guidelines. The audit revealed that four of five app-building platforms shipped 100% unguarded motion, with 66.3% of apps having infinite loops without a pause mechanism. The developer recommends adding the media query guard and pause controls to AI app-builders' default outputs.

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.