3.3.1 Identyfikacja błędu

Krótko

Jeśli użytkownik popełni błąd w formularzu, strona musi jasno wskazać, gdzie jest błąd i na czym polega.

Problem w praktyce

Użytkownik wysyła formularz, ale coś jest nie tak. Jeśli strona pokazuje tylko komunikat „formularz zawiera błędy” albo zaznacza pole samym kolorem, użytkownik może nie wiedzieć, które pole poprawić i co dokładnie jest błędne.

W praktyce osoba może wrócić na formularz po wysłaniu i nie zauważyć błędu, zwłaszcza gdy komunikat jest poza aktualnym widokiem, znika po chwili albo nie jest powiązany z polem.

Kogo to dotyczy?

• Osób niewidomych korzystających z czytników ekranu, które potrzebują tekstowej informacji o błędzie.
• Osób słabowidzących, dla których sam kolor albo cienkie obramowanie może być niewystarczające.
• Osób z trudnościami poznawczymi, które potrzebują jasnego wskazania problemu.
• Osób korzystających z klawiatury, które przechodzą przez formularz pole po polu.
• Osób w stresie, pośpiechu albo na urządzeniach mobilnych, gdzie łatwo przeoczyć komunikat.

Dobry przykład

• Przy polu e-mail pojawia się tekst „Wpisz adres e-mail w formacie nazwa@example.com”.
• Przy wymaganym polu pojawia się tekst „To pole jest wymagane”.
• Na początku formularza pojawia się podsumowanie błędów z linkami do pól.
• Błędne pole ma komunikat tekstowy połączony z polem.
• Błąd nie jest sygnalizowany wyłącznie kolorem.

Zły przykład

• Komunikat „Błąd formularza” bez wskazania pola.
• Czerwone obramowanie bez tekstu.
• Komunikat znika po chwili.
• Błąd pojawia się tylko jako placeholder.
• Czytnik ekranu nie ma informacji, które pole jest błędne.
• Użytkownik trafia z powrotem na formularz, ale nie wie, co poprawić.

Przykłady kodu

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

<div class="form-error-summary">
  <h2>Popraw błędy w formularzu</h2>
  <ul>
    <li>
      <a href="#email">Adres e-mail: wpisz adres w formacie nazwa@example.com.</a>
    </li>
    <li>
      <a href="#phone">Telefon: wpisz 9 cyfr bez spacji.</a>
    </li>
  </ul>
</div>

<label for="name">Imię</label>
<input
  id="name"
  name="name"
  class="error"
>

Przykład graficzny

Jak sprawdzić?

1. Wypełnij formularz błędnymi danymi albo zostaw wymagane pola puste.
2. Wyślij formularz.
3. Sprawdź, czy strona wskazuje konkretne pola z błędami.
4. Sprawdź, czy każdy błąd ma tekstowy opis.
5. Sprawdź, czy informacja o błędzie nie jest przekazana wyłącznie kolorem.
6. Sprawdź, czy komunikat błędu jest blisko pola albo połączony z polem programistycznie.
7. Przejdź po formularzu klawiaturą.
8. Uruchom czytnik ekranu, np. NVDA albo VoiceOver.
9. Sprawdź, czy użytkownik słyszy etykietę pola i komunikat błędu.
10. W dłuższym formularzu sprawdź, czy jest podsumowanie błędów z linkami do pól.

Co sprawdzi automat, a czego nie?

Automat może wykryć

• Pola bez etykiet.
• Część niepoprawnych relacji aria-describedby.
• Niektóre problemy z aria-invalid.
• Część problemów kontrastu komunikatów.
• Niektóre błędy struktury formularza.

Automat nie oceni pewnie

• Czy komunikat błędu jest zrozumiały.
• Czy wskazuje dokładnie problem.
• Czy użytkownik wie, co poprawić.
• Czy błąd jest pokazany w dobrym momencie.
• Czy cały proces walidacji jest logiczny.
• Czy osoba korzystająca z czytnika ekranu faktycznie zrozumie sytuację.

Typowe błędy

• Komunikat „Wystąpił błąd” bez wskazania pola.
• Czerwony kolor jako jedyna informacja o błędzie.
• Brak powiązania komunikatu z polem formularza.
• Błędy widoczne tylko po najechaniu myszą.
• Błędy ukryte poza aktualnym widokiem.
• Brak podsumowania błędów w długich formularzach.
• Placeholder używany jako jedyna instrukcja.
• Komunikaty techniczne, np. „invalid input” albo „wrong value”.

Powiązane kryteria

• 1.3.1 Informacje i relacje: etykiety, komunikaty i relacje muszą być dostępne programowo.
• 1.4.1 Użycie koloru: błąd nie może być przekazany wyłącznie kolorem.
• 2.4.3 Kolejność fokusu: po błędzie użytkownik powinien móc logicznie przejść przez formularz.
• 3.3.2 Etykiety lub instrukcje: formularz powinien mieć jasne etykiety i instrukcje.
• 3.3.3 Sugestie korekty błędów: może pomóc podpowiedzieć, jak naprawić błąd, ale nie jest wymaganiem 3.3.1.
• 3.3.4 Zapobieganie błędom (prawne, finansowe, dane): dotyczy ważnych działań, które wymagają dodatkowego zabezpieczenia przed skutkami błędów.
• 4.1.3 Komunikaty o stanie: dotyczy komunikatów, które powinny być przekazane technologiom wspomagającym bez przenoszenia fokusu.

Źródła

• WCAG 2.2: 3.3.1 Error Identification (otwiera się w nowym oknie)
• Understanding WCAG 3.3.1 Error Identification (otwiera się w nowym oknie)
• How to Meet WCAG 3.3.1 Error Identification (otwiera się w nowym oknie)
• Technika G83: tekstowe wskazanie wymaganych pól, których nie wypełniono (otwiera się w nowym oknie)
• Technika G84: tekstowy opis błędu, gdy użytkownik poda niedozwoloną wartość (otwiera się w nowym oknie)
• Technika G85: tekstowy opis błędu, gdy dane mają zły format albo wartość (otwiera się w nowym oknie)
• Technika H90: wskazywanie wymaganych pól przez label lub legend (otwiera się w nowym oknie)
• Technika ARIA21: użycie aria-invalid przy błędnym polu (otwiera się w nowym oknie)