WCAG 3.3.2 Etykiety lub instrukcje

Kryterium sukcesu 3.3.2 sprawia, że każdy wie, co wpisać w formularzu. Osoby z niepełnosprawnościami poznawczymi, osoby starsze, użytkownicy czytników ekranu i każdy, kto wypełnia proces zamówienia na małym telefonie, korzystają na jasnych etykietach, widocznych oznaczeniach pól wymaganych i krótkich podpowiedziach dotyczących formatu. To poziom A; w normie EN 301 549 kryterium to występuje jako punkt 9.3.3.2.

Czego wymaga kryterium

Gdy treść wymaga wprowadzenia danych przez użytkownika, muszą być zapewnione etykiety lub instrukcje. W3C zaznacza, że „wymaga” oznacza „przyjmuje lub oczekuje danych”, więc liczą się również pola opcjonalne.

• Etykieta to tekst (lub komponent z tekstem alternatywnym) prezentowany wszystkim użytkownikom, który identyfikuje element sterujący. Nie musi to być element HTML <label>, ale musi być widoczna dla wszystkich — w odróżnieniu od nazwy dostępnej, która może być ukryta.
• Instrukcje wyjaśniają oczekiwane dane lub format, na przykład „Data urodzenia (DD.MM.RRRR)”, które pola są wymagane albo czego dotyczy grupa przycisków opcji.

Celem są przydatne wskazówki bez zbędnego tłoku: nie każde pole potrzebuje akapitu, ale nikt nie powinien musieć zgadywać.

Typowe błędy w sklepie internetowym

• pola procesu zamówienia z samym tekstem zastępczym (placeholderem), który znika, gdy użytkownik zaczyna pisać;
• pole telefonu lub karty podzielone na kilka okienek bez etykiety dla każdej części;
• pola wymagane oznaczone tylko czerwoną gwiazdką, bez wyjaśnienia, co gwiazdka oznacza;
• przyciski opcji dla sposobów dostawy lub pola wyboru zgód bez etykiety grupy;
• pole ilości, wyszukiwarka lub pole newslettera z ikoną, ale bez widocznego tekstu;
• nietypowy format (NIP UE, zasady hasła) bez podpowiedzi, zanim użytkownik popełni błąd.

Jak to sprawdzić

Automatycznie: nasz skaner stosuje regułę form-field-multiple-labels, która zgłasza pola z więcej niż jedną etykietą. Powiązane reguły dotyczące brakujących nazw dostępnych (np. label, select-name) są opisane przy 4.1.2. To, czy etykieta jest widoczna i zrozumiała, musi ocenić człowiek.

Ręcznie: należy przejść przez każdy formularz. Przy każdym polu sprawdzić, czy jest widoczny tekst, który pozostaje na ekranie podczas pisania, czy pola wymagane są oznaczone tekstem, czy grupy opcji mają nagłówek lub legendę i czy specjalne formaty są wyjaśnione przed wprowadzeniem danych.

Jak to naprawić

• Nadać każdemu polu widoczny element <label for="…">; placeholdery stosować tylko do przykładów.
• Grupować przyciski opcji i pola wyboru w <fieldset> z <legend>.
• Oznaczać pola wymagane w etykiecie („E-mail (wymagane)”) albo objaśnić gwiazdkę na górze formularza.
• Dodać krótką podpowiedź dotyczącą formatu i powiązać ją przez aria-describedby.

Powiązane kryteria

• 3.3.1 Identyfikacja błędu — co się dzieje, gdy dane są błędne.
• 4.1.2 Nazwa, rola, wartość — programowa nazwa każdego pola.
• 1.3.5 Określenie pożądanej wartości — autouzupełnianie pól z danymi osobowymi.

Najczęstsze pytania

Czy tekst zastępczy (placeholder) wystarczy jako etykieta?

To ryzykowne. Placeholder znika, gdy tylko użytkownik zacznie pisać, często ma niski kontrast i nie zawsze jest odczytywany przez technologie wspomagające. Niezawodnym rozwiązaniem jest widoczna etykieta, która pozostaje na ekranie.

Czy 3.3.2 dotyczy tylko pól wymaganych?

Nie. W3C wyjaśnia, że „wymaga” oznacza tu „przyjmuje lub oczekuje danych”, więc pola opcjonalne również potrzebują etykiet lub instrukcji.

Czy trzeba oznaczać pola wymagane?

To oczekiwany sposób spełnienia 3.3.2, gdy niektóre pola są wymagane: W3C wymienia oznaczenie pól wymaganych w etykiecie lub legendzie jako technikę wystarczającą. Należy użyć tekstu lub objaśnionego symbolu, a nie samego koloru.

Czym różni się 3.3.2 od 4.1.2?

3.3.2 dotyczy etykiet i instrukcji, które widzą wszyscy użytkownicy. 4.1.2 dotyczy nazwy dostępnej, którą odczytuje oprogramowanie. Pole może mieć ukrytą nazwę, a mimo to nie mieć widocznej etykiety.