What is motion slop?

Kevin Fröba · 2026-07-07 · MotionSpec

Motion slop is generated animation that ships broken by default. The term follows the pattern of "AI slop" — low-quality generated content pushed out at scale — applied to the animation layer of web interfaces. A page has motion slop when its animation was produced without verification and shows one or more of four concrete, checkable defects:

• No reduced-motion guard. The animation runs even for users whose operating system asks for reduced motion (prefers-reduced-motion: reduce). For people with vestibular disorders this isn't a style problem; it can cause dizziness and nausea.
• Infinite attention traps. Looping spinners, pulsing badges, and auto-playing movement that never pauses — the pattern WCAG 2.2.2 (Pause, Stop, Hide) exists to prevent.
• Off-budget effects. Animation of layout-affecting properties (width, top, margin) instead of compositable ones (transform, opacity), or effects heavy enough to degrade Core Web Vitals on real devices.
• Hallucinated APIs. Calls to animation methods, easing names, or library options that don't exist — code that looks plausible in review and fails at runtime.

The defining property: any one page of it looks like a small bug. The problem is that it isn't one page — it's the default output of the fastest-growing way to build web UI.

Where motion slop comes from

Large language models write animation code the way they write everything: by producing the most statistically plausible pattern. In training data, most animation snippets carry no prefers-reduced-motion guard, no pause control, and no performance budget — so generated animation doesn't either, unless something enforces it. Prompting helps inconsistently: a prompt is a request, not a constraint. As AI app builders multiply how much web UI gets generated, the animation layer — the least reviewed part of the stack — scales its defects the fastest. For context on how widespread baseline accessibility failures already are, see the WebAIM Million, an annual audit that consistently finds accessibility failures on the overwhelming majority of the top million home pages.

What it looks like

A minimal, typical specimen — generated, plausible, broken:

/* generated: no guard, no pause, runs forever for everyone */
.badge { animation: pulse 0.8s infinite; }

el.style.animation = "spin 0.4s infinite";  // no reduced-motion check
el.animate(frames, { easing: "ease-in-out-back" });  // easing doesn't exist

None of these will fail a build. All of them fail users.

How to detect it

Manually: switch your OS to "reduce motion" and reload — anything still moving that isn't essential is a finding. Then scan the CSS for animation and transition rules that sit outside a @media (prefers-reduced-motion: no-preference) block, and for infinite iteration counts with no pause control. The full step-by-step process, including the relevant WCAG criteria and code patterns, is in our guide: How to verify web motion accessibility. If you want the CSS part automated, our free motion check statically scans any URL against WCAG 2.2.2 and 2.3.3 and shows every finding with a fix — no signup, nothing stored.

How to fix it

Three habits eliminate most motion slop: wrap every non-essential animation in a prefers-reduced-motion: no-preference media query (or an equivalent JavaScript guard); give anything that moves longer than five seconds a pause path; and animate compositable properties only, with durations and distances that fit a stated budget. The structural fix is to stop hoping generated code follows the rules and make the rules non-optional — that's the layer MotionSpec builds: animation assembled from verified primitives that ship the guard and the budget by construction.