How to fix: Auto-playing media without controls
Media that plays automatically should not play sound without a way to stop it; add a controls attribute (and a way to pause or stop) for audio, or use muted for background video, to satisfy WCAG 1.4.2 Audio Control.
What it is
Autoplay means an <audio> or <video> element starts playing on its own when the page loads, via the autoplay attribute. WCAG Success Criterion 1.4.2 Audio Control says that if any audio plays automatically for more than three seconds, the page must give the user a mechanism to pause it, stop it, or control its volume independently of the system volume. The simplest way to provide that mechanism is the native controls attribute.
The failure is autoplaying media that produces sound with no built-in way to silence it. An <audio autoplay> with no controls, or a <video autoplay> that carries sound but no controls and is not muted, drops the user into unexpected audio with nowhere obvious to turn it off. This is especially disruptive when it competes with a screen reader the user is actively listening to.
There are two clean fixes. If media genuinely needs to autoplay, give it controls so anyone can pause, stop, or adjust it immediately. If it is a decorative background video, add the muted attribute so it plays silently and never triggers the audio-control requirement at all. Avoiding autoplaying sound altogether is the safest default.
Who it affects & why it matters
Screen reader users are hit hardest. Unexpected audio plays over the synthesized speech they depend on, drowning out the screen reader and making the page impossible to navigate until they hunt down a way to stop the sound, which is exactly what is missing when there are no controls.
It also affects people with cognitive and attention-related disabilities, for whom sudden, uncontrollable sound is disorienting, and anyone in a quiet or shared environment. Even users without disabilities scramble to mute a page that blares audio on load, so this fix improves the experience broadly.
Autoplaying media without a control mechanism is a Level A failure under SC 1.4.2, the most basic conformance tier, and WCAG 2.1 Level AA (which includes all Level A criteria) is the benchmark U.S. courts apply to ADA Title III claims. Uncontrollable audio is a vivid, easily demonstrated barrier, the kind a plaintiff can document simply by loading the page, so it is a meaningful audit and demand-letter risk.
It is also a quick fix with an outsized usability payoff: adding controls or muted is a one-attribute change that immediately removes a jarring experience for every visitor. With web accessibility lawsuits climbing and disproportionately targeting businesses under $25 million in revenue, eliminating autoplaying sound clears an obvious Level A failure at almost no cost.
How to fix it
- Find every <audio> and <video> element that has the autoplay attribute.
- Decide whether the media truly needs to start on its own; the safest option is to remove autoplay and let the user start it.
- If audio must autoplay, add the controls attribute so users can immediately pause, stop, or adjust the volume.
- If it is a decorative background video, add the muted attribute so it plays silently and never triggers the audio-control requirement.
- Confirm that no media plays sound for more than three seconds without a way to stop it, then re-scan.
<audio src="/podcast-intro.mp3" autoplay></audio>
<video src="/hero-loop.mp4" autoplay loop></video><audio src="/podcast-intro.mp3" controls></audio>
<video src="/hero-loop.mp4" autoplay loop muted></video>How AccessKnight detects this
AccessKnight selects every <audio> and <video> element that carries the autoplay attribute, then flags any of them that has neither a controls attribute nor a muted attribute. The presence of either one is treated as a pass: controls gives the user a way to pause or stop the sound, and muted means the media produces no sound to control. So adding controls (with a pause or stop mechanism) or, for background video, adding muted resolves the finding.