WCAG 1.2.9: Tylko dźwięk (na żywo)

Co oznacza ta zasada

Kryterium sukcesu WCAG 1.2.9, Tylko dźwięk (na żywo), należy do Wytycznej 1.2 (Media zależne od czasu) na poziomie AAA. Stanowi ono: „Dostępna jest alternatywa dla mediów zależnych od czasu, która przedstawia równoważne informacje dla treści audio na żywo bez obrazu.” W praktyce oznacza to, że za każdym razem, gdy Twoja strona internetowa lub aplikacja transmituje lub dostarcza treści audio na żywo — i treści te nie mają komponentu wideo — użytkownikom musi zostać udostępniony równoważny tekst w czasie rzeczywistym, który wiernie przekazuje te same informacje.

Prezentacja audio na żywo bez obrazu to każdy strumień audio nadawany w czasie rzeczywistym bez zsynchronizowanej ścieżki wideo. Typowe przykłady obejmują audycje radiowe na żywo osadzone na stronie, komentarz audio na żywo podczas wydarzenia sportowego, konferencje prasowe na żywo transmitowane w formacie audio, telekonferencje wynikowe lub briefingi dla inwestorów na żywo oraz podcasty audio na żywo lub transmisje talk-show, w których dźwiękowi nie towarzyszy żaden obraz wideo.

Wymagana przez to kryterium alternatywa tekstowa musi być równoważna — to znaczy musi obejmować nie tylko wypowiadane słowa, ale także istotne informacje z dźwięków niewerbalnych, takich jak odgłosy tłumu, alarmy, efekty dźwiękowe czy muzyka, jeśli niosą wartość informacyjną. Częściowa lub opóźniona transkrypcja nie spełnia tego kryterium; alternatywa musi być aktualizowana synchronicznie (lub prawie synchronicznie) ze strumieniem na żywo, aby osoby głuche i słabosłyszące mogły śledzić treść w czasie rzeczywistym.

Akceptowalne techniki spełnienia tego kryterium obejmują zapewnienie stenografa na żywo tworzącego tekst w czasie rzeczywistym (CART — Communication Access Realtime Translation), osadzenie zsynchronizowanych napisów na żywo generowanych przez wykwalifikowaną usługę tworzenia napisów lub wyświetlanie strumienia tekstowego na żywo, który jest uruchomiony równolegle z transmisją audio. Automatycznie generowane napisy tworzone przez oprogramowanie rozpoznawania mowy mogą również spełniać to kryterium, pod warunkiem że dokładność jest wystarczająco wysoka, a wynik jest prezentowany w czasie zbliżonym do rzeczywistego.

Co jest uznawane za spełnienie wymogu: Strona zapewnia widoczną, synchroniczną alternatywę tekstową — wyraźnie powiązaną z odtwarzaczem audio lub wyświetlaną obok niego — która przedstawia równoważne informacje względem strumienia audio na żywo w miarę jego trwania. Alternatywa musi być postrzegalna dla użytkowników, którzy nie słyszą dźwięku.

Co jest uznawane za niespełnienie wymogu: Nie jest oferowana żadna alternatywa tekstowa; alternatywa tekstowa jest zapewniona, ale znacząco opóźniona (np. transkrypcja opublikowana po wydarzeniu); alternatywa tekstowa obejmuje tylko część dźwięku (np. tylko wypowiedzi prowadzącego, ale nie pytania z publiczności); lub alternatywa tekstowa istnieje, ale nie jest dostępna dla użytkowników technologii asystujących (np. jest renderowana jako niefokusowalny element canvas lub zamknięta wewnątrz widżetu Flash).

Oficjalne wyjątki: WCAG nie przewiduje szczególnych wyjątków dla 1.2.9 poza ogólną zasadą, że wymóg dotyczy wyłącznie treści audio na żywo bez obrazu. Treści audio bez obrazu nagrane wcześniej są objęte odrębnym kryterium 1.2.1. Nie ma wyjątku dla krótkich klipów audio czy krótkich komunikatów — jeśli treść jest na żywo i tylko audio, kryterium ma zastosowanie.

Dlaczego to ma znaczenie

