Napisy rozszerzone — na żywo

Co oznacza to kryterium

Podczas transmisji osoba bez słyszenia powinna móc czytać informacje przekazywane dźwiękiem w związku z bieżącym wydarzeniem. Napisy obejmują wypowiedzi, potrzebne rozróżnienie mówców i ważne dźwięki, np. alarm lub reakcję publiczności. Transkrypcja po zakończeniu nie daje dostępu podczas emisji.

Pomaga to osobom Głuchym i słabosłyszącym; korzystanie chwilowo bez dźwięku jest dodatkową korzyścią. Napisy same nie opisują informacji dostępnej wyłącznie w obrazie.

Przykłady błędów i poprawek

Plan rzeczywistego instruktażu

Własny prowadzący pokazuje zmianę punktu odbioru Centrum → Park, Leśna 12, mówi o potwierdzeniu, po którym słychać dwa ważne sygnały, i podaje termin 6 października. Dane pozostają syntetyczne. Do wykonania potrzebne są autoryzowane rzeczywiste zdarzenie, osoby lub źródła i tor przechwycenia oraz dostarczenia.

Problem

Rzeczywista transmisja nie dostarcza napisów lub pomija ważne informacje dźwiękowe.

Skutek

Odbiorca bez słyszenia nie może na bieżąco śledzić tej samej prezentacji i znaczenia sygnałów.

Poprawka

Zorganizuj wytwarzanie, transport i wyświetlanie pełnych napisów podczas emisji; sprawdź treść i synchronizację w rzeczywistym odbiorniku.

Nie wykorzystano tu mikrofonu, kamery, cudzej transmisji ani danych klientów. Nie zebrano materiału z docelowego wydarzenia.

Co sprawdzono na wcześniejszym MP4

Pomocnicza demonstracja WWW odtwarzała istniejący film 1.2.2, 17,333333 s, H.264 804 × 1958 px, 60 fps i AAC. Obraz pochodził z wcześniejszych działań iOS, audio z syntezy Zosia i dwóch tonów. To nagranie, bez rzeczywistego uczestnika i bez transmisji.

Tekst obok filmu pochodził z TextTrack.activeCues i cuechange, według rzeczywistego media time. Nie było timera imitującego wydarzenie ani komunikatu aria-live przy każdej kwestii. Istniejące kadry tej mechaniki pokazują stany pliku; nie osadzamy ich jako dowodu docelowego zdarzenia. Nagranie 1.2.2 można obejrzeć w artykule 1.2.2 o napisach do nagrań.

Kiedy obowiązuje i gdzie są wyjątki

Rzeczywiste zdarzenie i granica definicji live

Informacja musi pochodzić z wydarzenia w świecie rzeczywistym i docierać najwyżej z opóźnieniem transmisji. Krótkie opóźnienie emisji, pozwalające przygotować lub ocenzurować sygnał, nie wyłącza warunku. Czas wystarczający na znaczący montaż wykracza poza tę definicję. Nie ma uniwersalnego normatywnego progu sekund.

Treść całkowicie wygenerowana komputerowo nie jest live. Odtwarzanie MP4, zapętlona animacja, licznik, lokalny stream pliku i etykieta LIVE nie dowodzą rzeczywistego zdarzenia. Komputerowa transmisja lub wspomaganie napisów nie przekreślają prawdziwego źródła. W programie mieszanym ustal pochodzenie segmentów; archiwum ocenia się jako nagranie według 1.2.2.

Audio i alternatywa tekstu

Audio na żywo musi być częścią mediów zsynchronizowanych: z obrazem, slajdami lub czasową interakcją. Sam radiowy strumień bez takiej synchronizacji ma odrębny warunek 1.2.9, poziom AAA. Niemy strumień obrazu nie uruchamia napisów do audio. Brak mowy nie wyłącza istotnych dźwięków lub muzyki.

W samym zdaniu 1.2.4 nie ma listy wyjątków. Definicja mediów zsynchronizowanych wyłącza jasno oznaczoną alternatywę tekstu, gdy cała informacja już w nim istnieje. Konspekt, slajdy i późniejsza transkrypcja nie wystarczą. Improwizowana odpowiedź albo nowy ważny dźwięk wykraczający poza tekst podważa równoważność. Pomocniczy MP4 nie korzysta z tego wyjątku: po prostu nie jest live.

Treść, czas i odpowiedzialność

Napisy przekazują sens dialogu oraz ważnych informacji niedialogowych, w tym potrzebnych mówców i ich położenia. Można uprościć wypowiedź bez utraty informacji; nie trzeba opisywać każdego szumu. Błąd zmieniający liczbę lub nazwę może mieć inną wagę niż literówka.

Sprawdź związek z audio odbieranym przez widza: opóźnienie, dryf, zmianę mówcy, segmenty, przerwy, czytelność i zasłanianie ważnego obrazu. Sam CC i pakiet tekstu nie wystarczą. Kryterium nie wymaga możliwości wyłączenia napisów otwartych ani określonego transportu. ASR może wspierać rozwiązanie, ale wymaga kontroli rzeczywistej treści.

Understanding opisuje intencję broadcastu; nie nakłada bezwarunkowo napisów na każdą dwukierunkową rozmowę multimedialną niezależnie od potrzeb uczestników. Dostarczanie treści napisów należy do dostawców treści, uczestników lub hosta, bez automatycznego przypisania go samej aplikacji rozmów. Publiczny webinar z pytaniami nie zostaje z tego powodu zwolniony. Potrzeby, funkcje aplikacji i odpowiedzialność za emisję ustal odrębnie.

