WCAG 1.4.7: Low or No Background Audio

What This Rule Means

WCAG Success Criterion 1.4.7 — Low or No Background Audio — applies to pre-recorded audio-only content that contains speech in the foreground. It does not apply to audio that is itself a musical performance, such as a song, or to audio that is primarily an ambient soundscape with no intended speech component. When speech-based audio content is present, the criterion requires that at least one of the following three conditions is met:

• No background audio: The audio track contains speech with no background sounds at all — silence behind the voice.
• User control: Any background audio can be turned off by the user, independently of the foreground speech, without affecting the speech content.
• 20 dB rule: Background sounds are at least 20 decibels lower in volume than the foreground speech. A 20 dB difference roughly equates to background audio being four times quieter than the speech, which is a meaningful perceptual gap for most listeners.

A pass is recorded when any of those three conditions is fully satisfied. A fail occurs when foreground speech competes with background audio that cannot be turned off and whose volume difference is less than 20 dB relative to the speech signal. Note that occasional sound effects — such as a brief notification chime — that last only one or two seconds are explicitly exempted from this requirement by the WCAG specification.

This criterion applies to the audio track regardless of whether that audio is delivered as a standalone audio file, as the audio component of a video, or embedded via a podcast player, HTML5 <audio> element, or a third-party media widget. The requirement is about the production of the audio content itself, not about a specific HTML element or ARIA attribute — which is why automated scanning tools cannot reliably detect violations and manual review of the actual audio content is always necessary.

Why It Matters

Approximately 1.5 billion people worldwide live with some degree of hearing loss, according to the World Health Organization. Even moderate hearing loss can make it extremely difficult — sometimes impossible — to isolate a speaker's voice when background music, ambient noise, or other audio elements are mixed at similar or competing volume levels. For users who rely on hearing aids or cochlear implants, background audio interference is amplified alongside the speech, making intelligibility dramatically worse rather than better.

Users with cognitive disabilities, including those with attention-deficit disorders, auditory processing disorders, or traumatic brain injuries, also face significant challenges when audio tracks contain competing sounds. Even when the listener has no measurable hearing loss, their brain may struggle to filter out irrelevant audio signals and focus on the speech content, leading to fatigue, comprehension failure, or complete exclusion from the content.

Consider a concrete real-world scenario: a Turkish government agency publishes a recorded audio explainer about how citizens can apply for a social benefit. The narrator's voice is mixed over a continuous background music track at roughly equal volume levels. A user with moderate sensorineural hearing loss visits the page using a hearing aid. Because the hearing aid amplifies all frequencies simultaneously, the music competes directly with the narrator's speech. The user cannot understand the instructions and misses a deadline for their benefit application. Had the audio been recorded with no background music, or had a volume control been provided to suppress the background track independently, the user would have had equal access to the information.

Beyond disability, clear audio with minimal background noise improves comprehension for all users — those listening in noisy environments on mobile devices, non-native speakers of the language being spoken, and users in low-bandwidth situations where audio quality may already be degraded. There are also indirect SEO benefits: transcripts of clearly intelligible audio produce higher-quality text content that search engines can index, improving the discoverability of your content.

Related Axe-core Rules

WCAG 1.4.7 requires manual testing. There is no axe-core automated rule that can detect this violation, and this is by design. Automated accessibility scanners such as axe-core, Lighthouse, or IBM Equal Access Checker operate by analyzing the DOM structure, HTML attributes, ARIA roles, and computed styles of a web page. They have no capability to:

• Analyze the audio content of a file: Scanners cannot open an audio or video file and measure the relative decibel levels of foreground speech versus background audio. Doing so would require audio signal processing far beyond the scope of a DOM-based accessibility checker.
• Detect whether a separate background audio control exists and works correctly: Even if a UI control labeled "Turn off background music" is present in the DOM, a scanner cannot verify that it actually suppresses the background audio track without affecting the speech track, nor can it verify the control works as expected in all browsers.
• Distinguish speech from non-speech audio: Automated tools cannot reliably classify an audio file as speech-primary, music-primary, or ambient-primary, which is the prerequisite determination before the criterion even applies.

Because all evaluation must be done by a human reviewer listening to the content and, where needed, using audio analysis software to measure decibel levels, axe-core flags this criterion as requiring manual review. When you run axe DevTools against a page containing <audio> or <video> elements, the tool may surface a general media-related advisory reminding you to manually evaluate audio quality criteria, but it will not produce a pass or fail verdict for 1.4.7 automatically.

How to Test

