Dostępne formularze: etykiety, podpowiedzi i błędy

Sześć kryteriów sukcesu dla formularzy

WCAG 2.2 to aktualna rekomendacja W3C dotycząca dostępności treści internetowych. Dla tekstów formularza najważniejsze jest sześć jej kryteriów sukcesu:

• 1.3.1 Info and Relationships (poziom A): to, co pokazuje układ, na przykład która etykieta należy do którego pola, jest dostępne także w kodzie lub w tekście.
• 1.3.5 Identify Input Purpose (poziom AA): pola, które pytają o dane użytkownika, takie jak imię czy e-mail, określają swój cel w kodzie.
• 3.3.1 Error Identification (poziom A): jeśli błąd we wprowadzonych danych zostanie wykryty automatycznie, pole jest wskazane, a błąd opisany tekstem.
• 3.3.2 Labels or Instructions (poziom A): gdy treść wymaga wprowadzenia danych, są etykiety lub instrukcje.
• 3.3.3 Error Suggestion (poziom AA): jeśli błąd zostanie wykryty, a znana jest poprawka, jest ona proponowana, chyba że zagroziłoby to bezpieczeństwu lub celowi treści.
• 4.1.2 Name, Role, Value (poziom A): każdy element sterujący ma nazwę i rolę, które oprogramowanie może odczytać.

Każde pole potrzebuje widocznej etykiety

Etykieta mówi, co wpisać w pole, i pozostaje widoczna podczas pisania. W HTML połącz element label z polem: atrybut for etykiety ma dokładnie tę samą wartość co id pola. Wtedy czytniki ekranu odczytują etykietę razem z polem, a kliknięcie etykiety ustawia kursor w polu. Przycisk dostaje etykietę ze swojego tekstu, a „Wyślij wiadomość” mówi więcej niż „Wyślij”. Etykiety stoją zwykle na prawo od przycisków opcji i pól wyboru oraz na lewo od innych pól lub nad nimi; nad polem zajmują mniej miejsca w szerokości.

Placeholder nie jest etykietą

Szary tekst w pustym polu wygląda jak etykieta, ale nią nie jest. W3C wymienia problemy:

• Znika, gdy tylko ktoś zacznie pisać, więc trudniej sprawdzić dane przed wysłaniem.
• Przeglądarki często pokazują go w jasnym kolorze o zbyt małym kontraście.
• Czytniki ekranu nie traktują go jako etykiety, a obsługa bywa różna.

Używaj placeholdera najwyżej do przykładu, a wszystko ważne umieść w etykiecie lub podpowiedzi.

Podpowiedzi i pola wymagane

• Zasady zapisz w podpowiedzi: format daty, długość numeru klienta, czego wymaga hasło. W HTML połączysz podpowiedź z polem przez aria-describedby, a czytniki ekranu odczytają ją po etykiecie.
• Napisz, które pola są wymagane, a które opcjonalne. Jeśli używasz gwiazdki, wyjaśnij ją raz na początku formularza.
• Instrukcje dotyczące całego formularza umieść przed formularzem, na przykład o limicie czasu.
• Pisz krótkie podpowiedzi. Zbyt wiele instrukcji utrudnia wypełnienie formularza zamiast je ułatwiać.

Grupuj powiązane pola

Przyciski opcji i pola wyboru, które do siebie należą, grupujesz elementem fieldset, a element legend nazywa grupę, na przykład „Jak mamy się z tobą skontaktować?”. W3C pisze, że grupy przycisków opcji zawsze powinny być tak zgrupowane. Legenda niech będzie krótka, bo niektóre czytniki ekranu odczytują ją przy każdym polu. Grupy pomagają też przy polach o tej samej etykiecie, na przykład ulicy w adresie dostawy i adresie do faktury.

autocomplete: niech pomoże przeglądarka

Dla pól z danymi użytkownika kryterium 1.3.5 wymaga, by ich cel dało się określić w kodzie. WCAG 2.2 ma listę takich celów, opartą na części specyfikacji HTML o autouzupełnianiu, na przykład name, given-name, family-name, email, tel, street-address i postal-code. W HTML ustawiasz je atrybutem autocomplete, na przykład autocomplete="email". Przeglądarka może wtedy wstawić zapisane wartości, co oszczędza pisania. Pola, które nie pytają o użytkownika, nie potrzebują celu.

Komunikaty o błędach, które pomagają

Komunikat o błędzie ma trzy zadania: nazwać pole, powiedzieć, co jest nie tak, i powiedzieć, jak to poprawić. Kryterium 3.3.1 wymaga dwóch pierwszych w formie tekstu, więc sama czerwona ramka lub ikona nie wystarczy. Kryterium 3.3.3 wymaga poprawki tam, gdzie jest znana.

• Pokaż komunikat obok pola i połącz go przez aria-describedby, żeby czytniki ekranu odczytały go razem z polem.
• Po wysłaniu pokaż na górze, przed formularzem, listę wszystkich błędów pod jasnym nagłówkiem. Każdy wpis nazywa pole, problem i rozwiązanie oraz linkuje do pola.
• Zmień też tytuł strony, na przykład „2 błędy – formularz kontaktowy”, i przenieś fokus na pierwsze pole z błędem.
• Zachowaj to, co użytkownik już wpisał. To nasza rada, a nie zasada WCAG: kto po jednym błędzie musi wszystko wpisać od nowa, często rezygnuje.

Sprawdź formularz z Do4U

Narzędzie Teksty formularzy sprawdza teksty formularza. Wklejasz kod HTML formularza albo podajesz adres strony i możesz dodać komunikaty o błędach, które pokazuje twój formularz. Kod czyta każde pole: jego etykietę i jej źródło, podpowiedzi, placeholdery, pola wymagane, wartości autocomplete oraz grupy przycisków opcji i pól wyboru. Znajduje problemy, takie jak pole bez etykiety, placeholder jako jedyna etykieta, pola wymagane, o których tekst nie mówi, brak wartości autocomplete i ogólnikowe komunikaty o błędach, każdy z kryterium sukcesu. AI proponuje jasną etykietę, krótką podpowiedź i komunikat o błędzie, który nazywa pole i mówi, jak poprawić dane. Kod sprawdza każdą propozycję i buduje z twojego formularza poprawiony szkic HTML.

Do4U znajduje wskazówki i buduje szkic, a ty sprawdzasz i decydujesz. Narzędzie sprawdza znaczniki, a nie style, skrypty czy obsługę klawiaturą, i nie mówi, czy twój formularz jest dostępny. Przetestuj poprawiony formularz klawiaturą i czytnikiem ekranu.