Zrozumiałość · Poziom AA

3.3.3 Sugestie korekty błędów

Błędy i komunikaty walidacyjne muszą pokazywać tekst wyjaśniający problem i sugerujący, jak go naprawić, na przykład „wpisz co najmniej 8 znaków”.

Krótko

Jeśli formularz wykryje błąd i wiadomo, jak go poprawić, użytkownik powinien dostać konkretną podpowiedź naprawy.

Problem w praktyce

Użytkownik wpisuje dane w formularzu. Po wysłaniu widzi komunikat „Nieprawidłowa wartość” albo „Błąd formularza”. Wie, że coś jest źle, ale nie wie, jak to naprawić.

Musi zgadywać format daty, liczbę cyfr telefonu, wymagany układ hasła albo sposób wpisania numeru dokumentu. W długim formularzu taka zgadywanka szybko zamienia prosty błąd w porzucone zadanie.

To kryterium dotyczy sugestii po wykryciu błędu. Nie zastępuje etykiet i instrukcji przed wpisaniem danych ani samego wskazania, gdzie jest błąd.

Kogo to dotyczy

  • Osób z trudnościami poznawczymi, które potrzebują jasnego następnego kroku.
  • Osób niewidomych korzystających z czytników ekranu.
  • Osób słabowidzących, które mogą widzieć tylko część formularza lub komunikatu.
  • Osób korzystających z klawiatury, które przechodzą między polami i komunikatami bez myszy.
  • Osób starszych.
  • Osób w stresie lub pośpiechu.
  • Użytkowników formularzy urzędowych, rekrutacyjnych, medycznych, finansowych i zakupowych.

Dobry przykład

  • Zamiast „Błędny e-mail” komunikat mówi: „Wpisz adres e-mail w formacie nazwa@example.com”.
  • Zamiast „Niepoprawna data” komunikat mówi: „Wpisz datę w formacie RRRR-MM-DD, np. 1990-04-27”.
  • Przy haśle komunikat mówi: „Hasło musi mieć co najmniej 12 znaków, jedną cyfrę i jeden znak specjalny”.
  • Przy telefonie komunikat mówi: „Wpisz 9 cyfr, bez spacji i prefiksu kraju”.
  • Sugestia nie ujawnia danych wrażliwych i nie obniża bezpieczeństwa.
  • Sugestia jest blisko pola albo połączona z polem przez aria-describedby.

Zły przykład

  • „Nieprawidłowa wartość” bez instrukcji.
  • „Błąd” bez wskazania poprawnego formatu.
  • Komunikat techniczny typu „invalid input”.
  • Podpowiedź dostępna dopiero w dokumentacji poza formularzem.
  • Komunikat, który tylko powtarza etykietę pola.
  • Sugestia nieadekwatna do błędu, na przykład instrukcja dla PESEL przy polu telefonu.
  • Sugestia zdradzająca za dużo informacji w polu związanym z bezpieczeństwem.

Kiedy sugestia nie jest możliwa albo niebezpieczna

Nie zawsze można podać pełną sugestię korekty. 3.3.3 wymaga sugestii wtedy, gdy błąd został wykryty i można bezpiecznie podać pomocną podpowiedź.

  • Logowanie: nie mówimy, czy błędny jest login czy hasło, jeśli mogłoby to obniżyć bezpieczeństwo.
  • Dane wrażliwe: nie podpowiadamy informacji, które mogłyby ujawnić prywatne dane.
  • Testy i quizy: nie podajemy poprawnej odpowiedzi, jeśli celem jest sprawdzenie wiedzy.
  • Wartości zależne od użytkownika: system nie zawsze może znać poprawną wartość, więc powinien wskazać regułę, format albo bezpieczny następny krok.

Przykłady kodu

Dobra sugestia dla adresu e-mail

Komunikat nie tylko mówi, że jest błąd. Pokazuje też, jak poprawić wartość.

Kod — HTML

