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

Kevin Fröba — Sat, 18 Jul 2026 11:33:19 +0000

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;
  }
}

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.

Full write-up + per-cohort detail: https://motionspec.dev/blog/state-of-motion-ai-generated-uis
Open dataset (CC-BY-4.0, 196 rows, anonymized): https://motionspec.dev/blog/data/state-of-motion-2026.csv
Scan your own URL (free, static, nothing stored): https://motionspec.dev/motion-check?utm_source=article&utm_medium=devto

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.

Your AI-generated UI probably breaks prefers-reduced-motion

Kevin Fröba — Tue, 14 Jul 2026 13:07:30 +0000

AI coding tools have gotten very good at motion. Ask for a landing page and you get parallax heroes, staggered reveals, spring physics on every card. It looks great in the demo.

Here's what it almost never ships with: a prefers-reduced-motion path.

Why this is a real problem, not a checkbox

Vestibular disorders are common. For the people who have them, large parallax movement, zooming, and spinning UI can trigger dizziness, nausea, and migraines. That's why the media query exists, and why WCAG has two success criteria aimed squarely at this:

WCAG 2.2.2 (Pause, Stop, Hide) — Level A. Anything that moves automatically for more than 5 seconds needs a way to pause, stop, or hide it. Level A means baseline, not aspirational.
WCAG 2.3.3 (Animation from Interactions) — motion triggered by interaction should be disableable unless it's essential.

Most AI-generated motion fails both by default. Not because models "don't know" about reduced motion — they'll happily explain it if you ask — but because generation is sampling. Same model, same prompt, different run, different compliance.

Prompting is hope. Verification is a property.

"Make it accessible" in the prompt is not a guarantee, it's a suggestion. The pattern that actually works for LLM-generated code — the argument the Bun team made when they rewrote in Rust with heavy agent involvement — is a conformance suite plus mechanical enforcement. The model can write whatever it wants; the output has to pass the checks.

Motion has no such layer today. axe-core and Lighthouse are excellent, but they largely can't catch a scroll-jacked hero with no reduced-motion path, because statically analyzing dynamic motion behavior is hard. The gap is exactly where AI tools generate the most output.

What verifying motion looks like

The trick is treating motion as data instead of as scattered CSS and JS. If motion is declared in a spec, it becomes checkable:

json{
"element": "hero-title",
"primitive": "fade-rise",
"duration": 600,
"trigger": "scroll",
"reducedMotion": "opacity-only"
}

(Simplified for illustration.)

With motion as a spec, the questions become mechanical:

Does every animated element define reduced-motion behavior?
Does anything auto-play longer than 5s without a pause/stop/hide mechanism?
Are durations and movement distances inside a sane performance budget?

Fail any of these and the check fails — deterministically, every run.

MotionSpec

That's what MotionSpec does. It's open-core: an MIT-licensed npm package (40 motion primitives, 373 automated tests) plus a hosted verification API. It runs as an HTTP API and an MCP server on Cloudflare Workers — which means AI agents can call it inline while generating UI. The same agent that writes the motion has to pass the check before the motion ships.

There's a free motion-check on the site, no signup, if you want to see what your current motion setup fails.

One disambiguation, because the name space is crowded: MotionSpec is not an AI video or animation generator. It's a verification layer for web interface motion — closer to axe-core or Lighthouse than to any of the AI "Motion" tools.

Honest scope

It verifies motion that's described as a spec. It won't magically retrofit arbitrary legacy CSS/JS animation you point it at — the check is only as good as the spec describing the motion. That's the trade: declare motion as data, get verifiability in return.

If you try it, I genuinely want to know where the checks feel too strict or too loose — that calibration is the whole product. → motionspec.dev

DEV Community: Kevin Fröba