WCAG 1.2.9: Alleen audio (live)

Wat Deze Regel Betekent

WCAG Succescriterium 1.2.9, Alleen-audio (live), valt onder Richtlijn 1.2 (Tijdgebaseerde media) op niveau AAA. Het stelt: “Er wordt een alternatief voor tijdgebaseerde media aangeboden dat gelijkwaardige informatie presenteert voor live alleen-audio-inhoud.” In praktische termen betekent dit dat wanneer je website of applicatie live audio-inhoud streamt of levert — en die inhoud geen videocomponent bevat — gebruikers een tekstueel equivalent in real time moeten krijgen dat dezelfde informatie getrouw overbrengt.

Een live alleen-audiopresentatie is elke audiostream die in real time wordt uitgezonden zonder een gesynchroniseerde videotrack. Veelvoorkomende voorbeelden zijn live radioprogramma’s die in een webpagina zijn ingesloten, live audiocommentaar tijdens een sportevenement, live persconferenties die in audioformaat worden gestreamd, live earnings calls of beleggersbijeenkomsten, en live audiopodcasts of talkshowstreams waarbij geen videobeeld de audio begeleidt.

Het tekstalternatief dat door dit criterium wordt vereist, moet gelijkwaardig zijn — wat betekent dat het niet alleen gesproken woorden moet vastleggen, maar ook relevante niet-spraakgeluiden zoals publieksgeluid, alarmen, geluidseffecten of muziek die informatieve waarde hebben. Een gedeeltelijke of vertraagde transcriptie voldoet niet aan dit criterium; het alternatief moet synchroon (of nagenoeg synchroon) met de livestream worden bijgewerkt, zodat dove en slechthorende gebruikers de inhoud in real time kunnen volgen.

Aanvaardbare technieken om aan dit criterium te voldoen zijn onder meer het inzetten van een live menselijke stenograaf die realtimetekst produceert (CART — Communication Access Realtime Translation), het insluiten van gesynchroniseerde live ondertiteling die wordt gegenereerd door een gekwalificeerde ondertitelingsdienst, of het tonen van een live tekstfeed die gelijktijdig met de audiouitzending loopt. Automatisch gegenereerde ondertitels die door spraakherkenningssoftware worden geproduceerd, kunnen ook aan het criterium voldoen, mits de nauwkeurigheid voldoende hoog is en de output nagenoeg in real time wordt gepresenteerd.

Wat telt als een voldoende resultaat: De pagina biedt een zichtbaar, synchroon tekstalternatief — duidelijk gekoppeld aan of weergegeven naast de audioplayer — dat gelijkwaardige informatie presenteert ten opzichte van de live audiostream terwijl deze zich ontvouwt. Het alternatief moet waarneembaar zijn voor gebruikers die de audio niet kunnen horen.

Wat telt als een onvoldoende resultaat: Er wordt helemaal geen tekstalternatief aangeboden; er wordt een tekstalternatief aangeboden maar dit is aanzienlijk vertraagd (bijv. een transcript dat na het evenement wordt geplaatst); een tekstalternatief dekt slechts een deel van de audio (bijv. alleen de toespraak van de presentator maar niet de vragen uit het publiek); of er bestaat een tekstalternatief maar dit is niet toegankelijk voor gebruikers van ondersteunende technologie (bijv. het wordt weergegeven als een niet-focusbare canvas-element of opgesloten in een Flash-widget).

Officiële uitzonderingen: WCAG voorziet niet in specifieke uitzonderingen voor 1.2.9, afgezien van het algemene principe dat de eis alleen van toepassing is op live alleen-audio-inhoud. Vooraf opgenomen alleen-audio-inhoud valt onder het afzonderlijke criterium 1.2.1. Er is geen uitzondering voor korte audioclips of korte aankondigingen — als de inhoud live en alleen-audio is, is het criterium van toepassing.

Waarom Het Belangrijk Is

