WCAG 3.3.3 Sugestie korekty błędów

Kryterium sukcesu 3.3.3 pomaga poprawić formularz, gdy coś poszło nie tak. Komunikat w rodzaju „Nieprawidłowe dane” mówi klientowi, że jest problem, ale nie mówi, co zrobić. Osoby z niepełnosprawnościami poznawczymi, użytkownicy czytników ekranu i osoby z niepełnosprawnościami ruchowymi, które popełniają błędy przy pisaniu, często rezygnują właśnie w tym momencie. To poziom AA; w normie EN 301 549 kryterium to występuje jako punkt 9.3.3.3.

Czego wymaga kryterium

Jeśli błąd wprowadzania danych zostanie wykryty automatycznie i znane są sugestie korekty, sugestie te muszą zostać przekazane użytkownikowi.

• Błąd wprowadzania danych obejmuje pominięcie wymaganych informacji oraz informacje niezgodne z wymaganym formatem lub zakresem wartości.
• „Znane” oznacza, że serwis potrafi określić, co zostałoby przyjęte — na przykład oczekiwany format, dopuszczalny zakres albo listę prawidłowych opcji.
• Wyjątek: sugestię można pominąć, jeśli zagroziłaby bezpieczeństwu lub celowi treści — na przykład ujawniłaby, która część danych logowania była błędna, albo zdradziła odpowiedź w quizie.

Sugestia ma zwykle postać tekstu i musi spełniać pozostałe kryteria (na przykład być czytelna i dostępna dla czytników ekranu).

Typowe błędy w sklepie internetowym

• „Nieprawidłowy kod pocztowy” bez podpowiedzi o oczekiwanym formacie dla wybranego kraju;
• „Nieprawidłowa data” w polu daty ważności karty bez informacji, że format to MM/RR;
• „Hasło nie spełnia wymagań” bez wymienienia tych wymagań;
• „Ilość niedostępna” bez informacji, ile sztuk jest w magazynie;
• pole kodu rabatowego, które przy wygasłym kodzie pokazuje tylko „Błąd”;
• pole numeru VAT UE, które odrzuca dane bez pokazania przykładu.

Jak to sprawdzić

Automatycznie: nasz skaner nie ma reguły dla tego kryterium. Potrzebna jest kontrola ręczna.

Ręcznie: w każdym formularzu należy wpisać typowe błędne wartości: kod pocztowy w złym formacie, datę z przeszłości, za krótkie hasło, ilość większą niż stan magazynowy, e-mail bez „@”. Przeczytać każdy komunikat i zadać pytanie: czy mówi, jak poprawić dane? Sprawdzić też, czy czytnik ekranu ogłasza komunikat, gdy się pojawia lub po przejściu do pola.

Jak to naprawić

• Pisać komunikaty, które podają sposób poprawy: „Wpisz kod pocztowy w formacie 00-000, na przykład 00-950”.
• Podawać zasady z góry (długość hasła, dozwolone znaki) i powtarzać je w komunikacie o błędzie.
• Gdy prawidłowych wartości jest niewiele, podpowiadać najbliższe albo oferować wybór.
• Zachowywać dane wpisane przez użytkownika w polu, aby mógł je poprawić, a nie wpisywać od nowa.

Powiązane kryteria

• 3.3.1 Identyfikacja błędu — błąd musi być wskazany i opisany.
• 3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych) — kontrola, zanim zamówienie stanie się ostateczne.
• 3.3.2 Etykiety lub instrukcje — wyjaśnienie formatu, zanim użytkownik zacznie pisać.

Najczęstsze pytania

Czym różni się 3.3.1 od 3.3.3?

3.3.1 wymaga wskazania pola z błędem i opisania błędu tekstem. 3.3.3 idzie o krok dalej: jeśli wiadomo, jak użytkownik może poprawić błąd, trzeba mu to powiedzieć.

Czy formularz logowania powinien mówić, czy błędny był e-mail, czy hasło?

Niekoniecznie. 3.3.3 ma wyjątek dla sytuacji, gdy sugestia zagroziłaby bezpieczeństwu lub celowi treści, więc ogólny komunikat „e-mail lub hasło są nieprawidłowe” jest dopuszczalny.

Czy automatyczne narzędzie może sprawdzić sugestie korekty błędów?

Nie. Musiałoby wysyłać formularze z błędnymi danymi i oceniać treść komunikatów, dlatego sprawdza się to ręcznie.