Techniki pomocnicze wskazują proces dostarczania napisów w czasie rzeczywistym oraz otwarty lub zamknięty sposób prezentacji. Nie są dodatkowym wymaganiem ani zleceniem użycia historycznego SMIL. Nie przenoś przypisania błędów pomijania audio lub nieoznaczonej alternatywy tekstu z 1.2.2 na oficjalne błędy 1.2.4.

Platformy

Źródłowa interpretacja AI z 2026-10-04: WCAG 2.2 dla WWW oraz WCAG2ICT 2.2, Group Note 2025-12-11, bez zmiany wymagania dla dokumentów i oprogramowania. To wskazówka interpretacyjna, bez ustalania zakresu regulacji.

Brak transmisji w przykładzie oznacza, że 1.2.4 nie dotyczy tego scenariusza, bez wyłączenia całej platformy. W hybrydzie rozdziel odbiorniki.

Rozwiązania w technologiach

Rozdziel wytworzenie napisów, transport, oś czasu i odbiornik. Fragmenty poniżej wybierają lub wyświetlają treść; nie zestawiają transmisji. Dokumentację API przejrzano 2026-10-04. Odbiornik ma korzystać z własnego media time, także po buforowaniu i przerwach.

import androidx.media3.common.C
import androidx.media3.common.Player

fun preferPolishCaptions(player: Player) {
    player.trackSelectionParameters = player.trackSelectionParameters
        .buildUpon()
        .setPreferredTextLanguage("pl")
        .setTrackTypeDisabled(C.TRACK_TYPE_TEXT, false)
        .build()
}

import AVFoundation
import Foundation

func selectPolishCaptions(item: AVPlayerItem,
                         group: AVMediaSelectionGroup) -> Bool {
    let options = AVMediaSelectionGroup.mediaSelectionOptions(
        from: group.options, with: Locale(identifier: "pl"))
    guard let option = options.first else { return false }
    item.select(option, in: group)
    return true
}

import 'package:flutter/cupertino.dart';
import 'package:flutter/foundation.dart';

Widget captionPanel(ValueListenable<String> activeCaption) =>
    ValueListenableBuilder<String>(
      valueListenable: activeCaption,
      builder: (context, text, child) => Text(text),
    );

import { Text, View } from 'react-native';

type Props = { activeCaption: string };
export function CaptionPanel({ activeCaption }: Props) {
  return (
    <View>
      <Text>{activeCaption}</Text>
    </View>
  );
}

Jak sprawdzić

Plan odbioru rzeczywistego wydarzenia — niewykonany

1. Ustal rzeczywiste źródło, czas, tor emisji i odpowiedzialność. Zachowaj pochodzenie; oddziel archiwum, pełną generację, samo audio i alternatywę tekstu.
2. Sprawdź procedurę operatora, przerwy i korekty. Tekst ma powstawać i docierać podczas emisji.
3. W rzeczywistym odbiorniku sprawdź początek, zmiany mówcy, ważny dźwięk, nazwę, liczbę, szybkie wypowiedzi i koniec. Włącz rzeczywistą ścieżkę CC lub obserwuj otwarte napisy.
4. Zachowaj odebrane audio, obraz i tekst, czas zdarzenia i odbioru oraz synchronizację zegarów z niepewnością. Oceń opóźnienie, dryf i buforowanie. Nie odejmuj niesynchronizowanych zegarów jako wiarygodnej latencji.
5. Reviewer porównuje znaczenie i wykonuje odsłuch; odbiór bez słyszenia sprawdza dostęp do informacji. Screenshot nie zastępuje całego przebiegu.

Weryfikacja i ograniczenia

Pierwszy pomocniczy bad tylko ukrywał tekst, pozostawiając ścieżkę; nie był dowodem braku napisów. Po odłączeniu track ponowne użycie tego samego elementu nie przeładowało speech, więc kadr nadal zawierał sygnał. Dopiero tworzenie świeżego track i ponowiona końcowa próba dały brak sygnału przy zachowanych wypowiedziach. Wstępne i puste zapisy obserwatora pozostają historią, poza dowodem końcowym. Finalne obrazy i odczyty były sekwencyjne, nie jednoczesne.

Reguła może wykryć track, błąd pobrania lub wybrany tryb, lecz DOM nie dowodzi pochodzenia live, pełności ani przekazania ważnego audio. Brak tekstu w AX nie wyklucza napisów otwartych. Sam niepusty tekst i pięć kwestii nie są uniwersalnym warunkiem zaliczenia. Dla nieznanego źródła wynik pozostaje nieustalony, bez PASS/FAIL z samego CC. AI może proponować porównanie treści, ze znanym źródłem, zakresem i niepewnością; tutaj nie oceniała audio.

Jak sprawdza Clearship

Katalog metody z 2026-10-08 zachowuje ręczną ocenę. Detektor zbiera kandydatów z nagrań oznaczonych w pakiecie jako live; samo takie oznaczenie nie potwierdza źródła zdarzenia. Pomiar na Androidzie i iOS pozostaje niewykonany. Do oceny potrzebne są rzeczywiście odebrane audio, obraz i napisy oraz pochodzenie, czasy, przerwy i korekty. Pomocniczy MP4 i generator kwestii nie dostarczają tego dowodu. Brak wymaganych danych pozostawia kryterium nieprzebadane.

Powiązane kryteria

• 1.2.2
  Napisy rozszerzone — nagranie

  Archiwum transmisji jest nagraniem i wymaga oceny według tego warunku.

• 1.2.9
  Audio-only (Live)

  Samo audio na żywo ma odrębne wymaganie AAA; nie rozszerza 1.2.4 AA.

  Artykuł nie jest jeszcze dostępny.