Około 466 milionów osób na świecie ma upośledzenie słuchu powodujące niepełnosprawność, według Światowej Organizacji Zdrowia, a liczba ta ma wzrosnąć do ponad 900 milionów do 2050 roku. Dla tych użytkowników treści audio na żywo bez obrazu są całkowicie niedostępne bez równoważnego tekstu. W przeciwieństwie do treści nagranych — dla których transkrypcję można przygotować z wyprzedzeniem i dołączyć po fakcie — audio na żywo stanowi szczególne wyzwanie, ponieważ informacje są wrażliwe na czas i ulotne. Użytkownik, który jest głuchy, nie może po prostu odtworzyć transmisji na żywo później i oczekiwać tego samego doświadczenia; z definicji treści na żywo tracą swoją aktualność, gdy chwila mija.

Rozważmy konkretny scenariusz z życia: spółka publiczna organizuje telekonferencję wynikową na żywo, transmitowaną jako audio bez obrazu na swojej stronie relacji inwestorskich. Analitycy, dziennikarze i inwestorzy indywidualni, którzy są głusi lub słabosłyszący, nie mogą uczestniczyć w tej telekonferencji — ani nawet biernie jej śledzić — bez strumienia tekstowego w czasie rzeczywistym. Ważne informacje finansowe, aktualizacje wytycznych i odpowiedzi na pytania analityków są przekazywane w czasie rzeczywistym, a każde opóźnienie w otrzymaniu tych informacji stawia tych użytkowników w istotnie gorszej sytuacji informacyjnej. W regulowanych branżach może to nawet rodzić pytania o równy dostęp do informacji publicznej.

Poza osobami głuchymi, to kryterium przynosi korzyści szerszej populacji. Użytkownicy z zaburzeniami przetwarzania słuchowego mogą słyszeć dźwięk, ale mieć trudności z wystarczająco szybkim dekodowaniem mowy, aby śledzić transmisję na żywo; zsynchronizowany strumień tekstowy pozwala im czytać w tempie odpowiadającym ich możliwościom przetwarzania, podczas gdy dźwięk jest odtwarzany. Użytkownicy w środowiskach wrażliwych na hałas — takich jak biura typu open space, biblioteki czy transport publiczny — którzy nie mogą odtwarzać dźwięku na głos, korzystają z alternatywy tekstowej. Użytkownicy, dla których język transmisji jest językiem obcym, również uznają alternatywy tekstowe za łatwiejsze do śledzenia niż szybka mowa na żywo.

Z punktu widzenia SEO i wykrywalności treści, strumień tekstowy na żywo lub napisy tworzą indeksowalny tekst, który wyszukiwarki mogą przeszukiwać. Wydarzenia na żywo, które generują tekst w czasie rzeczywistym, mają większą szansę pojawić się w wynikach wyszukiwania i agregatorach wiadomości, rozszerzając zasięg odbiorców daleko poza pierwotne okno transmisji.

Dla organizacji działających w sektorach regulowanych — usługi finansowe, opieka zdrowotna, administracja publiczna — zapewnienie równego dostępu do informacji audio na żywo staje się coraz częściej oczekiwaniem, a nie uprzejmością. Niespełnienie tego kryterium może narazić organizacje na skargi, ryzyko reputacyjne, a w niektórych jurysdykcjach także odpowiedzialność prawną.

Powiązane reguły Axe-core

WCAG 1.2.9 wymaga ręcznego testowania; żadna zautomatyzowana reguła axe-core nie może wiarygodnie wykryć, czy strumień audio na żywo bez obrazu ma synchroniczną alternatywę tekstową. Przyczyny tego ograniczenia wynikają z samej natury kryterium:

• Dlaczego automatyzacja nie może wykryć tego naruszenia: Zautomatyzowane narzędzia, takie jak axe-core, działają na statycznych zrzutach DOM lub stanach strony w jednym momencie. Mogą wykryć obecność elementu <audio> lub odtwarzacza multimedialnego, ale nie są w stanie określić, czy powiązana treść jest na żywo czy nagrana, czy widoczny obszar tekstowy na stronie faktycznie aktualizuje się synchronicznie ze strumieniem audio, czy treść tekstowa jest semantycznie równoważna dźwiękowi (obejmuje całą mowę i istotne dźwięki niewerbalne) ani czy jakakolwiek powiązana zewnętrzna usługa napisów jest faktycznie aktywna i dokładna. Wszystkie te oceny wymagają ludzkiego przeglądu samej transmisji na żywo.
• Co musi sprawdzić audytor ręczny: Audytor musi wejść na stronę, gdy strumień audio na żywo jest aktywny, zidentyfikować, w jaki sposób (lub czy w ogóle) prezentowana jest alternatywa tekstowa, potwierdzić, że alternatywa tekstowa aktualizuje się w czasie rzeczywistym wraz z postępem audio, zweryfikować, że tekst obejmuje całą istotną treść audio, w tym identyfikację mówców, dźwięki niewerbalne i przejścia, oraz potwierdzić, że alternatywa tekstowa jest dostępna dla technologii asystujących — na przykład, że region na żywo używający aria-live='polite' lub aria-live='assertive' odpowiednio ogłasza aktualizacje użytkownikom czytników ekranu.
• Częściowe sygnały automatyzacji: Chociaż axe-core nie może bezpośrednio oznaczyć braku tekstowej alternatywy na żywo, audytorzy powinni zauważyć, że axe-core będzie oznaczać powiązane problemy, które potęgują problem — na przykład, jeśli obszar transkrypcji tekstowej istnieje, ale jest ukryty za pomocą display:none, lub jeśli odtwarzacz multimedialny nie ma dostępnych kontrolek. Te sygnały stanowią użyteczne punkty wyjścia podczas ręcznego przeglądu.

