WCAG 1.2.4: Napisy (na żywo)

Co oznacza ta zasada

\n

WCAG 1.2.4 (Napisy — treści na żywo) wymaga, aby napisy były zapewnione dla wszystkich treści audio na żywo w mediach zsynchronizowanych. Media zsynchronizowane są definiowane jako treści audio lub wideo, które są zsynchronizowane z innym formatem prezentowania informacji lub z interaktywnymi komponentami zależnymi od czasu, takimi jak webcast, transmisja na żywo lub nadawanie w czasie rzeczywistym w sieci.

\n

W praktyce oznacza to, że każde wydarzenie na żywo opublikowane na stronie internetowej lub w aplikacji webowej, które zawiera dźwięk — transmitowana na stronie informacyjnej konferencja prasowa, firmowa transmisja „all-hands”, przesłuchanie rządowe, zajęcia online na żywo czy transmisja komentarza sportowego — musi wyświetlać napisy w czasie rzeczywistym, które dokładnie odzwierciedlają to, co jest wypowiadane w momencie, gdy to pada.

\n

Co jest uznawane za spełnienie kryterium: Transmisja na żywo spełnia to kryterium, gdy zsynchronizowane, dokładne napisy w czasie rzeczywistym są widoczne dla użytkownika podczas odtwarzania. Napisy muszą odzwierciedlać cały dialog oraz istotne informacje z dźwięków innych niż mowa (takie jak „[oklaski]” czy „[dźwięk alarmu]”). Typowe podejścia obejmują CART (Communication Access Realtime Translation) zapewniane przez profesjonalnego autora napisów, napisy generowane automatycznie przez system rozpoznawania mowy (ASR) z kwalifikowanej usługi napisów na żywo lub integracje zewnętrzne, takie jak te oferowane przez platformy streamingowe.

\n

Co jest uznawane za niespełnienie kryterium: Transmisja na żywo nie spełnia tego kryterium, gdy napisy nie są dostępne, gdy napisy nie są zsynchronizowane z mówionym dźwiękiem, gdy napisy pomijają istotne fragmenty dialogu lub gdy dokładność napisów jest tak niska, że zrozumienie jest poważnie utrudnione. Udostępnienie transkrypcji po fakcie nie spełnia tego wymagania — napisy muszą być dostępne na żywo, w czasie rzeczywistym.

\n

Oficjalne wyjątki: WCAG definiuje jeden wyjątek od tej zasady: media, które same w sobie są alternatywą medialną dla tekstu i są wyraźnie jako takie oznaczone, są zwolnione. Na przykład, jeśli publikujesz szczegółową transkrypcję tekstową wywiadu, a następnie udostępniasz także wersję audio na żywo tej samej treści, która jest wyraźnie oznaczona jako alternatywa audio dla tekstu, napisy mogą nie być bezwzględnie wymagane. Jednak ten wyjątek jest wąski i rzadko ma zastosowanie w praktyce.

\n

Kryterium ma zastosowanie do wszystkich mediów zsynchronizowanych publikowanych w sieci — niezależnie od tego, czy wideo zostało przygotowane wcześniej, czy jest rzeczywiście na żywo. Odtwarzany jak na żywo zapis wcześniej nagranego webinaru nadal podlega 1.2.3 lub 1.2.5, ale prawdziwa transmisja w czasie rzeczywistym wprost podlega 1.2.4.

\n\n

Dlaczego to ma znaczenie

\n

Około 430 milionów osób na całym świecie ma upośledzenie słuchu według Światowej Organizacji Zdrowia, a liczba ta ma wzrosnąć do ponad 700 milionów do 2050 roku. Dla osób głuchych i słabosłyszących napisy w czasie rzeczywistym nie są udogodnieniem — są podstawowym lub jedynym sposobem dostępu do treści audio w kontekście na żywo. Bez napisów użytkownicy ci są całkowicie wykluczeni z uczestnictwa w jakimkolwiek wydarzeniu medialnym na żywo lub zrozumienia go.

\n

Poza głuchotą i ubytkiem słuchu, napisy na żywo przynoszą korzyści znacznie szerszej grupie odbiorców. Użytkownicy w hałaśliwym otoczeniu — lotniska, biura typu open space, transport publiczny — mogą nie być w stanie korzystać z dźwięku. Użytkownicy oglądający w cichym otoczeniu bez słuchawek lub tacy, którzy wyciszyli swoje urządzenia, polegają na napisach, aby śledzić treść. Osoby niebędące rodzimymi użytkownikami języka często uznają napisy za niezbędne do zrozumienia, szczególnie gdy mówcy używają złożonego słownictwa, akcentów lub specjalistycznego żargonu. Różnice w przetwarzaniu poznawczym i językowym również mogą sprawić, że napisy staną się kluczowe dla dokładnego zrozumienia.

