Success Criteria

WCAG 1.4.2 Audio Control

Success Criterion 1.4.2 requires that if audio plays automatically on a page for more than 3 seconds, there's a mechanism to pause or stop it, or to control its volume independently of the overall system volume. It's a Level A criterion under Guideline 1.4 (Distinguishable).

Who this protects, and how

Screen reader users rely entirely on their own synthesized speech audio to use a page at all. Autoplaying background audio or video competing with that speech can make a screen reader genuinely unusable — the user can't hear their own screen reader over the competing sound, and unlike a sighted user who might just visually ignore an autoplaying video, there's no equivalent way to "look past" competing audio.

The 3-second threshold

Audio that plays automatically for 3 seconds or less is exempt — a brief notification sound or short chime doesn't need its own pause control. Anything longer needs a way to stop it or control its volume separately from the device's master volume.

What satisfies this

• A visible, accessible pause/stop button for any autoplaying audio or video
• Not autoplaying audio at all (the simplest and most common real-world fix — most modern sites avoid autoplay by default, in part because browsers themselves have increasingly restricted it for UX reasons independent of accessibility)
• A volume control specific to that audio source, separate from system volume

A practical note on modern browser defaults

Many browsers now block autoplaying audio with sound by default unless a user has interacted with the page or site first — this has organically reduced how often this violation appears in practice compared to a decade ago. It's still worth checking deliberately for any embedded third-party widget (an ad, a video embed, a background music player) that might slip through with its own autoplay behavior independent of the browser's general policy.

Common questions

What is WCAG 1.4.2 Audio Control?

A Level A criterion: if audio auto-plays for more than three seconds, users must be able to pause, stop, or mute it separately from their device volume.

Why is auto-playing audio an accessibility problem?

It interferes with screen reader speech, which shares the same audio channel, making the page unusable for blind users until they can silence it.

How do I comply with 1.4.2?

Avoid auto-playing audio; if you must use it, provide a visible, keyboard-accessible pause/stop/mute control near the top of the page.