WCAG-Erfolgskriterien · Level A
WCAG 1.4.2: Audiosteuerung
WCAG 1.4.2 verlangt, dass jede Audioausgabe, die automatisch länger als drei Sekunden abgespielt wird, den Nutzern eine Möglichkeit bieten muss, sie zu pausieren, zu stoppen oder ihre Lautstärke unabhängig von der Systemlautstärke zu regeln. Dies verhindert, dass Audio die Ausgabe von Screenreadern stört, und schützt Nutzer vor unerwarteten, desorientierenden Geräuschen.
Was diese Regel bedeutet
WCAG 1.4.2 — Audiosteuerung ist ein Erfolgskriterium der Stufe A unter dem Prinzip „Wahrnehmbar“. Es besagt: Wenn auf einer Webseite irgendeine Audioausgabe automatisch länger als 3 Sekunden abgespielt wird, ist entweder ein Mechanismus verfügbar, um die Audioausgabe zu pausieren oder zu stoppen, oder ein Mechanismus ist verfügbar, um die Lautstärke der Audioausgabe unabhängig von der allgemeinen Systemlautstärke zu steuern.
Das Kriterium wird durch jegliche Audioinhalte ausgelöst, die ohne explizite Nutzeraktion zu spielen beginnen und länger als drei Sekunden andauern. Dazu gehören in eine Seite eingebettete Hintergrundmusik, automatisch abspielende Videos mit hörbarer Tonspur, Audio-Werbung, sich wiederholende Soundeffekte und gesprochene Einführungen, die beim Laden der Seite starten. Der entscheidende Ausdruck ist automatisch — Audio, die der Nutzer bewusst startet (Klick auf eine Abspieltaste, Aktivieren eines Links), fällt nicht unter diese Regel.
Um dieses Kriterium zu erfüllen, muss mindestens eine der folgenden Bedingungen zutreffen:
- Dem Nutzer wird eine Pausen- oder Stopp-Steuerung bereitgestellt, die die Audioausgabe vollständig anhält oder sie aussetzt, bis der Nutzer sie fortsetzt.
- Dem Nutzer wird eine Lautstärkeregelung bereitgestellt, die unabhängig von der Master-Lautstärke des Betriebssystems ist, sodass er die Audioausgabe reduzieren oder stummschalten kann, ohne andere Anwendungen oder Systemklänge zu beeinflussen.
Ein Mechanismus, der nur am oberen Rand der Seite erscheint und per Tastatur zugänglich ist, ist zulässig, muss aber erreichbar und bedienbar sein, bevor die Audioausgabe störend wird. Als bewährte Praxis gilt nachdrücklich, die Steuerung als allererstes interaktives Element in der Fokusreihenfolge zu platzieren, damit Tastatur- und Screenreader-Nutzer sie sofort vorfinden.
Die einzige offizielle Ausnahme, die in den WCAG definiert ist, betrifft Audio, die drei Sekunden oder weniger dauert. Kurze Benachrichtigungstöne oder kurze Klänge, die von selbst enden, sind ausgenommen. Es gibt keine Ausnahme für leise Audioausgabe, geloopte Audioausgabe oder Audio, das in Widgets von Drittanbietern eingebettet ist — all dies fällt unter die Regel, wenn es automatisch abgespielt wird und länger als drei Sekunden dauert.
Warum das wichtig ist
Unkontrollierte, automatisch abspielende Audioausgabe schafft erhebliche Barrieren für mehrere Gruppen von Menschen mit Behinderungen und verursacht sogar für nichtbehinderte Nutzer Reibung in ruhigen oder gemeinsam genutzten Umgebungen.
Screenreader-Nutzer sind die am stärksten betroffene Gruppe. Screenreader wie JAWS, NVDA und VoiceOver erzeugen synthetische Sprachausgabe, um Seiteninhalte zu vermitteln. Wenn eine Webseite gleichzeitig Hintergrundaudio oder eine Videotonspur abspielt, überlagern sich die beiden Audioströme. Die Stimme des Screenreaders wird schwer oder gar nicht mehr zu verstehen, wodurch der Nutzer faktisch von der Seite ausgeschlossen wird, bis er eine Stopp-Steuerung finden und aktivieren kann — die er jedoch nicht leicht finden kann, weil der Screenreader die Seite wegen des Lärms nicht vorlesen kann. Laut der Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung, und ein erheblicher Teil von ihnen ist auf Screenreader als primäres Werkzeug zum Surfen angewiesen.
Nutzer mit kognitiven Beeinträchtigungen und Aufmerksamkeitsstörungen, einschließlich Personen mit ADHS, Autismus-Spektrum-Bedingungen oder Angststörungen, können unerwartete Audioausgabe als äußerst desorientierend oder belastend empfinden. Das plötzliche Einsetzen von Musik oder Sprache kann die Konzentration unterbrechen, sensorische Überlastung auslösen oder Verwirrung darüber verursachen, ob der Ton Teil des Seiteninhalts oder eine externe Benachrichtigung ist.
Nutzer mit auditiven Verarbeitungsstörungen oder Hörgeräten können Rückkopplungsschleifen oder verstärkte Verzerrungen erleben, wenn Audio in unerwarteter Lautstärke über Hörgeräte abgespielt wird. Eine unabhängige Lautstärkeregelung ermöglicht es ihnen, ihre Hörumgebung zu steuern, ohne systemweite Einstellungen anzupassen, die andere Anwendungen betreffen.
Motorisch beeinträchtigte Nutzer, die per Tastatur oder Schaltersteuerung navigieren, benötigen eine Stopp-/Pause-Steuerung, die per Tastatur erreichbar ist und logisch früh in der Seitenstruktur positioniert wird. Wenn die Steuerung nur mit der Maus anklickbar ist oder spät in der Tab-Reihenfolge versteckt ist, bietet sie während der Zeit, die zum Navigieren dorthin benötigt wird, keine praktische Entlastung.
Betrachten wir ein konkretes Szenario: Eine blinde Arbeitssuchende besucht die Karriereseite eines Unternehmens, auf der automatisch ein Werbevideo mit peppiger Musik abgespielt wird. Die Nutzerin startet ihren Screenreader, der sofort beginnt, den Seitentitel und die Navigation vorzulesen. Die Musik übertönt die Sprachausgabe vollständig. Die Stopp-Schaltfläche ist ein gestyltes <div> ohne Tastaturfokus, das visuell im Videoplayer in der Mitte der Seite positioniert ist. Die Nutzerin kann es nicht per Tastatur erreichen, kann ihren Screenreader nicht gut genug hören, um effizient zu navigieren, und bricht schließlich den Besuch der Seite ab. Das Unternehmen verliert eine qualifizierte Kandidatin und setzt sich potenziellen rechtlichen Risiken aus.
Aus Nutzbarkeits- und SEO-Perspektive weisen Seiten mit automatisch abspielender Audioausgabe häufig erhöhte Absprungraten auf, da viele Nutzer — mit oder ohne Behinderung — Tabs sofort schließen, wenn unerwarteter Ton beginnt. Suchmaschinen interpretieren hohe Absprungraten als negatives Qualitätssignal, was die Auffindbarkeit indirekt beeinträchtigt.
Verwandte Axe-core-Regeln
WCAG 1.4.2 erfordert manuelle Tests. Keine automatisierte axe-core-Regel ist diesem Kriterium direkt zugeordnet. Der Grund, warum automatisierte Tools diesen Verstoß nicht erkennen können, ist grundlegend für die Funktionsweise von Browsern und JavaScript:
- Dynamische Audioauslösung: Audio kann durch JavaScript-Timer, Ereignis-Listener oder Skripte von Drittanbietern ausgelöst werden, die nach dem initialen DOM-Parsing ausgeführt werden. Ein automatischer Scanner, der das statische DOM untersucht, kann nicht zuverlässig bestimmen, ob Audio automatisch abgespielt wird, wie lange es dauert oder ob eine Steuerung funktional mit genau dieser Audioquelle verbunden ist.
- Vorhandensein und Bedienbarkeit von Steuerelementen: Ein Lautstärkeregler oder eine Pausentaste kann im DOM vorhanden sein, aber nicht funktionieren, außerhalb des sichtbaren Bereichs versteckt oder für Tastaturnutzer unzugänglich sein. Automatisierte Tools können das Vorhandensein eines Elements erkennen, aber nicht verifizieren, dass dessen Aktivierung die Audioausgabe tatsächlich stoppt, ohne die Interaktion auszuführen und auf ein Ergebnis zu „hören“ — eine Aufgabe, die menschliches Hörvermögen erfordert.
- Timing-Schwelle: Festzustellen, ob Audio länger als drei Sekunden abgespielt wird, erfordert eine zeitbasierte Bewertung während des Seitenladens, was außerhalb des Umfangs von Tools zur Analyse des statischen oder sogar zur Laufzeit vorliegenden DOM liegt.
- Inhalte von Drittanbietern: Audio, das über iframes, SDKs von Drittanbietern oder Werbenetzwerke eingebettet wird, ist für die JavaScript-Sandbox des Testtools möglicherweise nicht untersuchbar, was eine programmgesteuerte Erkennung unmöglich macht.
Aufgrund dieser Einschränkungen müssen Prüfer Seiten persönlich besuchen, auf automatisch abspielende Audioausgabe achten und manuell verifizieren, dass Pause-/Stopp-/Lautstärkeregler vorhanden, per Tastatur erreichbar und funktional sind.
Wie man testet
- Automatischer Vorab-Scan: Führen Sie axe DevTools oder Google Lighthouse auf der Seite aus. Auch wenn keines der Tools einen Verstoß gegen 1.4.2 direkt kennzeichnet, werden damit verwandte Probleme sichtbar, etwa fehlender Tastaturfokus auf Steuerelementen, unzugängliche Mediaplayer-Elemente oder fehlende ARIA-Labels bei benutzerdefinierten Audio-Widgets. Beheben Sie diese, bevor Sie mit manuellen Tests beginnen, damit Sie keine separaten Probleme vermischen.
- Manuelle Audioerkennung: Laden Sie die Seite mit eingeschalteten Lautsprechern oder Kopfhörern. Beobachten Sie, ob innerhalb der ersten Sekunden ohne Nutzerinteraktion Audio beginnt. Falls ja, verwenden Sie einen Timer, um zu bestätigen, dass sie länger als drei Sekunden abgespielt wird. Prüfen Sie alle wichtigen Seitentypen: Startseite, Landingpages, Produktseiten und alle Seiten, von denen bekannt ist, dass sie Medien-Einbettungen oder Werbeflächen enthalten.
- Lokalisieren der Stopp-/Pause-/Lautstärkeregelung: Drücken Sie ohne Maus direkt nach dem Laden der Seite die Tab-Taste. Zählen Sie, wie viele Tabstopps auftreten, bevor Sie die Audiosteuerung erreichen. Verifizieren Sie, dass die Steuerung einen sichtbaren Fokusindikator erhält. Drücken Sie Enter oder Leertaste, um sie zu aktivieren, und bestätigen Sie, dass die Audioausgabe stoppt oder ihre Lautstärke unabhängig angepasst werden kann.
- Screenreader-Test mit NVDA und Firefox: Starten Sie NVDA, öffnen Sie Firefox und navigieren Sie zur Seite. Lassen Sie die Audioausgabe beginnen. Versuchen Sie, mit den Lese-Befehlen von NVDA (Pfeiltasten, virtueller Cursor) die Audiosteuerung zu finden und zu aktivieren. Bestätigen Sie, dass NVDA die Rolle und Beschriftung der Steuerung korrekt ansagt (z. B. „Audio pausieren, Schaltfläche“) und dass deren Aktivierung die konkurrierende Audioausgabe zum Schweigen bringt.
- Screenreader-Test mit VoiceOver und Safari (macOS/iOS): Aktivieren Sie VoiceOver mit Befehl + F5. Navigieren Sie zur Seite und wischen Sie oder verwenden Sie die Pfeiltasten, um die Audiosteuerung zu finden. Verifizieren Sie, dass VoiceOver eine aussagekräftige Beschriftung vorliest und dass die Steuerung wie erwartet funktioniert. Testen Sie unter iOS zusätzlich das Auto-Play-Verhalten, da mobile Browser Audio-Berechtigungen anders handhaben.
- Screenreader-Test mit JAWS und Chrome: Laden Sie mit aktivem JAWS die Seite in Chrome. Verwenden Sie die Tab-Taste und die JAWS-Liste der Formularsteuerelemente (Einfügen + F5), um interaktive Elemente zu lokalisieren. Bestätigen Sie, dass die Audiosteuerung in der Liste erscheint und bedienbar ist.
- Prüfung von Inhalten Dritter: Wenn die Seite eingebettete Social-Media-Videos, Werbeeinheiten oder iframe-Inhalte enthält, laden Sie diese nach Möglichkeit separat und verifizieren Sie, dass sie ebenfalls konform sind oder dass die Host-Seite eine übergeordnete Steuerung bereitstellt.
- Prüfung der Lautstärkeunabhängigkeit: Wenn die Seite eine Lautstärkeregelung statt einer Pause-/Stopp-Steuerung anbietet, verifizieren Sie, dass die Anpassung der Seitenaudio-Lautstärke nicht die Master-Lautstärke des Betriebssystems verändert. Öffnen Sie eine andere Anwendung (z. B. einen lokalen Mediaplayer) und bestätigen Sie, dass deren Lautstärke nach Bedienung der Seitenaudiosteuerung unverändert bleibt.
Wie man es behebt
Automatisch abspielende Hintergrundaudio ohne Steuerelemente — Falsch
<!-- Audio startet automatisch ohne sichtbare oder per Tastatur zugängliche Steuerung -->
<audio src='background-music.mp3' autoplay loop></audio>
Automatisch abspielende Hintergrundaudio mit zugänglicher Pausensteuerung — Richtig
<!-- Steuerung ist das erste fokussierbare Element und wird von Screenreadern korrekt angekündigt -->
<button id='audio-toggle' aria-label='Pause background music' aria-pressed='true' onclick='toggleAudio()'>
Pause Music
</button>
<audio id='bg-audio' src='background-music.mp3' autoplay loop></audio>
<script>
function toggleAudio() {
var audio = document.getElementById('bg-audio');
var btn = document.getElementById('audio-toggle');
if (audio.paused) {
audio.play();
btn.setAttribute('aria-pressed', 'true');
btn.setAttribute('aria-label', 'Pause background music');
btn.textContent = 'Pause Music';
} else {
audio.pause();
btn.setAttribute('aria-pressed', 'false');
btn.setAttribute('aria-label', 'Play background music');
btn.textContent = 'Play Music';
}
}
</script>
<!-- Das native <button>-Element ist standardmäßig per Tastatur zugänglich.
aria-pressed kommuniziert den Umschaltzustand an Screenreader.
aria-label wird dynamisch aktualisiert, um die aktuelle Aktion widerzuspiegeln. -->
Automatisch abspielendes Video mit Tonspur und ohne per Tastatur zugängliche Stopp-Steuerung — Falsch
<!-- Das Video wird mit Ton automatisch abgespielt; die einzige Stopp-Steuerung ist ein Maus-Overlay -->
<div class='hero-video-wrapper'>
<video src='promo.mp4' autoplay loop></video>
<div class='stop-btn' onclick='stopVideo()'>Stop</div>
</div>
<!-- Problem: <div> ist nicht per Tastatur fokussierbar und hat weder Rolle noch Beschriftung -->
Automatisch abspielendes Video mit zugänglicher Stopp-Steuerung — Richtig
<div class='hero-video-wrapper'>
<!-- Stopp-Steuerung erscheint zuerst in DOM- und Fokusreihenfolge -->
<button
id='video-stop-btn'
aria-label='Stop promotional video'
onclick='stopVideo()'
>
Stop Video
</button>
<video id='promo-video' src='promo.mp4' autoplay loop muted='false'></video>
</div>
<script>
function stopVideo() {
var video = document.getElementById('promo-video');
var btn = document.getElementById('video-stop-btn');
video.pause();
video.currentTime = 0;
btn.disabled = true;
btn.textContent = 'Video Stopped';
}
</script>
<!-- Die Verwendung eines nativen <button> gewährleistet Tastaturzugang ohne zusätzliche ARIA.
Die Platzierung der Schaltfläche vor dem Video in der DOM-Reihenfolge bringt sie früh in die Tab-Sequenz. -->
Eingebettetes Audio-Widget eines Drittanbieters mit unabhängiger Lautstärkeregelung — Richtig
<!-- Wenn ein Widget eines Drittanbieters automatisch abspielt, stellen Sie eine hostseitige Stummschaltung bereit -->
<button
id='mute-widget-audio'
aria-label='Mute podcast player'
aria-pressed='false'
onclick='muteWidget()'
>
Mute Podcast
</button>
<iframe
id='podcast-frame'
src='https://embed.example.com/podcast/ep42?autoplay=1'
title='Episode 42: Web Accessibility Deep Dive'
allow='autoplay'
></iframe>
<script>
function muteWidget() {
<!-- postMessage-API wird verwendet, um mit dem Cross-Origin-iframe-Player zu kommunizieren -->
var frame = document.getElementById('podcast-frame');
var btn = document.getElementById('mute-widget-audio');
var isMuted = btn.getAttribute('aria-pressed') === 'true';
frame.contentWindow.postMessage({ action: isMuted ? 'unmute' : 'mute' }, 'https://embed.example.com');
btn.setAttribute('aria-pressed', String(!isMuted));
btn.setAttribute('aria-label', isMuted ? 'Mute podcast player' : 'Unmute podcast player');
}
</script>
<!-- Hinweis: Eine hostseitige Lautstärke-/Stummschaltungssteuerung erfüllt 1.4.2,
wenn die eigenen Steuerelemente des iframe-Players unzugänglich sein können. -->
Häufige Fehler
- Verwendung eines
<div>oder<span>als Audio-Stopp-Schaltfläche ohne Hinzufügen vontabindex='0', einemrole='button'und Tastatur-Ereignis-Handlern. Solche Elemente sind für die Tastaturnavigation und Screenreader unsichtbar und machen die Steuerung für die Nutzer, die sie am dringendsten benötigen, unbrauchbar. - Platzierung der Audiosteuerung hinter dem Hauptinhalt im DOM, sodass Tastaturnutzer durch Dutzende von Links und Formularfeldern tabben müssen, bevor sie sie erreichen — zu diesem Zeitpunkt läuft die Audioausgabe möglicherweise bereits seit einer Minute oder länger. Die Steuerung sollte das erste oder zweite fokussierbare Element auf der Seite sein.
- Standardmäßiges Stummschalten der Audioausgabe mit dem HTML-Attribut
mutedund Behandlung dessen als Konformität. Ein stummgeschaltetes, automatisch abspielendes Audioelement ist keine vom Nutzer bedienbare Steuerung; der Nutzer hat keine Möglichkeit zu wissen, dass Audio existiert oder seine eigene Lautstärkepräferenz zu wählen. - Bereitstellung eines Lautstärkereglers, der
window.AudioContext.destination.gainaufruft und Systemaudiopegel verändert, statt nur die.volume-Eigenschaft des spezifischen Medienelements anzupassen. Dies verstößt gegen die Anforderung der Unabhängigkeit. - Die Annahme, dass mobile Browser Auto-Play blockieren und daher keine Steuerung erforderlich ist. Viele mobile Browser erlauben Auto-Play, wenn Audio in einem Videoelement eingebettet ist oder wenn der Nutzer zuvor mit der Domain interagiert hat. Implementieren Sie immer Steuerelemente, unabhängig vom angenommenen Browserverhalten.
- Das Unterlassen der Aktualisierung der zugänglichen Beschriftung der Schaltfläche, wenn sich ihr Zustand ändert. Eine Schaltfläche mit der Beschriftung „Pause“, die nun Audio fortsetzt, sollte ihr
aria-labelauf „Play“ aktualisieren — andernfalls hören Screenreader-Nutzer eine falsche Ankündigung und könnten die falsche Aktion auslösen. - Verlassen auf die nativen Mediensteuerelemente des Browsers (Attribut
controls), ohne zu verifizieren, dass sie erscheinen, bevor automatisch abgespielte Audioausgabe aufdringlich wird. Native Steuerelemente werden unterhalb des Medienelements gerendert, das sich unterhalb des sichtbaren Bereichs befinden kann, wodurch sie per Tastatur nicht erreichbar sind, bevor erhebliche Störungen auftreten. - Versäumnis, mit Audio-Werbeanzeigen zu testen, die über Werbenetzwerke ausgeliefert werden. Werbeflächen, die dynamisch nach dem Laden der Seite eingefügt werden, sind Teil der Seitenerfahrung und unterliegen 1.4.2. Wenn das Werbenetzwerk keine Konformität garantieren kann, stellen Sie eine globale Stummschaltung für die Seite bereit.
- Behandlung der Drei-Sekunden-Ausnahme als Schlupfloch, indem ein kontinuierlicher Audiotrack in Segmente von jeweils unter drei Sekunden aufgeteilt wird. Die Absicht der WCAG ist klar: Audio, die kontinuierlich abgespielt oder geloopt wird, unterliegt dem Kriterium, unabhängig davon, wie sie technisch in Stücke geteilt wird.
- Keine Bereitstellung eines sichtbaren Fokusindikators auf der Audiosteuerung. Selbst wenn die Steuerung per Tastatur erreichbar ist, können sehende Tastaturnutzer sie nicht finden, wenn es keinen Fokusring gibt, was sowohl der Nutzbarkeitsabsicht dieses Kriteriums als auch WCAG 2.4.7 (Sichtbarer Fokus) widerspricht.
Bezug zu den Barrierefreiheitsvorschriften der Türkei
Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit fest, die an WCAG 2.2 ausgerichtet sind, und gilt für eine breite Palette öffentlicher und privater Einrichtungen, die in der Türkei tätig sind. WCAG 1.4.2 — Audiosteuerung ist ein Kriterium der Stufe A und gehört damit zur grundlegendsten Anforderungsebene. Nichtkonformität mit Kriterien der Stufe A stellt einen grundlegenden Verstoß gegen die Verfügung dar.
Die Verfügung schreibt folgende Konformitätsfristen vor: öffentliche Institutionen müssen innerhalb von einem Jahr nach dem Veröffentlichungsdatum der Verfügung vollständige Konformität mit Stufe A erreichen, während private Sektorunternehmen, die von der Regelung erfasst sind, zwei Jahre Zeit zur Umsetzung haben.
Die folgenden Einrichtungstypen sind in der Präsidialverfügung ausdrücklich genannt und müssen daher WCAG 1.4.2 erfüllen:
- Öffentliche Institutionen und Regierungsstellen auf allen Ebenen, einschließlich Ministerien, Gemeinden und staatsnahen Behörden, deren digitale Dienste von der Öffentlichkeit genutzt werden.
- E-Commerce-Plattformen, die in der Türkei tätig sind, einschließlich Marktplatzbetreiber und Direktvertriebs-Onlinehändler.
- Banken und Finanzinstitute, die dem türkischen Bankrecht unterliegen, einschließlich ihrer Online-Banking-Portale, mobilen Weboberflächen und digitalen Produktseiten.
- Krankenhäuser und Gesundheitsdienstleister, einschließlich privater Krankenhausgruppen und öffentlicher Gesundheitsportale, über die Patientinnen und Patienten Termine vereinbaren, auf Unterlagen zugreifen oder Gesundheitsinformationen erhalten.
- Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, deren kundenorientierte Websites, Self-Service-Portale und Werbeseiten konform sein müssen.
- Reisebüros und Online-Reiseplattformen, die Verbraucherinnen und Verbraucher in der Türkei bedienen, einschließlich Buchungsmaschinen und Zielinhaltsseiten.
- Private Transportunternehmen, die Online-Dienste für Ticketverkauf und Fahrgastinformationen anbieten.
- Private Schulen, die vom Ministerium für Nationale Bildung (MoNE) autorisiert sind, einschließlich ihrer Einschreibeportale, Lernmanagementsysteme und Informationswebsites.
Für all diese Einrichtungen stellt eine Seite, die Audio automatisch abspielt — sei es ein Werbevideo auf der Startseite einer Bank, eine Hintergrundmusik auf einer Produktseite eines E-Commerce-Angebots oder ein eingebetteter Nachrichtenclip auf einem Regierungsportal — ohne eine zugängliche, per Tastatur erreichbare Pause- oder Lautstärkeregelung bereitzustellen, einen direkten Verstoß sowohl gegen WCAG 1.4.2 als auch gegen die Verpflichtungen aus der Präsidialverfügung 2025/10 dar. Betroffene Einrichtungen sind nachdrücklich aufgefordert, alle Seitentemplates auf automatisch abspielende Medien zu prüfen und rechtzeitig vor Ablauf ihrer jeweiligen Frist konforme Steuerelemente zu implementieren, um aufsichtsrechtliche Beanstandungen zu vermeiden und allen Nutzern einen gleichberechtigten Zugang zu bieten.
Quellen & Referenzen
- W3C Understanding 1.4.2 Audio Control
- W3C Techniques for 1.4.2 Audio Control
- WebAIM: Accessible Audio and Video
- MDN: HTMLMediaElement.pause()
- MDN: HTMLMediaElement.volume
- W3C Technique G60: Playing a sound that turns off automatically within three seconds
- W3C Technique G170: Providing a control near the beginning of the Web page that turns off sounds
