Gdy komunikaty o błędach blokują użytkowników

Moment, w którym formularz zawodzi

Wyobraź sobie: niewidomy użytkownik wypełnia formularz zamówienia, wysyła go i nie słyszy od swojego czytnika ekranu nic użytecznego. Żadnego ogłoszenia. Żadnego wyjaśnienia. Strona wizualnie oznaczyła na czerwono pięć błędów walidacji, ale użytkownik nie ma o tym pojęcia. Klika „Wyślij” ponownie. I jeszcze raz. W końcu odchodzi.

To nie jest marginalny scenariusz. Niedostępna obsługa błędów to jedna z najczęstszych barier, jakie znajdujemy w rzeczywistych audytach, i taka, która frustruje użytkowników w najgorszym możliwym momencie — gdy próbują sfinalizować transakcję lub przesłać coś ważnego.

Dobra wiadomość jest taka, że naprawa to w dużej mierze kwestia wiedzy, jak wygląda „dobre” rozwiązanie. Błędy to niemal zawsze te same kilka wzorców.

Dlaczego komunikaty o błędach są trudne dla użytkowników technologii asystujących

Widzący użytkownicy myszy zwykle zauważają błędy walidacji natychmiast — czerwona ramka, ikona ostrzeżenia, tekst pojawiający się pod polem. Ale użytkownicy polegający na czytnikach ekranu, nawigacji klawiaturą lub sterowaniu głosowym mają zupełnie inne doświadczenie.

Gdy formularz zostaje wysłany i pojawiają się błędy:

Użytkownicy czytników ekranu mogą niczego nie usłyszeć, o ile fokus nie przejdzie do błędu lub region na żywo go nie ogłosi
Użytkownicy klawiatury muszą móc dotrzeć do każdego komunikatu o błędzie z klawiatury i zrozumieć, do którego pola należy
Użytkownicy sterowania głosowego muszą wskazywać pola po widocznej, poprawnej etykiecie — jeśli etykieta jest błędna lub jej brakuje, utykają w miejscu

Nic z tego nie dzieje się automatycznie. Trzeba to zbudować.

Kryteria WCAG, które mają tu zastosowanie

Cztery kryteria sukcesu w WCAG 2.2 dotyczą bezpośrednio obsługi błędów:

3.3.1 Identyfikacja błędu (poziom A) — Jeśli błąd zostanie wykryty automatycznie, element zawierający błąd musi być zidentyfikowany i opisany użytkownikowi tekstem. Nie można przekazywać błędów wyłącznie kolorem.

3.3.2 Etykiety lub instrukcje (poziom A) — Pola wymagające określonego formatu muszą jasno komunikować ten wymóg przed wprowadzaniem danych lub w jego trakcie, a nie dopiero po nieudanym wysłaniu.

3.3.3 Sugestie korekty błędów (poziom AA) — Jeśli błąd zostanie wykryty i znane są sugestie poprawy, należy je podać. „Nieprawidłowa data” nie wystarczy. „Wprowadź datę w formacie DD/MM/RRRR” — tak.

3.3.4 Zapobieganie błędom (poziom AA) — W przypadku operacji o poważnych konsekwencjach (transakcje finansowe, umowy prawne) daj użytkownikom możliwość przejrzenia, poprawienia i potwierdzenia danych, zanim działanie stanie się nieodwracalne.

Jest też kryterium 4.1.3 Komunikaty o stanie (poziom AA), które obejmuje dynamicznie wstrzykiwane komunikaty nieotrzymujące fokusu — muszą one być ogłaszane przez technologie asystujące za pomocą role="status" lub role="alert".

Czego naprawdę potrzebuje dostępny komunikat o błędzie

Poprawne komunikaty o błędach wymagają zadbania o cztery odrębne warstwy:

1. Powiązanie programistyczne

Każdy komunikat o błędzie musi być powiązany ze swoim polem za pomocą aria-describedby. To mówi czytnikom ekranu, aby ogłaszały tekst błędu, gdy pole otrzyma fokus.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Atrybut aria-invalid="true" sygnalizuje, że pole jest obecnie nieprawidłowe, co większość czytników ekranu ogłasza, gdy fokus na nim wyląduje.

2. Zarządzanie fokusem po wysłaniu

Gdy formularz zostaje wysłany i występują błędy, fokus musi przenieść się w użyteczne miejsce. Dwa najczęstsze wzorce:

Przenieś fokus do podsumowania błędów na górze formularza, które wymienia wszystkie błędy wraz z linkami do odpowiednich pól
Przenieś fokus do pierwszego pola z błędem

Jeśli fokus pozostaje na przycisku wysyłania albo nigdzie, użytkownicy czytników ekranu muszą sami odkrywać błędy, nawigując przez formularz — o ile w ogóle wiedzą, że błędy istnieją.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Ogłoszenia w regionach na żywo dla błędów dynamicznych

