WCAG 1.4.7: Geringe oder keine Hintergrundgeräusche

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 1.4.7 – Geringe oder keine Hintergrundgeräusche – gilt für vorab aufgezeichnete, ausschließlich akustische Inhalte, die Sprache im Vordergrund enthalten. Es gilt nicht für Audio, das selbst eine musikalische Darbietung ist, etwa ein Lied, oder für Audio, das in erster Linie eine Umgebungs-Klanglandschaft ohne beabsichtigte Sprachkomponente darstellt. Wenn sprachbasierte Audioinhalte vorhanden sind, verlangt das Kriterium, dass mindestens eine der folgenden drei Bedingungen erfüllt ist:

• Kein Hintergrundaudio: Die Audiospur enthält Sprache ohne jegliche Hintergrundgeräusche – Stille hinter der Stimme.
• Benutzersteuerung: Jedes Hintergrundaudio kann vom Benutzer unabhängig von der Sprache im Vordergrund ausgeschaltet werden, ohne den Sprachinhalt zu beeinträchtigen.
• 20-dB-Regel: Hintergrundgeräusche sind mindestens 20 Dezibel leiser als die Sprache im Vordergrund. Ein Unterschied von 20 dB entspricht ungefähr einem viermal leiseren Hintergrundaudio im Vergleich zur Sprache, was für die meisten Zuhörer eine deutlich wahrnehmbare Differenz darstellt.

Ein Bestanden wird verzeichnet, wenn eine dieser drei Bedingungen vollständig erfüllt ist. Ein Nicht bestanden liegt vor, wenn die Sprache im Vordergrund mit Hintergrundaudio konkurriert, das nicht ausgeschaltet werden kann und dessen Lautstärkeunterschied im Verhältnis zum Sprachsignal weniger als 20 dB beträgt. Beachten Sie, dass gelegentliche Soundeffekte – wie ein kurzer Benachrichtigungston – von nur ein oder zwei Sekunden Dauer gemäß der WCAG-Spezifikation ausdrücklich von dieser Anforderung ausgenommen sind.

Dieses Kriterium gilt für die Audiospur unabhängig davon, ob das Audio als eigenständige Audiodatei bereitgestellt wird, als Audiokomponente eines Videos, oder über einen Podcast-Player, ein HTML5-<audio>-Element oder ein Medien-Widget eines Drittanbieters eingebettet ist. Die Anforderung bezieht sich auf die Produktion des Audiomaterials selbst, nicht auf ein bestimmtes HTML-Element oder ein ARIA-Attribut – weshalb automatisierte Scantools Verstöße nicht zuverlässig erkennen können und eine manuelle Überprüfung des tatsächlichen Audiomaterials immer erforderlich ist.

Warum das wichtig ist

Laut Weltgesundheitsorganisation leben weltweit etwa 1,5 Milliarden Menschen mit einer Form von Hörverlust. Schon ein moderater Hörverlust kann es extrem schwierig – manchmal unmöglich – machen, die Stimme eines Sprechers zu isolieren, wenn Hintergrundmusik, Umgebungsgeräusche oder andere Audioelemente in ähnlicher oder konkurrierender Lautstärke mitgemischt sind. Für Nutzer, die auf Hörgeräte oder Cochlea-Implantate angewiesen sind, wird die Störung durch Hintergrundaudio zusammen mit der Sprache verstärkt, was die Verständlichkeit drastisch verschlechtert statt verbessert.

Nutzer mit kognitiven Beeinträchtigungen, einschließlich Personen mit Aufmerksamkeitsstörungen, auditiven Verarbeitungsstörungen oder traumatischen Hirnverletzungen, stehen ebenfalls vor erheblichen Herausforderungen, wenn Audiospuren konkurrierende Geräusche enthalten. Selbst wenn beim Zuhörer kein messbarer Hörverlust vorliegt, kann es dem Gehirn schwerfallen, irrelevante Audiosignale herauszufiltern und sich auf den Sprachinhalt zu konzentrieren, was zu Ermüdung, Verständnisschwierigkeiten oder vollständigem Ausschluss vom Inhalt führen kann.

