Level A

Autoplay audio longer than 3 seconds with no pause or independent volume control fails 1.4.2 and renders the page unusable for screen reader users, whose speech output shares the system audio channel

1.4.2 Audio Control

In Plain Language

1.4.2 Audio Control (Level A) says that if any audio on the page plays automatically for more than 3 seconds, the page must provide either a mechanism to pause or stop the audio, or a mechanism to control its volume independently of the overall system volume[1]. System volume does not count, because turning the system down also turns the user's screen reader down.

The simplest way to pass is to not autoplay audio. If autoplay is required, keep the clip under 3 seconds, or expose a visible pause or stop control near the top of the page so a screen reader user can find and operate it before the noise buries their text-to-speech output.

Why It Matters

  • Screen readers render the accessibility tree as synthesized speech through the same audio output device as the page. Background music, an autoplay hero video with sound, or an audio ad mixes into that output and drowns out the AT's speech. The user cannot hear what the screen reader is reading.
  • The operating system volume slider is not a fix: it attenuates page audio and screen reader audio together at the same ratio, so the speech-to-noise problem survives any system-level adjustment[1]. Independent volume means a control that targets only the page audio.
  • Users with cognitive and learning disabilities can be destabilised by unexpected sound, losing the thread of whatever they were reading until the audio stops.
  • Users in shared environments (offices, libraries, public transit) cannot always mute or put on headphones. If the only escape hatch is "leave the page", the page has failed the criterion.
  • 1.4.2 is distinct from 1.4.7 Low or No Background Audio (Level AAA), which governs the mix ratio between foreground speech and background music inside a single audio track. 1.4.2 is about any autoplaying audio at all; 1.4.7 is about spoken-word recordings specifically.

Examples

Do: Audio with visible pause and volume controls

Background Music

<div class="player">
  <p class="player-label">Background Music</p>
  <button aria-label="Pause background music">
    Pause
  </button>
  <button aria-label="Mute background music">
    Mute
  </button>
  <label>Vol
    <input type="range" min="0" max="100"
           value="50" aria-label="Volume">
  </label>
</div>
<!-- Pause/stop and an independent volume
     slider satisfy 1.4.2. -->
Don't: Auto-playing audio with no controls

No pause, stop, or volume control is provided. Users must mute their entire system to silence the audio.

<!-- FAILS 1.4.2: autoplay, >3s, no control -->
<audio autoplay>
  <source src="background.mp3" type="audio/mpeg">
</audio>
<!-- The only escape is the OS volume slider,
     which also silences the user's screen
     reader. The page becomes unusable. -->
Do: Video with native browser controls

Use the native controls attribute on media elements:

<video autoplay controls muted>

This provides built-in pause, volume, and mute controls that are keyboard-accessible.

<video autoplay controls muted>
  <source src="hero.mp4" type="video/mp4">
</video>
<!-- `controls` exposes a native pause button
     and an independent volume slider, both
     keyboard-operable. `muted` means autoplay
     starts silent, which also satisfies 1.4.2
     until the user opts in. -->
Don't: Auto-playing video without controls attribute

Hero video without controls:

<video autoplay loop>

No way to pause, mute, or adjust volume. If the video has audio, screen reader users are blocked.

<!-- FAILS 1.4.2 as soon as the track has
     audio and plays for >3s -->
<video autoplay loop>
  <source src="hero.mp4" type="video/mp4">
</video>
<!-- No `controls`, no `muted`. The audio
     track mixes into the same output as the
     screen reader with no way to stop it. -->

How to Fix It

  1. Do not autoplay audio. The cleanest pass is to require a user action (click, tap, key press) before any audio starts. This also aligns with browser autoplay policies that already block unmuted autoplay in most contexts.
  2. If autoplay is a product requirement, start muted. Add the muted attribute on <audio> and <video>. Muted autoplay is out of scope for 1.4.2 because no audio is actually playing until the user opts in.
  3. Expose controls on media elements. The native controls attribute renders a pause button and a volume slider that is independent of system volume, and both are keyboard-operable by default -- this is the shortest path to satisfying the criterion for <audio> and <video>[1].
  4. Place the control within reach of the start of the page. A mute button at the bottom of the page, behind a modal, or reachable only after tabbing through the header is not a usable mechanism. A screen reader user has to find and activate it while the audio is already drowning out the AT. Put it in the first focusable region on the page.
  5. Keep incidental clips under 3 seconds. Short UI sound effects (notification chimes, button clicks) that play for less than 3 seconds are out of scope. Anything longer, including looped short clips that exceed 3 seconds in aggregate, is in scope.
  6. Do not conflate 1.4.2 with 1.4.7. 1.4.7 Low or No Background Audio (Level AAA) governs the foreground-to-background mix inside a single spoken-audio recording. 1.4.2 is a Level A floor that applies to any autoplaying audio at all, regardless of content.

References

  1. [1] W3C (2023). Understanding Success Criterion 1.4.2: Audio Control. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html ↩ ↩ ↩