1. Inventory all audio content on the page. Load the page and identify every <audio> element, every <video> element with an audio track, every embedded podcast or media player, and any background audio that plays automatically. Determine whether each piece of audio is pre-recorded and contains foreground speech. If it is a pure music track or ambient sound with no speech, 1.4.7 does not apply to it.
2. Run an automated scan for baseline issues. Use axe DevTools, Lighthouse, or the Accsible widget's built-in audit to scan the page. While these tools will not assess audio quality, they may flag missing captions, absent controls attributes on <audio> elements, or related media accessibility issues. Address any flagged issues before proceeding to manual audio evaluation.
3. Listen to each qualifying audio track in its entirety. Use the page's built-in player or download the file and open it in a media player. Specifically listen for background music, ambient sound, or other non-speech audio that plays simultaneously with the foreground speech.
4. Assess whether background audio can be turned off independently. If the player provides a separate control to mute or lower background music without affecting the voice track, verify that this control works as expected across Chrome, Firefox, and Safari. Test with keyboard-only navigation to confirm the control is accessible.
5. Measure decibel levels if background audio is present and cannot be turned off. Import the audio file into a free audio editor such as Audacity. Use the built-in waveform or spectrogram view and the "Analyze > Contrast" tool (or equivalent) to measure the average RMS level of the speech segments versus the average RMS level of the background audio segments. Confirm the difference is at least 20 dB. If you do not have access to audio analysis software, use your professional judgment as an experienced listener: if a typical person with mild hearing loss would find the background audio distracting or obscuring, treat it as a likely failure.
6. Test with assistive technologies. Using NVDA with Firefox, VoiceOver with Safari on macOS, and JAWS with Chrome, navigate to each audio player. Confirm that all controls — including any separate background audio toggle — are reachable by keyboard (Tab/Shift+Tab), announced correctly by the screen reader, and operable with Enter or Space. This does not test the audio quality directly, but confirms that any remediation controls you have added are accessible.
7. Document findings. Record which audio files pass (no background audio, user control available, or 20 dB difference confirmed), which fail, and which are exempt (short sound effects under 2 seconds, or audio that is primarily music rather than speech).

How to Fix

Scenario 1: Background music mixed too loudly — Incorrect

<!-- Audio file contains a narrator speaking over background music
     mixed at roughly equal volume levels. No separate control exists.
     This fails WCAG 1.4.7 because background audio is not 20 dB below speech
     and cannot be turned off independently. -->
<audio controls src='product-explainer.mp3'>
  Your browser does not support the audio element.
</audio>

Scenario 1: Background music mixed too loudly — Correct

<!-- The audio file has been re-exported with no background music.
     If background music is desired for branding, produce two separate
     audio tracks: one speech-only and one with music. Offer the
     speech-only version as the default accessible option. -->
<audio controls src='product-explainer-speech-only.mp3'>
  Your browser does not support the audio element.
</audio>
<p>
  <a href='product-explainer-with-music.mp3'>
    Listen to version with background music (may be harder to follow for some users)
  </a>
</p>

Scenario 2: Background audio with an independent mute control — Incorrect

<!-- A custom player claims to offer background audio control,
     but the button is not keyboard-accessible and has no accessible name.
     Sighted mouse users can click it, but screen reader users and
     keyboard-only users cannot reach or operate the control. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play</button>
  <div onclick='toggleBackground()' style='cursor:pointer'>
    <img src='music-icon.png'>
  </div>
</div>

Scenario 2: Background audio with an independent mute control — Correct

<!-- The background audio toggle is now a proper <button> element with
     an accessible name, keyboard focus, and an aria-pressed state so
     screen readers announce whether background audio is on or off. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <audio id='bg-audio' src='background-ambience.mp3' loop></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play lecture</button>
  <button
    id='bg-toggle'
    aria-pressed='true'
    onclick='toggleBackground()'
  >
    Background audio: on
  </button>
</div>
<script>
  function toggleBackground() {
    var bg = document.getElementById('bg-audio');
    var btn = document.getElementById('bg-toggle');
    if (bg.paused) {
      bg.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.textContent = 'Background audio: on';
    } else {
      bg.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.textContent = 'Background audio: off';
    }
  }
</script>

Scenario 3: Autoplay background audio on page load — Incorrect

<!-- Background audio autoplays when the page loads and there is
     no way to turn it off. If a narrator audio also plays, the
     background audio will compete with it and cannot be suppressed. -->
<audio autoplay loop src='ambient-background.mp3'></audio>
<audio controls src='welcome-message.mp3'></audio>

Scenario 3: Autoplay background audio on page load — Correct

<!-- Background audio does not autoplay. A clearly labeled, keyboard-
     accessible button allows the user to opt in if desired. The speech
     audio is presented independently and cleanly without competition. -->
