WCAG-Erfolgskriterien · Level AAA

WCAG 1.2.9: Nur Audio (Live)

WCAG 1.2.9 verlangt, dass alle Live-Audioinhalte ohne Bild – wie Live-Rundfunksendungen oder reine Audiostreams – von einer gleichwertigen, in Echtzeit bereitgestellten Textalternative begleitet werden, etwa einem Live-Untertitelungsfeed oder einem Texttranskript, das synchron aktualisiert wird. Dies stellt sicher, dass Nutzerinnen und Nutzer, die taub oder schwerhörig sind, auf Live-Audioinhalte zugreifen können, ohne auf die Tonspur selbst angewiesen zu sein.

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 1.2.9, Nur Audio (Live), fällt unter Richtlinie 1.2 (Zeitbasierte Medien) auf Stufe AAA. Es lautet: „Es wird eine Alternative für zeitbasierte Medien bereitgestellt, die gleichwertige Informationen für Live-Audioinhalte ohne Video liefert.“ Praktisch bedeutet dies, dass immer dann, wenn Ihre Website oder Anwendung Live-Audioinhalte streamt oder bereitstellt – und diese Inhalte keine Videokomponente enthalten – den Nutzern ein Echtzeit-Textäquivalent zur Verfügung gestellt werden muss, das dieselben Informationen zuverlässig vermittelt.

Eine Live-Audio-only-Präsentation ist jeder Audiostream, der in Echtzeit ohne synchronisierte Videospur übertragen wird. Häufige Beispiele sind Live-Radiosendungen, die in eine Webseite eingebettet sind, Live-Audiokommentare während eines Sportereignisses, Live-Pressekonferenzen, die im Audioformat gestreamt werden, Live-Earnings-Calls oder Investorenbriefings sowie Live-Audio-Podcasts oder Talkshow-Streams, bei denen kein Videofeed den Ton begleitet.

Die von diesem Kriterium geforderte Textalternative muss gleichwertig sein – das bedeutet, sie muss nicht nur gesprochene Worte erfassen, sondern auch relevante nichtsprachliche Audioinformationen wie Publikumslärm, Alarme, Soundeffekte oder Musik, die Informationswert haben. Ein teilweises oder stark verzögertes Transkript erfüllt dieses Kriterium nicht; die Alternative muss synchron (oder nahezu synchron) mit dem Livestream aktualisiert werden, damit gehörlose und schwerhörige Nutzer den Inhalt in Echtzeit verfolgen können.

Zulässige Techniken zur Erfüllung dieses Kriteriums umfassen die Bereitstellung eines Live-Stenografen, der Echtzeittext erstellt (CART – Communication Access Realtime Translation), das Einbetten synchronisierter Live-Untertitel, die von einem qualifizierten Untertitelungsdienst erzeugt werden, oder die Anzeige eines Live-Textfeeds, der parallel zur Audioübertragung läuft. Automatisch generierte Untertitel, die durch Spracherkennungssoftware erstellt werden, können das Kriterium ebenfalls erfüllen, sofern die Genauigkeit ausreichend hoch ist und die Ausgabe nahezu in Echtzeit präsentiert wird.

Was als bestanden gilt: Die Seite stellt eine sichtbare, synchrone Textalternative bereit – klar verlinkt oder in unmittelbarer Nähe zum Audioplayer angezeigt –, die gleichwertige Informationen zum Live-Audiostream liefert, während dieser abläuft. Die Alternative muss für Nutzer wahrnehmbar sein, die das Audio nicht hören können.

Was als nicht bestanden gilt: Es wird überhaupt keine Textalternative angeboten; eine Textalternative wird bereitgestellt, ist aber erheblich verzögert (z. B. ein Transkript, das erst nach der Veranstaltung veröffentlicht wird); eine Textalternative deckt nur einen Teil des Audios ab (z. B. nur die Rede des Vortragenden, aber nicht die Fragen aus dem Publikum); oder eine Textalternative existiert, ist aber für Nutzer von unterstützender Technologie nicht zugänglich (z. B. sie wird als nicht fokussierbares Canvas-Element gerendert oder in einem Flash-Widget eingeschlossen).

