WCAG 3.3.1 Identyfikacja błędu

Kryterium sukcesu 3.3.1 sprawia, że użytkownik zauważa, że formularz nie został przyjęty, i wie, które pole jest błędne. Osoby niewidome nie widzą czerwonej ramki, osoby z zaburzeniami widzenia barw mogą jej nie zauważyć, a osoby z niepełnosprawnościami poznawczymi mogą nie zrozumieć ikony. W sklepie często decyduje to o tym, czy zamówienie zostanie złożone, czy koszyk porzucony. To poziom A; w normie EN 301 549 kryterium to występuje jako punkt 9.3.3.1.

Czego wymaga kryterium

Jeśli błąd wprowadzania danych zostanie wykryty automatycznie, to:

1. element, w którym wystąpił błąd, zostaje wskazany, oraz
2. błąd zostaje opisany użytkownikowi w formie tekstu.

Błąd wprowadzania danych to informacja podana przez użytkownika, która nie została przyjęta. Obejmuje to pominięcie wymaganych informacji oraz informacje niezgodne z wymaganym formatem lub zakresem wartości. WCAG nie określa, jak błędy mają być wyświetlane. Podpowiedź, jak poprawić błąd, to osobne kryterium 3.3.3 Sugestie korekty błędów.

Typowe błędy w sklepie internetowym

• nieprawidłowe pole jest oznaczone tylko czerwoną ramką lub czerwoną ikoną, bez tekstu;
• po kliknięciu „Złóż zamówienie” strona procesu zamówienia przeładowuje się bez komunikatu albo pokazuje tylko ogólne „Coś poszło nie tak”;
• komunikat pojawia się na górze strony, ale nie mówi, którego pola dotyczy;
• błędy karty z widżetu płatności są pokazywane jako obrazek albo znikają po kilku sekundach;
• tekst błędu jest widoczny, ale niepowiązany z polem, więc użytkownik czytnika ekranu, będąc w polu, go nie słyszy.

Jak to sprawdzić

Automatycznie: nasz skaner nie ma reguły dla tego kryterium. Automatyczne skanowanie nie wysyła formularzy z błędnymi danymi, dlatego potrzebna jest kontrola ręczna.

Ręcznie: każdy ważny formularz — rejestrację, logowanie, newsletter, kontakt, proces zamówienia, książkę adresową — należy wysłać z pustymi polami wymaganymi, a potem z błędnymi formatami (e-mail bez @, za krótki kod pocztowy, data ważności z przeszłości). Upewnić się, że każdy błąd jest pokazany tekstem, nazywa pole lub na nie wskazuje i jest odczytywany przez czytnik ekranu po przejściu do pola.

Jak to naprawić

• Wyświetlać komunikat tekstowy obok każdego nieprawidłowego pola, na przykład „Adres e-mail: wpisz adres w formacie [email protected]”.
• Powiązać komunikat z polem przez aria-describedby i ustawić w polu aria-invalid="true".
• W długich formularzach dodać na górze podsumowanie błędów z linkami do pól i po wysłaniu przenieść na nie fokus.
• Utrzymywać komunikaty widoczne do czasu poprawienia błędu; nie polegać wyłącznie na kolorze lub ikonach.

Powiązane kryteria

• 3.3.3 Sugestie korekty błędów — informowanie użytkowników, jak poprawić błąd.
• 4.1.3 Komunikaty o stanie — ogłaszanie błędów, które pojawiają się bez przeniesienia fokusu.
• 1.4.1 Użycie koloru — kolor nie może być jedynym sygnałem.

Najczęstsze pytania

Czy czerwona ramka wystarczy, by pokazać błąd w formularzu?

Nie. WCAG 3.3.1 wymaga opisania błędu tekstem. Sam kolor nie spełnia też kryterium 1.4.1 Użycie koloru. Obok pola należy dodać komunikat, na przykład „Wpisz kod pocztowy”.

Czy 3.3.1 dotyczy pustych pól wymaganych?

Tak. Informacja, której strona wymaga, a użytkownik jej nie podał, liczy się jako błąd wprowadzania danych, więc puste pole wymagane musi zostać wskazane i opisane tekstem.

Czy WCAG określa, gdzie mają się pojawiać komunikaty o błędach?

Nie jest wymagany żaden konkretny sposób prezentacji. Powszechną dobrą praktyką jest komunikat obok pola, powiązany z nim przez aria-describedby, a przy długich formularzach także podsumowanie na górze formularza.