Dostępna walidacja formularzy i komunikaty o błędach

Formularze zamówienia i rejestracji to miejsca, w których sklepy tracą klientów, a obsługa błędów to to, na czym formularze najczęściej zawodzą osoby korzystające z czytników ekranu, powiększenia lub klawiatury. Zasada jest prosta: powiedzieć, co jest nie tak, tekstem, obok pola, i zadbać, by technologia wspomagająca to usłyszała. Ta strona należy do serii dostępne wzorce interfejsu.

Kryteria WCAG

• 3.3.1 Identyfikacja błędu (A): „element z błędem jest wskazany, a błąd opisany użytkownikowi tekstem”. W3C dodaje, że kolor można stosować, ale tylko dodatkowo wobec tekstu.
• 3.3.3 Sugestie korekty błędów (AA): jeśli błąd wykryto automatycznie, a korekta jest znana, należy ją zasugerować, chyba że zagroziłoby to bezpieczeństwu lub celowi treści. „Adres e-mail jest nieprawidłowy” spełnia 3.3.1; „Wpisz adres e-mail w formacie [email protected]” spełnia także 3.3.3.
• 3.3.2 Etykiety lub instrukcje (A): z góry powiedzieć, co jest wymagane i w jakim formacie.
• 4.1.3 Komunikaty o stanie (AA): przykład samego W3C to tekst „5 błędów na stronie” dodany do formularza bez przenoszenia fokusu – musi zostać ogłoszony. Komunikat, który otrzymuje fokus, jest zmianą kontekstu, a nie komunikatem o stanie.
• 3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych) (AA): zamówienia muszą dać się cofnąć, sprawdzić lub potwierdzić przed ostatecznym wysłaniem.
• 1.4.1 Użycie koloru (A), 1.4.3 Kontrast (minimum) (AA): czerwony tekst na białym tle nadal musi osiągać 4,5:1.
• 3.3.7 Zbędne ponowne wprowadzanie danych (A): po błędzie nie należy zmuszać użytkowników do ponownego wpisywania danych, które już podali.

Przykład kodu

<form novalidate>
  <div id="error-summary" tabindex="-1" aria-labelledby="error-summary-title" hidden>
    <h2 id="error-summary-title">2 błędy w formularzu</h2>
    <ul>
      <li><a href="#email">E-mail: wpisz adres w formacie [email protected]</a></li>
      <li><a href="#postcode">Kod pocztowy: wpisz go w formacie 00-950</a></li>
    </ul>
  </div>

  <label for="email">E-mail</label>
  <input id="email" type="email" autocomplete="email"
         aria-invalid="true" aria-describedby="email-error">
  <p id="email-error" class="error">
    <span aria-hidden="true">⚠</span> Wpisz adres w formacie [email protected]
  </p>

  <label for="postcode">Kod pocztowy <span class="hint" id="postcode-hint">(na przykład 00-950)</span></label>
  <input id="postcode" autocomplete="postal-code"
         aria-invalid="true" aria-describedby="postcode-hint postcode-error">
  <p id="postcode-error" class="error">Wpisz kod pocztowy w formacie 00-950</p>

  <button type="submit">Przejdź do płatności</button>
</form>

Jak to działa:

• Tekst obok pola. Każdy komunikat to widoczny tekst, powiązany przez aria-describedby, więc jest czytany razem z polem. aria-invalid="true" oznacza pole jako nieprawidłowe – to technika W3C ARIA21 „Using aria-invalid to Indicate An Error Field”.
• Podsumowanie błędów po wysłaniu. U góry pokazujemy podsumowanie z linkami do pól i przenosimy na nie fokus (ma tabindex="-1", więc może go przyjąć) albo przenosimy fokus na pierwsze nieprawidłowe pole. Jeśli fokus nie jest przenoszony, błędy należy ogłosić przez region live – technika W3C ARIA19 „Using ARIA role=alert or Live Regions to Identify Errors”. Nie należy robić obu rzeczy naraz, bo komunikat zostanie odczytany dwa razy.
• Walidacja w trakcie wpisywania powinna być łagodna: sprawdzać po opuszczeniu pola, a nie przy każdym naciśnięciu klawisza, i usuwać błąd, gdy tylko zostanie poprawiony.
• Zachować dane. Po nieudanym wysłaniu należy zachować wszystko, co użytkownik wpisał.
• Natywna walidacja przeglądarki (required, type="email") też działa, ale jej komunikaty i wygląd różnią się zależnie od przeglądarki i języka; wiele sklepów używa novalidate i własnych komunikatów w języku strony.