Offizielle Ausnahmen: Die WCAG sieht für 1.2.9 keine spezifischen Ausnahmen vor, abgesehen von dem allgemeinen Grundsatz, dass die Anforderung nur für Live-Audio-only-Inhalte gilt. Vorab aufgezeichnete Audio-only-Inhalte werden durch das separate Kriterium 1.2.1 abgedeckt. Es gibt keine Ausnahme für kurze Audioclips oder kurze Durchsagen – wenn Inhalte live und nur Audio sind, gilt das Kriterium.

Warum es wichtig ist

Weltweit haben laut Weltgesundheitsorganisation etwa 466 Millionen Menschen einen beeinträchtigenden Hörverlust, und diese Zahl wird bis 2050 voraussichtlich auf über 900 Millionen steigen. Für diese Nutzer sind Live-Audio-only-Inhalte ohne Textäquivalent vollständig unzugänglich. Anders als bei vorab aufgezeichneten Inhalten – bei denen ein Transkript im Voraus erstellt und nachträglich beigefügt werden kann – stellen Live-Audioinhalte eine besondere Herausforderung dar, weil die Informationen zeitkritisch und flüchtig sind. Eine gehörlose Person kann einen Livestream nicht einfach später erneut abspielen und dieselbe Erfahrung erwarten; per Definition verliert Live-Content seine Unmittelbarkeit, sobald der Moment verstrichen ist.

Betrachten Sie ein konkretes Szenario aus der Praxis: Ein börsennotiertes Unternehmen veranstaltet einen Live-Earnings-Call, der als reines Audio auf seiner Investor-Relations-Seite gestreamt wird. Analysten, Journalisten und Privatanleger, die gehörlos oder schwerhörig sind, können ohne Echtzeit-Textfeed nicht an der Telefonkonferenz teilnehmen oder ihr auch nur passiv folgen. Wichtige Finanzinformationen, aktualisierte Prognosen und Antworten auf Analystenfragen werden in Echtzeit kommuniziert, und jede Verzögerung beim Erhalt dieser Informationen bringt diese Nutzer in einen erheblichen Informationsnachteil. In regulierten Branchen kann dies sogar Fragen der gleichberechtigten Zugänglichkeit zu öffentlichen Informationen aufwerfen.

Über Gehörlosigkeit hinaus kommt dieses Kriterium einer breiteren Nutzergruppe zugute. Nutzer mit auditorischen Verarbeitungsstörungen können Audio zwar hören, haben aber Schwierigkeiten, Sprache schnell genug zu entschlüsseln, um einem Livestream zu folgen; ein synchronisierter Textfeed ermöglicht es ihnen, in ihrem eigenen Verständnistempo zu lesen, während das Audio läuft. Nutzer in lärmsensiblen Umgebungen – etwa Großraumbüros, Bibliotheken oder öffentliche Verkehrsmittel – die Audio nicht laut abspielen können, profitieren von einer Textalternative. Nutzer, für die die Sprache der Übertragung eine Zweitsprache ist, finden Textalternativen ebenfalls leichter zu verfolgen als schnell gesprochene Live-Sprache.

Aus SEO- und Sichtbarkeits-Perspektive erzeugt ein Live-Texttranskript oder Untertitelfeed indizierbaren Text, den Suchmaschinen crawlen können. Live-Events, die Echtzeittext generieren, werden mit höherer Wahrscheinlichkeit in Suchergebnissen und Nachrichtenaggregatoren angezeigt und erweitern die Reichweite des Publikums weit über das ursprüngliche Sendezeitfenster hinaus.

Für Organisationen in regulierten Sektoren – Finanzdienstleistungen, Gesundheitswesen, Regierung – ist die Bereitstellung eines gleichberechtigten Zugangs zu Live-Audioinformationen zunehmend eine Erwartung und keine bloße Höflichkeit. Die Nichterfüllung dieses Kriteriums kann Organisationen Beschwerden, Reputationsrisiken und in einigen Rechtsordnungen rechtlicher Haftung aussetzen.

Verwandte Axe-core-Regeln

