- Poziom
- AA
- Od wersji
- WCAG 2.0
3.3.3 Sugestie korekty błędów
Gdy formularz wykrywa pomyłkę i wie, jak ją poprawić, musi powiedzieć to człowiekowi, chyba że zagroziłoby to bezpieczeństwu albo celowi treści.
/ Czego wymaga
Kryterium 3.3.1 dba o to, żeby człowiek dowiedział się, że coś jest nie tak. To kryterium dba o to, żeby dowiedział się, jak to poprawić. Gdy system automatycznie wykrywa błąd we wprowadzonych danych i zna sposób korekty, musi go podać: oczekiwany format, dopuszczalne wartości albo wartość, o którą najpewniej chodziło. Błąd wprowadzania to informacja podana przez użytkownika, której system nie przyjmuje, łącznie z pustym polem obowiązkowym. Bez podpowiedzi osoby z niepełnosprawnością poznawczą mogą nie dojść do poprawki, osoby niewidome mogą nigdy nie trafić na przykład wydrukowany pod polem, a wiele osób porzuca formularz.
Wymaganie ma dwa warunki i jeden wyjątek. Dotyczy tylko sytuacji, gdy błąd jest wykrywany automatycznie, a podpowiedź jest znana; system, który nie może znać właściwej odpowiedzi, nie ma czego podpowiedzieć. Nie obowiązuje tam, gdzie podpowiedź zagroziłaby bezpieczeństwu albo celowi treści: formularz logowania nie podsuwa właściwego hasła, a test nie zdradza poprawnej odpowiedzi. Podpowiedź może pochodzić od autora albo od programu użytkownika, więc komunikat przeglądarki mówiący, czego brakuje, może spełniać kryterium.
/ Jak strony go nie spełniają
- Pole daty odrzuca wpis 5/11/2026 komunikatem „Nieprawidłowa data” i nigdzie nie podaje, jaki format przyjmuje.
- Pole kodu pocztowego mówi „Błędny kod”, choć system wie, że wzór to 00-000.
- Puste pole obowiązkowe robi się czerwone z napisem „Błąd”, a nic nie mówi, co należy w nie wpisać.
- Nowe hasło jest sprawdzane według reguł, takich jak minimalna długość i cyfra, a komunikat mówi tylko „Hasło nie zostało przyjęte”.
- Pole przyjmujące wartości z ustalonej listy, na przykład miesiąc albo kraj, odrzuca literówkę bez podsunięcia najbliższej wartości ani listy.
/ Jak sprawdzić samodzielnie
- Wyślij każdy formularz z typowymi pomyłkami: pustymi polami obowiązkowymi, złym formatem, wartościami spoza zakresu i literówkami. Tam, gdzie prawdziwe wysłanie złożyłoby zamówienie, użyj konta testowego albo środowiska testowego.
- Przy każdym komunikacie zapytaj, czy mówi, jak poprawić wpis, a nie tylko, że jest błędny.
- Gdy komunikat niczego nie podpowiada, oceń, czy system mógłby znać poprawkę. Wymagany format, zakres albo lista dopuszczalnych wartości oznaczają, że tak.
- Tam, gdzie podpowiedzi celowo brak, sprawdź, czy powodem jest bezpieczeństwo albo cel treści, jak przy haśle albo odpowiedzi w quizie.
- Powtórz próbę z czytnikiem ekranu, na przykład NVDA, i sprawdź, czy podpowiedź jest odczytywana razem z komunikatem o błędzie albo po przejściu do pola.
/ Jak to naprawić
- Pisz komunikat jako poprawkę: „Wpisz datę w formacie DD.MM.RRRR, na przykład 05.11.2026” zamiast „Nieprawidłowa data”.
- W polu o ograniczonym zbiorze wartości wymień dopuszczalne wartości albo podsuń najbliższą, jak w „Czy chodziło o grudzień?”.
- Użyj w komunikacie o błędzie tej samej wskazówki o formacie, która stoi pod polem, i powiąż obie z elementem input atrybutem aria-describedby.
- Gdy pole korzysta z atrybutu pattern, przeglądarka powie tylko, że format się nie zgadza. Podaj oczekiwany format we wskazówce albo we własnym komunikacie.
- Korzystaj z wyjątku bezpieczeństwa tylko tam, gdzie podpowiedź pomogłaby atakującemu, jak przy właściwym haśle. Zasady tworzenia nowego hasła nie są tajemnicą i należą do komunikatu.
/ Co sprawdza nasz skaner
Żaden automatyczny test w naszym skanie nie ocenia, czy komunikat o błędzie podpowiada poprawkę, bo to pytanie o słowa. W rozszerzeniu przeglądarki test formularza zauważa komunikaty, które pojawiają się po opuszczeniu pola, i zgłasza je przy kryteriach 3.3.1 i 4.1.3, gdy nie są powiązane z polem albo nie są ogłaszane, ale nie czyta ich treści. Niczego nie wysyła, więc nie widzi też błędów zgłaszanych przez serwer. Komunikaty czyta człowiek w audycie ręcznym.
/ 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 Sugestie korekty błędów dotyczą formularzy logowania?
Tak, z wyjątkiem, który kryterium samo wymienia. Nie wymaga ono podpowiedzi, która zagroziłaby bezpieczeństwu, więc formularz logowania nie musi zdradzać właściwego hasła. Nadal musi jednak powiedzieć to, co można powiedzieć bezpiecznie, na przykład że pole jest puste albo że w adresie e-mail brakuje znaku małpy.
Czy wbudowany komunikat walidacji przeglądarki wystarczy?
Może wystarczyć. W3C pisze, że opis błędu może pochodzić od autora albo od programu użytkownika. Komunikat przeglądarki przy polu e-mail bez znaku małpy mówi, czego brakuje, a to jest podpowiedź. Przy atrybucie pattern przeglądarka powie tylko, że format się nie zgadza, więc oczekiwany format musi pokazać strona.
Jaki poziom ma kryterium 3.3.3 Sugestie korekty błędów?
Poziom AA, w WCAG od wersji 2.0, bez zmian w 2.1 i 2.2. Obowiązuje tylko wtedy, gdy błąd jest wykrywany automatycznie i znany jest sposób korekty, i nie obowiązuje, gdy podpowiedź zagroziłaby bezpieczeństwu albo celowi treści, jak przy odpowiedzi na pytanie testowe.