WCAG 1.4.2: Audio Control
Sound that starts on its own is not just annoying — for someone using a screen reader it can drown out the speech they depend on to use the page at all. This criterion asks that whenever audio auto-plays for more than three seconds, users can pause or stop it, or turn it down independently of their system volume. The best answer is usually the simplest: don't auto-play audio in the first place.
The success criterion, in full
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.
Two things make this criterion easy to misjudge. First, it is triggered by any auto-playing sound over three seconds — background music, an ambient loop, or the audio track of an auto-playing video all count. Second, the volume control must be independent: relying on the operating-system volume does not satisfy it, because that would force a blind user to silence their screen reader along with your audio.
Who this helps
Uncontrolled audio is a barrier for far more people than you might expect. Giving users a way to stop or lower it keeps the page usable for everyone within earshot:
Screen reader users
Auto-playing audio plays over the synthesized speech a blind user relies on. If they cannot silence your sound without silencing their screen reader too, the entire page becomes unusable.
People with cognitive and attention disabilities
Unexpected background sound competes for attention and makes it hard to focus on reading, following instructions, or completing a task.
People with hearing aids and cochlear implants
Sudden or layered audio can be disorienting or physically uncomfortable when amplified directly into the ear.
Users with anxiety or sensory sensitivities
Sound that starts without warning can be startling or distressing; an immediate way to stop it prevents a stressful experience.
Anyone in a shared or quiet space
Offices, libraries, classrooms, public transit — a page that blares audio on load embarrasses users and makes them close it rather than use it.
Voice-interface and speech-input users
Background audio interferes with speech recognition, making voice control unreliable while the sound is playing.
What the requirement covers
The trigger is narrow but the coverage is broad. 1.4.2 only applies when audio plays automatically — without the user starting it — and continues for more than three seconds. When both are true, the audio must come with one of two mechanisms:
- A pause or stop mechanism. An in-page control that silences the audio — a stop button, a pause toggle, a mute that fully cuts the sound. It must be operable by keyboard and have a clear accessible name.
- Independent volume control. A control that adjusts your audio's level separately from the system volume, so a user can turn your sound to zero without touching their screen reader or the rest of the device.
- Reachable early. Because the audio competes with assistive technology from the moment it starts, the control should be one of the first things a keyboard or screen-reader user encounters — ideally the first focusable element, at the top of the DOM.
What counts as “audio”, and what's exempt
“Audio” here means any sound: background music, ambient loops, sound effects, and the audio track of an auto-playing video. The one thing that removes the obligation is duration — audio that auto-plays and stops on its own within three seconds is not covered. There is no exception for “essential” audio: the criterion applies whether or not the sound is central to the content, because for a screen-reader user any uncontrolled audio can make the page unusable. The genuinely safe pattern is to never auto-play sound and let the user press play. See also 1.4.1 Use of Color and the time-based media criteria for related requirements.
Pass and fail examples
✓ Passes 1.4.2
- Audio that does not play until the user presses a play button.
- Background music that auto-plays but offers a prominent pause/stop button at the top of the page.
- An auto-playing video whose sound can be muted or paused with an in-page control.
- A short notification chime that stops on its own within three seconds.
- Auto-playing audio with an in-page volume slider that can be lowered to silent, independently of the system volume.
✗ Fails 1.4.2
- Background music that starts on page load and runs for a minute with no way to stop it.
- An auto-playing promo video with sound and no accessible mute or pause control.
- Audio whose only “control” is to turn down the device or system volume.
- A stop button that exists but is buried at the bottom of the page after all the content.
- An ambient sound loop that keeps playing while a screen reader tries to announce the page.
Code examples
Don't auto-play; let the user start it
The simplest way to pass is to never auto-play. A native <audio controls> element gives the user play, pause, and volume out of the box.
<!-- ✗ Auto-plays with no way to stop it -->
<audio src="background-music.mp3" autoplay loop></audio>
<!-- ✓ User starts it; native controls include pause + volume -->
<audio src="podcast.mp3" controls preload="none">
Your browser doesn't support audio.
<a href="podcast.mp3">Download the audio file</a>.
</audio>If audio must auto-play, provide a control first
When auto-play is unavoidable, put a real, keyboard-operable stop control at the very top of the page so it is the first thing an assistive-technology user reaches.
<!-- ✗ Auto-plays; the only "fix" is the OS volume -->
<audio id="bg" src="ambient.mp3" autoplay loop></audio>
<!-- ✓ Stop control is the first focusable element on the page -->
<button type="button" onclick="document.getElementById('bg').pause()">
Stop background audio
</button>
<audio id="bg" src="ambient.mp3" autoplay loop></audio>An independent volume control
The second way to conform is a volume control that changes only your audio, leaving the system volume — and the user's screen reader — untouched.
<audio id="track" src="ambient.mp3" autoplay loop></audio>
<label for="vol">Background audio volume</label>
<input
id="vol"
type="range"
min="0" max="1" step="0.01" value="0.5"
oninput="document.getElementById('track').volume = this.value">
<!-- Lowering this slider to 0 silences the page audio only,
independently of the operating-system volume level. -->Interactive Demo
Compare a compliant audio player — nothing plays until you press Play, with pause, stop, mute, and an independent volume slider — against a non-compliant scenario where sound just starts and keeps going past the three-second limit with no way to control it.
Compliant: user-controlled audio
Nothing plays until you press Play, and you can pause or stop it at any time. The volume slider changes the audio level independently of your operating-system volume — exactly what 1.4.2 asks for.
Non-compliant: audio that just starts
This simulates background audio that auto-plays on page load with no pause, stop, or volume control. For a screen-reader user it would drown out their speech output for as long as it runs. Press the button to see the problem play out (no real sound is emitted).
Common failures
- Auto-playing background music or ambient loops on page load with no in-page pause, stop, or mute.
- Auto-playing video that includes an audio track with no accessible way to mute or pause it.
- Treating the operating-system or hardware volume as the 'control' — it also silences the screen reader.
- Providing a stop button but placing it late in the DOM, after navigation and content, where it is hard to reach in time.
- A pause control that is only operable with a mouse and cannot be reached or activated by keyboard.
- Audio controls with no accessible name, announced by screen readers as an unlabeled button.
- Assuming audio under 3 seconds that actually loops — a looping short clip runs indefinitely and is covered.
- Believing 'essential' audio is exempt; 1.4.2 applies regardless of how important the sound is.
How to test for 1.4.2
- 1
Load the page and listen
Open the page fresh, with sound on, and note whether any audio starts on its own. If nothing auto-plays, 1.4.2 does not apply — but confirm across the states and pages that might trigger sound (modals, hero videos, ad slots).
- 2
Time any auto-playing audio
If audio does auto-play, measure how long it runs. Audio that stops by itself within 3 seconds passes without a control. Anything longer than 3 seconds — including short clips that loop — needs a mechanism.
- 3
Find the control and check it works
Locate the in-page pause/stop or independent volume control. Confirm it actually silences or lowers the audio, and that a volume control affects only the page audio, not the system volume.
- 4
Check how early the control is reachable
Tab from the top of the page. The stop control should be one of the first focusable elements, so a screen-reader user reaches it before wading through content while audio plays over their speech.
- 5
Test with a keyboard only
Unplug the mouse. Confirm you can move focus to the audio control and activate it with Enter or Space, and that it has a visible focus indicator.
- 6
Test with a screen reader
With NVDA, JAWS, or VoiceOver running, load the page. Verify you can still hear and operate the screen reader, that the control is announced with a clear name, and that stopping the audio restores clear speech output.
For a structured audit, work through the full WCAG 2.2 checklist.
Related Success Criteria
Color is not used as the only visual means of conveying information.
Text has a contrast ratio of at least 4.5:1 (3:1 for large text).
Text can be resized up to 200% without loss of content or functionality.
Text is used instead of images of text, except for customizable or essential images.
Text has a contrast ratio of at least 7:1 (4.5:1 for large text).
Frequently asked questions
What does WCAG 1.4.2 Audio Control require?
It requires that if any audio on a web page plays automatically for more than 3 seconds, you provide either a mechanism to pause or stop the audio, or a mechanism to control the audio volume independently of the overall system volume. You only need to satisfy one of those two options, but the control must be part of the page itself. It is a Level A success criterion under the Perceivable principle, which means it is a baseline requirement — auto-playing sound with no in-page control is one of the most disruptive accessibility barriers there is.
Does the 3-second rule mean short auto-playing audio is always fine?
Audio that plays automatically and stops on its own within 3 seconds is not covered by 1.4.2, so a brief notification chime or a two-second intro sting does not trigger the requirement. Anything longer than 3 seconds does, and the safest practice is simply not to auto-play audio at all. If you must, either keep it to 3 seconds or less, or add an obvious pause/stop or independent volume control that a keyboard and screen-reader user can reach immediately.
Why doesn't the operating-system volume control count?
The system or hardware volume affects everything at once — including a blind user's screen reader speech. If the only way to quiet your auto-playing audio is to turn down the whole system, the user has to silence their screen reader too, which makes the page unusable. WCAG 1.4.2 is explicit that the volume control must be independent of the overall system volume, meaning it lives in the page and adjusts only your audio, leaving assistive-technology output untouched.
Where should the pause or stop control be placed on the page?
As early as possible. Because auto-playing audio starts competing with a screen reader immediately, the control that stops it should be easy to find and reach right away — ideally the first focusable element on the page, or at the very top of the DOM order. If a screen-reader user has to tab through a whole navigation bar while audio drowns out their speech, the control technically exists but does not really help. Put it first, make it a real button, and give it a clear accessible name.
Does 1.4.2 apply to audio inside auto-playing video?
Yes. The criterion is about sound, not about the element that produces it. Background music, ambient loops, audio in an auto-playing video, and any other automatically-started sound over 3 seconds all fall under 1.4.2. If a video auto-plays with an audio track, you must provide a way to pause or stop it, or an independent volume control — muting the video, pausing it, or stopping playback all satisfy the requirement as long as the control is available in the page.
Is auto-playing audio ever acceptable if it's essential to the content?
1.4.2 applies regardless of whether the audio is essential — there is no 'essential' exception here. Even if the sound is central to the experience, you still have to give users a way to pause, stop, or independently lower it. The reason is simple: no matter how important the audio is to some users, for a screen-reader user it can make the rest of the page completely inaccessible, so control must always be available.