\n

Rozważmy konkretny scenariusz: gmina w Turcji transmituje na żywo posiedzenie rady miejskiej na swojej oficjalnej stronie internetowej. Mieszkanka lub mieszkaniec, który jest głuchy, chce śledzić debatę na temat zmian w zagospodarowaniu przestrzennym w swojej okolicy. Bez napisów w czasie rzeczywistym ta osoba jest całkowicie wykluczona z udziału w życiu obywatelskim. To samo dotyczy głuchej studentki lub głuchego studenta uczestniczących w zajęciach online na żywo w systemie zarządzania nauczaniem prywatnej szkoły lub klientki/klienta próbującej/próbującego śledzić webinar banku z ogłoszeniem nowego produktu na żywo.

\n

Z praktycznego punktu widzenia infrastruktura napisów na żywo generuje również transkrypcję, którą można indeksować w wyszukiwarkach, poprawiając wykrywalność treści wideo. Organizacje inwestujące w napisy na żywo często odkrywają, że powstała transkrypcja staje się cennym zasobem do dokumentacji po wydarzeniu, tworzenia podsumowań i wyszukiwania w archiwach.

\n\n

Powiązane reguły Axe-core

\n

WCAG 1.2.4 wymaga testów manualnych. Żadna zautomatyzowana reguła axe-core nie może wiarygodnie wykryć obecności ani jakości napisów na żywo, i jest to ważne rozróżnienie, które należy zrozumieć przy planowaniu strategii audytu dostępności.

\n

\n
• Wymagane testy manualne — obecność napisów na żywo: Narzędzia automatyczne, takie jak axe-core, mogą skanować DOM w poszukiwaniu elementu <track> z kind='captions' w elemencie <video>, ale transmisje na żywo prawie nigdy nie są dostarczane za pomocą prostego elementu HTML <video> z <track>. Zazwyczaj używają formatów adaptacyjnej przepływności (HLS, DASH) dostarczanych przez odtwarzacze oparte na JavaScript, takie jak Video.js, JW Player lub natywne odtwarzacze platformowe. Te odtwarzacze renderują napisy dynamicznie w sposób, którego axe-core nie może introspekcyjnie zbadać. Narzędzie nie może oglądać transmisji na żywo w czasie rzeczywistym, oceniać dokładności napisów, mierzyć opóźnienia synchronizacji ani określić, czy nakładka z napisami rzeczywiście odzwierciedla treść mówioną, czy jest statycznym wypełniaczem.
\n
• Wymagane testy manualne — jakość i dokładność napisów: Nawet gdyby narzędzie automatyczne mogło wykryć, że istnieje strumień napisów, nie ma ono możliwości oceny, czy napisy są dokładne, kompletne lub zsynchronizowane w akceptowalnym stopniu. Napisy tworzone przez CART i napisy słabej jakości generowane automatycznie mogą być przez narzędzie postrzegane jednakowo jako „napisy obecne”, ale tylko jedne z nich spełniają WCAG 1.2.4. Ludzka weryfikacja podczas wydarzenia na żywo jest jedynym wiarygodnym sposobem potwierdzenia zgodności.
\n
• Wymagane testy manualne — dostępność napisów w odtwarzaczu: Narzędzia automatyczne zazwyczaj nie są w stanie określić, czy kontrolki napisów w niestandardowym odtwarzaczu multimedialnym są dostępne z klawiatury, czy wyświetlanie napisów można zmieniać rozmiarem lub dostosowywać przez użytkownika, ani czy styl napisów odpowiada potrzebom użytkowników. Te aspekty wymagają praktycznych testów z użyciem rzeczywistej nawigacji klawiaturą i czytników ekranu.
\n

\n\n

Jak testować

\n