Jak testować

1. Skan automatyczny jako punkt wyjścia: Uruchom axe DevTools lub Lighthouse na stronie hostującej strumień audio na żywo. Zanotuj wszelkie oznaczone problemy z elementami multimedialnymi, brakującymi etykietami lub niedostępnymi kontrolkami. Chociaż żadne z tych narzędzi nie oznaczy bezpośrednio braku tekstowej alternatywy na żywo, mogą one ujawnić powiązane bariery — takie jak odtwarzacz audio bez dostępnej nazwy lub kontener transkrypcji ukryty przed drzewem dostępności. Udokumentuj te ustalenia i potraktuj je jako część ogólnej oceny dostępności.
2. Zidentyfikuj treść audio na żywo: Gdy transmisja na żywo jest aktywna, potwierdź, że strumień audio jest na żywo (a nie nagraniem) i że nie zawiera ścieżki wideo. Sprawdź źródło strony i żądania sieciowe w poszukiwaniu wskazówek — strumienie na żywo zazwyczaj używają HLS (.m3u8), MPEG-DASH lub dostarczania opartego na WebSocket. Potwierdź, że treść jest wyłącznie audio.
3. Sprawdź alternatywę tekstową: Poszukaj widocznego obszaru tekstowego, nakładki z napisami lub wyraźnie oznaczonego strumienia transkrypcji na stronie lub bezpośrednio z niej podlinkowanego. Alternatywa musi być wyeksponowana w sposób widoczny — nie ukryta w menu ustawień ani dostępna wyłącznie na żądanie. Jeśli żadna alternatywa tekstowa nie jest widoczna, kryterium jest natychmiast niespełnione.
4. Zweryfikuj synchronizację: Przy widocznej alternatywie tekstowej słuchaj strumienia audio i jednocześnie czytaj strumień tekstowy. Potwierdź, że tekst aktualizuje się z rozsądnym opóźnieniem (zazwyczaj nie większym niż kilka sekund w przypadku CART lub profesjonalnych usług tworzenia napisów). Strumień tekstowy, który aktualizuje się co kilka minut lub dopiero po zakończeniu transmisji, nie spełnia kryterium.
5. Zweryfikuj równoważność: Potwierdź, że alternatywa tekstowa obejmuje całą istotną treść audio: wypowiadane słowa, identyfikację mówców, gdy występuje wiele głosów, istotne dźwięki niewerbalne (np. „[oklaski]”, „[dźwięk alarmu]”, „[gra muzyka]”) oraz wszelkie komunikaty na antenie lub przerwy.
6. Test z czytnikiem ekranu — NVDA + Firefox: Otwórz stronę z włączonym NVDA. Przejdź do regionu tekstu na żywo. Jeśli region używa aria-live, NVDA powinien automatycznie ogłaszać nowe wstawki tekstu. Jeśli jest to przewijany obszar tekstowy, zweryfikuj, że można na nim umieścić fokus i że treść jest czytelna. Sprawdź, czy kontrolki odtwarzacza audio są również obsługiwalne z klawiatury.
7. Test z czytnikiem ekranu — VoiceOver + Safari (macOS/iOS): Włącz VoiceOver i przejdź do regionu tekstu na żywo. Potwierdź, że VoiceOver odczytuje nowy tekst w miarę jego pojawiania się. Na iOS zweryfikuj również doświadczenie na urządzeniu mobilnym — wydarzenia na żywo są często oglądane przez przeglądarki mobilne.
8. Test z czytnikiem ekranu — JAWS + Chrome: Z włączonym JAWS przejdź do strony i potwierdź, że ogłoszenia regionu na żywo działają. JAWS obsługuje aria-live='polite' i aria-live='assertive' w różny sposób; potwierdź, że ustawienie szczegółowości jest odpowiednie dla typu treści (szybko aktualizujący się strumień napisów może lepiej pasować do assertive, aby uniknąć opóźnień w kolejce).
9. Test mobilny i przy niskiej przepustowości: Jeśli strona obsługuje odbiorców mobilnych, przetestuj alternatywę tekstową na żywo na średniej klasy urządzeniu z Androidem przy ograniczonym łączu. Potwierdź, że strumień tekstowy pozostaje zsynchronizowany i dostępny nawet w warunkach ograniczonych zasobów.

