Formularz zamówienia to ostatnie miejsce, w którym sklep może stracić klienta, i pierwsze, w którym traci go najłatwiej. Użytkownik włożył już pracę w wybór produktów. Jeśli teraz zobaczy czerwoną ramkę bez wyjaśnienia albo komunikat zniknie, zanim zdąży go przeczytać, część osób po prostu zamknie kartę. Dla użytkowników czytników ekranu źle zrobiona walidacja bywa ścianą nie do przejścia.
Z czego składa się komunikat, który działa
Dobra obsługa błędu zaczyna się od treści. Komunikat mówi, co się stało i jak to naprawić, najlepiej z przykładem poprawnej wartości. Zamiast suchego „Nieprawidłowe dane" piszemy „Uzupełnij numer telefonu, np. 601 234 567. Potrzebujemy go do awizacji dostawy". Druga warstwa to powiązanie techniczne: pole dostaje atrybut aria-invalid, a identyfikator komunikatu trafia do aria-describedby, dzięki czemu czytnik ekranu odczyta błąd razem z etykietą pola. Trzecia warstwa to poinformowanie o samym fakcie wystąpienia błędów, bo osoba niewidoma nie zobaczy czerwieni na drugim ekranie formularza.
W kodzie minimalny poprawny wariant wygląda tak:
<label for="phone">Numer telefonu</label>
<input id="phone" name="phone" type="tel"
aria-invalid="true" aria-describedby="phone-error">
<p id="phone-error">Uzupełnij numer telefonu, np. 601 234 567.</p>Po zatwierdzeniu formularza: podsumowanie zamiast domysłów
Gdy walidacja odrzuca cały formularz, sprawdzonym wzorcem jest podsumowanie błędów nad formularzem, z linkami prowadzącymi do konkretnych pól. Fokus przenosimy na to podsumowanie. Użytkownik klawiatury dostaje wtedy spis rzeczy do poprawienia i skróty do każdej z nich, zamiast wędrować przez kilkanaście pól w poszukiwaniu czerwonej ramki.
Antywzorce, które wciąż widujemy w audytach
- Błąd zakomunikowany wyłącznie kolorem ramki, bez tekstu.
- Komunikat w dymku, który znika po trzech sekundach.
- Walidacja czyszcząca wpisane hasło albo numer karty przy każdej próbie.
- Fokus przeskakujący na górę strony bez żadnej informacji, co poszło źle.
- Komunikat wstawiany do DOM w miejscu, którego czytnik ekranu nigdy nie ogłosi.
Kiedy walidować: w trakcie pisania czy po wysłaniu
Walidacja odpalana przy każdym wciśniętym klawiszu potrafi zasypać użytkownika czytnika ekranu potokiem komunikatów o błędzie, którego jeszcze nie zdążył popełnić, bo przecież dopiero wpisuje trzecią cyfrę numeru. Spokojniejszy wariant sprawdza wartość po opuszczeniu pola, a komunikaty ogłasza przez region live w sposób grzeczny, bez przerywania. Odwrotna skrajność, czyli walidacja dopiero po wysłaniu całego formularza, bywa akceptowalna pod warunkiem porządnego podsumowania błędów. Wybór między tymi trybami zależy od długości formularza, natomiast zasada pozostaje wspólna: użytkownik ma dostać informację wtedy, gdy może na nią zareagować, i tam, gdzie jej szuka.
Jak to sprawdzić własnymi siłami
Test zajmuje pół godziny. Wysyłamy pusty formularz i patrzymy, czy da się z samej treści komunikatów zrozumieć, co poprawić. Przechodzimy całość klawiaturą. Włączamy darmowego NVDA i słuchamy, co zostaje ogłoszone w momencie błędu oraz przy wejściu w pole. Jeżeli w którymś z tych kroków musimy się domyślać, klient też będzie musiał, tyle że on ma otwarte trzy inne sklepy z tym samym produktem.