WCAG 2.2.2: Pause, Stop, Hide
WCAG 2.2.2 (Pause, Stop, Hide) is the Level A success criterion that gives users control over content that moves on its own. It requires that for any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it — unless the movement is part of an activity where it is essential. For auto-updating information that starts automatically and sits alongside other content, the same applies, with one extra option: the user may instead be given control over the frequency of updates. The criterion is defined by the W3C; the authoritative reference is the Understanding document for SC 2.2.2.
All three conditions must hold before the requirement applies. Motion a user starts by clicking is not "automatic"; a bounded animation that ends within five seconds is not "more than five seconds"; a progress indicator that is the only thing on a blocking load screen is commonly treated as out of scope because nothing else is presented in parallel with it. The same spinner embedded in a page full of content is in scope.
What falls under Pause, Stop, Hide — and what doesn't?
WCAG 2.2.2 covers content that starts moving on its own and keeps going: auto-playing carousels, marquees and news tickers, infinite CSS animation loops, auto-playing background video, and looping animated GIFs. In practice the most common web patterns are:
- Auto-advancing carousels and sliders that rotate hero content with no pause control.
- Marquees and tickers — scrolling headlines, logos, or prices that never stop.
- Infinite CSS loops — spinners, pulsing badges, floating decorations declared with
animation-iteration-count: infiniteand no pause path. This is the single most frequent pattern in generated UI code, one of the four defects we group under motion slop. - Auto-playing background video longer than five seconds behind text or forms.
- Auto-updating regions — live feeds, stock or score tickers — where 2.2.2 also accepts a control over update frequency.
Outside the criterion: motion the user initiates (hover or click effects that then end), auto-starting motion that finishes on its own within five seconds, and movement that is essential to the activity — a video the user chose to play, or an animation whose motion is itself the information. "Essential" is a narrow exception, not a loophole for decorative loops.
How do you pass WCAG 2.2.2?
A page passes WCAG 2.2.2 when every piece of auto-starting motion either ends within five seconds or has a control that pauses, stops, or hides it. Three fixes cover almost every case, in order of preference:
- Don't autoplay. Let the user start the carousel, the video, the ticker. Motion that starts on request is outside the criterion entirely.
- Bound the loop. Replace
infinitewith a finite iteration count so the animation ends on its own inside five seconds. - Wire a real control. A visible, keyboard-operable button that actually halts the movement — not a hover-pause, which ends the moment the pointer leaves.
/* Fails 2.2.2: starts automatically, loops forever, no control */
.badge { animation: pulse 0.8s infinite; }
/* Fix A — bounded: ends on its own within five seconds */
.badge { animation: pulse 0.8s 5; } /* 4s total, then stops */
/* Fix B — pause path: a control wired to the animation */
.carousel.is-paused .track { animation-play-state: paused; }
<button type="button" aria-pressed="false">Pause animation</button>
The full manual test process — OS settings, what to look for, and the code patterns for each finding — is in our guide on how to verify web motion accessibility.
How is 2.2.2 different from prefers-reduced-motion?
WCAG 2.2.2 requires an on-page control that works for every user; prefers-reduced-motion honours an operating-system preference and maps to WCAG 2.3.3, a best-practice track. These are two separate rails and one does not substitute for the other. A page whose every animation is wrapped in a prefers-reduced-motion guard is doing the right thing for users who have set that preference — but a user who has not set it, or doesn't know it exists, still has no way to stop an infinite carousel. Conversely, a pause button satisfies 2.2.2 but does nothing for the person whose OS asked for reduced motion before the page even loaded. Robust motion ships both: the guard by default, and a pause path for anything that runs longer than five seconds.
How often is WCAG 2.2.2 failed in AI-generated apps?
In our static scan of 196 AI-generated production apps, 66.3% ran at least one infinite animation with no way to pause it — a WCAG 2.2.2 Level A failure. That is the central finding of our study The State of Motion in AI-Generated UIs. The median app carried 17 distinct motion root causes, and only six apps of 196 — 3.1% — came back clean. Every number is a lower bound: the scan reads linked CSS and inline styles only, so runtime JavaScript motion is not measured, and only the public entry page was visited. It is a static scan, not a full audit. The anonymized per-app dataset is published as CSV under CC-BY-4.0, so the result can be reproduced without our tooling.
How does MotionSpec detect 2.2.2 patterns?
MotionSpec detects WCAG 2.2.2 patterns statically: the free motion check scans a URL's linked CSS and style blocks for infinite, auto-playing animation with no pause path, and reports every finding with its fix. This is detection, not conformance: a scan can prove the failing pattern is present, but it cannot certify a page — whether a control truly qualifies, or whether movement is "essential", is a human judgment. For motion that is being generated rather than audited, the MotionSpec MCP takes the other route: animation is compiled from verified primitives, so loops are bounded and the reduced-motion guard is present by construction instead of being checked after the fact.
FAQ
Is WCAG 2.2.2 Level A?
Yes. Pause, Stop, Hide is a Level A success criterion — part of the minimum conformance level every WCAG conformance claim starts from. For teams tracking the European Accessibility Act, the practical point is narrower: 2.2.2 is a machine-checkable Level A success criterion, so the failing pattern — an infinite, auto-playing animation with no pause path — can be tested automatically at scale.
Are animations under five seconds exempt from WCAG 2.2.2?
Moving, blinking or scrolling content that starts automatically but ends on its own within five seconds does not require a pause mechanism under 2.2.2. That is an exemption from this one criterion, not a general pass: flashing content is covered separately by WCAG 2.3.1, and honouring prefers-reduced-motion remains best practice for any motion, however short.
Does prefers-reduced-motion satisfy WCAG 2.2.2?
No. A prefers-reduced-motion media query honours an operating-system preference, which maps to the WCAG 2.3.3 best-practice track. WCAG 2.2.2 asks for a mechanism any user can operate on the page itself — a pause, stop or hide control — regardless of their OS settings. A page can guard every animation perfectly and still need the control.
Is an auto-playing carousel with a pause button enough?
A pause control can satisfy 2.2.2 if it genuinely stops the movement, is easy to find, and is keyboard-operable. A control that only pauses on hover, or that resumes the motion on its own, does not provide the mechanism the criterion asks for. Automated tools can flag a missing control; whether a given control truly qualifies is a judgment for human review.
Paste a URL into the free motion check — a static scan against WCAG 2.2.2 and 2.3.3, every finding with its fix. No signup, nothing stored.
Run the free motion checkGenerating web UI at scale? See the Design Partner Program.
MotionSpec verifies and compiles UI animation for AI-generated web apps — it does not generate AI video.