Ongeveer 466 miljoen mensen wereldwijd hebben een gehoorverlies dat tot een beperking leidt, volgens de Wereldgezondheidsorganisatie, en dit aantal zal naar verwachting oplopen tot meer dan 900 miljoen in 2050. Voor deze gebruikers is live alleen-audio-inhoud volledig ontoegankelijk zonder een tekstueel equivalent. In tegenstelling tot vooraf opgenomen inhoud — waarbij een transcript vooraf kan worden voorbereid en achteraf kan worden toegevoegd — vormt live audio een unieke uitdaging omdat de informatie tijdkritisch en vluchtig is. Een dove gebruiker kan een livestream niet simpelweg later opnieuw afspelen en dezelfde ervaring verwachten; per definitie verliest live inhoud zijn directheid zodra het moment voorbij is.

Denk aan een concreet scenario uit de echte wereld: een beursgenoteerd bedrijf organiseert een live earnings call die als alleen-audio wordt gestreamd op de pagina voor beleggersrelaties. Analisten, journalisten en particuliere beleggers die doof of slechthorend zijn, kunnen niet deelnemen aan — of zelfs passief volgen — de call zonder een tekstfeed in real time. Belangrijke financiële openbaarmakingen, updates van verwachtingen en antwoorden op vragen van analisten worden in real time gecommuniceerd, en elke vertraging in het ontvangen van die informatie plaatst deze gebruikers in een aanzienlijk informatie-nadeel. In gereguleerde sectoren kan dit zelfs vragen oproepen over gelijke toegang tot publieke informatie.

Naast doofheid komt dit criterium een bredere populatie ten goede. Gebruikers met auditieve verwerkingsstoornissen kunnen audio wel horen, maar hebben moeite spraak snel genoeg te decoderen om een livestream te volgen; een gesynchroniseerde tekstfeed stelt hen in staat in hun eigen begrijptempo te lezen terwijl de audio afspeelt. Gebruikers in geluidssensitieve omgevingen — zoals kantoortuinen, bibliotheken of het openbaar vervoer — die audio niet hardop kunnen afspelen, profiteren van een tekstalternatief. Gebruikers voor wie de uitzendtaal een tweede taal is, vinden tekstalternatieven vaak ook makkelijker te volgen dan snel gesproken live spraak.

Vanuit SEO- en contentvindbaarheidsperspectief creëert een live teksttranscript of ondertitelfeed indexeerbare tekst die door zoekmachines kan worden gecrawld. Live evenementen die realtimetekst genereren, komen eerder naar voren in zoekresultaten en nieuwsaggregators, waardoor het publieksbereik ruim voorbij het oorspronkelijke uitzendvenster wordt vergroot.

Voor organisaties die actief zijn in gereguleerde sectoren — financiële dienstverlening, gezondheidszorg, overheid — wordt het bieden van gelijke toegang tot live audio-informatie in toenemende mate gezien als een verwachting in plaats van een gunst. Het niet voldoen aan dit criterium kan organisaties blootstellen aan klachten, reputatierisico en in sommige rechtsgebieden juridische aansprakelijkheid.

Gerelateerde Axe-core-regels

WCAG 1.2.9 vereist handmatige tests; geen enkele geautomatiseerde axe-core-regel kan betrouwbaar detecteren of een live alleen-audiostream een synchrone tekstalternatief heeft. De redenen voor deze beperking zijn fundamenteel voor de aard van het criterium:

