WCAG 1.2.4: Textning (live)

Vad den här regeln innebär

\n

WCAG 1.2.4 (Textning — direktsändning) kräver att textning tillhandahålls för allt direktsänt ljudinnehåll i synkroniserade medier. Synkroniserade medier definieras som ljud- eller videoinnehåll som är synkroniserat med ett annat format för att presentera information eller med tidsbaserade interaktiva komponenter, såsom en webcast, liveström eller direktsändning på webben.

\n

I praktiken innebär detta att alla direktsända evenemang som publiceras på en webbplats eller webbapplikation och som innehåller ljud — en presskonferens som strömmas på en nyhetssajt, en företagsomfattande direktsändning, en offentlig utfrågning, en direktsänd onlinelektion eller en sportkommentarsström — måste visa textning i realtid som korrekt återger det som sägs när det sker.

\n

Vad som räknas som godkänt: En liveström uppfyller detta kriterium när synkroniserad, korrekt textning i realtid är synlig för användaren under uppspelning. Textningen måste återge all dialog och relevant icke-talat ljud (såsom ”[applåder]” eller ”[larmljud]”). Vanliga metoder inkluderar CART (Communication Access Realtime Translation) som tillhandahålls av en professionell textare, automatisk taligenkänning (ASR) från en kvalificerad tjänst för direktextning, eller tredjepartsintegrationer såsom de som erbjuds av strömningsplattformar.

\n

Vad som räknas som underkänt: En liveström uppfyller inte detta kriterium när ingen textning finns tillgänglig, när textningen inte är synkroniserad med det talade ljudet, när textningen utelämnar betydande delar av dialogen, eller när textningens noggrannhet är så låg att förståelsen blir allvarligt försämrad. Att tillhandahålla en transkription i efterhand uppfyller inte detta krav — textning måste finnas direkt, i realtid.

\n

Officiella undantag: WCAG definierar ett undantag från denna regel: media som i sig är ett medialternativ till text, och som tydligt är märkt som sådant, är undantaget. Till exempel, om du publicerar en detaljerad texttranskription av en intervju och sedan också tillhandahåller en direktsänd ljudversion av samma innehåll som uttryckligen är märkt som ett ljudalternativ till texten, kan textning vara mindre strikt nödvändig. Detta undantag är dock snävt och sällan tillämpligt i praktiken.

\n

Kriteriet gäller för alla synkroniserade medier som publiceras på webben — oavsett om videon har producerats i förväg eller är genuint direktsänd. En förinspelad webbinarieuppspelning som strömmas som om den vore live omfattas fortfarande av 1.2.3 eller 1.2.5, men en genuin direktsändning omfattas direkt av 1.2.4.

\n\n

Varför det är viktigt

\n

Ungefär 430 miljoner människor världen över har funktionsnedsättande hörselnedsättning enligt Världshälsoorganisationen, och det antalet beräknas stiga till över 700 miljoner till 2050. För döva och hörselskadade användare är textning i realtid inte en bekvämlighet — det är det primära eller enda sättet att ta del av ljudinnehåll i en direktsänd kontext. Utan textning utestängs dessa användare helt från att delta i eller förstå något direktsänt mediaevenemang.

\n

Utöver dövhet och hörselnedsättning gynnar direktextning en mycket bredare publik. Användare i bullriga miljöer — flygplatser, öppna kontorslandskap, kollektivtrafik — kan vara oförmögna att använda ljud. Användare som tittar i tysta miljöer utan hörlurar, eller användare som har stängt av ljudet på sina enheter, är beroende av textning för att kunna följa med. Icke-modersmålstalare upplever ofta textning som oumbärlig för förståelsen, särskilt när talare använder komplex vokabulär, accenter eller teknisk jargong. Kognitiva och språkliga bearbetningsskillnader kan också göra textning avgörande för korrekt förståelse.

\n

Överväg ett konkret scenario: en kommun i Turkiet strömmar ett direktsänt kommunfullmäktigemöte på sin officiella webbplats. En boende som är döv vill följa debatten om ändringar i detaljplanen i deras område. Utan textning i realtid utestängs den boende helt från medborgerligt deltagande. Detsamma gäller en döv student som deltar i en direktsänd onlinelektion i ett privat skolors lärplattform, eller en kund som försöker följa en banks direktsända webbinariepresentation av en produktlansering.

\n

Ur ett praktiskt perspektiv genererar infrastrukturen för direktextning också en transkription som kan indexeras av sökmotorer, vilket förbättrar upptäckbarheten för videoinnehåll. Organisationer som investerar i direktextning upptäcker ofta att transkriptet blir en värdefull resurs för dokumentation efter evenemanget, sammanfattningar och arkivsökning.

\n\n

