- Poziom
- A
- Od wersji
- WCAG 2.0
- Pozycje
- 20 / 193
3.3.1 Identyfikacja błędu
Gdy formularz odrzuca to, co ktoś wpisał, strona musi powiedzieć słowami, które pole jest błędne i co jest z nim nie tak.
/ Czego wymaga
Gdy oprogramowanie wykrywa błąd we wprowadzonych danych, w przeglądarce albo na serwerze, muszą stać się dwie rzeczy: błędne pole zostaje wskazane, a błąd zostaje opisany użytkownikowi tekstem. Sama czerwona ramka nie załatwia żadnej z nich dla kogoś, kto nie widzi kolorów albo ekranu. Użytkownicy czytników ekranu, osoby z zaburzeniami widzenia barw i osoby, którym formularze sprawiają trudność, potrzebują zdania, które nazywa pole i problem, na przykład „E-mail: wpisz adres zawierający znak małpy”.
Kryterium dotyczy tylko błędów wykrywanych automatycznie i nie wymienia żadnych wyjątków. Nie wymaga podpowiedzi, jak poprawić wpis, bo tym zajmuje się kryterium 3.3.3 na poziomie AA, choć dobry komunikat często robi jedno i drugie. Kolor i ikony mogą towarzyszyć tekstowi, ale nie mogą go zastępować. Podsumowanie o treści „Formularz zawiera błędy” nie spełnia kryterium, bo nie wskazuje błędnego elementu. Z tego samego powodu nie spełnia go komunikat, który nie nazywa żadnego pola.
/ Jak strony go nie spełniają
- Błędne pole dostaje czerwoną ramkę i żadnego tekstu.
- Formularz przeładowuje się z banerem, który mówi tylko, że są błędy, i nie wymienia żadnego pola.
- Błąd jest pokazany ikoną, która nie ma tekstu alternatywnego.
- Komunikat pojawia się obok pola tylko wizualnie i nie jest z nim powiązany w kodzie, więc użytkownik czytnika ekranu po powrocie do pola go nie słyszy.
- Jedynym sygnałem jest przycisk wysyłania, który pozostaje nieaktywny, bez wyjaśnienia, które pole go blokuje.
/ Jak sprawdzić samodzielnie
- Wyślij formularz pusty, a potem z celowo błędnymi wartościami, na przykład z adresem e-mail bez znaku małpy. Tam, gdzie prawdziwe wysłanie złożyłoby zamówienie, użyj formularza testowego.
- Przy każdym błędzie sprawdź, czy jest tekst, czy nazywa on pole albo stoi tuż przy nim i czy mówi, co jest nie tak.
- Obejrzyj stronę w odcieniach szarości albo po prostu pomiń kolor. Każdy błąd nadal musi dać się znaleźć.
- Zbadaj błędne pole w narzędziach deweloperskich i poszukaj aria-invalid="true" oraz atrybutu aria-describedby wskazującego id komunikatu.
- Powtórz wysyłkę z włączonym darmowym czytnikiem ekranu, na przykład NVDA. Posłuchaj błędów w chwili, gdy się pojawiają, i ponownie po przejściu tabulatorem do pola.
/ Jak to naprawić
- Wyświetl komunikat tekstowy przy każdym błędnym polu, nadaj mu id i wskaż go z elementu input atrybutem aria-describedby.
- Ustaw na polu aria-invalid="true" na czas trwania błędu i usuń ten atrybut, gdy wartość zostanie przyjęta.
- Nazwij pole w komunikacie, na przykład „Kod pocztowy: użyj formatu 00-000”, żeby miał sens także czytany osobno.
- Po nieudanej wysyłce dodaj u góry podsumowanie, w którym każdy błąd jest linkiem do swojego pola, i przenieś na nie fokus albo nadaj mu role="alert".
- Czerwoną ramkę i ikonę zostaw jako sygnały dodatkowe, nigdy jako jedyne.
/ Co sprawdza nasz skaner
Test error-not-associated znajduje widoczny tekst w elemencie z role="alert" albo ze słowem „error” lub „invalid” w nazwie klasy i bierze pierwsze pole w tym samym bloku. Zgłasza komunikat, chyba że pole wskazuje go przez aria-describedby lub aria-errormessage albo ma aria-invalid="true" obok alertu. Niczego nie wysyła, więc błędów pokazywanych dopiero po wysłaniu formularza nie widzi.
/ Kto je łamie, według naszych pomiarów
Jedna strona na podmiot, mierzona automatycznie w tygodniowym cyklu. Jeśli podmiot coś naprawił od ostatniego pomiaru, zmiana będzie widoczna przy następnym, a każdy podmiot może odpowiedzieć na swojej stronie.
/ Pytania o to kryterium
Czy czerwona ramka wystarczy, żeby pokazać błąd w formularzu?
Nie. Kryterium wymaga, żeby błąd był opisany tekstem, a kryterium 1.4.1 Użycie koloru osobno zabrania przekazywania informacji wyłącznie kolorem. Czerwona ramka może zostać jako pomoc wizualna. Obok niej musi się znaleźć komunikat wyrażony słowami, który mówi, którego pola dotyczy błąd i co jest nie tak.
Czym różnią się kryteria 3.3.1 i 3.3.3?
3.3.1 Identyfikacja błędu, poziom A, wymaga, żeby błędne pole zostało wskazane, a błąd opisany tekstem. 3.3.3 Sugestie korekty błędów, poziom AA, idzie o krok dalej: gdy system wie, jak można poprawić wpis, musi to powiedzieć, chyba że zagroziłoby to bezpieczeństwu albo celowi treści.
Czy komunikaty o błędach muszą mieć aria-describedby albo aria-invalid?
Kryterium nie wymienia żadnego atrybutu. Wymaga rezultatu: element zostaje wskazany, a błąd opisany tekstem. W HTML atrybut aria-invalid na polu i aria-describedby wskazujący komunikat to zwykły sposób, żeby ten rezultat dotarł do użytkownika czytnika ekranu, który w przeciwnym razie może nigdy nie natrafić na tekst umieszczony obok pola.