• Waarom automatisering deze overtreding niet kan detecteren: Geautomatiseerde tools zoals axe-core werken op statische DOM-snapshots of paginastatussen op één moment in de tijd. Ze kunnen de aanwezigheid van een <audio>-element of een mediaplayer detecteren, maar ze kunnen niet bepalen of de bijbehorende inhoud live of vooraf opgenomen is, of een zichtbaar tekstgebied op de pagina daadwerkelijk in synchronie met een audiostream wordt bijgewerkt, of de tekstinhoud semantisch gelijkwaardig is aan de audio (alle spraak en niet-spraakgeluiden dekkend), of een gekoppelde externe ondertitelingsdienst daadwerkelijk actief en nauwkeurig is. Al deze oordelen vereisen menselijke beoordeling van de live uitzending zelf.
• Wat een handmatige auditor moet controleren: De auditor moet de pagina bezoeken terwijl de live audiostream actief is, nagaan hoe (of of) een tekstalternatief wordt gepresenteerd, bevestigen dat het tekstalternatief in real time wordt bijgewerkt terwijl de audio vordert, verifiëren dat de tekst alle betekenisvolle audio-inhoud dekt, inclusief sprekeridentificatie, niet-spraakgeluiden en overgangen, en bevestigen dat het tekstalternatief toegankelijk is voor ondersteunende technologie — bijvoorbeeld dat een live-regio met aria-live='polite' of aria-live='assertive' updates op passende wijze aankondigt aan schermlezers.
• Gedeeltelijke automatiseringssignalen: Hoewel axe-core een ontbrekend live tekstalternatief niet direct kan markeren, moeten auditors er rekening mee houden dat axe-core wel gerelateerde problemen zal markeren die het probleem verergeren — bijvoorbeeld als er een teksttranscriptgebied bestaat maar dit is verborgen met display:none, of als een mediaplayer geen toegankelijke bedieningselementen heeft. Deze signalen vormen nuttige vertrekpunten tijdens een handmatige beoordeling.

Hoe te Testen

1. Geautomatiseerde scan als basislijn: Voer axe DevTools of Lighthouse uit op de pagina die de live audiostream host. Noteer alle gemarkeerde problemen met media-elementen, ontbrekende labels of ontoegankelijke bedieningselementen. Hoewel geen van beide tools een ontbrekend live tekstalternatief direct zal markeren, kunnen ze gerelateerde barrières aan het licht brengen — zoals een audioplayer zonder toegankelijke naam of een transcriptcontainer die is verborgen voor de toegankelijkheidsboom. Documenteer deze bevindingen en beschouw ze als onderdeel van de algehele toegankelijkheidsbeoordeling.
2. Identificeer de live audio-inhoud: Bevestig, terwijl de live uitzending actief is, dat de audiostream live is (geen opname) en dat er geen videotrack is. Controleer de paginabron en netwerkverzoeken op aanwijzingen — livestreams gebruiken doorgaans HLS (.m3u8), MPEG-DASH of WebSocket-gebaseerde levering. Bevestig dat de inhoud alleen audio is.
3. Controleer op een tekstalternatief: Zoek naar een zichtbaar tekstgebied, ondertitelingsoverlay of duidelijk gelabelde transcriptfeed op de pagina of direct gelinkt vanaf de pagina. Het alternatief moet prominent worden getoond — niet verborgen in een instellingenmenu of alleen op verzoek beschikbaar. Als er geen zichtbaar tekstalternatief is, faalt het criterium onmiddellijk.
4. Verifieer synchroniteit: Met het live tekstalternatief zichtbaar, luister naar de audiostream en lees tegelijkertijd de tekstfeed. Bevestig dat de tekst wordt bijgewerkt met een redelijke vertraging (doorgaans niet meer dan enkele seconden voor CART- of professionele ondertitelingsdiensten). Een tekstfeed die slechts om de paar minuten wordt bijgewerkt of pas na afloop van de uitzending, voldoet niet aan het criterium.
5. Verifieer gelijkwaardigheid: Bevestig dat het tekstalternatief alle betekenisvolle audio-inhoud vastlegt: gesproken woorden, sprekeridentificatie wanneer er meerdere stemmen zijn, relevante niet-spraakgeluiden (bijv. “[applaus]”, “[alarmsignalen]”, “[muziek speelt]”) en alle on-air aankondigingen of onderbrekingen.
6. Schermlezer-test — NVDA + Firefox: Open de pagina met NVDA actief. Navigeer naar de live tekstregio. Als de regio aria-live gebruikt, moet NVDA nieuwe tekstinvoegingen automatisch aankondigen. Als het een scrollend tekstgebied is, verifieer dan dat je er focus op kunt plaatsen en dat de inhoud leesbaar is. Controleer ook dat de bedieningselementen van de audioplayer met het toetsenbord bedienbaar zijn.
7. Schermlezer-test — VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in en navigeer naar de live tekstregio. Bevestig dat VoiceOver nieuwe tekst voorleest zodra deze verschijnt. Verifieer op iOS ook de ervaring op mobiel — live evenementen worden vaak via mobiele browsers bezocht.
8. Schermlezer-test — JAWS + Chrome: Navigeer met JAWS actief naar de pagina en bevestig dat de aankondigingen van de live-regio functioneren. JAWS gaat anders om met aria-live='polite' en aria-live='assertive'; bevestig dat de verbositeitsinstelling passend is voor het type inhoud (een snel bewegende ondertitelfeed is mogelijk beter geschikt voor assertive om wachtrijvertragingen te voorkomen).
9. Mobiele en lage-bandbreedtetest: Als de site een mobiel publiek bedient, test dan het live tekstalternatief op een mid-range Android-apparaat via een gethrottlede verbinding. Bevestig dat de tekstfeed gesynchroniseerd en toegankelijk blijft, zelfs onder beperkte omstandigheden.