Relaterade Axe-core-regler

\n

WCAG 1.2.4 kräver manuell testning. Ingen automatiserad axe-core-regel kan pålitligt upptäcka förekomsten eller kvaliteten på direktextning, och detta är en viktig skillnad att förstå när du planerar din strategi för tillgänglighetsgranskning.

\n

\n
• Manuell testning krävs — förekomst av direktextning: Automatiserade verktyg som axe-core kan skanna DOM:en efter förekomsten av ett <track>-element med kind='captions' på ett <video>-element, men liveströmmar levereras nästan aldrig via ett enkelt HTML-<video>-element med ett <track>. De använder vanligtvis adaptiva bitrate-format (HLS, DASH) som levereras genom JavaScript-baserade spelare såsom Video.js, JW Player eller inbyggda plattformsspelare. Dessa spelare renderar textning dynamiskt på sätt som axe-core inte kan inspektera. Ett verktyg kan inte titta på en liveström i realtid, utvärdera textningens noggrannhet, mäta synkroniseringsfördröjning eller avgöra om en textningsoverlay verkligen återger talat innehåll eller är en statisk platshållare.
\n
• Manuell testning krävs — textningskvalitet och noggrannhet: Även om ett automatiserat verktyg skulle kunna upptäcka att en textningsström finns, har det inget sätt att bedöma om textningen är korrekt, fullständig eller tillräckligt synkroniserad. CART-producerad textning och textning av låg kvalitet som genereras automatiskt kan båda framstå som ”textning finns” för ett verktyg, men bara den ena uppfyller WCAG 1.2.4. Mänsklig granskning under ett direktsänt evenemang är det enda pålitliga sättet att verifiera efterlevnad.
\n
• Manuell testning krävs — textningens tillgänglighet i spelaren: Automatiserade verktyg kan i allmänhet inte avgöra om textningskontroller i en anpassad mediaspelare är tangentbordsåtkomliga, om textningsvisningen kan förstoras eller anpassas av användaren, eller om textningsstilen uppfyller användarnas behov. Dessa aspekter kräver praktisk testning med faktisk tangentbordsnavigering och skärmläsaranvändning.
\n

\n\n

Hur man testar

\n

\n
1. Identifiera allt direktsänt media på sidan: Gå igenom sidan efter alla direktsända video- eller ljudströmmar. Kontrollera inbäddade spelare, iframes eller dynamiskt inladdade mediakomponenter. Notera om innehållet är genuint direktsänt (direktsändning i realtid) eller förinspelat. Endast genuint direktsänt ljudinnehåll i synkroniserade medier omfattas av 1.2.4.
\n
2. Kör en automatiserad skanning med axe DevTools eller Lighthouse: Öppna axe DevTools i Chrome DevTools och kör en fullständig sidskanning. Även om axe inte kan validera direktextning kan det flagga relaterade problem såsom saknad aria-label på kontroller i mediaspelaren, otillgängliga play/paus-knappar eller bristande fokus­hantering. Notera alla flaggade problem som stödjande bevis, men förstå att en ren axe-rapport inte bekräftar efterlevnad av 1.2.4.
\n
3. Verifiera manuellt att textning finns under ett direktsänt evenemang: Gå in på liveströmmen under en aktiv sändning. Kontrollera om textning visas. Om spelaren har en textningsknapp (CC-knapp), aktivera den och bekräfta att textning visas och uppdateras nästan i realtid när talaren pratar. Bekräfta att fördröjningen i textningen är acceptabel — vanligtvis högst några sekunder för CART, eller något mer för ASR.
\n
4. Bedöm textningens noggrannhet: Lyssna på ljudet medan du läser textningen. Kontrollera om ord saknas, om det finns systematiska fel eller betydande utelämnanden. Textningen behöver inte vara ordagrann, men den måste förmedla hela innebörden av det talade innehållet. Notera talaridentifiering om flera talare förekommer — textningen bör ange vem som talar när det inte är uppenbart.
\n
5. Testa med NVDA + Firefox: Navigera till mediaspelaren med Tab-tangenten. Verifiera att alla spelarkontroller inklusive textningsknappen är nåbara och kan användas med tangentbordet. Bekräfta att NVDA meddelar tillståndet för textningsknappen (på/av). Aktivera textning och verifiera att textningstexten visas i ett DOM-element som NVDA kan läsa om användaren tabbar till eller runt spelaren.
\n
6. Testa med VoiceOver + Safari (macOS eller iOS): Använd VoiceOver-gester eller tangentbordskommandon för att navigera i spelaren. Verifiera att textningsknappen annonseras och kan användas. Bekräfta att ändringar i textningstexten exponeras på ett lämpligt sätt inom spelarens tillgängliga region.
\n
7. Testa med JAWS + Chrome: Navigera till spelarkontrollerna med Tab. Verifiera att JAWS läser alla kontroll­etiketter. Bekräfta att textningsknappen identifieras som en knapp med lämplig etikett och tillstånd. Aktivera textning och verifiera att textningsvisningen uppdateras som förväntat.
\n
8. Kontrollera anpassning av textningsvisning: Verifiera om spelaren låter användare förstora textningstext, ändra färger eller justera kontrast. Även om detta inte strikt krävs av 1.2.4 är det en bästa praxis och relevant för WCAG 1.4-kriterier.
\n

