WCAG 1.2.9: Endast ljud (live)

Vad den här regeln innebär

WCAG framgångskriterium 1.2.9, Endast ljud (live), faller under riktlinje 1.2 (Tidsberoende media) på nivå AAA. Det anger: ”Ett alternativ för tidsberoende media som presenterar likvärdig information för liveinnehåll med enbart ljud tillhandahålls.” I praktiken innebär detta att när din webbplats eller applikation strömmar eller levererar liveinnehåll med enbart ljud – och innehållet inte har någon videokomponent – måste användare få ett textalternativ i realtid som troget återger samma information.

En livepresentation med enbart ljud är varje ljudström som sänds i realtid utan ett synkroniserat videospår. Vanliga exempel är direktsända radioprogram inbäddade på en webbsida, live ljudkommentarer under en sporthändelse, direktsända presskonferenser i ljudformat, live resultatsamtal eller investerarpresentationer samt direktsända ljudpoddar eller talkshow-strömmar där ingen videoström åtföljer ljudet.

Det textalternativ som krävs enligt detta kriterium måste vara likvärdigt – vilket innebär att det inte bara ska fånga talade ord utan även relevant icke-talad ljudinformation såsom publikljud, larm, ljudeffekter eller musik som har informationsvärde. En partiell eller fördröjd transkription uppfyller inte detta kriterium; alternativet måste uppdateras synkront (eller nästan synkront) med liveströmmen så att döva och hörselskadade användare kan följa innehållet i realtid.

Godtagbara tekniker för att uppfylla detta kriterium inkluderar att tillhandahålla en live mänsklig stenograf som producerar text i realtid (CART — Communication Access Realtime Translation), att bädda in synkroniserade liveundertexter genererade av en kvalificerad textningsleverantör, eller att visa ett live textflöde som körs parallellt med ljudsändningen. Automatgenererade undertexter som produceras av taligenkänningsprogram kan också uppfylla kriteriet förutsatt att noggrannheten är tillräckligt hög och att resultatet presenteras i nära realtid.

Vad som räknas som godkänt: Sidan tillhandahåller ett synligt, synkront textalternativ — tydligt länkat till eller visat intill ljudspelaren — som presenterar likvärdig information med den direktsända ljudströmmen allteftersom den fortlöper. Alternativet måste vara uppfattbart för användare som inte kan höra ljudet.

Vad som räknas som underkänt: Inget textalternativ erbjuds alls; ett textalternativ tillhandahålls men är avsevärt fördröjt (t.ex. en transkription som publiceras efter evenemanget); ett textalternativ täcker endast en del av ljudet (t.ex. endast presentatörens tal men inte publikens frågor); eller ett textalternativ finns men är inte tillgängligt för användare av hjälpmedel (t.ex. det renderas som ett icke-fokuserbart canvas-element eller är inlåst i en Flash-widget).

Officiella undantag: WCAG gör inga specifika undantag för 1.2.9 utöver den allmänna principen att kravet endast gäller live innehåll med enbart ljud. Förinspelat innehåll med enbart ljud omfattas av det separata kriteriet 1.2.1. Det finns inget undantag för korta ljudklipp eller korta meddelanden — om innehållet är live och enbart ljud gäller kriteriet.

Varför det är viktigt

Ungefär 466 miljoner människor världen över har funktionsnedsättande hörselnedsättning enligt Världshälsoorganisationen, och detta antal beräknas stiga till över 900 miljoner till 2050. För dessa användare är liveinnehåll med enbart ljud helt otillgängligt utan ett textalternativ. Till skillnad från förinspelat innehåll — där en transkription kan förberedas i förväg och bifogas i efterhand — utgör live-ljud en unik utmaning eftersom informationen är tidskänslig och flyktig. En användare som är döv kan inte helt enkelt spela upp en liveström senare och förvänta sig samma upplevelse; per definition förlorar liveinnehåll sin omedelbarhet när ögonblicket har passerat.

Överväg ett konkret scenario i verkligheten: ett börsnoterat företag håller ett direktsänt resultatsamtal som strömmas som enbart ljud på sin sida för investerarkontakter. Analytiker, journalister och småsparare som är döva eller har nedsatt hörsel kan inte delta i — eller ens passivt följa — samtalet utan ett textflöde i realtid. Viktiga finansiella upplysningar, uppdateringar av prognoser och svar på analytikernas frågor kommuniceras i realtid, och varje fördröjning i att ta emot denna information placerar dessa användare i ett betydande informationsmässigt underläge. I reglerade branscher kan detta till och med väcka frågor om likvärdig tillgång till offentlig information.