WCAG 1.2.9 erfordert manuelle Tests; keine automatisierte axe-core-Regel kann zuverlässig erkennen, ob ein Live-Audio-only-Stream eine synchrone Textalternative hat. Die Gründe für diese Einschränkung sind grundlegend in der Natur des Kriteriums begründet:

  • Warum Automatisierung diesen Verstoß nicht erfassen kann: Automatisierte Tools wie axe-core arbeiten mit statischen DOM-Snapshots oder Seitenzuständen zu einem einzigen Zeitpunkt. Sie können das Vorhandensein eines <audio>-Elements oder eines Mediaplayers erkennen, aber sie können nicht feststellen, ob die zugehörigen Inhalte live oder vorab aufgezeichnet sind, ob ein sichtbarer Textbereich auf der Seite tatsächlich synchron mit einem Audiostream aktualisiert wird, ob der Textinhalt semantisch dem Audio entspricht (alle Sprach- und nichtsprachlichen Audioinformationen abdeckt) oder ob ein verlinkter externer Untertitelungsdienst tatsächlich aktiv und genau ist. All diese Beurteilungen erfordern eine menschliche Überprüfung der Live-Übertragung selbst.
  • Was ein manueller Auditor prüfen muss: Der Auditor muss auf die Seite zugreifen, während der Live-Audiostream aktiv ist, feststellen, wie (oder ob) eine Textalternative präsentiert wird, bestätigen, dass die Textalternative in Echtzeit aktualisiert wird, während das Audio fortschreitet, verifizieren, dass der Text alle bedeutungsvollen Audioinhalte abdeckt, einschließlich Sprecheridentifikation, nichtsprachlicher Geräusche und Übergänge, und sicherstellen, dass die Textalternative für unterstützende Technologien zugänglich ist – zum Beispiel, dass ein Live-Bereich mit aria-live='polite' oder aria-live='assertive' Aktualisierungen für Screenreader-Nutzer angemessen ankündigt.
  • Teilautomatisierte Signale: Auch wenn axe-core eine fehlende Live-Textalternative nicht direkt kennzeichnen kann, sollten Auditoren beachten, dass axe-core wohl verwandte Probleme meldet, die das Problem verschärfen – etwa wenn ein Texttranskriptbereich vorhanden ist, aber mit display:none versteckt wird oder wenn ein Mediaplayer keine zugänglichen Steuerelemente hat. Diese Hinweise dienen als nützliche Ausgangspunkte für eine manuelle Überprüfung.

