1.4.2 Audio Control
- Level A
- Perceivable
- Since WCAG 2.0
Summary
Audio that starts by itself is more than an annoyance: for someone using a screen reader, it is a denial of access. Screen reader users listen to synthesised speech to operate the page, and autoplaying sound competes directly with that speech. Worse, turning the system volume down silences the screen reader along with the offending audio, so the user cannot even hear their own tool well enough to hunt for a stop button. This is why 1.4.2 is classed as an interference criterion: a failure can block a screen reader user from using the entire page, not just the noisy widget.
The auditor's mental model is a simple decision chain. Does any audio play automatically? If yes, does it stop on its own within 3 seconds? If not, is there a mechanism to pause or stop it, or to control its volume independently of the overall system volume, and can a user who cannot see the page actually find and operate that mechanism early, near the top of the page or among the first focusable controls, as W3C guidance describes? The criterion has been Level A since WCAG 2.0, and because the harm lands the moment the page loads, a technically present but buried control does not rescue the experience.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.1.4.2
- Software and native apps
- Clause 11.1.4.2 (via Table 11.1)
Clause 9.1.4.2 applies this criterion to web pages unchanged. For software, clause 11.1.4.2 carries the requirement through a word-substitution table (Table 11.1) that restates it for application user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Load each page fresh with sound on and simply listen. The usual sources are autoplaying video with an unmuted audio track, carousels or hero sections with sound, background or ambient music, and embedded third party players. Time anything that starts by itself: audio that ends within 3 seconds passes without further analysis. Note that modern browsers often block unmuted autoplay until the user has interacted with the site, so test in a state where the autoplay genuinely fires (allow sound for the site, or interact and then reload); the criterion grades the content's own behaviour, not the browser's rescue.
Where audio runs longer than 3 seconds, look for the mechanism. Acceptable forms are a pause or stop control, or a volume control that governs the page's audio independently of system volume (turning it to zero must be possible). Then verify findability and operability under the conditions the criterion protects: put focus at the top of the page and tab; the control should be reachable within the first few focus stops, per W3C guidance that users need to find it quickly at or near the beginning of the page. Run a screen reader while the audio plays and confirm you can locate and activate the control despite the noise. In devtools, check <audio> and <video> elements for autoplay without muted, and check scripts that call play() on load.
Common web failure spots: hero videos that unmute themselves, background music baked into a template with no player chrome, third party ad or media embeds whose mute lives inside an iframe at the end of the source order, and players that remember a playing state and resume voiced on the next page load.
iOS
This criterion carries over to native apps: the European standard restates it for application user interfaces through a word substitution table, so autoplaying audio in an iOS app is graded the same way as on the web. Test each screen from a fresh launch, including a first install run: splash or launch jingles, autoplay video feeds with sound, and in-app videos that start voiced are the usual sources. Anything automatic and longer than 3 seconds needs a pause, stop, or independent volume mechanism.
Run VoiceOver while you test; the interference is the evidence. iOS ducks other audio while VoiceOver speaks by default, which softens the harm, but ducking is a screen reader feature, not the app's mechanism: grade against the presence of a findable pause, stop, or app-level volume control. Check the swipe order with VoiceOver: a mute or sound toggle should be among the first elements reached on the screen, not after the entire feed. Also watch the independence requirement: the hardware volume buttons and the silent switch are overall system controls, so an app whose only "volume control" is deferring to system volume has not provided an independent mechanism. An in-app slider or mute that affects only the app's own playback does qualify.
Common iOS failure spots: onboarding and splash screens with unskippable sound, video feeds that autoplay voiced with the sound toggle hidden in settings, and game or promo screens with looping music and no in-app mute.
Android
The same word substitution applies under the European standard, so grade Android apps against the same chain. Test from a cold start and a fresh install: splash sounds, autoplay feeds, story or reel surfaces, and in-app videos that begin voiced. Time the audio; past 3 seconds, the app must offer pause, stop, or independent volume.
Test with TalkBack running. TalkBack also ducks media audio while speaking, but as on iOS that is assistive technology behaviour, not the app's mechanism. Verify a mute or pause control is present, early in the reading order, keyboard and switch reachable, and actually operable while the audio plays. Check independence carefully on Android: the volume keys move the shared media stream, which is overall system volume in this criterion's terms. An in-app control that merely opens the system volume panel is not independent; a per-video mute button, an app settings toggle for autoplay sound, or an in-app slider that scales only the app's own output all qualify. A feed whose videos autoplay muted and only voice after a deliberate tap passes, because no audio plays automatically.
Common Android failure spots: launch jingles on splash screens, autoplaying voiced video in list feeds with the mute buried per item at the end of each card's traversal order, and background music in games or promotional screens with no in-app sound setting.
Pass and fail examples
Passes:
- A short brand chime plays on load and finishes in under 3 seconds: within the criterion's allowance, no mechanism required.
- A hero video autoplays muted, with a clearly labelled unmute button: no audio plays automatically, and sound is the user's choice.
- Background music plays on load, and a pause button is the first focusable control on the page, operable by keyboard and screen reader.
- An app's video feed autoplays silently; tapping a speaker icon on a video turns its sound on for that session.
- Page audio longer than 3 seconds ships with an in-page volume slider that controls only that audio and can be set to zero, independent of system volume.
Fails:
- Looping background music with no pause, stop, or volume control anywhere on the page.
- An autoplaying voiced video whose mute button sits at the bottom of a long page, dozens of tab stops in: the mechanism exists but a screen reader user cannot find it early enough for it to function as one, per W3C guidance that the control must be at or near the beginning of the page.
- A stop control rendered as a custom element that only responds to mouse clicks: keyboard and screen reader users, the people the criterion protects, cannot operate it.
- An app splash screen plays a 6 second jingle with no way to skip or silence it.
- An in-app "volume" control that just moves the overall system media volume: turning it down silences the screen reader too, so it is not independent.
Not a fail under this criterion:
- Video that autoplays muted: no audio plays automatically, so 1.4.2 is satisfied regardless of length.
- Sound that starts only after the user presses play: not automatic.
- A silently autoplaying carousel or animation: moving content without sound belongs to SC 2.2.2 Pause, Stop, Hide.
- A voiced video that lacks captions: that is a media alternative finding under Captions (Prerecorded), not an audio control finding.
- Background music mixed too loudly behind narration inside a recording the user chose to play: that is SC 1.4.7 Low or No Background Audio, a Level AAA concern.
Commonly confused with
- SC 2.2.2 Pause, Stop, Hide. The cleanest split: motion there, sound here. 2.2.2 governs moving, blinking, and auto-updating content; 1.4.2 governs automatic sound. An autoplaying video with a voiced track that also moves for more than 5 seconds can genuinely trigger both, and the two findings carry separate evidence.
- The 1.2.x media alternatives, including Captions (Prerecorded). Those criteria ask whether media has equivalents (captions, transcripts, audio description). 1.4.2 does not care what the audio contains, only that it started by itself and whether the user can shut it up.
- SC 1.4.7 Low or No Background Audio. A Level AAA criterion about the mix inside speech audio the user is already listening to. Auditors sometimes file "the music drowns the narration" under 1.4.2; that is a 1.4.7 issue unless the audio also autoplayed.
- Browser autoplay blocking. A browser suppressing unmuted autoplay does not make the content conform; another browser, or a returning user who has interacted with the site, will get the sound. Grade the content's own behaviour.
- An unlabelled mute button. If a pause or mute mechanism exists but has no accessible name, the 1.4.2 mechanism question turns on whether screen reader users can realistically find and operate it; the naming defect itself files by element type, under SC 1.1.1 for image based controls or SC 4.1.2 for icon font, SVG, or CSS rendered controls. One finding, one criterion.
How AUDITSU tests this
AUDITSU's audit walkthrough puts audio control into the load behaviour checks for every page or screen you review. Arriving on each screen fresh, the walkthrough asks whether any sound started automatically, whether it stopped within 3 seconds, and, if not, directs you to locate the pause, stop, or independent volume mechanism and confirm it sits early in the focus and reading order. Because the walkthrough has you run a screen reader on the relevant screens, the interference is not theoretical: you hear the page audio compete with speech, and that recording or observation becomes the evidence attached to the finding.
Each question records a pass, fail, or not applicable result per screen, so silent screens close the criterion out quickly and noisy ones carry their evidence into the report tied to the exact screen and player. For the full guided workflow, see the audit platform.