\n\n

Hur man åtgärdar

\n

Direktsändning utan textningsspår — Felaktigt

\n

<!-- A live HLS stream embedded with no caption configuration -->\n<video id='live-player' controls autoplay>\n  <source src='https://stream.example.com/live/event.m3u8' type='application/x-mpegURL'>\n  <!-- No <track> element and no caption configuration in the player -->\n</video>

\n

Direktsändning med integrerat CART-textningsspår — Korrekt

\n

<!-- Live stream using Video.js with a live WebVTT caption track fed by a CART service.\n     The src for the track points to a live caption endpoint that updates in real time. -->\n<video\n  id='live-player'\n  class='video-js vjs-default-skin'\n  controls\n  autoplay\n  aria-label='Live conference stream with real-time captions'>\n  <source src='https://stream.example.com/live/event.m3u8' type='application/x-mpegURL'>\n  <track\n    kind='captions'\n    src='https://captions.example.com/live/event.vtt'\n    srclang='tr'\n    label='Turkish captions'\n    default>\n</video>\n<script>\n  var player = videojs('live-player');\n  // Enable captions by default for accessibility\n  player.ready(function() {\n    player.textTracks()[0].mode = 'showing';\n  });\n</script>

\n

Inbäddad direktsändning från en plattform med textning inaktiverad i inbäddningen — Felaktigt

\n

<!-- YouTube live embed with closed captions explicitly disabled via cc_load_policy=0.\n     This removes the user's ability to enable captions, causing a 1.2.4 failure. -->\n<iframe\n  src='https://www.youtube.com/embed/live_stream?channel=CHANNEL_ID&cc_load_policy=0'\n  title='Company all-hands live stream'\n  allowfullscreen>\n</iframe>

\n

Inbäddad direktsändning från en plattform med textning aktiverad — Korrekt

\n

<!-- YouTube live embed with closed captions enabled by default (cc_load_policy=1).\n     The platform's native caption infrastructure is used, which supports live auto-captions\n     and human-reviewed CART when configured in the YouTube Studio settings.\n     The host page also provides a direct link to the captioned stream for users\n     who cannot interact with the iframe. -->\n<iframe\n  src='https://www.youtube.com/embed/live_stream?channel=CHANNEL_ID&cc_load_policy=1'\n  title='Company all-hands live stream with captions enabled'\n  allowfullscreen>\n</iframe>\n<p>\n  <a href='https://www.youtube.com/watch?v=LIVE_VIDEO_ID'>\n    Watch with captions directly on YouTube\n  </a>\n</p>

\n

Anpassad spelare med en textningsknapp som inte är tangentbordsåtkomlig — Felaktigt

\n

<!-- Caption toggle implemented as a non-interactive <div>.\n     Keyboard users and screen reader users cannot activate this control. -->\n<div class='player-controls'>\n  <div class='cc-button' onclick='toggleCaptions()'>CC</div>\n</div>

\n

Anpassad spelare med en tillgänglig textningsknapp — Korrekt

\n

<!-- Caption toggle implemented as a <button> with an explicit label and\n     ARIA pressed state so keyboard and screen reader users can discover\n     and operate it. The state updates dynamically when captions are toggled. -->\n<div class='player-controls'>\n  <button\n    class='cc-button'\n    id='captions-toggle'\n    aria-pressed='false'\n    aria-label='Toggle captions'\n    onclick='toggleCaptions(this)'>\n    CC\n  </button>\n</div>\n<script>\n  function toggleCaptions(btn) {\n    var isActive = btn.getAttribute('aria-pressed') === 'true';\n    btn.setAttribute('aria-pressed', String(!isActive));\n    // logic to show/hide the caption track\n  }\n</script>

\n\n

Vanliga misstag

\n

\n
• Att tillhandahålla en transkription efter evenemanget istället för textning i realtid: Att publicera en texttranskription av ett direktsänt evenemang efter att det avslutats uppfyller inte 1.2.4. Textning måste finnas tillgänglig samtidigt som det direktsända ljudet, så att döva användare kan följa innehållet i realtid tillsammans med seende hörande användare.

(Content truncated due to token limit — please retry this article.)