WCAG 1.4.7 Low or No Background Audio: Making Audio Easier to Hear

What is WCAG 1.4.7?

WCAG 1.4.7 is a Level AA success criterion added in WCAG 2.1. It requires that when human speech is present in audio, background sounds must not prevent the speech from being heard or understood. The rule gives authors several ways to make speech accessible: reduce or remove background audio, let the user turn it off, or provide an alternative without background sounds.

When this criterion applies

• Audio-only content that contains spoken words, such as podcasts or audio articles.
• Video with spoken dialogue or narration.
• Multimedia where speech and background sounds play at the same time.

Practical ways to meet WCAG 1.4.7

There are four common approaches. Use the one that fits your production workflow and content type.

1. Provide a version with low or no background audio

Publish a second audio file or alternate video track that contains the same speech but without background music or effects. This is the simplest way to guarantee clear speech for people who need it.

2. Let the user turn off background audio

If background sounds are separate from speech on independent tracks, offer a player control to mute or lower the background track while keeping the speech track audible. This works well for interactive players and webcast platforms.

3. Reduce background audio during speech

Edit the mix so that background sounds are lowered or removed while someone is speaking. Avoid crowd noise, heavy music, or effects that mask consonants and sibilants.

4. Provide text alternatives

When changing audio is not feasible, provide accurate captions and a transcript. Captions help people who cannot hear clearly. A transcript gives a full, text version of spoken content for search and assistive technology.

Step-by-step testing checklist

1. Identify every audio segment that contains human speech.
2. Listen with common consumer devices: laptop speakers, mobile earbuds, and built-in phone speaker.
3. Confirm speech is intelligible when devices are set to typical listening volume. If not, try one of the four approaches above.
4. Check that any offered control actually mutes or lowers background audio while leaving speech audible.
5. Provide captions or a transcript for any content where speech remains hard to hear.

Tools and techniques for producers

• Use an editor such as Audacity or a DAW to inspect waveforms and to separate or lower background tracks.
• Use compressors and equalizers sparingly; these can help clarity but may not solve masking from music or effects.
• Record speech on a dedicated mic track when possible. Isolate ambient sound at source rather than fixing it in post.

Code pattern for offering alternate audio

Offer two files and a transcript link. This HTML fragment shows a simple pattern publishers can adapt.

<audio controls>
  <source src="speech-only.mp3" type="audio/mpeg">
  Your browser does not support the audio element.
</audio>

<!-- Optionally add the full program with background as a separate player -->
<audio controls>
  <source src="full-mix.mp3" type="audio/mpeg">
  Your browser does not support the audio element.
</audio>

<p><a href="transcript.txt">Transcript</a> available</p>

Common mistakes and how to avoid them

• Keeping loud music under speech. Lower or remove that music for a separate version.
• Relying only on automated gain or compression. These can bring up background noise as well as speech.
• Providing captions but not a clear audio option. Text helps, but many users need audible speech too.
• Not testing on small speakers. Mobile and laptop speakers reveal masking that studio monitors hide.

Decision framework: which fix to choose

Use this short guide to pick a solution.

• If you can produce separate tracks at source, offer a speech-only version.
• If content must retain music or effects for artistic reasons, provide a control to turn those off or provide a transcript and captions.
• If content is live, reduce background audio at the mixing desk and publish a clean on-demand version after the event.

Testing with real users and assistive tech

User testing matters. Invite people who use hearing aids, cochlear implants, captioning, or screen readers to try your players and transcripts. Observe whether they can access the spoken information without extra effort. Fix any workflow or player issues you discover.

Quick compliance checklist for WCAG 1.4.7

• Speech segments identified and reviewed.
• At least one of these provided: speech-only audio, user control of background, lowered background during speech, or accurate transcript/captions.
• Players tested on small speakers and mobile devices.
• Documentation for content editors so future uploads follow the same rules.

Where WCAG 1.4.7 fits with other success criteria

This criterion sits with other audio and multimedia rules. Captions and transcripts remain essential. Also check your media player for proper keyboard access and standard accessibility features so everyone can reach the controls that affect background audio.

If you follow the steps above you will make speech easier to hear for many users while keeping creative options. Start by auditing current audio assets, then decide on the most practical fix for each file.