Jak naprawić

Scenariusz 1: Odtwarzacz audio na żywo bez alternatywy tekstowej — Niepoprawne

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

Scenariusz 1: Odtwarzacz audio na żywo z transkrypcją w regionie ARIA live — Poprawne

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

Scenariusz 2: Transkrypcja opublikowana dopiero po zakończeniu wydarzenia — Niepoprawne

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

Scenariusz 2: Strumień CART w czasie rzeczywistym podlinkowany obok odtwarzacza — Poprawne

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

Scenariusz 3: Automatycznie generowane napisy ukryte za przełącznikiem w ustawieniach — Niepoprawne

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

Scenariusz 3: Napisy domyślnie włączone z wyraźnym przełącznikiem — Poprawne

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

Typowe błędy

• Publikowanie transkrypcji po wydarzeniu i twierdzenie, że spełnia to 1.2.9: Transkrypcja opublikowana godziny lub dni po transmisji na żywo nie jest alternatywą tekstową w czasie rzeczywistym. WCAG 1.2.9 wyraźnie wymaga, aby alternatywa była dostępna równolegle z treścią audio na żywo, a nie wstecznie.
• Używanie aria-live='polite' dla szybko aktualizującego się strumienia napisów: Grzeczne regiony na żywo czekają, aż użytkownik zakończy interakcję, zanim ogłoszą nową treść. W przypadku szybko aktualizujących się napisów powoduje to, że użytkownicy czytników ekranu tracą ogłoszenia. Użyj aria-live='assertive' dla strumieni napisów na żywo, w których każda aktualizacja jest krytyczna czasowo.
• Wstrzykiwanie całej historii napisów przy każdej aktualizacji zamiast tylko nowej treści: Gdy ustawione jest aria-atomic='true' i cały blok tekstu jest zastępowany przy każdej aktualizacji, czytniki ekranu próbują ponownie odczytać cały region, co powoduje nieprzyjemne doświadczenie. Użyj aria-atomic='false' i dołączaj nowe węzły tekstowe, aby ogłaszana była tylko nowa część.
• Osadzanie strumienia napisów w elemencie <canvas> lub jako graficzną nakładkę wideo: Tekst napisów renderowany jako piksele na canvasie lub wypalony w klatce wideo jest niewidoczny dla technologii asystujących. Alternatywy tekstowe muszą być dostarczane jako rzeczywiste węzły tekstowe DOM.
• Umieszczanie regionu napisów na żywo poza ekranem za pomocą position:absolute; left:-9999px: Chociaż wizualne ukrycie treści w ten sposób utrzymuje ją w drzewie dostępności, pozbawia widzących użytkowników z ubytkiem słuchu możliwości czytania napisów. Alternatywa tekstowa musi być wizualnie dostępna dla wszystkich użytkowników, a nie tylko dla użytkowników czytników ekranu.
• Brak identyfikacji mówców w transmisjach z wieloma mówcami: Strumień napisów, który transkrybuje mowę bez przypisywania jej do konkretnych mówców (np. „[Moderator]:”, „[CEO]:”, „[Uczestnik z publiczności]:”) nie jest w pełni równoważny. Identyfikacja mówców jest kluczowa, aby użytkownicy mogli śledzić strukturę rozmowy podczas wydarzenia na żywo.
• Pomijanie informacji o dźwiękach niewerbalnych w alternatywie tekstowej: Istotne dźwięki, takie jak oklaski, przerwy techniczne, muzyka w tle, alarmy czy śmiech, niosą treść informacyjną i muszą być opisane w strumieniu tekstowym (np. „[oklaski]”, „[problemy techniczne — przerwa w dźwięku]”).
• Zapewnianie alternatywy tekstowej wyłącznie przez osobny zewnętrzny adres URL bez osadzenia jej na tej samej stronie: Wymaganie od użytkowników otwarcia osobnej karty lub okna przeglądarki, aby uzyskać dostęp do napisów, podczas gdy dźwięk odtwarzany jest na oryginalnej stronie, tworzy istotną barierę użyteczności, szczególnie dla użytkowników czytników ekranu i użytkowników korzystających wyłącznie z klawiatury, którzy muszą przełączać kontekst.
• Założenie, że automatycznie generowane napisy zawsze spełniają próg równoważności: Napisy generowane przez AI mogą mieć wysoki odsetek błędów przy mowie z akcentem, słownictwie technicznym, nazwach własnych i szybkiej mowie. Wdrożenie niekorygowanych automatycznych napisów dla wydarzenia na żywo o wysokiej stawce (np. briefing medyczny lub ujawnienie informacji finansowych) może nie spełniać standardu równoważności, nawet jeśli strumień napisów technicznie istnieje.
• Brak testowania regionu tekstu na żywo z użyciem rzeczywistych czytników ekranu podczas transmisji na żywo: Wiele zespołów testuje odtwarzacz i kontener napisów w izolacji, używając statycznego tekstu zastępczego, ale nigdy nie testuje zachowania dynamicznego podczas rzeczywistej transmisji na żywo. Błędy w JavaScript, który wstrzykuje aktualizacje napisów — takie jak obserwatory mutacji DOM, które cicho zawodzą — ujawnią się dopiero podczas testów na żywo.