Wie man testet

  1. Automatisierter Scan als Ausgangsbasis: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, die den Live-Audiostream hostet. Notieren Sie alle gemeldeten Probleme mit Medienelementen, fehlenden Beschriftungen oder unzugänglichen Steuerelementen. Auch wenn keines der beiden Tools eine fehlende Live-Textalternative direkt kennzeichnet, können sie verwandte Barrieren aufzeigen – etwa einen Audioplayer ohne zugänglichen Namen oder einen Transkriptcontainer, der im Accessibility Tree verborgen ist. Dokumentieren Sie diese Ergebnisse und betrachten Sie sie als Teil der Gesamtbewertung der Barrierefreiheit.
  2. Identifizieren Sie die Live-Audioinhalte: Bestätigen Sie während der aktiven Live-Übertragung, dass der Audiostream live (keine Aufzeichnung) ist und keine Videospur enthält. Prüfen Sie den Seitenquelltext und die Netzwerk-Anfragen auf Hinweise – Live-Streams verwenden typischerweise HLS (.m3u8), MPEG-DASH oder WebSocket-basierte Übertragung. Bestätigen Sie, dass der Inhalt nur Audio ist.
  3. Prüfen Sie auf eine Textalternative: Suchen Sie nach einem sichtbaren Textbereich, einer Untertitel-Overlay oder einem klar beschrifteten Transkriptfeed auf der Seite oder unmittelbar von der Seite aus verlinkt. Die Alternative muss deutlich hervorgehoben sein – nicht in einem Einstellungsmenü versteckt oder nur auf Anfrage verfügbar. Wenn keine Textalternative sichtbar ist, fällt das Kriterium sofort durch.
  4. Synchronität überprüfen: Hören Sie bei sichtbarer Live-Textalternative gleichzeitig den Audiostream und lesen Sie den Textfeed. Bestätigen Sie, dass Textaktualisierungen mit einer angemessenen Verzögerung erfolgen (typischerweise nicht mehr als einige Sekunden bei CART- oder professionellen Untertitelungsdiensten). Ein Textfeed, der nur alle paar Minuten oder erst nach Ende der Übertragung aktualisiert wird, erfüllt das Kriterium nicht.
  5. Gleichwertigkeit überprüfen: Bestätigen Sie, dass die Textalternative alle bedeutungsvollen Audioinhalte erfasst: gesprochene Worte, Sprecheridentifikation, wenn mehrere Stimmen vorhanden sind, relevante nichtsprachliche Audioinhalte (z. B. „[Applaus]“, „[Alarm ertönt]“, „[Musik spielt]“) sowie alle Durchsagen oder Unterbrechungen auf Sendung.
  6. Screenreader-Test – NVDA + Firefox: Öffnen Sie die Seite mit aktivem NVDA. Navigieren Sie zum Live-Textbereich. Wenn der Bereich aria-live verwendet, sollte NVDA neue Texteinfügungen automatisch ankündigen. Handelt es sich um einen scrollenden Textbereich, vergewissern Sie sich, dass der Fokus darauf gesetzt werden kann und dass der Inhalt lesbar ist. Prüfen Sie, dass die Steuerelemente des Audioplayers ebenfalls per Tastatur bedienbar sind.
  7. Screenreader-Test – VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver und navigieren Sie zum Live-Textbereich. Bestätigen Sie, dass VoiceOver neuen Text vorliest, sobald er erscheint. Überprüfen Sie auf iOS zusätzlich die Erfahrung auf Mobilgeräten – Live-Events werden häufig über mobile Browser aufgerufen.
  8. Screenreader-Test – JAWS + Chrome: Navigieren Sie mit aktivem JAWS zur Seite und bestätigen Sie, dass die Ankündigungen des Live-Bereichs funktionieren. JAWS behandelt aria-live='polite' und aria-live='assertive' unterschiedlich; stellen Sie sicher, dass die Ausführlichkeitseinstellung für die Art des Inhalts geeignet ist (ein sich schnell aktualisierender Untertitelfeed eignet sich möglicherweise besser für assertive, um Warteschlangenverzögerungen zu vermeiden).
  9. Test auf Mobilgeräten und bei geringer Bandbreite: Wenn die Website ein mobiles Publikum bedient, testen Sie die Live-Textalternative auf einem Android-Gerät der Mittelklasse bei gedrosselter Verbindung. Bestätigen Sie, dass der Textfeed auch unter eingeschränkten Bedingungen synchron und zugänglich bleibt.

Wie man es behebt

Szenario 1: Live-Audioplayer ohne Textalternative – Falsch

<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'>
    Your browser does not support the audio element.
  </audio>
</section>

Szenario 1: Live-Audioplayer mit ARIA-Live-Region-Transkript – Richtig

<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'
         aria-describedby='live-caption-feed'>
    Your browser does not support the audio element.
  </audio>
  <!-- aria-live='assertive' ensures screen readers announce new text immediately -->
  <!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
  <div id='live-caption-feed'
       role='region'
       aria-label='Live captions'
       aria-live='assertive'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text is injected here by the captioning service JavaScript -->
  </div>
</section>

Szenario 2: Transkript wird erst nach Ende der Veranstaltung veröffentlicht – Falsch

<!-- Transcript link appears but only resolves after the broadcast -->
<div>
  <audio controls src='https://stream.example.com/press-conference'></audio>
  <p>A full transcript will be available after the press conference concludes.</p>
</div>

Szenario 2: Echtzeit-CART-Feed neben dem Player verlinkt – Richtig

<!-- Real-time CART captions are displayed inline during the live event -->
<div>
  <audio controls src='https://stream.example.com/press-conference'
         aria-describedby='cart-feed'></audio>
  <!-- The CART feed is an iframe served by a professional captioning provider -->
  <!-- The iframe must itself be accessible with an appropriate title -->
  <iframe
    id='cart-feed'
    src='https://cart-provider.example.com/feed/press-conference-2025'
    title='Real-time captions for live press conference'
    width='100%'
    height='200'>
  </iframe>
  <p>A full transcript will also be published after the event concludes.</p>
