What on your page starts before anyone clicks?

Two criteria about things nobody asked for

Almost every accessibility rule is about whether a person can reach something. These two are the opposite: they are about something reaching the person. SC 1.4.2 Audio Control says that if sound starts on its own and runs for more than three seconds, there must be a way to stop it. SC 2.2.2 Pause, Stop, Hide says that if content moves on its own for more than five seconds next to content someone is reading, there must be a way to pause it. Both are level A — the floor, not the stretch goal.

They survive on so many sites because the thing they govern is a design decision made once, at launch, by somebody who was looking at the page rather than sitting in it. The hero video loops. The logo strip scrolls. The testimonial carousel advances every four seconds. None of it ever comes back up in a review, because none of it is broken in the way a team notices things are broken.

And the person it costs is specific. Someone with a vestibular disorder gets nausea and dizziness from large background motion — not irritation, symptoms. Someone with ADHD loses the sentence every time the slide changes. Someone using a screen reader has your soundtrack and their own speech output in the same ear, and the announcement telling them how to leave is the one your audio is covering.

“Browsers block autoplay now”

They block some of it, on some sites, for some people, and that is precisely the problem. Chrome decides using a media engagement score that rises the more often you visit a site — so unmuted autoplay is blocked for a first-time visitor and allowed for a regular. The developer who built the page has loaded it two hundred times. They are in the bucket where it plays, which is why the defect is so often shipped by somebody who checked.

Safari applies its own rules, Firefox another set, and an in-app webview inside a social app frequently applies none. Conformance is a property of what you shipped, not of what one browser chose to do with it on one visit. A criterion is not satisfied by intermittent third-party intervention.

What this checker refuses to call a failure

Every defect here has a near-identical shape that is completely correct, and the correct shape is far more common. So the negatives are pinned as hard as the positives, by scripts/check-autoplay-audit.mjs in the build:

<!-- correct — no audio to control, never reported -->
<video autoplay muted playsinline src="/bg.mp4"></video>

/* correct — over in 400ms, 2.2.2 does not apply */
.fade { animation: fade .4s ease 1; }

/* correct — this IS the fix, never read as the defect */
@media (prefers-reduced-motion: reduce) { * { animation: none } }

<!-- fails 1.4.2 — sound on load, no mechanism -->
<video autoplay src="/hero.mp4"></video>
<iframe src="https://www.youtube.com/embed/x?autoplay=1"></iframe>

/* in scope for 2.2.2 — never ends */
.ticker { animation: scroll 30s linear infinite; }

The controls attribute is a pause mechanism, so an autoplaying element that ships it is not reported. transition is never read as automatic motion — it starts because somebody did something, which is a different criterion at a different level. A @media print block is stripped before the CSS is read. A Swiper snippet that trips three of the library’s option names produces one carousel finding, not three.

And the honest gap: we read the HTML your server sends and the CSS inside it. An external stylesheet is a separate file we do not fetch, so a page with no inline CSS is reported as verify, never as a clean pass. Grep your stylesheets for the word infinite; it finds nearly every animation this criterion is about.

The fix, in full

Four changes, none of them bigger than a line, plus one media query that covers everything you have not thought of.

<!-- decoration: no sound, so nothing to control -->
<video autoplay muted loop playsinline poster="/hero.jpg" src="/bg.mp4"></video>

<!-- the sound is the point: ship the browser's pause button -->
<audio controls src="/episode.mp3"></audio>

<!-- embeds: mute beside autoplay, or drop autoplay -->
<iframe src="https://www.youtube.com/embed/x?autoplay=1&mute=1" title="Demo"></iframe>

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

That media query is level AAA and it is still the best value on this page, because the reader has already done their half: they went into their operating system settings and asked for less movement. Every modern browser passes that request through. Your stylesheet is the only part of the chain that has to choose to listen.

Then check the place it actually breaks: the carousel timer and the hero video live in a template, so one component fixes every page built from it — and one component left alone keeps failing on every page built from it. That is why the free scan crawls the site rather than reading one URL.

Common questions

Which WCAG criteria is this actually checking?