Hoe te Herstellen

Scenario 1: Live audioplayer zonder tekstalternatief — Onjuist

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

Scenario 1: Live audioplayer met ARIA live-regio-transcript — Juist

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

Scenario 2: Transcript alleen na afloop van het evenement geplaatst — Onjuist

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

Scenario 2: Real-time CART-feed naast de player gelinkt — Juist

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

Scenario 3: Automatisch gegenereerde ondertitels verborgen achter een instellingentoggle — Onjuist

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

Scenario 3: Ondertitels standaard ingeschakeld met een duidelijke toggle — Juist

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

Veelvoorkomende Fouten

• Een transcript na het evenement publiceren en claimen dat dit voldoet aan 1.2.9: Een transcript dat uren of dagen na een live uitzending wordt geplaatst, is geen tekstalternatief in real time. WCAG 1.2.9 vereist specifiek dat het alternatief gelijktijdig met de live audio beschikbaar is, niet achteraf.
• aria-live='polite' gebruiken voor een snel bewegende ondertitelfeed: “Polite” live-regio’s wachten tot de gebruiker klaar is met interactie voordat nieuwe inhoud wordt aangekondigd. Voor snel bijgewerkte ondertitels zorgt dit ervoor dat schermlezergebruikers aankondigingen missen. Gebruik aria-live='assertive' voor live ondertitelfeeds waarbij elke update tijdkritisch is.
• Bij elke update de volledige ondertitelgeschiedenis injecteren in plaats van alleen nieuwe inhoud: Wanneer aria-atomic='true' is ingesteld en het volledige tekstblok bij elke update wordt vervangen, proberen schermlezers de hele regio opnieuw te lezen, wat een schokkende ervaring veroorzaakt. Gebruik aria-atomic='false' en voeg nieuwe tekstnodes toe zodat alleen het nieuwe deel wordt aangekondigd.
• De ondertitelfeed insluiten in een <canvas>-element of als een video-overlaygrafiek: Ondertiteltekst die als pixels op een canvas of ingebrand in een videoframe wordt weergegeven, is onzichtbaar voor ondersteunende technologieën. Tekstalternatieven moeten worden aangeboden als daadwerkelijke DOM-tekstnodes.
• De live ondertitelregio buiten beeld plaatsen met position:absolute; left:-9999px: Hoewel het visueel verbergen van inhoud op deze manier het in de toegankelijkheidsboom houdt, ontneemt het ziende gebruikers met gehoorverlies de mogelijkheid de ondertitels te lezen. Het tekstalternatief moet visueel beschikbaar zijn voor alle gebruikers, niet alleen voor schermlezergebruikers.
• Sprekers niet identificeren in uitzendingen met meerdere sprekers: Een ondertitelfeed die spraak transcribeert zonder deze toe te schrijven aan specifieke sprekers (bijv. “[Moderator]:”, “[CEO]:”, “[Publiekslid]:”) is niet volledig gelijkwaardig. Sprekeridentificatie is essentieel voor gebruikers om de gespreksstructuur van een live evenement te kunnen volgen.
• Niet-spraakgeluiden weglaten uit het tekstalternatief: Relevante geluiden zoals applaus, technische onderbrekingen, achtergrondmuziek, alarmen of gelach hebben informatieve waarde en moeten in de tekstfeed worden beschreven (bijv. “[applaus]”, “[technische problemen — audio onderbroken]”).
• Het tekstalternatief alleen via een aparte externe URL aanbieden zonder het op dezelfde pagina in te sluiten: Gebruikers dwingen een apart browsertabblad of -venster te openen om ondertitels te bekijken terwijl de audio op de oorspronkelijke pagina afspeelt, creëert een aanzienlijke gebruiksbarrière, vooral voor schermlezergebruikers en gebruikers die alleen het toetsenbord gebruiken en van context moeten wisselen.
• Aannemen dat automatisch gegenereerde ondertitels altijd aan de gelijkwaardigheidsdrempel voldoen: Door AI gegenereerde ondertitels kunnen hoge foutpercentages hebben bij geaccentueerde spraak, technische terminologie, eigennamen en snelle spraak. Het inzetten van ongecorrigeerde automatisch gegenereerde ondertitels voor een hoog-risico live evenement (bijv. een medische briefing of financiële openbaarmaking) kan de gelijkwaardigheidsnorm niet halen, zelfs als er technisch gezien een ondertitelfeed aanwezig is.
• De live tekstregio niet testen met echte schermlezers tijdens een live uitzending: Veel teams testen de player en de ondertitelcontainer geïsoleerd met statische placeholdertekst, maar testen het dynamische gedrag nooit tijdens een daadwerkelijke livestream. Bugs in de JavaScript die ondertitelupdates injecteert — zoals DOM-mutation observers die stil falen — komen alleen aan het licht tijdens live tests.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt bindende webtoegankelijkheidsverplichtingen vast voor een brede reeks organisaties die in Turkije actief zijn. De circulaire schrijft conformiteit met WCAG 2.2 op AA-niveau voor als basisnorm. De typen entiteiten die hieronder vallen, omvatten overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en particuliere zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, erkende reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE).