W przypadku błędów pojawiających się w trakcie pisania (walidacja w czasie rzeczywistym) używaj regionów na żywo ARIA, aby komunikat był ogłaszany bez konieczności przenoszenia fokusu.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Używaj role="alert" / aria-live="assertive" dla błędów wymagających natychmiastowej uwagi. Używaj role="status" / aria-live="polite" dla mniej pilnych informacji, które mogą poczekać, aż użytkownik zrobi pauzę.

4. Sam komunikat o błędzie

Język ma znaczenie. Dostępne komunikaty o błędach są:

Konkretne: mówią, co jest nie tak, a nie tylko że coś jest nie tak
Wykonalne: mówią użytkownikowi dokładnie, co zrobić, aby to naprawić
Uprzejme: unikają obwiniającego języka w rodzaju „wprowadziłeś nieprawidłową wartość”

Niedostępne	Dostępne
„Nieprawidłowe dane”	„Adres e-mail musi zawierać znak @, np. imie@przyklad.pl”
„Błąd”	„Data musi być w formacie DD/MM/RRRR”
„Pole wymagane”	„Imię i nazwisko jest wymagane”
„Hasło nieprawidłowe”	„Hasło musi mieć co najmniej 8 znaków i zawierać jedną cyfrę”

Wzorce dla różnych scenariuszy błędów

Błędy przy polach (inline)

Najczęstszy wzorzec. Komunikat o błędzie pojawia się bezpośrednio pod powiązanym polem. Sprawdza się w prostych formularzach. Wymaga aria-describedby i aria-invalid, aby był poprawnie ogłaszany.

Banery z podsumowaniem błędów

W długich formularzach z wieloma błędami umieść na górze podsumowanie wymieniające wszystkie problemy jako linki prowadzące do odpowiednich pól. Po nieudanym wysłaniu przenieś tutaj fokus. To wzorzec stosowany przez GOV.UK i szeroko zalecany dla złożonych formularzy.

Powiadomienia typu toast

Krótkotrwałe komunikaty pojawiające się na krawędzi ekranu należą do najbardziej niedostępnych wzorców w powszechnym użyciu. Znikają, zanim użytkownicy czytników ekranu zdążą do nich dotrzeć, często w ogóle nie są ogłaszane i nie dają żadnej ścieżki naprawy. Unikaj toastów do komunikowania błędów. Jeśli już ich używasz, łącz je z trwałym stanem błędu na samym formularzu.

Błędy systemowe

Gdy coś pójdzie nie tak po stronie serwera, powiedz użytkownikowi prostym językiem, co się stało i co może zrobić dalej. „Coś poszło nie tak” bez dalszych wskazówek pozostawia użytkowników bez wyjścia.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

Lista kontrolna do testów

Po wdrożeniu obsługi błędów zweryfikuj ręcznie poniższe punkty — narzędzia automatyczne większości z nich nie wychwycą:

Wysłanie pustego formularza z polami wymaganymi przenosi fokus do podsumowania błędów lub pierwszego pola z błędem
Każdy komunikat o błędzie jest powiązany ze swoim polem przez aria-describedby
Pola z błędem mają aria-invalid="true"
Komunikaty o błędach są ogłaszane, gdy fokus trafia na dotknięte pole
Walidacja w czasie rzeczywistym korzysta z regionów na żywo
Komunikaty o błędach używają konkretnego, wykonalnego języka — nie tylko „nieprawidłowe”
Kolor nie jest jedynym sposobem sygnalizowania błędów (obok czerwieni jest ikona lub etykieta tekstowa)
Do błędu można dotrzeć tabulatorem z klawiatury
Kolejność fokusu po wysłaniu jest logiczna i nie przeskakuje nieprzewidywalnie
Komunikaty toast są połączone z trwałym stanem błędu

Dlaczego narzędzia automatyczne pomijają większość tych problemów

Automatyczny skaner potrafi sprawdzić, czy aria-describedby wskazuje na istniejący element i czy aria-invalid jest obecne. Nie potrafi sprawdzić, czy fokus przenosi się poprawnie po wysłaniu, czy tekst błędu jest trafny ani czy powiadomienie toast znika, zanim da się je przeczytać. Nasze ręczne audyty dostępności obejmują testy formularzy z prawdziwymi technologiami asystującymi — to jedyny niezawodny sposób weryfikacji, czy obsługa błędów rzeczywiście działa od początku do końca.

Jeśli nie masz pewności, jak wypadają Twoje formularze, uruchom darmowy skan, aby najpierw wychwycić problemy wykrywalne automatycznie, a potem działać dalej.