<label for="email">
  Adres e-mail
</label>
<input
  id="email"
  name="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">
  Wpisz adres e-mail w formacie nazwa@example.com.
</p>

Dobra sugestia dla daty

Użytkownik nie musi zgadywać formatu daty.

Kod — HTML

<label for="birth-date">
  Data urodzenia
</label>
<input
  id="birth-date"
  name="birth-date"
  type="text"
  aria-invalid="true"
  aria-describedby="birth-date-error"
>
<p id="birth-date-error">
  Wpisz datę w formacie RRRR-MM-DD, np. 1990-04-27.
</p>

Zły przykład: komunikat zbyt ogólny

Użytkownik wie, że jest błąd, ale nie wie, jak go poprawić. Brakuje sugestii.

Kod — HTML

<label for="phone">
  Telefon
</label>
<input
  id="phone"
  name="phone"
  type="tel"
  aria-invalid="true"
>
<p>
  Nieprawidłowa wartość.
</p>

Bezpieczny komunikat logowania

W logowaniu nie zawsze należy podawać, która część danych jest błędna. Sugestia ma pomagać, ale nie może obniżać bezpieczeństwa.

Kod — HTML

<p id="login-error">
  Nie udało się zalogować. Sprawdź login i hasło.
</p>

Przykład graficzny

To statyczne demo edukacyjne. Pola i komunikaty są makietami, nie działającym formularzem.

Źle

Telefon

123 45

Nieprawidłowa wartość.

Komunikat wskazuje problem, ale nie mówi, co trzeba zmienić.

Ryzykownie

Data urodzenia

27.04.90

Wpisz poprawną datę.

Sugestia jest nadal za ogólna. Użytkownik nie zna oczekiwanego formatu.

Dobrze

Data urodzenia

27.04.90

Wpisz datę w formacie RRRR-MM-DD, np. 1990-04-27.

Komunikat daje konkretną, bezpieczną podpowiedź naprawy.

Statyczne demo pokazuje różnicę między samą informacją o błędzie a sugestią, która pomaga go poprawić.

Jak sprawdzić

  1. Wypełnij formularz błędnymi danymi.
  2. Sprawdź, czy błąd jest zidentyfikowany.
  3. Sprawdź, czy komunikat mówi, jak poprawić błąd.
  4. Sprawdź, czy sugestia jest konkretna, na przykład podaje format albo przykład.
  5. Sprawdź, czy sugestia jest blisko pola albo połączona programistycznie z polem.
  6. Sprawdź, czy sugestia jest bezpieczna i nie ujawnia danych wrażliwych.
  7. Sprawdź formularz klawiaturą.
  8. Sprawdź formularz czytnikiem ekranu.
  9. Nie oceniaj wyłącznie automatem.

Co sprawdzi automat, a czego nie

Automat może wykryć

  • Część pól bez etykiet.
  • Część błędnych relacji aria-describedby.
  • Część problemów z aria-invalid.
  • Niektóre problemy z komunikatami błędów.

Automat nie oceni pewnie

  • Czy sugestia jest pomocna.
  • Czy sugestia jest wystarczająco konkretna.
  • Czy sugestia jest bezpieczna.
  • Czy użytkownik rzeczywiście wie, jak poprawić błąd.
  • Czy system powinien podać sugestię w danym kontekście.
  • Czy komunikat nie ujawnia zbyt wielu informacji.

Typowe błędy

  • Komunikat „Nieprawidłowa wartość”.
  • Komunikat „Błąd formularza” bez sugestii.
  • Brak przykładu poprawnego formatu.
  • Sugestia schowana w placeholderze.
  • Informacja dopiero po kilku nieudanych próbach.
  • Techniczne komunikaty walidatora.
  • Brak rozróżnienia między formularzem zwykłym a formularzem związanym z bezpieczeństwem.
  • Zbyt szczegółowe podpowiedzi w logowaniu.

Powiązane kryteria

Źródła