Związek z tureckimi regulacjami dotyczącymi dostępności

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące obowiązki w zakresie dostępności stron internetowych dla szerokiego zakresu organizacji działających w Turcji. Okrężnica nakazuje zgodność z WCAG 2.2 na poziomie AA jako standardem bazowym. Typy podmiotów objętych regulacją obejmują instytucje i agencje publiczne, platformy e-commerce, banki i instytucje finansowe, szpitale i prywatnych świadczeniodawców opieki zdrowotnej, przedsiębiorstwa telekomunikacyjne z 200,000 lub większą liczbą abonentów, licencjonowane biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).

WCAG 1.2.9 jest kryterium poziomu AAA, co oznacza, że nie należy do wymogów zgodności wymaganych przez Okrężnicę na bazowym poziomie AA. Organizacje objęte Okrężnicą Prezydencką 2025/10 nie są prawnie zobowiązane do wdrażania alternatyw tekstowych dla treści audio na żywo bez obrazu, chyba że osobno zobowiązały się do pełnej zgodności z WCAG 2.2 na poziomie AAA.

Jednak kilka praktycznych względów sprawia, że 1.2.9 jest wysoce istotne dla tureckich organizacji, nawet poza ścisłym minimum prawnym. Dostawcy usług telekomunikacyjnych, instytucje finansowe i nadawcy publiczni często dostarczają treści audio na żywo — telekonferencje wynikowe, komunikaty publiczne, transmisje obsługi klienta na żywo — od których zależą osoby głuche i słabosłyszące w Turcji. Wykazanie zgodności na poziomie AAA sygnalizuje najlepsze w swojej klasie podejście do dostępności i znacząco zmniejsza ryzyko skarg o dyskryminację w ramach szerszego tureckiego systemu praw osób z niepełnosprawnościami, w tym Ustawy o Osobach z Niepełnosprawnościami nr 5378 i jej przepisów wykonawczych.

Dla organizacji, które dobrowolnie dążą do zgodności z WCAG 2.2 na poziomie AAA — czy to w celu wyróżnienia swojej postawy w zakresie dostępności, obsługi rynków międzynarodowych o bardziej rygorystycznych wymaganiach, czy dostosowania się do kryteriów zamówień publicznych wymagających poziomu AAA — prawidłowe wdrożenie 1.2.9 jest kluczowe. Accsible zaleca, aby tureckie organizacje w sektorach regulowanych proaktywnie oceniły swoje treści audio na żywo i zbadały możliwość integracji usług CART lub wysokiej dokładności napisów w czasie rzeczywistym, szczególnie w przypadku wydarzeń na żywo skierowanych do opinii publicznej, w których równość dostępu do informacji jest konkretnym oczekiwaniem interesariuszy.