State of Motion in AI-Generated UIs: 196 Sites Tested for Motion Accessibility (2026)

Kevin Fröba · 2026-07-18 · MotionSpec · Motion Accessibility Index #1

In short: we scanned 196 AI-generated production web apps for one narrow thing — does the motion they ship by default let a person stop it? 66.3% run at least one infinite animation with no way to pause it, a WCAG 2.2.2 Level A failure. 96.9% ship some motion with no reduced-motion guard. Six apps — 3.1% — came back clean. The full method and the raw dataset are below, so you don't have to take our word for any of it.

Somewhere right now, a person who gets motion sick from moving interfaces has told their computer to calm down. Every major operating system has the switch: Reduce Motion. It's not a preference in the decorative sense — for people with vestibular disorders, a parallax hero or an auto-scrolling marquee can trigger real dizziness, nausea and migraine. The web has a standard way to honour that switch. The question we set out to answer was simple: in the new wave of apps that AI builders generate for us, how many actually do?

We took 196 publicly accessible production apps built with five major AI app-builder platforms, and ran one focused check against the two oldest, most automatable motion-accessibility rules on the books: is there a reduced-motion guard, and is there a way to pause a loop that never stops? Mostly, the answer was no. What follows is the data, why this particular gap stays invisible to the tools most teams already run, and — because it's genuinely fixable in minutes — what to do about it.

Key findings

• 66.3% fail WCAG 2.2.2 (Level A). Two-thirds of the apps ran at least one infinite, auto-playing animation with no pause, stop, or hide path. Level A is the minimum bar — the one everyone is meant to clear.
• 96.9% ship unguarded motion. Nearly every app had some animation or transition with no prefers-reduced-motion guard. We're deliberately careful here: this is a best-practice gap, not a strict Level A/AA failure (see method). It's the ambient problem; the 66.3% is the hard one.
• The median app carried 17 distinct motion root causes. Not 17 CSS selectors — 17 separate causes, each an animation or an unguarded transition layer.
• The median motion score was 35 out of 100 on our own heuristic (see the caveat below). Across the corpus, 6 apps scored a clean 100.
• Only 6 apps out of 196 were clean. And — this is the interesting part — they clustered.

The 0–100 "motion score" is MotionSpec's own weighting heuristic, not a WCAG conformance rate. We report it because it's reproducible (the formula ships with every result), but the load-bearing numbers here are the WCAG-mapped percentages, not the score.

By cohort — and the one that got it right

We grouped the apps into five anonymized cohorts, A–E, one per platform. The pattern is stark, and it points somewhere useful.

Cohort D is the smallest (21 apps), so its percentages carry wider uncertainty than the others. Full per-app data is in the linked dataset.

Four of the five cohorts hit 100% on the unguarded-motion check. That near-uniformity is the tell: this isn't a few careless builders, it's a default. But cohort E breaks the pattern — 85% unguarded instead of 100%, a quarter of the loop-failure rate of its peers, and the only cohort shipping clean apps at all. That matters more than any single headline number, because it means the gap is not a technical ceiling. Somewhere, one platform's design-system defaults already ship a reduced-motion guard often enough to move the numbers. If one can, the rest can.

Why this gap stays invisible

Here's the uncomfortable thing: most of these apps would pass the accessibility scan a careful team actually runs. That's not because the scanners are bad — it's because they don't look at motion.

The most authoritative snapshot of the field, the WebAIM Million, analyses the top one million home pages every year. Its 2026 report found detectable WCAG failures on 95.9% of them and flagged the first accessibility regression in seven years — pinning part of it on the rise of AI-assisted "vibe coding." But look at what it measures: the recurring top failures are low-contrast text, missing alt text, empty links and buttons, missing form labels, missing document language. Motion is not on the list — not because it's rare, but because the automated scanners behind studies like that (and behind axe, WAVE and Lighthouse) don't reliably evaluate animation. Visual-regression tools go further in the wrong direction: they freeze animation on purpose so they can diff screenshots.

So the honest framing is not "motion is the biggest accessibility problem." It isn't. Contrast and alt text are the epidemic; fix those first. Motion is a different kind of problem — the one the standard tooling can't see, which is exactly why it keeps shipping on sites that otherwise pass. It's not the largest gap. It's the invisible one. And an AI builder that was never asked about reduced motion will reproduce it a thousand times without a warning.

Why it matters now

Three things are converging in 2026, and together they turn an old, quiet gap into a live one.

Motion just became everyone's job. Figma shipped Figma Motion at Config 2026 — a native timeline plus an AI agent that generates animation from a prompt, on every plan. Figma's own recap adds the caveat in the same breath: motion in the tool "does not replace reduced-motion preferences or contrast checks." More motion, made by more people, faster — with no enforcement in the tool that makes it.

AI is generating the unsafe version at scale. That's what our 196 apps show, and what WebAIM's regression hints at from the other direction. The default output of a generation pipeline that was never prompted about accessibility is motion with no brake.

And the law is starting to bite — carefully stated. The European Accessibility Act has been in force since June 2025. On 4 June 2026, a French court (the Carrefour case) issued what's regarded as the first EAA enforcement decision: an order to fix within six months or pay €500 per day. To be precise, because this gets exaggerated: that is a court order with a daily penalty, not one of the "€900k–€1M fines" that circulate online — those are statutory maximums, not sums anyone has actually been made to pay. The enforcement is real; the million-euro headline is not yet.

Whose job is this?

It's tempting, from where we sit, to point at the builders. We're not going to — partly because it wouldn't be fair, and partly because it wouldn't be true. The people using these tools aren't careless, and the tools aren't malicious. The gap exists because the whole chain optimised for shipping something that looks alive, and nobody in it was ever asked to also let it stop.