Betrachten Sie ein konkretes Szenario aus der Praxis: Eine türkische Regierungsbehörde veröffentlicht eine aufgezeichnete Audio-Erklärung dazu, wie Bürger eine Sozialleistung beantragen können. Die Stimme des Sprechers ist über eine durchgehende Hintergrundmusikspur gemischt, und beide liegen ungefähr auf demselben Lautstärkeniveau. Ein Nutzer mit moderatem sensorineuralem Hörverlust besucht die Seite mit einem Hörgerät. Da das Hörgerät alle Frequenzen gleichzeitig verstärkt, konkurriert die Musik direkt mit der Sprache des Sprechers. Der Nutzer kann die Anweisungen nicht verstehen und verpasst eine Frist für seinen Leistungsantrag. Wäre das Audio ohne Hintergrundmusik aufgenommen worden oder wäre eine Lautstärkeregelung bereitgestellt worden, um die Hintergrundspur unabhängig zu unterdrücken, hätte der Nutzer gleichberechtigten Zugang zu den Informationen gehabt.

Über Behinderungen hinaus verbessert klares Audio mit minimalen Hintergrundgeräuschen das Verständnis für alle Nutzer – für diejenigen, die in lauten Umgebungen auf mobilen Geräten zuhören, für Nicht-Muttersprachler der gesprochenen Sprache und für Nutzer in Situationen mit geringer Bandbreite, in denen die Audioqualität bereits beeinträchtigt sein kann. Es gibt auch indirekte SEO-Vorteile: Transkripte von klar verständlichem Audio erzeugen hochwertigere Textinhalte, die von Suchmaschinen indexiert werden können und so die Auffindbarkeit Ihrer Inhalte verbessern.

Verwandte Axe-core-Regeln

WCAG 1.4.7 erfordert manuelle Tests. Es gibt keine automatisierte axe-core-Regel, die diesen Verstoß erkennen kann, und das ist beabsichtigt. Automatisierte Barrierefreiheits-Scanner wie axe-core, Lighthouse oder IBM Equal Access Checker arbeiten, indem sie die DOM-Struktur, HTML-Attribute, ARIA-Rollen und berechnete Styles einer Webseite analysieren. Sie haben keinerlei Möglichkeit:

• Den Audiogehalt einer Datei zu analysieren: Scanner können keine Audio- oder Videodatei öffnen und die relativen Dezibelpegel von Sprache im Vordergrund im Vergleich zu Hintergrundaudio messen. Dies würde eine Audio-Signalverarbeitung erfordern, die weit über den Umfang eines DOM-basierten Barrierefreiheits-Checkers hinausgeht.
• Zu erkennen, ob eine separate Hintergrundaudio-Steuerung existiert und korrekt funktioniert: Selbst wenn ein UI-Element mit der Beschriftung „Hintergrundmusik ausschalten“ im DOM vorhanden ist, kann ein Scanner nicht überprüfen, ob es tatsächlich die Hintergrund-Audiospur unterdrückt, ohne die Sprachspur zu beeinflussen, noch kann er verifizieren, dass die Steuerung in allen Browsern wie erwartet funktioniert.
• Sprache von Nicht-Sprach-Audio zu unterscheiden: Automatisierte Tools können eine Audiodatei nicht zuverlässig als sprachdominant, musikdominant oder umgebungsdominant klassifizieren, was die notwendige Vorentscheidung ist, bevor das Kriterium überhaupt anwendbar ist.

Da die gesamte Bewertung von einem menschlichen Prüfer vorgenommen werden muss, der den Inhalt anhört und bei Bedarf Audio-Analyse-Software verwendet, um Dezibelpegel zu messen, kennzeichnet axe-core dieses Kriterium als manuell zu prüfend. Wenn Sie axe DevTools auf einer Seite mit <audio>- oder <video>-Elementen ausführen, kann das Tool einen allgemeinen medienbezogenen Hinweis anzeigen, der Sie daran erinnert, die Audioqualitätskriterien manuell zu bewerten, aber es wird nicht automatisch ein Bestanden- oder Nicht-bestanden-Urteil für 1.4.7 ausgeben.

