WCAG 1.4.2 Audio Control says that if any sound on a page starts playing on its own for more than 3 seconds, you must give people a way to pause it, stop it, or turn its volume down separately from their device. It is a Level A rule — the bare minimum for an accessible site.

What WCAG 1.4.2 actually requires

The official wording from the W3C is precise:

If any audio on a web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Three details decide whether this criterion applies to you:

  • It is about automatic audio. Sound the user deliberately starts — a video they press play on, a song they choose — is fine. The rule targets audio that begins without any action from the visitor.
  • The 3-second line is firm. A jingle that plays on its own and ends within 3 seconds is exempt. Anything that runs longer needs an off switch.
  • “Or” means you have options. You can offer a pause/stop control, or an independent volume control. In practice the pause/stop button is far simpler to build correctly.

Because auto-playing sound can interfere with a person’s ability to operate the entire page, the W3C notes that all content on the page must meet this criterion — there is no “minor element” exception.

Who it affects, and why

The headline beneficiary is the screen reader user. Software screen readers — NVDA, JAWS, and VoiceOver — speak the interface aloud through the same audio channel and the same system volume as your background sound. When your page blasts music or a video soundtrack, it literally drowns out the synthetic voice the user relies on to navigate. They cannot turn your audio down without also turning their screen reader down, which makes the page unusable.

This is a Perceivable problem at its core: the user can no longer perceive the screen reader output that is their interface. The criterion also helps:

  • People with cognitive, attention, or learning disabilities, for whom unexpected sound is distracting or disorienting enough to derail a task.
  • People who are hard of hearing, who may have system volume turned up high — making a surprise autoplay clip jarring or painful.
  • Everyone else, frankly: anyone browsing in an open-plan office, a library, or a quiet house at night who gets ambushed by sound and scrambles to find the mute button.

Concrete ways sites fail 1.4.2

The W3C documents two specific failures, and both are common on small-business sites.

Failure F23 — a background sound with no off switch. A page loads a looping ambient track or a “welcome” voice clip via an old script or a <bgsound>-style embed, with nothing on screen to silence it.

Failure F93 — HTML5 media that autoplays with sound and no controls. This is the modern version. An <audio> or <video> element has the autoplay attribute, has an active sound track, runs past 3 seconds, is not muted, and exposes no pause/stop control. The canonical failing pattern from the W3C looks like this:

<!-- Fails 1.4.2: autoplays with sound, loops, no controls -->
<video src="promo.mp4" autoplay loop></video>

Other real-world offenders we see during remediation:

  • A homepage hero video that autoplays with its soundtrack on.
  • A self-hosted “explainer” audio file triggered by JavaScript on page load.
  • A third-party chat or ad widget that plays a notification chime in a loop.

How to fix it

The fix depends on whether the audio needs to exist at all. In order of preference:

1. Don’t autoplay — let the user start it. This is the most robust answer and aligns with the W3C’s own recommendation that sound be started by a user action. Remove autoplay and rely on native controls:

<!-- Passes: user initiates, native controls present -->
<video src="promo.mp4" controls></video>

2. Mute the autoplay. If a hero video must move on load (a common design choice), strip its sound. A muted element produces no audio, so 1.4.2 no longer applies:

<!-- Passes: muted autoplay produces no sound -->
<video src="promo.mp4" autoplay loop muted playsinline></video>

3. Keep the sound but add a real pause/stop control. If audio truly must play, surface a visible, keyboard-reachable control near the top of the page so a screen reader user finds it before anything else:

<audio id="bg" src="ambience.mp3" autoplay loop></audio>
<button onclick="document.getElementById('bg').pause()">
  Pause background audio
</button>

Note the button must be operable by keyboard and exposed to assistive tech — a <button> element handles that for free, whereas a clickable <div> does not.

How to test for 1.4.2

You do not need expensive tooling to check this one — your ears do most of the work.

  1. Load each unique page type with system sound on. Listen for anything that starts on its own.
  2. Time it. If auto-playing sound lasts more than 3 seconds, the page needs a control.
  3. Hunt for the off switch. Is there a visible pause, stop, or independent volume control, and can you reach it with the Tab key alone?
  4. Grep your codebase for the autoplay attribute and for any .play() calls fired on load. Confirm each one is either muted or controlled.
  5. Check embeds and widgets — carousels, chat tools, ad units, and background-video plugins often ship autoplay defaults you forgot about.

Automated scanners can flag autoplay attributes, but they cannot always tell whether a clip exceeds 3 seconds or whether a control truly works, so this criterion rewards a quick manual pass. A free Curbcut scan gives you a fast first list of offending media.

Why this matters legally

Auto-playing audio is one of the easiest accessibility failures for a plaintiff’s tester to document: they simply load your page, and the violation announces itself. Website accessibility lawsuits under ADA Title III run into the thousands each year and have trended upward across recent years (EcomBack 2025 report), and U.S. courts and the DOJ treat WCAG 2.1 AA — which incorporates this Level A criterion — as the practical benchmark for an accessible site. An unstoppable autoplay clip is exactly the kind of obvious barrier that turns up in demand letters.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Curbcut fixes 1.4.2 the right way: we find every auto-playing element and either remove the autoplay, mute it, or wire up a genuine, keyboard-accessible control in your actual code. We are deliberately anti-overlay — a widget that bolts a “mute” button onto your page does not stop the sound from firing on load and won’t satisfy a skeptical court (here’s why overlays don’t work). For the full picture, an accessibility audit catches autoplay alongside every other success criterion, or you can start with a free scan and we’ll show you exactly what’s making noise.