WCAG 3.0 is an active W3C Working Draft in development by the AGWG. Requirements, assertions, the conformance model and reporting tiers are still being developed and may change. The latest published draft is the 10 September 2026 Working Draft; this site follows the editors’ draft, which also includes exploratory provisions.
developingCore requirement
Page/view audio adjustable
Group: user-control • Guideline: media-control
Summary in Plain English
Where audio plays automatically, users can pause it, stop it, and adjust its volume separately from the system volume. All three are required, which is stricter than WCAG 2.2's 1.4.2, where any one of them is enough.
Why It Matters
Background audio masks a screen reader's speech, making the page unusable until it stops - and the system volume control turns off both at once.
For audio content in a media player, check that the media player has controls that can pause, stop, or adjust the audio volume.
For audio content set at an application level, check that there is a central setting that enables or disables audio across the application.
Check that one of these are present:
a. There is a mechanism within the first three elements in the page / view for the user to pause, stop, or adjust the audio volume;
b. There are keyboard controls that can pause, stop, or adjust the audio volume.
Expected results
#2, #3, or #4 is true.
W3C Working Group Status
W3C Maturity Status:developing
Track / Group:user-control
The draft records no open editors' notes on this provision.
W3C Threads on This Provision
1 GitHub thread carrying 3 comments,
fetched from w3c/wcag3 by the
tracker. Titles, numbers and states are the threads' own.
What the Argument Is About
A short 2020 exchange about why WCAG 2 allows autoplaying audio 3 seconds but auto-updating content 5, ending with bruce-usab preferring not to touch it in the 2.x series and an unpursued suggestion that WCAG 3 regroup audio with motion.
Positions taken in the thread
Harmonise the limits and regroup the requirementWildebrew
Opened #181 arguing the 3-versus-5-second split is hard to measure and has no rationale: a screen reader user is not less patient than a sighted one, and the two-second gap just adds complexity for testers. Also questions why autoplaying audio sits under Perceivable while auto-updating content sits under Operable, when unstoppable loud audio blocks operation exactly as animation does. His opening recommendation is to drop the autoplaying audio criterion altogether and add its requirement to 2.2.2 or its WCAG 3 equivalent, so the factors are assessed together. When alastc floats increasing the time on 1.4.2, Wildebrew agrees, recommending 1.4.2 change from 3 seconds to 5 to keep backwards compatibility, and treats WCAG 3 as the opportunity to group all page-level sound and animation together.
Not worth a backwards-incompatible changealastc, bruce-usab
alastc notes the limits were set around 14 years earlier and no explanation is to hand, and that changing them would likely be backwards-incompatible — content passing WCAG 2.2 might not pass 2.0 or 2.1 — and he floats increasing the time on 1.4.2 as the alternative, while asking what the benefit would be given how long it has been that way. bruce-usab offers the historical guess that annoying sounds used to start immediately while animation and video took a few seconds to load, and five seconds of unwanted music was plainly too much. He does not claim the distinction is coherent, but would rather not make this change in the 2.x series.
Agreed
The 3-versus-5-second difference has no principled justification anyone in the thread could produce.
Still open
Whether 1.4.2 should be raised from 3 seconds to 5 within WCAG 2.x — alastc floated it, Wildebrew recommended it, and bruce-usab would rather not make the change in the 2.x series.
Wildebrew's actual proposal — that WCAG 3 group autoplaying audio with page-level animation and auto-updating content rather than keeping them apart — was never answered and the thread stopped in April 2020.
Note
Three comments total, all from 2020, in a thread carrying both this provision's label and "No visual motion". Wildebrew's second comment is a mail reply with the quoted email trailer left in.
A mechanism is available to pause, stop, and adjust the volume independently of the overall system volume level, of any automatically playing audio in a page/view.
:::applies-when
- Notifications or other interruptions are present.
:::
:::note
Mechanisms include controls on each instance of content, or a single app-wide control that disables audio, for example: app-wide earcons.
:::