Zachowanie klawiatury i fokusu

Typowe błędy w sklepach internetowych

• Tylko czerwona ramka wokół nieprawidłowego pola albo czerwona gwiazdka bez tekstu.
• Błędy jako komunikat (toast) u góry ekranu, który znika po trzech sekundach i nigdy nie jest ogłaszany.
• Ogólne komunikaty – „Nieprawidłowe dane”, „Błąd” – bez wskazówki, jaki format jest oczekiwany.
• Placeholder jako jedyna etykieta i wskazówka formatu, który znika, gdy tylko użytkownik zacznie pisać.
• Komunikaty niepowiązane z polami, więc użytkownicy czytników ekranu słyszą etykietę i nic więcej.
• Przycisk wysyłania nieaktywny, dopóki formularz nie jest poprawny, co ukrywa problem zamiast go wyjaśnić; zob. nieaktywne przyciski.
• Elementy iframe dostawców płatności z własnymi polami bez etykiet i błędami tylko po angielsku w zlokalizowanym sklepie.
• Formularz zostaje wyczyszczony po błędzie po stronie serwera, razem z adresem dostawy.

Co wychwytuje kontrola automatyczna, a co wymaga testu ręcznego

Wszystkie to karty z naszej biblioteki reguł. Kontrola automatyczna widzi formularz w stanie początkowym; nie wysyła go. Test ręczny: proszę wysłać formularz pusty i z błędnymi wartościami, sprawdzić, czy każdy błąd jest opisany tekstem, powiązany z polem, ogłaszany przez czytnik ekranu i czytelny przy powiększeniu 200%. Dzięki rozszerzeniu do przeglądarki można ponownie uruchomić reguły automatyczne, gdy błędy są widoczne na ekranie. Kroki opisano w jak testować WCAG.

Darmowa kontrola jednej strony uruchomiona na stronie zamówienia lub kontaktu to automatyczna kontrola, a nie pełny audyt.

Najczęstsze pytania

Czego WCAG wymaga w przypadku błędów formularza?

3.3.1 Identyfikacja błędu (A): pole z błędem jest wskazane, a błąd opisany tekstem. 3.3.3 Sugestie korekty błędów (AA): jeśli korekta jest znana, trzeba ją zasugerować. 4.1.3 Komunikaty o stanie (AA): komunikaty pojawiające się bez przeniesienia fokusu są ogłaszane przez technologię wspomagającą.

Czy czerwona ramka wystarczy do pokazania błędu?

Nie. W3C mówi, że kolor można stosować dodatkowo, ale błąd musi być też wskazany tekstem. Sama czerwona ramka zawodzi osoby, które nie widzą kolorów, oraz użytkowników czytników ekranu.

Jak powiązać komunikat o błędzie z polem?

Należy nadać komunikatowi id, odwołać się do niego z pola przez aria-describedby i ustawić na polu aria-invalid="true" (technika W3C ARIA21). Czytnik ekranu odczyta wtedy etykietę, stan nieprawidłowy i komunikat.

Czy fokus powinien przejść do pierwszego błędu?

Po wysłaniu formularza przeniesienie fokusu do podsumowania błędów lub do pierwszego nieprawidłowego pola to częste i solidne podejście. Jeśli fokus się nie przesuwa, komunikat typu „3 błędy w formularzu” musi być komunikatem o stanie, aby został ogłoszony.

Czy kontrola automatyczna przetestuje błędy formularza?

Sprawdza formularz w stanie początkowym: etykiety, wartości autocomplete, poprawne odwołania ARIA i kontrast. Nie wysyła formularzy, więc to, czy błędy się pojawiają, są opisane tekstem i ogłaszane, trzeba przetestować ręcznie.

Źródła

• W3C, Understanding 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
• W3C, Understanding 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html
• W3C, Understanding 4.1.3 Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html