WCAG 1.2.9 is een criterium op niveau AAA, wat betekent dat het niet behoort tot de conformiteitseisen die door de circulaire op AA-basisniveau worden voorgeschreven. Organisaties die onder Presidential Circular 2025/10 vallen, zijn juridisch niet verplicht om tekstalternatieven voor live alleen-audio te implementeren, tenzij zij zich afzonderlijk hebben gecommitteerd aan volledige WCAG 2.2 AAA-conformiteit.

Toch maken verschillende praktische overwegingen 1.2.9 zeer relevant voor Turkse organisaties, zelfs voorbij het strikte wettelijke minimum. Telecomaanbieders, financiële instellingen en publieke omroepen leveren vaak live audio-inhoud — beleggerscalls, publieke aankondigingen, live klantenservice-uitzendingen — waar dove en slechthorende gebruikers in Turkije van afhankelijk zijn. Het aantonen van AAA-niveau conformiteit geeft blijk van een toonaangevende toegankelijkheidsinzet en verkleint het risico op discriminatieklachten aanzienlijk onder het bredere Turkse kader voor rechten van personen met een handicap, waaronder de Wet op Personen met een Handicap nr. 5378 en de uitvoeringsregelingen daarvan.

Voor organisaties die vrijwillig WCAG 2.2 AAA-conformiteit nastreven — ofwel om hun toegankelijkheidsprofiel te onderscheiden, om internationale markten met strengere eisen te bedienen, of om zich te richten naar aanbestedingscriteria die AAA vereisen — is een correcte implementatie van 1.2.9 essentieel. Accsible raadt Turkse organisaties in gereguleerde sectoren aan om hun live audio-inhoud proactief te beoordelen en de haalbaarheid te evalueren van het integreren van CART-diensten of zeer nauwkeurige real-time ondertiteling, met name voor publiekgerichte live evenementen waar informatiegelijkheid een concrete verwachting van belanghebbenden is.