Wie man testet

1. Erfassen Sie alle Audioinhalte auf der Seite. Laden Sie die Seite und identifizieren Sie jedes <audio>-Element, jedes <video>-Element mit Audiospur, jeden eingebetteten Podcast oder Medienplayer und jedes Hintergrundaudio, das automatisch abgespielt wird. Bestimmen Sie, ob jedes Audio vorab aufgezeichnet ist und Sprache im Vordergrund enthält. Handelt es sich um eine reine Musikspur oder Umgebungsgeräusche ohne Sprache, gilt 1.4.7 nicht.
2. Führen Sie einen automatisierten Scan auf Basisprobleme durch. Verwenden Sie axe DevTools, Lighthouse oder das integrierte Audit des Accsible-Widgets, um die Seite zu scannen. Auch wenn diese Tools die Audioqualität nicht bewerten, können sie fehlende Untertitel, fehlende controls-Attribute bei <audio>-Elementen oder verwandte Probleme der Medienzugänglichkeit markieren. Beheben Sie alle gemeldeten Probleme, bevor Sie mit der manuellen Audio-Bewertung fortfahren.
3. Hören Sie jede qualifizierende Audiospur vollständig an. Verwenden Sie den eingebauten Player der Seite oder laden Sie die Datei herunter und öffnen Sie sie in einem Mediaplayer. Achten Sie speziell auf Hintergrundmusik, Umgebungsgeräusche oder andere nichtsprachliche Audioelemente, die gleichzeitig mit der Sprache im Vordergrund abgespielt werden.
4. Bewerten Sie, ob Hintergrundaudio unabhängig ausgeschaltet werden kann. Wenn der Player eine separate Steuerung zum Stummschalten oder Verringern der Hintergrundmusik bietet, ohne die Sprachspur zu beeinflussen, überprüfen Sie, ob diese Steuerung in Chrome, Firefox und Safari wie erwartet funktioniert. Testen Sie mit reiner Tastaturnavigation, um sicherzustellen, dass die Steuerung zugänglich ist.
5. Messen Sie die Dezibelpegel, wenn Hintergrundaudio vorhanden ist und nicht ausgeschaltet werden kann. Importieren Sie die Audiodatei in einen kostenlosen Audio-Editor wie Audacity. Verwenden Sie die integrierte Wellenform- oder Spektrogramm-Ansicht und das Tool „Analyze > Contrast“ (oder ein entsprechendes), um den durchschnittlichen RMS-Pegel der Sprachsegmente mit dem durchschnittlichen RMS-Pegel der Hintergrundaudio-Segmente zu vergleichen. Bestätigen Sie, dass der Unterschied mindestens 20 dB beträgt. Wenn Sie keinen Zugang zu Audio-Analyse-Software haben, nutzen Sie Ihr professionelles Urteil als erfahrener Zuhörer: Wenn eine typische Person mit leichtem Hörverlust das Hintergrundaudio als ablenkend oder überlagernd empfinden würde, behandeln Sie es als wahrscheinlichen Verstoß.
6. Testen Sie mit unterstützenden Technologien. Navigieren Sie mit NVDA und Firefox, VoiceOver und Safari auf macOS sowie JAWS und Chrome zu jedem Audioplayer. Stellen Sie sicher, dass alle Steuerelemente – einschließlich einer separaten Hintergrundaudio-Umschaltung – per Tastatur (Tab/Shift+Tab) erreichbar, vom Screenreader korrekt angesagt und mit Enter oder Leertaste bedienbar sind. Dies testet nicht direkt die Audioqualität, bestätigt aber, dass alle von Ihnen hinzugefügten Abhilfesteuerungen zugänglich sind.
7. Dokumentieren Sie die Ergebnisse. Halten Sie fest, welche Audiodateien bestehen (kein Hintergrundaudio, Benutzersteuerung verfügbar oder 20-dB-Differenz bestätigt), welche durchfallen und welche ausgenommen sind (kurze Soundeffekte unter 2 Sekunden oder Audio, das primär Musik statt Sprache ist).