Two, both level A. SC 1.4.2 Audio Control: if audio plays automatically for more than three seconds, there has to be a mechanism to pause or stop it, or to change its volume separately from the system volume. SC 2.2.2 Pause, Stop, Hide: content that moves, blinks or scrolls automatically, runs for more than five seconds and sits alongside other content needs a way to pause it. A third, SC 2.3.3 Animation from Interactions, is level AAA — this checker names it and says so, and never counts it as a failure.

Is muted autoplay a problem?

Not for 1.4.2. There is no audio, so there is nothing to control, and <video autoplay muted playsinline> is the correct and ubiquitous way to ship a background video. This checker never reports it as a failure. What it does flag, for review rather than as a failure, is a muted video that also carries loop and no controls — because 2.2.2 is about movement rather than sound, and a hero video that loops moves for as long as the page is open with nothing on the page to stop it.

Browsers already block autoplay. Doesn't that fix it?

It hides it, which is worse. Chrome's media engagement heuristic blocks unmuted autoplay on a site you have never visited and allows it on one you use daily — so the developer who built the page, who has loaded it two hundred times, is in exactly the bucket where it plays. Safari, Firefox and every embedded webview draw the line somewhere else again. The markup is the thing that is either conformant or not, and a criterion is not satisfied by a browser sometimes intervening.

Why is auto-playing audio singled out as the worst one?

Because of who is on the other end. A screen reader user has your audio and their own speech output coming through the same speaker at the same time, and the announcement they need in order to navigate away from your page is the thing your audio is drowning. The criterion asks for the stop mechanism to be near the beginning of the page for exactly this reason: by the time they have found it the normal way, they have been fighting it for a minute.

What counts as a pause mechanism?

Anything the reader can operate that stops it, reachable by keyboard and labelled. The browser's own control bar counts — that is why an element carrying `controls` is not reported here. A custom pause button counts. Pause-on-hover does not, because a keyboard user never hovers. Neither does "they can scroll past it", and neither does the operating system volume control, which 1.4.2 explicitly rules out because it silences everything rather than your page.

Do I have to stop using carousels?

No — you have to stop them rotating on a timer without a way to pause. An auto-rotating hero is the textbook 2.2.2 case: it moves unprompted, it runs longer than five seconds, and it sits next to the thing someone is reading. A carousel the reader advances themselves raises no issue under this criterion at all. Since we cannot see from the HTML whether a reachable pause control exists, a timer is reported for review, never as a failure.

What about animated GIFs?

The HTML tells us a .gif is on the page and nothing else — not whether it animates, not how long it runs, not whether it loops. All three live inside the file. A looping animated GIF longer than five seconds is a 2.2.2 failure with no pause mechanism available at all, which is what makes the format worth a second look; a static one is nothing. So it is listed for review with the manual check, and it is never called a failure.

Is prefers-reduced-motion required?

Not at AA. SC 2.3.3 is level AAA, and any tool that tells you a missing media query fails your AA audit is wrong. It is on this list because it is the cheapest fix on the page — one media query, applied globally — and because the reader it serves has already done their half: they went into their operating system settings and asked for less movement. Your stylesheet is the only thing in the chain not reading that.

Can you see my CSS?

Only the rules inside the HTML — <style> blocks and style attributes. An external stylesheet is a separate file we do not fetch, and on SC 2.2.2 that is a real gap, because keyframe animations live in CSS. So a page with no inline CSS is reported as VERIFY rather than as a clean pass, and told to grep its stylesheets for the word `infinite`, which finds nearly every animation this criterion is about. Rules inside @media print are stripped before anything is read, and so are rules inside @media (prefers-reduced-motion: reduce) — those are the fix, and reporting them as the defect would be the worst thing this tool could do.

My hero video is injected by JavaScript. Will this see it?

Only what is in the HTML your server sends, which is what this reads — deliberately, because it is fast, free and the same markup a crawler sees. If the checker finds nothing on a page you know has a background video, the video arrives with your scripts. The free WCAG 2.1 AA scan renders each page in a real browser and will see it.

Does this store my domain?

No. The check is an HTTP GET of the page you name, run inside the request and discarded when it answers. There is no account, no email field and no row written anywhere. If you go on to run the free scan, that one does keep a report so you can come back to it, which is the whole point of a report.