Formularze to miejsce, w którym Twoja witryna przestaje mówić, a zaczyna słuchać: zapytania kontaktowe, zamówienia, rejestracje, wyszukiwania. To też miejsce, w którym dostępność zawodzi najczęściej. Badanie WebAIM Million, które co roku skanuje milion najpopularniejszych stron głównych, konsekwentnie znajduje brakujące etykiety pól formularzy na prawie połowie z nich, co czyni ten problem jednym z najczęstszych błędów dostępności w sieci. Frustrujące jest to, że dostępne formularze wcale nie są trudne. Garść poprawnie użytych atrybutów HTML decyduje o tym, czy niewidoma osoba wyśle Ci wiadomość, czy po cichu się podda, i czy Twój formularz spełnia WCAG, które European Accessibility Act uczynił wymogiem prawnym dla wielu firm. Ten przewodnik przechodzi przez pięć rzeczy, które mają znaczenie, z gotowym kodem do skopiowania, i kończy się szczerym spojrzeniem na wtyczki formularzy dla WordPressa.
Dlaczego to formularze są największym problemem dostępności?
Widzący użytkownik myszy odczytuje formularz jako wizualną całość: tekst obok pola oczywiście do niego należy, czerwona ramka oczywiście oznacza błąd. Technologie wspomagające nie mają żadnego z tych kontekstów. Użytkownik czytnika ekranu przechodzi tabulatorem od kontrolki do kontrolki i słyszy wyłącznie to, co kod jawnie powiązał z danym polem. Jeśli powiązania brakuje, słyszy pole tekstowe, puste, i musi zgadywać, czego pole oczekuje. Użytkownicy sterowania głosem mają analogiczny problem: polecenie kliknij e-mail zadziała tylko wtedy, gdy pole jest programowo nazwane e-mail.
To właśnie podstawowa zasada stojąca za każdą regułą w tym przewodniku: każda wizualna relacja w formularzu musi istnieć również w kodzie. Etykieta do pola, wskazówka do pola, błąd do pola, grupa do opcji. Odpowiednie kryteria sukcesu WCAG (1.3.1 Info and Relationships, 3.3.1 Error Identification, 3.3.2 Labels or Instructions) sprowadzają się do tej jednej myśli.
Jak poprawnie etykietować pola formularza
Fundamentem każdego dostępnego formularza jest element label powiązany ze swoim polem atrybutem for wskazującym na id pola:
<label for="email">Adres e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">
<!-- Dodatkowa wskazówka, powiązana przez aria-describedby -->
<label for="password">Hasło</label>
<input type="password" id="password" name="password" aria-describedby="password-hint">
<p id="password-hint">Co najmniej dwanaście znaków.</p>To daje trzy rzeczy naraz: czytniki ekranu odczytują etykietę, gdy pole otrzymuje fokus, kliknięcie etykiety ustawia fokus w polu (czyli większy cel dotykowy na urządzeniach mobilnych dla wszystkich), a sterowanie głosem może odwołać się do pola po nazwie. Wskazówki i instrukcje dotyczące formatu trafiają do osobnego elementu wskazanego przez aria-describedby, dzięki czemu są odczytywane po etykiecie, nie zaśmiecając jej. Atrybut autocomplete to cicha premia: dla pól zbierających dane osobowe wymaga go WCAG 1.3.5, a przy okazji pozwala przeglądarkom poprawnie wypełnić pole, co najbardziej pomaga użytkownikom z ograniczeniami motorycznymi i poznawczymi. Poradnik W3C o formularzach omawia każdy wariant tych wzorców.
Dlaczego placeholder nie jest etykietą
Pole formularza opisane wyłącznie placeholderem to najczęstszy błąd, który wygląda na dostępny. Wygląda schludnie i zawodzi na cztery sposoby naraz:
- Tekst znika przy wpisywaniu. Opis ulatnia się dokładnie wtedy, gdy użytkownik pracuje z polem. Każdy, kto zapomniał, o co pytało częściowo wypełnione pole, dobrze to zna.
- Domyślna szarość nie spełnia kontrastu. Typowe stylowanie placeholdera nie osiąga współczynnika kontrastu 4,5:1, którego WCAG wymaga dla tekstu.
- Wsparcie technologii wspomagających jest niespójne. Część kombinacji czytnika ekranu i przeglądarki odczytuje placeholdery, część nie. Etykietę odczytują wszystkie.
- Wypełnione pola wyglądają na puste, a puste na wypełnione. Użytkownicy skanujący formularz w poszukiwaniu tego, co zostało do uzupełnienia, dostają odwrotny obraz.
Placeholdery są w porządku jako uzupełnienie, na przykład jako przykład formatu w rodzaju imie@example.com wewnątrz prawidłowo oetykietowanego pola. Jako jedyny opis pola są naruszeniem WCAG 3.3.2 w ładnej typografii.
Jak dostępnie oznaczać pola wymagane
Zawsze dwa kanały jednocześnie. Kanał maszynowy to atrybut HTML required, dzięki któremu przeglądarki i czytniki ekranu ogłaszają pole jako wymagane i który włącza walidację natywną. Kanał ludzki to widoczny tekst: słowo wymagane (albo jego przeciwieństwo, opcjonalne) w etykiecie. Popularna czerwona gwiazdka sama w sobie zawodzi na obu polach: sam kolor nie może nieść informacji (WCAG 1.4.1), a konwencja gwiazdki, jeśli już jej używasz, musi być przynajmniej wyjaśniona nad formularzem i zawarta w etykiecie, żeby została odczytana.
<label for="name">Imię i nazwisko (wymagane)</label>
<input type="text" id="name" name="name" required>Pragmatyczne odwrócenie często daje najczystsze formularze: jeśli prawie każde pole jest wymagane, oznacz tylko te opcjonalne i napisz o tym nad formularzem. A najlepsze pole wymagane to takie, które usuwasz; każde pole, o które formularz nie pyta, jest polem, którego nie da się wypełnić błędnie.
Jak sprawić, żeby komunikaty o błędach były dostępne
To na obsłudze błędów formularze tracą użytkowników, których jeszcze nie straciły. WCAG 3.3.1 wymaga, aby błędy były zidentyfikowane tekstem i opisane użytkownikowi. Solidny wzorzec dla pojedynczego pola:
<label for="email">Adres e-mail (wymagane)</label>
<input type="email" id="email" name="email" required
aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error">
Podaj adres e-mail, na przykład imie@example.com.
</p>Poszczególne elementy: aria-invalid="true" oznacza pole jako błędne, dzięki czemu czytniki ekranu ogłaszają nieprawidłowy wpis przy przejściu na nie, komunikat jest prawdziwym tekstem (a nie tylko czerwoną ramką czy ikoną) i jest powiązany z polem przez aria-describedby, a treść mówi, jak naprawić problem, a nie tylko że problem istnieje. Błąd, proszę poprawić nie pomaga nikomu; Podaj datę w formacie DD.MM.RRRR pomaga.
Przy walidacji uruchamianej po wysłaniu formularza liczy się jeszcze jeden krok: po nieudanej próbie przenieś fokus klawiatury na pierwsze błędne pole albo wyrenderuj na górze podsumowanie błędów z role="alert" i odnośnikami do problematycznych pól. Użytkownik czytnika ekranu, który wysyła formularz i nie słyszy nic, zakłada, że wszystko się udało. Cisza po nieudanym wysłaniu to najokrutniejszy błąd formularza, jaki istnieje.
Fieldset i legend: grupowanie przycisków radiowych i pól wyboru
Przyciski radiowe i grupy pól wyboru mają strukturę dwupoziomową: grupa ma pytanie, a każda opcja ma etykietę. Oba poziomy muszą znaleźć się w kodzie, a natywne elementy dla poziomu grupy to fieldset i legend:
<fieldset>
<legend>Preferowana forma kontaktu (wymagane)</legend>
<input type="radio" id="contact-email" name="contact" value="email">
<label for="contact-email">E-mail</label>
<input type="radio" id="contact-phone" name="contact" value="phone">
<label for="contact-phone">Telefon</label>
</fieldset>Bez fieldsetu użytkownik czytnika ekranu wchodzący tabulatorem w grupę słyszy tylko E-mail, przycisk radiowy, jeden z dwóch, i nie ma pojęcia, na jakie pytanie odpowiadają opcje. Z nim legenda jest odczytywana jako pierwsza. Ta sama struktura obsługuje grupy pól wyboru i warto ją zachować nawet wtedy, gdy system projektowy przestyluje elementy nie do poznania; semantyka nic nie kosztuje, a niesie wszystko.
Czy wtyczki formularzy WordPress są dostępne?
W większości mogą być, ale żadna tego nie gwarantuje. Szczery obraz wtyczka po wtyczce: Contact Form 7 renderuje to, co wpiszesz w jego szablonie formularza, więc etykiety, fieldsety i oprzewodowanie błędów spoczywają całkowicie w Twoich rękach; elastyczność, która czyni tę wtyczkę popularną, sprawia też, że łatwo wypuścić formularz bez etykiet. Gravity Forms kilka lat temu przebudowały swój kod z dostępnością jako jawnym celem i w bieżących wersjach generują solidny wynik. WPForms podobnie zainwestowały w dostępne ustawienia domyślne. W każdym przypadku trzy rzeczy wciąż mogą zepsuć dostępną wtyczkę: stylowanie Twojego motywu (usunięte obrysy fokusu, zniszczony kontrast), mechanizmy CAPTCHA (całkowicie niedostępna bariera, podejścia typu honeypot omijają ten problem) oraz doklejone własne typy pól.
Testuj więc wyrenderowany wynik, a nie stronę marketingową. Wersja dwuminutowa: odłącz mysz i wypełnij formularz samą klawiaturą, sprawdzając, czy na każdym kroku widzisz fokus, a potem wyślij go pustego i sprawdź, czy komunikaty o błędach są odczytywane i osiągalne. Automatyczne walidatory takie jak WAVE wyłapują w kilka sekund strukturalną połowę problemów, w tym brakujące etykiety.
Jak InspectWP pomaga znaleźć problemy z formularzami
Raport InspectWP analizuje wyrenderowaną witrynę WordPress tak, jak widzi ją przeglądarka, a kilka kontroli dotyczy bezpośrednio formularzy. Oznacza formularze, których action wysyła dane pod niezabezpieczony adres HTTP, czyli problem, za który przeglądarki karzą ostrzeżeniami dokładnie w chwili, gdy odwiedzający ma powierzyć Ci swoje dane. Poza tym raport obejmuje podstawy dostępności wokół formularzy: obrazy bez atrybutów alt, hierarchię nagłówków, po której poruszają się użytkownicy czytników ekranu, oraz błędy konsoli, które często zdradzają zepsute skrypty walidacji. Darmowy raport to szybki pierwszy przegląd strony, na której mieszka Twój formularz.