Wie man Probleme behebt

Szenario 1: Hintergrundmusik zu laut abgemischt – Falsch

<!-- 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>

Szenario 1: Hintergrundmusik zu laut abgemischt – Richtig

<!-- 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>

Szenario 2: Hintergrundaudio mit unabhängiger Stummschaltung – Falsch

<!-- 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>

Szenario 2: Hintergrundaudio mit unabhängiger Stummschaltung – Richtig

<!-- 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>

Szenario 3: Automatisches Hintergrundaudio beim Laden der Seite – Falsch

<!-- 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>

Szenario 3: Automatisches Hintergrundaudio beim Laden der Seite – Richtig

<!-- 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>

Häufige Fehler

• Hintergrundmusik auf -10 dB statt der erforderlichen -20 dB abmischen: Produzenten reduzieren die Lautstärke der Hintergrundmusik oft nur moderat und gehen davon aus, dass dies ausreicht. Der WCAG-Standard verlangt jedoch eine vollständige Differenz von 20 dB (ungefähr viermal leiser), nicht nur eine merkliche Reduktion. Überprüfen Sie immer mit einem Audio-Analyse-Tool, statt sich ausschließlich auf subjektives Urteil zu verlassen.
• Die Gesamtlautstärkeregelung des Players mit einer unabhängigen Hintergrundaudio-Steuerung verwechseln: Ein Master-Lautstärkeregler, der Sprache und Hintergrundaudio gleichzeitig leiser stellt, erfüllt nicht die Bedingung „Benutzer kann Hintergrundaudio ausschalten“. Die Steuerung muss ausschließlich das Hintergrundaudio unterdrücken, ohne die Sprache im Vordergrund zu beeinflussen.
• Annehmen, das Kriterium gelte nur für eigenständige Audiodateien: Viele Entwickler übersehen, dass die Audiospur eines Video-Elements gleichermaßen 1.4.7 unterliegt. Ein Video-Erklärstück mit laut abgemischter Hintergrundmusik in der Audiospur verstößt gegen das Kriterium genauso wie eine Podcast-Datei.
• Alle kurzen Geräusche als ausgenommen behandeln: Die WCAG-Ausnahme für kurze Soundeffekte gilt nur für Geräusche, die zwei Sekunden oder weniger dauern. Eine wiederkehrende kurze Jingle-Sequenz, die alle paar Sekunden abgespielt wird, oder eine Hintergrundschleife aus kurzen Geräuschen fällt nicht unter diese Ausnahme und muss dennoch konform sein.
• Die Hintergrundaudio-Umschaltung nicht mit reiner Tastaturnavigation testen: Teams implementieren häufig eine optisch ansprechende Stummschalt-Schaltfläche mit einem nicht interaktiven Element wie <div> oder <span>, das mit der Tab-Taste nicht erreichbar und mit Enter oder Leertaste nicht bedienbar ist. Verwenden Sie ein natives <button>-Element, damit Tastatur- und Assistenztechnologie-Unterstützung eingebaut ist.
• Vergessen, aria-pressed oder einen gleichwertigen Zustand zu Hintergrundaudio-Schaltflächen hinzuzufügen: Ohne Zustandsanzeige können Screenreader-Nutzer die Schaltfläche zwar bedienen, aber nicht erkennen, ob das Hintergrundaudio derzeit ein- oder ausgeschaltet ist. Spiegeln Sie den aktuellen Zustand immer im zugänglichen Namen der Schaltfläche oder über aria-pressed wider.
• Nur eine gemischte Audiodatei produzieren, statt separate Spuren anzubieten: Wenn Hintergrundaudio integraler Bestandteil der kreativen Intention ist, exportieren Teams häufig eine einzige gemischte Datei, statt eine sprachreine Alternative anzubieten. Eine separate Sprachversion bereitzustellen, verursacht nur geringen zusätzlichen Produktionsaufwand und eliminiert das Compliance-Risiko vollständig.
• 1.4.7 auf Live-Audiostreams anwenden: Das Kriterium gilt ausdrücklich nur für vorab aufgezeichnetes Audio. Live-Audioübertragungen unterliegen nicht dieser spezifischen Regel, auch wenn andere Kriterien wie 1.4.4 (Textvergrößerung) und Untertitelanforderungen weiterhin für zugehörige Inhalte gelten können.
• Versäumen, eingebettete Player von Drittanbietern zu prüfen: Wenn Inhalte von externen Plattformen (Podcast-Hosts, Video-CDNs, Audio-Sharing-Dienste) eingebettet werden, gehen Teams oft davon aus, dass die Plattform für die Einhaltung verantwortlich ist. Der Seitenbetreiber ist jedoch für die Barrierefreiheit aller Inhalte auf seinen Seiten verantwortlich, einschließlich eingebetteter Medien. Vergewissern Sie sich, dass der Player eines Drittanbieters entweder die Anforderungen an die Audioqualität erfüllt oder die notwendigen Steuerungen anbietet.
• Spitzenpegel statt durchschnittlicher RMS-Pegel messen, wenn die 20-dB-Anforderung geprüft wird: Die 20-dB-Schwelle in WCAG 1.4.7 bezieht sich auf die wahrgenommene Lautstärke des Audios, die am besten durch durchschnittliche RMS-Werte (Root Mean Square) angenähert wird, nicht durch momentane Spitzenpegel. Die Verwendung von Spitzenpegelmessungen kann irreführend günstige Werte liefern, die nicht der tatsächlichen Hörerfahrung entsprechen.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die digitale Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung übernimmt WCAG 2.2 als normative technische Norm und definiert spezifische Konformitätspflichten basierend auf dem Organisationstyp.