</div>

Szenario 3: Automatisch generierte Untertitel hinter einem Einstellungsumschalter versteckt – Falsch

<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'></audio>
  <button onclick='toggleSettings()'>Settings</button>
  <div id='settings-panel' hidden>
    <button onclick='enableCaptions()'>Enable Captions</button>
  </div>
</div>

Szenario 3: Untertitel standardmäßig aktiviert mit klarer Umschaltmöglichkeit – Richtig

<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'
         aria-describedby='webinar-captions'></audio>
  <!-- Default state is captions-on; aria-pressed reflects current state -->
  <button id='caption-toggle'
          aria-pressed='true'
          onclick='toggleCaptions(this)'>
    Live Captions: On
  </button>
  <div id='webinar-captions'
       role='region'
       aria-label='Live webinar captions'
       aria-live='polite'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text injected here in real time -->
  </div>
</div>

Häufige Fehler

  • Veröffentlichung eines Transkripts nach der Veranstaltung und Behauptung, dies erfülle 1.2.9: Ein Transkript, das Stunden oder Tage nach einer Live-Übertragung veröffentlicht wird, ist keine Echtzeit-Textalternative. WCAG 1.2.9 verlangt ausdrücklich, dass die Alternative gleichzeitig mit dem Live-Audio verfügbar ist, nicht nachträglich.
  • Verwendung von aria-live='polite' für einen sich schnell aktualisierenden Untertitelfeed: „Polite“-Live-Bereiche warten, bis der Nutzer seine Interaktion beendet hat, bevor neue Inhalte angekündigt werden. Bei sich schnell aktualisierenden Untertiteln führt dies dazu, dass Screenreader-Nutzer Ankündigungen verpassen. Verwenden Sie aria-live='assertive' für Live-Untertitelstreams, bei denen jede Aktualisierung zeitkritisch ist.
  • Einfügen des gesamten Untertitelverlaufs bei jeder Aktualisierung statt nur neuer Inhalte: Wenn aria-atomic='true' gesetzt ist und der gesamte Textblock bei jeder Aktualisierung ersetzt wird, versuchen Screenreader, den gesamten Bereich erneut vorzulesen, was zu einer störenden Erfahrung führt. Verwenden Sie aria-atomic='false' und fügen Sie neue Textknoten an, sodass nur der neue Teil angekündigt wird.
  • Einbetten des Untertitelfeeds in ein <canvas>-Element oder als grafisches Video-Overlay: Untertiteltext, der als Pixel auf einem Canvas oder in einen Videoframe eingebrannt dargestellt wird, ist für unterstützende Technologien unsichtbar. Textalternativen müssen als tatsächliche DOM-Textknoten bereitgestellt werden.
  • Platzierung des Live-Untertitelbereichs außerhalb des sichtbaren Bereichs mit position:absolute; left:-9999px: Auch wenn Inhalte auf diese Weise visuell versteckt und im Accessibility Tree belassen werden, wird sehenden Nutzern mit Hörverlust die Möglichkeit genommen, die Untertitel zu lesen. Die Textalternative muss für alle Nutzer visuell verfügbar sein, nicht nur für Screenreader-Nutzer.
  • Fehlende Sprecheridentifikation bei Übertragungen mit mehreren Sprechern: Ein Untertitelfeed, der Sprache transkribiert, ohne sie bestimmten Sprechern zuzuordnen (z. B. „[Moderator]:“, „[CEO]:“, „[Publikumsmitglied]:“), ist nicht vollständig gleichwertig. Die Sprecheridentifikation ist entscheidend, damit Nutzer der Gesprächsstruktur eines Live-Events folgen können.
  • Auslassen nichtsprachlicher Audioinformationen in der Textalternative: Relevante Geräusche wie Applaus, technische Unterbrechungen, Hintergrundmusik, Alarme oder Gelächter tragen Informationsgehalt und müssen im Textfeed beschrieben werden (z. B. „[Applaus]“, „[technische Probleme – Audio unterbrochen]“).
  • Bereitstellung der Textalternative nur über eine separate Drittanbieter-URL ohne Einbettung auf derselben Seite: Nutzer zu zwingen, einen separaten Browser-Tab oder ein separates Fenster zu öffnen, um Untertitel zu sehen, während das Audio auf der ursprünglichen Seite abgespielt wird, schafft eine erhebliche Usability-Barriere, insbesondere für Screenreader-Nutzer und Tastaturnutzer, die den Kontext wechseln müssen.
  • Die Annahme, dass automatisch generierte Untertitel immer die Gleichwertigkeitsschwelle erfüllen: KI-generierte Untertitel können hohe Fehlerraten bei akzentuierter Sprache, Fachvokabular, Eigennamen und schneller Sprache aufweisen. Der Einsatz unkorrigierter automatisch generierter Untertitel für ein hochrelevantes Live-Event (z. B. eine medizinische Unterrichtung oder eine Finanzveröffentlichung) kann den Gleichwertigkeitsstandard verfehlen, selbst wenn technisch ein Untertitelfeed vorhanden ist.
  • Kein Testen des Live-Textbereichs mit tatsächlichen Screenreadern während einer Live-Übertragung: Viele Teams testen den Player und den Untertitelcontainer isoliert mit statischem Platzhaltertext, testen aber nie das dynamische Verhalten während eines tatsächlichen Livestreams. Fehler in der JavaScript-Logik, die Untertitelaktualisierungen einfügt – etwa DOM-Mutationsbeobachter, die stillschweigend ausfallen –, treten nur bei Live-Tests zutage.

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 Web-Barrierefreiheitsverpflichtungen für eine breite Palette von Organisationen fest, die in der Türkei tätig sind. Die Verfügung schreibt die Konformität mit WCAG 2.2 auf AA-Niveau als Mindeststandard vor. Zu den erfassten Organisationstypen gehören öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind.

