4.1.3 Komunikaty o stanie

Komunikaty, które bez przenoszenia fokusu informują o wyniku, oczekiwaniu, postępie albo błędzie, muszą być oznaczone tak, żeby czytnik ekranu mógł je ogłosić.

/ Czego wymaga

Komunikat o stanie to zmiana treści, która nie jest zmianą kontekstu i informuje użytkownika o powodzeniu lub wyniku czynności, o oczekiwaniu aplikacji, o postępie procesu albo o wystąpieniu błędów. Osoby widzące zauważają, że na skraju pola widzenia pojawia się „18 wyników”, „Zapisano” albo „5 błędów na stronie”. Użytkownik czytnika ekranu nie słyszy nic, dopóki komunikat nie zostanie udostępniony przez rolę lub właściwość, na przykład role="status", role="alert" albo region aria-live, tak żeby technologia wspomagająca mogła go przekazać bez przenoszenia na niego fokusu.

Zakres jest wąski. Treść, która przychodzi razem ze zmianą kontekstu, jak błąd w oknie dialogowym przejmującym fokus, jest już ogłaszana i nie wchodzi w zakres. Podobnie treść pokazywana lub ukrywana przez komponent obsługiwany przez użytkownika, jak akordeon albo karta, którą obejmuje kryterium 4.1.2, oraz nowa treść, która nie jest stanem, jak sama lista wyników wyszukiwania albo dodatkowe pytania dołączone do formularza. Kryterium nie każe autorom tworzyć komunikatów, tylko udostępniać te, które pokazują. W3C zaznacza, że liczą się też inne sposoby programowe, łącznie z bezpośrednim użyciem interfejsów dostępności.

/ Jak strony go nie spełniają

Wyszukiwarka odświeża wyniki w miejscu i wpisuje „Brak wyników” do zwykłego elementu div, więc użytkownik czytnika ekranu tego nie słyszy.
Powiadomienie „Zapisano” jest doklejane na końcu elementu body bez role="status" i bez aria-live i znika po trzech sekundach.
Dodanie produktu do koszyka zmienia licznik z 0 na 1 w elemencie span, który nie jest regionem na żywo.
Komunikat walidacji pojawia się nad polem po jego opuszczeniu, poza jakimkolwiek regionem na żywo.
Skrypt, który pokazuje komunikat, tworzy region na żywo w tej samej chwili, w której wpisuje do niego tekst, więc niektóre zestawy przeglądarki i czytnika ekranu nie ogłaszają niczego.

/ Jak sprawdzić samodzielnie

Wywołaj każdy dynamiczny komunikat: wyszukiwanie i filtry, dodanie do koszyka, zapis, formularz wysłany z błędami i bez, przesłanie pliku, każdy wskaźnik ładowania.
Zanotuj, czy fokus się przesuwa. Jeśli zostaje na miejscu, a pojawia się tekst, ten tekst jest komunikatem o stanie.
Zbadaj w narzędziach deweloperskich element z komunikatem. On sam albo jego przodek potrzebuje role="status", role="alert", role="log", aria-live="polite" lub "assertive" albo elementu output, a region powinien być w DOM, zanim trafi do niego komunikat.
Powtórz czynność z NVDA w Firefoksie lub Chrome albo z VoiceOver na Macu i posłuchaj komunikatu bez przesuwania fokusu.
Sprawdź, czy ogłaszany tekst ma sens sam w sobie, na przykład „3 produkty w koszyku”, a nie samo „3”.

/ Jak to naprawić

Umieść w stronie przy ładowaniu pusty kontener z role="status" i wpisuj do niego komunikat, gdy wynik jest gotowy.
Używaj role="alert" tylko dla błędów i ostrzeżeń, które są ważne teraz, bo przerywa. Dla wyników i potwierdzeń używaj role="status", które jest uprzejme.
Przy liczniku koszyka albo liczbie wyników wstaw do regionu całe zdanie albo ustaw na nim aria-atomic="true", żeby czytnik powiedział „3 produkty”, a nie „3”.
Dla ciągłej serii aktualizacji, takich jak wiadomości czatu albo kroki długiego procesu, użyj role="log".
W frameworku komponentowym renderuj jeden region na żywo w układzie strony i wysyłaj do niego komunikaty, zamiast montować nowy region razem z każdym powiadomieniem.

/ Co sprawdza nasz skaner

Do tego kryterium przypisany jest jeden test, live-region-missing, i działa on tylko w naszym rozszerzeniu przeglądarki, nigdy w anonimowym skanie serwisu. Przy włączonym obserwowaniu strony MutationObserver rejestruje dodawane elementy; zgłasza widoczny element z tekstem do 400 znaków, poza regionem aria-live, status, alert lub log, który klasą, identyfikatorem albo zwięzłością przypomina komunikat. Test formularza robi to samo z komunikatami, które pojawiają się po opuszczeniu pola. Nie widzi tekstu zmienionego wewnątrz istniejącego elementu, każdą wartość aria-live, także „off”, uznaje za ogłoszenie i nie słucha, co faktycznie mówi czytnik ekranu.

/ Kto je łamie, według naszych pomiarów

Cotygodniowy indeks nie ma danych dla tego kryterium, bo żaden test uruchamiany przez skan witryny go nie sprawdza. Ocenia je człowiek i do tego służy audyt ręczny.

Jedna strona na podmiot, mierzona automatycznie w tygodniowym cyklu. Jeśli podmiot coś naprawił od ostatniego pomiaru, zmiana będzie widoczna przy następnym, a każdy podmiot może odpowiedzieć na swojej stronie.

/ Pytania o to kryterium

Czy wyniki wyszukiwania potrzebują regionu na żywo?

Same wyniki nie, ale komunikat o stanie wokół nich tak. W3C pisze, że lista wyników nie jest komunikatem o stanie, natomiast krótki tekst, jak „Znaleziono 18 wyników” albo „Brak wyników”, jest nim, gdy pojawia się bez przejmowania fokusu. Ten tekst powinien trafić do elementu z role="status".

Czego użyć: role="alert" czy role="status"?

role="status" dla wyników, potwierdzeń i postępu, które czytnik ekranu ogłasza, gdy skończy to, co właśnie mówi. role="alert" dla błędów i ostrzeżeń, które są ważne teraz, bo przerywa wypowiedź. W3C wymienia użycie role="alert" lub aria-live="assertive" dla treści, która nie jest ważna i pilna, jako częsty błąd.

Czy komunikat w oknie modalnym jest komunikatem o stanie?

Nie. Okno dialogowe, które przejmuje fokus, jest zmianą kontekstu, a samo przeniesienie fokusu sprawia, że czytnik ekranu je ogłasza, więc 4.1.3 nie ma zastosowania. Kryterium należy do poziomu AA i zostało dodane w WCAG 2.1, więc audyt na zgodność z WCAG 2.0 go nie obejmuje.

Zmierz własną stronę Wszystkie zmierzone bariery