DEV Community

Kevin Fröba
Kevin Fröba

Posted on • Originally published at motionspec.dev

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

#a11y #ai #webdev

TL;DR

  • I ran a static motion-accessibility scan on 196 AI-generated production apps.
  • 66.3% ship at least one infinite animation with no way to pause it → fails WCAG 2.2.2 (Pause, Stop, Hide), Level A.
  • 96.9% ship motion with no prefers-reduced-motion guard (a best-practice gap, not a strict A/AA fail). Only 3.1% were clean.
  • The fix for most of it is a media query and a pause control. Data + method + open dataset at the bottom.

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.

The gap your pipeline doesn't see

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.

What I found (196 apps)

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.)

Why 66.3% is the number that matters

Two rules are in play:

  • WCAG 2.2.2 Pause, Stop, Hide — Level A. Anything that moves automatically, runs > 5s, and plays alongside other content needs a pause/stop/hide mechanism. An infinite loop with no pause fails Level A — the minimum bar.
  • WCAG 2.3.3 Animation from Interactions — Level AAA. This is where "no prefers-reduced-motion guard" lives. It's best practice, interaction-scoped, and not a strict A/AA failure. That's why I lead with the 66.3%, not the 96.9%.

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.

The fix

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;
  }
}
Enter fullscreen mode Exit fullscreen mode

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.

Method (read before quoting)

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.

Your turn

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.

Top comments (0)