WCAG 1.2.9 ist ein Kriterium der Stufe AAA, was bedeutet, dass es nicht zu den Konformitätsanforderungen gehört, die durch die Verfügung auf AA-Niveau vorgeschrieben sind. Organisationen, die unter die Präsidialverfügung 2025/10 fallen, sind rechtlich nicht verpflichtet, Textalternativen für Live-Audio-only-Inhalte zu implementieren, es sei denn, sie haben sich gesondert zur vollständigen WCAG-2.2-AAA-Konformität verpflichtet.

Mehrere praktische Erwägungen machen 1.2.9 jedoch für türkische Organisationen auch über das strikte gesetzliche Minimum hinaus hochrelevant. Telekommunikationsanbieter, Finanzinstitute und öffentlich-rechtliche Rundfunkanstalten liefern häufig Live-Audioinhalte – Investoren-Calls, öffentliche Bekanntmachungen, Live-Kundendienstübertragungen –, auf die gehörlose und schwerhörige Nutzer in der Türkei angewiesen sind. Der Nachweis einer Konformität auf AAA-Niveau signalisiert ein erstklassiges Engagement für Barrierefreiheit und reduziert das Risiko von Diskriminierungsbeschwerden im Rahmen des breiteren türkischen Behindertenrechts, einschließlich des Gesetzes über Menschen mit Behinderungen Nr. 5378 und seiner Durchführungsbestimmungen, erheblich.

Für Organisationen, die freiwillig eine WCAG-2.2-AAA-Konformität anstreben – sei es, um ihre Barrierefreiheitsposition zu differenzieren, internationale Märkte mit strengeren Anforderungen zu bedienen oder sich an Beschaffungskriterien auszurichten, die AAA verlangen –, ist die korrekte Umsetzung von 1.2.9 unerlässlich. Accsible empfiehlt, dass türkische Organisationen in regulierten Sektoren ihre Live-Audioinhalte proaktiv bewerten und die Machbarkeit der Integration von CART-Diensten oder hochgenauer Echtzeituntertitelung prüfen, insbesondere für öffentlich zugängliche Live-Events, bei denen Informationsgerechtigkeit eine konkrete Erwartung der Stakeholder ist.