Every AI learned to make the web move. Almost none learned to let it stop. That includes us: we shipped unguarded motion ourselves before we started measuring it — which is the whole reason we can tell you where to look.

— Kevin Fröba, MotionSpec

The accessibility community has been clear for years about who this affects and why — writers like Tatiana Mac, who argues for a "no-motion-first" default, and Val Head, whose work on motion sensitivity predates the tooling that now makes the problem worse. The point of a study like this isn't to relitigate the "should." It's to measure the "is," and to make the gap legible to the people now generating motion who never saw those articles. An OS-level Reduce Motion setting only helps if the page listens for it — and, ideally, offers its own visible pause too.

The fix is small

None of this is exotic. It's the default output of tools that were never asked the question — and it's fixable in minutes once it's visible. Two patterns cover most of what we found.

1. Guard non-essential motion. Honour the reduced-motion request:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: .01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: .01ms !important;
    scroll-behavior: auto !important;
  }
}

That's a blunt safety net; a real implementation guards specific animations rather than blanket-killing them, but even the net is better than nothing. 2. Give loops an off switch. Anything that loops forever needs a pause control or a finite end — an animation-play-state: paused tied to a visible button, or simply a bounded animation-iteration-count. That single change is what moves an app out of the 66.3%.

How we measured (read before quoting)

This is a static scan of each page's linked CSS and inline <style> blocks — nothing else. That makes every number above a lower bound, not a ceiling, and we want to be specific about the edges:

• Runtime JavaScript motion is not measured. GSAP, the Web Animations API, scroll-driven libraries — anything animated through .animate() or a JS timeline is invisible to this scan. The true rate is very unlikely to be lower than what we report.
• One page per app. We visited each app's public entry page only; deeper routes weren't crawled.
• Corpus. 196 apps, 21–45 per cohort, collected 2026-07-16 from official galleries, platform homepages and search-indexed hosting domains. Every URL has recorded provenance; robots.txt was respected; login-walled apps were excluded. Showcase corpora over-represent small and demo apps — a known bias we're naming, not hiding.
• What maps to what. Reduced-motion guards and risky animated properties sit in WCAG 2.3.3 (Animation from Interactions) territory; pause paths for infinite or long autoplay motion map to WCAG 2.2.2 (Pause, Stop, Hide, Level A). Neither criterion is fully machine-checkable — whether a given motion is "essential" is a human judgment no scanner can make — so what we report are automatable failure patterns within each criterion, not a conformance verdict, and not a legal determination for any app, platform or company.

One objection we expect: that our cohort groupings and score weights are self-defined heuristics. Fair. Every number here is a pure function of published, reproducible rules — the scoring formula ships with every result at motionspec.dev/motion-check — and the full corpus, per-app results and both scorer versions are archived and re-runnable on demand. The anonymized, per-app dataset (no URLs, no platform names) is published under CC-BY-4.0:

Download the dataset (CSV, 196 rows) →

FAQ

Are AI-generated websites accessible for motion?

In our sample of 196 AI-generated production apps, 66.3% shipped at least one infinite animation with no way to pause it — a WCAG 2.2.2 Level A failure — and 96.9% shipped some motion with no reduced-motion guard. Only 3.1% came back clean. It's a static lower bound, not a full audit.

What is WCAG 2.2.2 Pause, Stop, Hide?

WCAG 2.2.2 is a Level A success criterion: any motion that starts automatically, runs more than five seconds, and plays alongside other content must give people a way to pause, stop, or hide it. An infinite loop with no pause control fails it. Level A is the minimum accessibility bar.

Is missing prefers-reduced-motion a WCAG failure?

Not on its own. Missing prefers-reduced-motion support maps to WCAG 2.3.3, a Level AAA criterion scoped to interaction-triggered motion — best practice, not a strict A or AA failure. We report it as a coverage gap. The hard failure in our data is the 66.3% under 2.2.2 Level A.

How was the study measured?

We ran a static scan of each app's linked CSS and inline styles — nothing else. That makes every number a lower bound: runtime JavaScript motion such as GSAP, WAAPI and scroll libraries is not measured, and only the public entry page was visited. The full method and the raw dataset are linked in the article.

Which AI builders were tested?

Five major AI app-builder platforms, 21 to 45 apps each, 196 in total. We don't name which is which — apps appear only as cohorts A to E. The point is the pattern across a category of tools, not a scoreboard for any one vendor, and per-app identities stay private.

How do you fix unguarded motion?

Wrap non-essential motion in a prefers-reduced-motion media query so it reduces or stops when the user asks, and give anything that loops a pause control or a finite end. Both are a few lines of CSS. You can scan any URL free at motionspec.dev/motion-check to see the specific fixes.

Cite this study

Free to reuse under CC-BY-4.0 with attribution.

APA. Fröba, K. / MotionSpec. (2026). State of Motion in AI-Generated UIs: 196 sites tested for motion accessibility (Motion Accessibility Index #1). https://motionspec.dev/blog/state-of-motion-ai-generated-uis

@misc{motionspec2026stateofmotion,
  title  = {State of Motion in AI-Generated UIs: 196 Sites Tested for Motion Accessibility},
  author = {Fröba, Kevin and {MotionSpec}},
  year   = {2026},
  note   = {Motion Accessibility Index #1},
  howpublished = {\url{https://motionspec.dev/blog/state-of-motion-ai-generated-uis}}
}

Related: prefers-reduced-motion, explained (and how to test it) →