Utöver dövhet gynnar detta kriterium en bredare befolkning. Användare med auditiva bearbetningssvårigheter kan höra ljud men har svårt att avkoda tal tillräckligt snabbt för att följa en liveström; ett synkroniserat textflöde gör det möjligt för dem att läsa i sin egen förståelsetakt medan ljudet spelas. Användare i ljudkänsliga miljöer — såsom öppna kontorslandskap, bibliotek eller kollektivtrafik — som inte kan spela upp ljud högt har nytta av ett textalternativ. Användare för vilka sändningsspråket är ett andraspråk upplever också att textalternativ är lättare att följa än snabbt live-tal.

Ur ett SEO- och innehållsupptäckbarhetsperspektiv skapar en live texttranskription eller ett undertextflöde indexerbar text som sökmotorer kan genomsöka. Liveevenemang som genererar text i realtid har större sannolikhet att dyka upp i sökresultat och nyhetsaggregatorer, vilket utökar publikräckvidden långt bortom det ursprungliga sändningsfönstret.

För organisationer som verkar i reglerade sektorer — finansiella tjänster, hälso- och sjukvård, offentlig sektor — blir det i allt högre grad en förväntan snarare än en artighet att tillhandahålla likvärdig tillgång till liveinformation i ljudform. Underlåtenhet att uppfylla detta kriterium kan utsätta organisationer för klagomål, skada på anseendet och i vissa jurisdiktioner även rättsligt ansvar.

Relaterade Axe-core-regler

WCAG 1.2.9 kräver manuell testning; ingen automatiserad axe-core-regel kan pålitligt upptäcka om en live-ström med enbart ljud har ett synkront textalternativ. Skälen till denna begränsning är grundläggande för kriteriets natur:

• Varför automatisering inte kan fånga denna överträdelse: Automatiserade verktyg som axe-core arbetar på statiska DOM-ögonblicksbilder eller sidtillstånd vid en enskild tidpunkt. De kan upptäcka förekomsten av ett <audio>-element eller en mediaspelare, men de kan inte avgöra om det associerade innehållet är live eller förinspelat, om ett synligt textområde på sidan verkligen uppdateras i synkroni med en ljudström, om textinnehållet är semantiskt likvärdigt med ljudet (täcker all talad och icke-talad ljudinformation), eller om någon länkad extern textningstjänst faktiskt är aktiv och korrekt. Alla dessa bedömningar kräver mänsklig granskning av själva livesändningen.
• Vad en manuell granskare måste kontrollera: Granskaren måste gå in på sidan medan den direktsända ljudströmmen är aktiv, identifiera hur (eller om) ett textalternativ presenteras, bekräfta att textalternativet uppdateras i realtid allteftersom ljudet fortskrider, verifiera att texten täcker allt meningsfullt ljudinnehåll inklusive identifiering av talare, icke-talade ljud och övergångar, samt bekräfta att textalternativet är tillgängligt för hjälpmedel — till exempel att ett liveområde som använder aria-live='polite' eller aria-live='assertive' meddelar uppdateringar för skärmläsaranvändare på ett korrekt sätt.
• Delvis automatiserade signaler: Även om axe-core inte direkt kan flagga ett saknat live textalternativ, bör granskare notera att axe-core kommer att flagga relaterade problem som förvärrar situationen — till exempel om ett texttranskriptionsområde finns men är dolt med display:none, eller om en mediaspelare saknar tillgängliga kontroller. Dessa flaggor fungerar som användbara utgångspunkter under en manuell granskning.

Hur man testar

