F23: When Autoplay Audio Locks Out Screen Reader Users

71 million. That's the estimated number of people in the United States living with hearing loss significant enough to affect daily communication — and autoplay audio without controls doesn't just annoy them. It actively interferes with the assistive technology they depend on to use the web at all.

WCAG Failure F23 (opens in new window) has been in the catalog for years. The rule is straightforward: if audio plays for more than three seconds and users have no way to stop it — independently from their system volume — you've failed Success Criterion 1.4.2 Audio Control (opens in new window). And yet, here we are. Background music that loops indefinitely. Narrators that launch without warning. Video heroes that autoplay with sound. The same pattern, repeated across the web, in 2026.

This is one of those failures where the technical fix is genuinely simple. The organizational failure to apply it is the more interesting — and frustrating — story.

The Failure

F23 describes two core scenarios, both drawn directly from the W3C's official failure document (opens in new window):

Example 1: A site plays continuous background music with no pause, stop, or mute control visible to the user.

Example 2: A narrator begins speaking when the page loads, runs longer than three seconds, and provides no mechanism to stop playback.

The failure condition is precise: audio that (a) doesn't stop automatically within 3 seconds, AND (b) offers no independent stop/pause/mute control. Both conditions must be present. A three-second brand jingle that stops on its own is not a failure. A 30-second ambient soundscape with no controls is.

The problematic pattern often looks like this:

<!-- FAILURE: Autoplay audio with no controls -->
<audio autoplay loop>
  <source src="background-music.mp3" type="audio/mpeg">
</audio>
<!-- Or embedded in a video hero -->
<video autoplay>
  <source src="brand-intro.mp4" type="video/mp4">
</video>

No controls attribute. No visible stop button. No ARIA-labeled mechanism. Just sound, playing into whatever environment the user is in — including directly into the ear of someone wearing headphones with a screen reader running.

Why This Matters

For screen reader users, this isn't a minor inconvenience. It's a collision.

Screen readers — NVDA, JAWS, VoiceOver — communicate through audio output. When a page launches background music or a narrator at the same time the screen reader begins announcing page content, the result is two audio streams competing simultaneously. Users can't parse either one clearly. The experience is disorienting in a way that sighted users rarely appreciate: imagine trying to read a legal document while someone plays a podcast directly into your ear at the same volume, with no way to pause either.

Users with auditory processing disorders face a similar problem. Competing audio streams aren't just distracting — they can make comprehension functionally impossible. For users with tinnitus, unexpected loud audio can cause real discomfort.

There's a language access dimension here that rarely gets discussed. A screen reader user who speaks Vietnamese, navigating a site with an English-language narrator that can't be stopped, is dealing with three simultaneous audio conflicts: their screen reader, the site's narrator, and the cognitive load of processing a second language. Tools like idioma.chat (opens in new window) address this by translating not just visible page text but the full accessibility layer — ARIA labels, alt text, form validation messages, and dynamically loaded content — so that the accessibility layer itself works across languages. But none of that matters if autoplay audio is drowning everything out before a user can even orient to the page.

This intersection — language access and disability access — is addressed in separate silos far too often. Both are civil rights obligations. Both affect overlapping populations. Both fail when audio control is absent.

The Fix

The corrected pattern gives users agency:

<!-- CORRECT: Audio with visible, operable controls -->
<audio controls>
  <source src="background-music.mp3" type="audio/mpeg">
  Your browser does not support the audio element.
</audio>
<!-- For background audio that must autoplay, provide a stop mechanism -->
<audio id="bg-audio" autoplay>
  <source src="ambient.mp3" type="audio/mpeg">
</audio>
<button 
  type="button"
  aria-label="Stop background audio"
  onclick="document.getElementById('bg-audio').pause(); this.setAttribute('aria-label', 'Play background audio');">
  ⏸ Stop Audio
</button>
<!-- For video, disable autoplay or provide controls -->
<video controls preload="metadata">
  <source src="brand-intro.mp4" type="video/mp4">
</video>

Three things to note about the corrected pattern:

1. The stop/pause control must be keyboard-accessible. A <button> element handles this natively. A <div> with an onclick handler does not.
2. The control must be independent from system volume. A user shouldn't have to mute their entire device to stop your background music — that would also mute their screen reader.
3. The control should be early in the DOM. If audio starts on page load, the mechanism to stop it should be reachable before users have to navigate through significant page content.

The governing requirement is SC 1.4.2 Audio Control (opens in new window), which applies to all technologies except voice interaction interfaces. This is a Level A requirement — the baseline. Not Level AA. Not AAA. The floor.

Applying This

This failure is one of the roughly 37% of accessibility issues that automated testing tools can detect — specifically, the presence of autoplay without a controls attribute on an <audio> or <video> element. Axe, Lighthouse, and similar tools will flag the obvious cases. But they won't catch a JavaScript-triggered audio file that starts three seconds after page load, or a Flash-era embed that's been ported to an iframe. Manual testing remains essential, as our research on automated vs. manual testing methodology makes clear.

In code review: Add a linting rule or PR checklist item: any <audio> or <video> element with autoplay must have a corresponding, keyboard-accessible stop mechanism documented in the same PR.

In design: If a designer specs background audio or an autoplay video hero, the stop control should be part of the component spec — not an afterthought in QA. Accessibility requirements belong in the design system, not the defect backlog.

In QA: Test with a screen reader running. Launch the page. Can you hear both the screen reader and the site audio simultaneously? Can you stop the site audio using only the keyboard before navigating anywhere else on the page? If either answer is no, F23 is present.

Quick win vs. longer fix: Removing autoplay entirely is a two-minute fix that solves 80% of cases. For sites where autoplay is a genuine product requirement (a radio station, a meditation app), the longer fix is building a proper audio controller component with full keyboard support, visible state, and ARIA live region announcements when state changes.

Organizations navigating multiple compliance frameworks — WCAG, Section 508, EN 301 549 — will find that SC 1.4.2 appears across all of them. Our research on standards fragmentation documents how this kind of overlap can create paralysis. It shouldn't here. F23 is one of the clearest, most consistent requirements across every major accessibility standard. Fix it once; it satisfies all of them.

CORS Perspective

Through a Community / Operational / Risk / Strategic lens, F23 reveals a familiar organizational pattern: the people harmed most — screen reader users, people with auditory processing differences, multilingual users navigating in a second language — are rarely in the room when the "add some ambient music to the homepage" decision gets made. The operational fix is trivial. The community impact is significant. The risk is real: SC 1.4.2 is Level A, meaning its absence is a foundational compliance failure, not a minor gap. Strategically, the argument to leadership is simple — autoplay audio is also bad UX for non-disabled users, which means fixing it serves everyone and costs almost nothing. The CORS framework pushes us to ask: who bears the cost of this decision? In F23, the answer is always the people who can least afford it.