<audio id='bg' loop src='ambient-background.mp3'></audio>
<button onclick='document.getElementById("bg").play()'>
  Play background music (optional)
</button>
<audio controls src='welcome-message.mp3'>
  Your browser does not support the audio element.
</audio>

Common Mistakes

• Mixing background music at -10 dB instead of the required -20 dB: Producers often apply a modest volume reduction to background music and assume it is sufficient. The WCAG standard requires a full 20 dB difference (approximately four times quieter), not just a noticeable reduction. Always verify with an audio analysis tool rather than relying on subjective judgment alone.
• Confusing the overall player volume control with an independent background audio control: A master volume slider that lowers both speech and background audio simultaneously does not satisfy the "user can turn off background audio" condition. The control must suppress only the background audio without affecting the foreground speech.
• Assuming the criterion only applies to standalone audio files: Many developers overlook that the audio track of a video element is equally subject to 1.4.7. A video explainer with loud background music mixed into the audio track fails the criterion just as a podcast file would.
• Treating all short sounds as exempt: The WCAG exemption for brief sound effects applies only to sounds that last two seconds or less. A recurring short jingle that repeats every few seconds, or a background loop of short sounds, is not covered by this exemption and must still comply.
• Not testing the background audio toggle with keyboard-only navigation: Teams often implement a visually appealing mute button using a non-interactive element like a <div> or <span>, which is not reachable by Tab key and not operable with Enter or Space. Use a native <button> element so keyboard and assistive technology support is built in.
• Forgetting to add aria-pressed or equivalent state to background audio toggle buttons: Without a state indicator, screen reader users can operate the button but cannot tell whether background audio is currently on or off. Always reflect the current state in the button's accessible name or via aria-pressed.
• Producing only one mixed audio file instead of offering separate tracks: When background audio is integral to the creative intent, teams often export a single mixed file rather than offering a speech-only alternative. Providing a separate speech-only version costs very little additional production effort and eliminates the compliance risk entirely.
• Applying 1.4.7 to live audio streams: The criterion explicitly covers pre-recorded audio only. Live audio broadcasts are not subject to this specific rule, though other criteria such as 1.4.4 (Resize Text) and captions requirements may still apply to associated content.
• Neglecting to check third-party embedded players: When content is embedded from external platforms (podcast hosts, video CDNs, audio sharing services), teams often assume compliance is the platform's responsibility. However, the page owner is accountable for accessibility of all content on their pages, including embedded media. Verify that the third-party player either meets the audio quality requirements or offers the necessary controls.
• Measuring peak levels instead of average RMS levels when checking the 20 dB requirement: The 20 dB threshold in WCAG 1.4.7 refers to the perceptual loudness of the audio, best approximated by average RMS (Root Mean Square) levels, not instantaneous peak levels. Using peak level measurements can produce misleadingly favorable readings that do not reflect the actual listening experience.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility requirements for a broad range of public and private sector entities operating in Turkey. The Circular adopts WCAG 2.2 as its normative technical standard and defines specific conformance obligations based on the type of organization.

The entities subject to mandatory compliance under the Circular include public institutions and government agencies at all levels, e-commerce platforms, banks and financial service providers, hospitals and healthcare institutions, telecommunications operators with 200,000 or more subscribers, licensed travel agencies, private transportation companies, and private schools authorized by the Ministry of National Education (MoNE). These organizations are required to meet WCAG 2.2 Level A and Level AA at minimum.

WCAG 1.4.7 — Low or No Background Audio — is a Level AAA criterion. This means it is not among the criteria that covered entities are legally obligated to meet under the 2025/10 Circular's baseline requirements. However, several important considerations apply. First, organizations that voluntarily commit to AAA conformance — or that serve populations with high concentrations of hearing-impaired users, such as hospitals, audiology clinics, or social services agencies — should treat 1.4.7 as effectively mandatory for their context. Second, any entity whose digital services include audio-based instructional content, customer service recordings, e-learning modules, or informational broadcasts directed at the public will find that meeting 1.4.7 substantially improves the real-world usability of those services for Turkish citizens with hearing disabilities.

Turkey has a significant population of individuals with hearing impairment, and the Circular reflects a government commitment to ensuring equal digital participation. While AAA criteria are positioned as aspirational in the technical standard, Turkish public institutions in particular are encouraged to exceed minimum requirements wherever their content and resources allow. Demonstrating 1.4.7 compliance signals organizational maturity, reduces legal and reputational risk, and positions Turkish digital services as leaders in inclusive design both domestically and in international markets where AAA conformance may be contractually required.