Zu den Einrichtungen, die unter die verbindliche Einhaltung der Verfügung fallen, gehören öffentliche Institutionen und Regierungsbehörden auf allen Ebenen, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitseinrichtungen, Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung (MoNE) zugelassen sind. Diese Organisationen sind verpflichtet, mindestens WCAG 2.2 Level A und Level AA zu erfüllen.

WCAG 1.4.7 – Geringe oder keine Hintergrundgeräusche – ist ein Kriterium der Stufe AAA. Das bedeutet, dass es nicht zu den Kriterien gehört, die die betroffenen Einrichtungen gemäß den Basisanforderungen der Verfügung 2025/10 rechtlich erfüllen müssen. Es gelten jedoch mehrere wichtige Überlegungen. Erstens sollten Organisationen, die sich freiwillig zu einer AAA-Konformität verpflichten – oder die Bevölkerungsgruppen mit einem hohen Anteil hörgeschädigter Nutzer bedienen, wie Krankenhäuser, Audiologie-Kliniken oder Sozialdienste – 1.4.7 in ihrem Kontext faktisch als verpflichtend behandeln. Zweitens werden alle Einrichtungen, deren digitale Dienste audio-basierte Lerninhalte, Kundenservice-Aufzeichnungen, E-Learning-Module oder Informationssendungen für die Öffentlichkeit umfassen, feststellen, dass die Erfüllung von 1.4.7 die tatsächliche Nutzbarkeit dieser Dienste für türkische Bürger mit Hörbehinderungen erheblich verbessert.

Die Türkei hat eine bedeutende Bevölkerung von Menschen mit Hörbeeinträchtigung, und die Verfügung spiegelt das Engagement der Regierung wider, eine gleichberechtigte digitale Teilhabe sicherzustellen. Während AAA-Kriterien im technischen Standard als aspirativ positioniert sind, werden insbesondere türkische öffentliche Institutionen ermutigt, die Mindestanforderungen zu übertreffen, wo immer ihre Inhalte und Ressourcen dies zulassen. Der Nachweis der Einhaltung von 1.4.7 signalisiert organisatorische Reife, reduziert rechtliche und Reputationsrisiken und positioniert türkische digitale Dienste als Vorreiter im inklusiven Design – sowohl im Inland als auch auf internationalen Märkten, in denen AAA-Konformität vertraglich gefordert sein kann.