\n
1. Zidentyfikuj wszystkie media na żywo na stronie: Przejrzyj stronę pod kątem wszelkich transmisji wideo lub audio na żywo. Sprawdź osadzone odtwarzacze, iframe’y lub dynamicznie ładowane komponenty multimedialne. Zwróć uwagę, czy treść jest rzeczywiście na żywo (transmisja w czasie rzeczywistym), czy nagrana wcześniej. Tylko rzeczywiście na żywo treści audio w mediach zsynchronizowanych podlegają 1.2.4.
\n
2. Uruchom skan automatyczny za pomocą axe DevTools lub Lighthouse: Otwórz axe DevTools w Chrome DevTools i uruchom skan całej strony. Choć axe nie może zweryfikować napisów na żywo, może wskazać powiązane problemy, takie jak brakujące aria-label w kontrolkach odtwarzacza, niedostępne przyciski odtwarzania/pauzy lub brak zarządzania fokusem. Zanotuj wszelkie wykryte problemy jako dowody pomocnicze, ale pamiętaj, że czysty raport axe nie potwierdza zgodności z 1.2.4.
\n
3. Ręcznie zweryfikuj dostępność napisów podczas wydarzenia na żywo: Uzyskaj dostęp do transmisji na żywo podczas aktywnego nadawania. Sprawdź, czy napisy są wyświetlane. Jeśli odtwarzacz ma przełącznik napisów (przycisk CC), aktywuj go i potwierdź, że napisy pojawiają się i aktualizują niemal w czasie rzeczywistym wraz z wypowiedziami mówcy. Potwierdź, że opóźnienie napisów jest akceptowalne — zazwyczaj nie więcej niż kilka sekund dla CART lub nieco więcej dla ASR.
\n
4. Oceń dokładność napisów: Słuchaj dźwięku, jednocześnie czytając napisy. Sprawdź, czy nie ma pominiętych słów, systematycznych błędów lub istotnych opuszczeń. Napisy nie muszą być dosłowne, ale muszą oddawać pełne znaczenie treści mówionej. Zwróć uwagę na oznaczanie mówców, jeśli występuje ich wielu — napisy powinny wskazywać, kto mówi, gdy nie jest to oczywiste.
\n
5. Przetestuj z NVDA + Firefox: Przejdź do odtwarzacza multimedialnego za pomocą klawisza Tab. Zweryfikuj, że wszystkie kontrolki odtwarzacza, w tym przełącznik napisów, są osiągalne i obsługiwalne z klawiatury. Potwierdź, że NVDA ogłasza stan przycisku napisów (włączone/wyłączone). Aktywuj napisy i sprawdź, czy tekst napisów pojawia się w elemencie DOM, który NVDA może odczytać, jeśli użytkownik przechodzi tabulatorem do lub wokół odtwarzacza.
\n
6. Przetestuj z VoiceOver + Safari (macOS lub iOS): Użyj gestów VoiceOver lub poleceń klawiaturowych, aby nawigować po odtwarzaczu. Zweryfikuj, że przełącznik napisów jest ogłaszany i obsługiwalny. Potwierdź, że zmiany tekstu napisów są odpowiednio prezentowane w dostępnej dla użytkownika części odtwarzacza.
\n
7. Przetestuj z JAWS + Chrome: Przejdź do kontrolek odtwarzacza za pomocą klawisza Tab. Zweryfikuj, że JAWS odczytuje wszystkie etykiety kontrolek. Potwierdź, że przełącznik napisów jest rozpoznawany jako przycisk z odpowiednią etykietą i stanem. Aktywuj napisy i sprawdź, czy wyświetlanie napisów aktualizuje się zgodnie z oczekiwaniami.
\n
8. Sprawdź możliwości dostosowania wyświetlania napisów: Zweryfikuj, czy odtwarzacz pozwala użytkownikom zmieniać rozmiar tekstu napisów, kolory lub kontrast. Choć nie jest to bezpośrednio wymagane przez 1.2.4, stanowi punkt oceny dobrych praktyk i jest istotne dla kryteriów WCAG 1.4.
\n

\n\n

Jak naprawić

\n

Transmisja na żywo bez ścieżki napisów — Niepoprawne

\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

Transmisja na żywo ze zintegrowaną ścieżką napisów CART — Poprawne

\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

Osadzona transmisja na żywo z platformy z wyłączonymi napisami w osadzeniu — Niepoprawne

\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

Osadzona transmisja na żywo z platformy z włączonymi napisami — Poprawne

\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

Niestandardowy odtwarzacz z przełącznikiem napisów niedostępnym z klawiatury — Niepoprawne

\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

Niestandardowy odtwarzacz z dostępnym przełącznikiem napisów — Poprawne

\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

Typowe błędy

\n

\n
• Udostępnianie transkrypcji po wydarzeniu zamiast napisów w czasie rzeczywistym: Opublikowanie tekstowej transkrypcji wydarzenia na żywo po jego zakończeniu nie spełnia 1.2.4. Napisy muszą być dostępne równocześnie z dźwiękiem na żywo, umożliwiając osobom głuchym śledzenie treści w czasie rzeczywistym wraz z widzącymi osobami słyszącymi.
\n\n

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