1. Automatiserad skanning som baslinje: Kör axe DevTools eller Lighthouse mot sidan som är värd för den direktsända ljudströmmen. Notera eventuella flaggade problem med medieelement, saknade etiketter eller otillgängliga kontroller. Även om inget av verktygen direkt flaggar ett saknat live textalternativ kan de lyfta fram relaterade hinder — såsom en ljudspelare utan tillgängligt namn eller en transkriptionsbehållare som är dold från tillgänglighetsträdet. Dokumentera dessa fynd och behandla dem som en del av den övergripande tillgänglighetsbedömningen.
2. Identifiera liveinnehållet med enbart ljud: Medan livesändningen är aktiv, bekräfta att ljudströmmen är live (inte en inspelning) och att den inte har något videospår. Kontrollera sidkällan och nätverksförfrågningar för ledtrådar — liveströmmar använder vanligtvis HLS (.m3u8), MPEG-DASH eller WebSocket-baserad leverans. Bekräfta att innehållet är enbart ljud.
3. Kontrollera om det finns ett textalternativ: Leta efter ett synligt textområde, en undertextoverlay eller ett tydligt märkt transkriptionsflöde på sidan eller direkt länkat från sidan. Alternativet måste lyftas fram tydligt — inte gömt i en inställningsmeny eller endast tillgängligt på begäran. Om inget textalternativ är synligt underkänns kriteriet omedelbart.
4. Verifiera synkronitet: Med det live textalternativet synligt, lyssna på ljudströmmen och läs textflödet samtidigt. Bekräfta att texten uppdateras med en rimlig fördröjning (vanligtvis högst några sekunder för CART eller professionella textningstjänster). Ett textflöde som uppdateras var flera minut eller först efter att sändningen avslutats uppfyller inte kriteriet.
5. Verifiera likvärdighet: Bekräfta att textalternativet fångar allt meningsfullt ljudinnehåll: talade ord, identifiering av talare när flera röster förekommer, relevant icke-talad ljudinformation (t.ex. ”[applåder]”, ”[larmljud]”, ”[musik spelas]”) och alla meddelanden eller avbrott i sändningen.
6. Skärmläsartest — NVDA + Firefox: Öppna sidan med NVDA aktivt. Navigera till live textområdet. Om området använder aria-live ska NVDA automatiskt meddela nya textinsättningar. Om det är ett rullande textområde, verifiera att fokus kan placeras på det och att innehållet är läsbart. Kontrollera att ljudspelarens kontroller också kan användas med tangentbord.
7. Skärmläsartest — VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver och navigera till live textområdet. Bekräfta att VoiceOver läser upp ny text när den visas. På iOS, verifiera också upplevelsen på mobil — liveevenemang nås ofta via mobila webbläsare.
8. Skärmläsartest — JAWS + Chrome: Med JAWS aktivt, navigera till sidan och bekräfta att meddelanden från liveområdet fungerar. JAWS hanterar aria-live='polite' och aria-live='assertive' olika; bekräfta att detaljnivån är lämplig för typen av innehåll (ett snabbt uppdaterande undertextflöde kan passa bättre med assertive för att undvika köfördröjningar).
9. Test på mobil och med låg bandbredd: Om webbplatsen har en mobil målgrupp, testa det live textalternativet på en mellanklass-Androidenhet över en strypt uppkoppling. Bekräfta att textflödet förblir synkroniserat och tillgängligt även under begränsade förhållanden.

Hur man åtgärdar

Scenario 1: Live ljudspelare utan textalternativ — Felaktigt

<!-- 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 ljudspelare med ARIA liveområde-transkript — Korrekt

<!-- 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: Transkript publiceras först efter att evenemanget avslutats — Felaktigt

<!-- 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: CART-flöde i realtid länkat intill spelaren — Korrekt

<!-- 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: Automatgenererade undertexter dolda bakom en inställningsväxel — Felaktigt

<!-- 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: Undertexter aktiverade som standard med en tydlig växel — Korrekt

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

Vanliga misstag

