Komunikaty o stanie

Czego wymaga kryterium

Gdy strona informuje użytkownika o tym, że coś się wydarzyło — „Produkt dodany do koszyka”, „Znaleziono 3 wyniki”, „Utracono połączenie”, „Zapisywanie…” — komunikat ten musi dotrzeć do użytkowników czytników ekranu bez wymuszania przeniesienia fokusa. Informacja musi być programowo określona jako status, aby technologia wspomagająca mogła ją odczytać i ogłosić.

Trzy kategorie wyróżnione przez WCAG:

• Sukces / ukończenie — „Profil zapisany”, „Wiadomość e-mail wysłana”.
• Wyniki działania — „12 wyników”, „Nie znaleziono wyników”.
• Stan aplikacji — „Zapisywanie…”, „Ponowne łączenie”, „Przesyłanie 40%”.

Jak spełnić wymaganie

• Należy umieścić region na żywo w DOM podczas wczytywania strony — pusty element z role="status" (uprzejmy) lub role="alert" (asertywny). Przy aktualizacji należy wpisać nowy tekst do tego elementu.
• Dla niekrytycznych potwierdzeń i liczby wyników należy użyć role="status" lub aria-live="polite". Czytniki ekranu poczekają na przerwę w działaniu użytkownika, a następnie ogłoszą komunikat.
• Dla krytycznych komunikatów — błędów przesłania formularza, utraty połączenia, zbliżającego się wygaśnięcia sesji — należy użyć role="alert" lub aria-live="assertive". Ogłoszenie przerwie bieżące działanie.
• Powiadomienia toast wymagają regionu na żywo. Kontener powiadomień powinien istnieć w DOM przed pojawieniem się komunikatu, z ustawionym aria-live, a treść powiadomienia powinna być wstrzykiwana jako element podrzędny.
• Warto sparować aria-live z aria-atomic="true", jeśli przy każdej aktualizacji cały region ma być odczytywany od nowa, a nie tylko zmienione węzły.
• Dla błędów formularza komunikat błędu inline może mieć role="alert" lub fokus można przenieść do podsumowania na górze formularza — nie należy jednak robić obu naraz; użytkownik powinien usłyszeć komunikat tylko raz.

Typowe błędy

• Powiadomienia toast renderowane do elementu, który nie istniał przed pojawieniem się powiadomienia — nasłuch regionu na żywo nigdy nie zostaje dołączony i nic nie jest ogłaszane.
• Baner sukcesu wstawiany do DOM, lecz umieszczony poza jakimkolwiek regionem aria-live — widoczny dla użytkowników widzących, niewidoczny dla użytkowników czytników ekranu.
• Liczba wyników wyszukiwania („Wyświetlanie 12 z 340”), która aktualizuje się po filtrowaniu bez jakiegokolwiek ogłoszenia. Użytkownicy wracają do wyników, nie wiedząc, czy cokolwiek się zmieniło.
• Walidacja formularza aktualizująca element inline <span class="error"> bez role="alert" ani aria-live — błąd się pojawia, czytnik ekranu milczy.
• Stosowanie aria-live="assertive" dla każdej aktualizacji stanu. Ciągłe przerywanie powoduje, że użytkownicy czytników ekranu wyłączają stronę.
• Przenoszenie fokusa do komunikatu o stanie, który nie jest nagłówkiem ani elementem interaktywnym — fokus ląduje na elemencie, który nie może go przyjąć, a użytkownicy klawiatury tracą orientację.
• Wskaźniki „Zapisywanie…” / „Zapisano”, które przełączają klasę CSS, lecz nigdy nie aktualizują żadnej treści tekstowej wewnątrz regionu na żywo.

Dlaczego to ważne

Komunikaty o stanie to słabe ogniwo nowoczesnych aplikacji jednostronicowych. Strona nigdy się nie przeładowuje, fokus rzadko się przemieszcza, a jedynym sygnałem dla użytkownika, że coś się wydarzyło, jest wizualna zmiana — bezużyteczna dla kogoś, kto nie patrzy na ekran. Kryterium 4.1.3 wymusza parytet: jeśli użytkownik widzący może zobaczyć „Dodano do koszyka”, użytkownik czytnika ekranu powinien to usłyszeć. Naprawa jest niemal zawsze prosta (jeden region na żywo, wypełniany przy aktualizacji), a jej brak niemal zawsze psuje kluczowe przepływy — płatność, wyszukiwanie, przesyłanie formularzy, czat w czasie rzeczywistym.