• Att publicera en transkription efter evenemanget och hävda att den uppfyller 1.2.9: En transkription som publiceras timmar eller dagar efter en livesändning är inte ett textalternativ i realtid. WCAG 1.2.9 kräver uttryckligen att alternativet ska vara tillgängligt samtidigt som live-ljudet, inte i efterhand.
• Att använda aria-live='polite' för ett snabbt undertextflöde: ”Polite”-liveområden väntar tills användaren har avslutat sin interaktion innan de meddelar nytt innehåll. För snabbt uppdaterande undertexter gör detta att skärmläsaranvändare missar meddelanden. Använd aria-live='assertive' för liveundertextströmmar där varje uppdatering är tidskritisk.
• Att injicera hela undertexthistoriken vid varje uppdatering istället för endast nytt innehåll: När aria-atomic='true' är satt och hela textblocket ersätts vid varje uppdatering försöker skärmläsare läsa om hela området, vilket skapar en ryckig upplevelse. Använd aria-atomic='false' och lägg till nya textnoder så att endast den nya delen meddelas.
• Att bädda in undertextflödet i ett <canvas>-element eller som en grafisk videooverlay: Undertext som renderas som pixlar på en canvas eller bränns in i en videobild är osynlig för hjälpmedel. Textalternativ måste tillhandahållas som faktiska DOM-textnoder.
• Att placera liveundertextområdet utanför skärmen med position:absolute; left:-9999px: Även om visuellt dolt innehåll på detta sätt finns kvar i tillgänglighetsträdet, förvägras seende användare med hörselnedsättning möjligheten att läsa undertexterna. Textalternativet måste vara visuellt tillgängligt för alla användare, inte bara skärmläsaranvändare.
• Att inte identifiera talare i sändningar med flera talare: Ett undertextflöde som transkriberar tal utan att tillskriva det specifika talare (t.ex. ”[Moderator]:”, ”[VD]:”, ”[Publikmedlem]:”) är inte fullt likvärdigt. Identifiering av talare är avgörande för att användare ska kunna följa den samtalsstruktur som ett liveevenemang har.
• Att utelämna icke-talad ljudinformation från textalternativet: Relevanta ljud såsom applåder, tekniska avbrott, bakgrundsmusik, larm eller skratt har informationsinnehåll och måste beskrivas i textflödet (t.ex. ”[applåder]”, ”[tekniska problem — ljudet avbrutet]”).
• Att endast tillhandahålla textalternativet via en separat tredjeparts-URL utan att bädda in det på samma sida: Att kräva att användare öppnar en separat webbläsarflik eller ett separat fönster för att få tillgång till undertexter medan ljudet spelas på den ursprungliga sidan skapar ett betydande användbarhetshinder, särskilt för skärmläsar- och tangentbordsanvändare som måste byta sammanhang.
• Att anta att automatgenererade undertexter alltid uppfyller likvärdighetskravet: AI-genererade undertexter kan ha hög felfrekvens vid accentuerat tal, teknisk vokabulär, egennamn och snabbt tal. Att använda okorrigerade automatgenererade undertexter för ett liveevenemang med höga insatser (t.ex. en medicinsk genomgång eller finansiell information) kan misslyckas med likvärdighetskravet även om ett undertextflöde tekniskt sett finns.
• Att inte testa live textområdet med faktiska skärmläsare under en livesändning: Många team testar spelaren och undertextbehållaren isolerat med statisk platshållartext, men testar aldrig det dynamiska beteendet under en verklig liveström. Buggar i JavaScriptet som injicerar undertextuppdateringar — såsom DOM-övervakare som misslyckas tyst — kommer endast att upptäckas under live-testning.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer bindande krav på webbtillgänglighet för ett brett spektrum av organisationer som är verksamma i Turkiet. Cirkuläret föreskriver efterlevnad av WCAG 2.2 på nivå AA som baslinjestandard. De typer av aktörer som omfattas inkluderar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som auktoriserats av utbildningsministeriet (MoNE).

WCAG 1.2.9 är ett kriterium på nivå AAA, vilket innebär att det inte ingår bland de efterlevnadskrav som föreskrivs av cirkuläret på AA-baslinjen. Organisationer som omfattas av presidentcirkulär 2025/10 är inte juridiskt skyldiga att implementera textalternativ för liveinnehåll med enbart ljud om de inte separat har åtagit sig full efterlevnad av WCAG 2.2 nivå AAA.

Flera praktiska överväganden gör dock 1.2.9 mycket relevant för turkiska organisationer även bortom den strikta juridiska miniminivån. Telekommunikationsleverantörer, finansiella institutioner och public service-bolag levererar ofta liveinnehåll i ljudform — resultatsamtal, offentliga meddelanden, direktsända kundtjänstsändningar — som döva och hörselskadade användare i Turkiet är beroende av. Att demonstrera efterlevnad på AAA-nivå signalerar ett förstklassigt tillgänglighetsåtagande och minskar avsevärt risken för diskrimineringsklagomål enligt Turkiets bredare ramverk för funktionsrättigheter, inklusive lagen om personer med funktionsnedsättning nr 5378 och dess genomförandeföreskrifter.

För organisationer som frivilligt strävar efter efterlevnad av WCAG 2.2 nivå AAA — vare sig för att särskilja sin tillgänglighetsprofil, för att betjäna internationella marknader med striktare krav eller för att uppfylla upphandlingskriterier som kräver AAA — är korrekt implementering av 1.2.9 avgörande. Accsible rekommenderar att turkiska organisationer i reglerade sektorer proaktivt utvärderar sitt liveinnehåll i ljudform och bedömer möjligheten att integrera CART-tjänster eller högprecisionstextning i realtid, särskilt för publika liveevenemang där informationsegalitet är en konkret förväntan från intressenter.