Jak tworzyć dostępne formularze: etykiety, błędy i walidacja

Według WebAIM, 48.6% stron głównych serwisów internetowych ma brakujące etykiety pól formularzy — co sprawia, że nieopisane pola są jednym z najczęstszych pojedynczych błędów dostępności w sieci. Pomyśl, co to oznacza w praktyce: użytkownik czytnika ekranu trafia na Twój formularz kontaktowy, naciska Tab, aby przechodzić między polami, i słyszy tylko „edit text” raz za razem. Czytniki ekranu odczytują etykiety pól formularzy — bez nich użytkownicy słyszą „edit text” bez kontekstu i nie wiedzą, jakie informacje powinni wprowadzić. Formularze są często najbardziej krytyczną biznesowo częścią strony — procesy zakupowe, ekrany rejestracji, strony kontaktowe, zgłoszenia do supportu — a mimo to pozostają jednymi z najbardziej konsekwentnie zepsutych doświadczeń dla osób korzystających z technologii asystujących.

Dlaczego dostępność formularzy ma większe znaczenie, niż myślisz

Biorąc pod uwagę, że 1 na 4 dorosłych w USA żyje z niepełnosprawnością, dostępna walidacja formularzy nie jest opcjonalna; jest niezbędna. Ta grupa obejmuje osoby niewidome lub słabowidzące, osoby z niepełnosprawnościami ruchowymi polegające na nawigacji klawiaturą, osoby z niepełnosprawnościami poznawczymi, które potrzebują jasnych instrukcji, oraz osoby korzystające z oprogramowania sterowanego głosem do wypełniania formularzy. Każde pole bez etykiety, każdy niejasny komunikat o błędzie i każdy wzorzec walidacji opierający się wyłącznie na kolorze to drzwi, które po cichu zamykają się przed znaczną częścią Twojej publiczności.

Większość użytkowników z niepełnosprawnościami napotyka błędy podczas wysyłania informacji i nie otrzymuje jasnych instrukcji, jak je naprawić — pozostawiając im dwie opcje: porzucić próbę i poszukać bardziej dostępnego formularza albo poprosić o pomoc kogoś innego, z których żadna nie jest idealnym doświadczeniem. Z perspektywy biznesowej dostępne formularze poprawiają doświadczenie użytkownika, zmniejszają współczynnik porzuceń i spełniają wymagania prawne. Z perspektywy zgodności WCAG 1.3.1 (Informacje i relacje) oraz 4.1.2 (Nazwa, rola, wartość) to wymagania na poziomie A, które istnieją od czasu uruchomienia WCAG 2.0 w 2008 roku. To nie są przypadki brzegowe ani zaawansowane techniki — to podstawowe oczekiwania standardu.

Według raportu WebAIM Million brakujące etykiety formularzy konsekwentnie znajdują się wśród najczęstszych błędów dostępności w sieci, a badania nad błędami wdrożeniowymi pokazują dlaczego: organizacje skupiają się na złożonych rozwiązaniach, ignorując podstawowe wzorce, które umożliwiłyby osobom z niepełnosprawnościami faktyczne korzystanie z ich usług. Dobrą wiadomością jest to, że naprawa większości z tych problemów nie wymaga niczego egzotycznego — tylko przemyślanego, świadomego HTML.

Kryteria sukcesu WCAG regulujące formularze

Zanim przejdziemy do implementacji, warto wiedzieć, które konkretne kryteria sukcesu WCAG mają zastosowanie do formularzy. Wytyczne dotyczące dostępności treści internetowych (WCAG) określają cztery kluczowe zasady — Postrzegalność, Funkcjonalność, Zrozumiałość i Solidność (POUR) — które stanowią kręgosłup inkluzywnych systemów walidacji. W ramach tej struktury kilka kryteriów sukcesu odnosi się bezpośrednio do projektowania formularzy.

Najistotniejsze kryteria obejmują: 1.3.1 Informacje i relacje (poziom A), które wymagają, aby informacje, struktura i relacje przekazywane poprzez prezentację mogły być określone programowo; 2.4.6 Nagłówki i etykiety (poziom AA), które stanowią, że nagłówki i etykiety opisują temat lub cel; 3.3.2 Etykiety lub instrukcje (poziom A), które wymagają, aby etykiety lub instrukcje były dostarczone, gdy treść wymaga wprowadzenia danych przez użytkownika; oraz 4.1.2 Nazwa, rola, wartość (poziom A), które wymagają, aby dla wszystkich komponentów interfejsu użytkownika nazwa i rola mogły być określone programowo.

Przestrzegając wytycznych WCAG 3.3.1 do 3.3.4, które obejmują identyfikację błędów, instrukcje, sugestie i zapobieganie, tworzysz formularze, które są łatwiejsze i bardziej intuicyjne dla wszystkich użytkowników. To nie są arbitralne przeszkody — każde kryterium odzwierciedla realną potrzebę użytkownika. Zrozumienie „dlaczego” stojącego za każdą regułą sprawia, że znacznie łatwiej jest ją poprawnie wdrożyć i podejmować rozsądne decyzje w przypadkach brzegowych.

Poprawne etykiety: fundament dostępnych formularzy

Etykieta to nie tylko wizualna podpowiedź. To programistyczne połączenie między tekstowym opisem a kontrolką formularza i podstawowy mechanizm, dzięki któremu technologie asystujące identyfikują, do czego służy dane pole. Najbardziej solidnym sposobem stworzenia tego połączenia jest użycie elementu HTML <label> i jego atrybutu for, wskazującego na odpowiadający mu id pola.

<!-- Źle: Sam placeholder nie jest dostępną etykietą -->
<input type='email' placeholder='Email address'>

<!-- Dobrze: Jawna etykieta powiązana przez for/id -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email'>

Etykiety powinny być zawsze widoczne — nie tylko jako placeholdery. Placeholder znika, gdy użytkownik zaczyna pisać, pozostawiając brak kontekstu. To niezwykle istotne rozróżnienie. Tekst placeholdera nigdy nie był zaprojektowany jako etykieta; znika w momencie, gdy użytkownik zaczyna pisać, często ma niewystarczający kontrast kolorystyczny, a wiele czytników ekranu nie udostępnia go w sposób niezawodny jako dostępnej nazwy pola. Poleganie wyłącznie na placeholderach zawodzi użytkowników na całej linii — nie tylko tych korzystających z technologii asystujących.

Gdy masz grupy powiązanych pól — takich jak zestaw przycisków opcji (radio) lub blok pól wyboru (checkbox) — poprawnym wzorcem jest <fieldset> i <legend>. Grupuj powiązane opcje, takie jak pola wyboru i przyciski opcji, za pomocą fieldset i legend, aby ułatwić zrozumienie złożonych formularzy.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type='radio' id='contact-email' name='contact' value='email'>
  <label for='contact-email'>Email</label>

  <input type='radio' id='contact-phone' name='contact' value='phone'>
  <label for='contact-phone'>Phone</label>
</fieldset>

W sytuacjach, gdy widoczna etykieta byłaby wizualnie redundantna — na przykład pojedyncze pole wyszukiwania obok wyraźnie opisanego przycisku Search — możesz użyć aria-label lub aria-labelledby, aby zapewnić dostępną nazwę bez wyświetlania widocznego tekstu. Używaj tego jednak oszczędnie. Osoby korzystające z czytników ekranu mogą łatwiej identyfikować i rozumieć kontrolki formularzy, ponieważ są one powiązane z etykietami, fieldsetami i innymi elementami strukturalnymi — a widoczne etykiety są korzystne dla wszystkich, w tym dla widzących użytkowników z niepełnosprawnościami poznawczymi, użytkowników powiększających widok do 400% oraz każdego, kto na chwilę zgubił miejsce w długim formularzu.

Ponadto pola wymagane muszą być oznaczone wizualnie i programowo, przy użyciu atrybutu required lub aria-required. Sam czerwon y asterysk nie jest wystarczający — umieść na górze formularza krótką notatkę w stylu „Pola oznaczone * są wymagane” i upewnij się, że atrybut required znajduje się w znacznikach, aby technologie asystujące mogły ogłosić pole jako wymagane, gdy użytkownik na nim się skupi.

Pisanie komunikatów o błędach, które naprawdę pomagają

Komunikaty o błędach to miejsce, w którym większość formularzy zawodzi użytkowników w drugi, potęgujący sposób. Po wysłaniu formularza, który wywołuje błędy walidacji, użytkownik musi wiedzieć trzy rzeczy: że wystąpił błąd, które pole go spowodowało i co musi zrobić, aby go naprawić. Większość błędów formularzy odpowiada tylko na pierwsze z tych pytań — i nawet to robi źle.

Niejasne komunikaty o błędach, takie jak „Invalid input” lub „Error”, nie mówią użytkownikom, co poszło nie tak ani jak to poprawić. Każdy komunikat o błędzie powinien identyfikować konkretny problem i sugerować konkretne rozwiązanie.

Aby zapewnić kompatybilność z czytnikami ekranu, komunikaty o błędach powinny być zintegrowane z DOM przy użyciu atrybutów ARIA, takich jak aria-invalid="true" i aria-describedby, które łączą komunikaty o błędach bezpośrednio z odpowiadającymi im polami formularza. Tak wygląda poprawnie oznaczony stan błędu:

<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
>
<span id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</span>

Atrybut aria-invalid="true" informuje czytnik ekranu, że pole zawiera obecnie nieprawidłową wartość. Atrybut aria-describedby wskazuje element zawierający komunikat o błędzie, który czytnik ekranu odczyta, gdy użytkownik skupi się na tym polu. Atrybut role="alert" na elemencie span z błędem powoduje, że komunikat jest ogłaszany natychmiast po wstrzyknięciu do DOM, bez konieczności nawigowania do niego przez użytkownika.

W minimalistycznym projekcie kuszące jest użycie wyłącznie czerwonego koloru, aby wyrazić, że pole jest nieprawidłowe — ale używanie wyłącznie koloru nie jest wystarczające, co potwierdza WCAG 1.4.1 Użycie koloru, ponieważ ludzie postrzegają kolor na różne sposoby i ten czerwony kolor nie zostanie zauważony przez wszystkich. Rozwiązaniem jest uzupełnienie kolorowego stanu błędu dodatkowym elementem wizualnym — może to być ikona, ale nawet to może nie wystarczyć, aby zrozumieć, dlaczego pole jest nieprawidłowe, więc najbardziej inkluzywnym rozwiązaniem jest wyraźne wyświetlenie komunikatu tekstowego.

Konkretne komunikaty o błędach są szczególnie pomocne dla użytkowników z wyzwaniami poznawczymi, obniżoną koncentracją lub korzystających z czytników ekranu — ponieważ źle napisane informacje zwrotne mogą prowadzić do frustracji, a nawet skłonić użytkowników do porzucenia formularza. Pisz komunikaty o błędach z perspektywy użytkownika: co miał wprowadzić i jak może to poprawić teraz, od razu?

Moment walidacji i zarządzanie fokusem

To, kiedy walidujesz, jest równie ważne jak to, jak walidujesz. Wywołaj błędy zbyt wcześnie — na przykład, gdy użytkownik wciąż pisze — a ryzykujesz przerwanie jego przepływu przedwczesnymi skargami. Wywołaj błędy dopiero przy wysłaniu i możesz zostawić użytkownika przewijającego długi formularz w poszukiwaniu pól wymagających uwagi. Właściwą odpowiedzią jest podejście warstwowe.

Połącz informacje zwrotne w czasie rzeczywistym dla krytycznych pól, sprawdzanie przy utracie fokusu (on-blur) dla pól o określonym formacie oraz walidację przy wysłaniu dla kompleksowego przeglądu błędów. W praktyce oznacza to: waliduj złożone formaty, takie jak hasła czy adresy e-mail, gdy użytkownik opuszcza pole (on blur); unikaj przerywania pracy użytkownika walidacją inline wywoływaną przy każdym naciśnięciu klawisza; a przy wysłaniu formularza wykonaj pełne sprawdzenie i jasno zakomunikuj wszystkie błędy naraz.

Po wysłaniu automatycznie skieruj fokus na pierwszy błąd, aby efektywnie poprowadzić użytkowników. Jeśli błędów jest wiele, najbardziej dostępnym wzorcem jest przeniesienie fokusu do podsumowania na górze formularza, które wymienia wszystkie błędy jako linki prowadzące do odpowiednich pól. Dzięki temu użytkownik słyszy podsumowanie błędów natychmiast po wysłaniu, może zrozumieć pełen zakres tego, co wymaga poprawy, i przejść bezpośrednio do każdego problemu.

<!-- Podsumowanie błędów umieszczone na górze formularza, fokus ustawiany programowo -->
<div id='error-summary' role='alert' tabindex='-1'>
  <h2>2 errors found. Please correct the following:</h2>
  <ul>
    <li><a href='#email'>Email address: Please enter a valid email</a></li>
    <li><a href='#phone'>Phone number: Please use the format (555) 555-5555</a></li>
  </ul>
</div>

Upewnij się, że użytkownicy mogą nawigować po formularzach bez użycia myszy, z logiczną kolejnością tabulacji i widocznymi wskaźnikami fokusu. Domyślny obrys fokusu przeglądarki jest prawną i funkcjonalną podstawą — ale wiele zespołów projektowych usuwa go za pomocą outline: none w CSS, nie zapewniając zamiennika. To sprawia, że formularz staje się w praktyce bezużyteczny dla użytkowników korzystających wyłącznie z klawiatury. Wyraźny, o wysokim kontraście wskaźnik fokusu jest wymagany przez WCAG 2.4.7 (poziom AA) oraz bardziej rygorystyczne 2.4.11 w WCAG 2.2. Jeśli wytyczne Twojej marki kolidują z domyślnym obrysem fokusu, zastąp go — nie usuwaj.

Instrukcje i podpowiedzi zanim pojawią się błędy

Najlepszy błąd formularza to ten, który nigdy nie musi się pojawić. Dobrze umieszczone instrukcje i podpowiedzi zapobiegają błędom w pierwszej kolejności, co jest lepsze dla każdego użytkownika. Pola wymagane lub pola wymagające określonego formatu, wartości lub długości powinny przekazywać te informacje w etykiecie elementu lub w programowo powiązanych instrukcjach.

Etykieta pola jest pierwszą wizualną instrukcją dotyczącą tego, co należy wypełnić, a w razie potrzeby następuje po niej opis. W ten sam sposób, w jaki widzący użytkownicy mogą zobaczyć opis, użytkownicy czytników ekranu również muszą być go świadomi — możesz połączyć opis z polem, używając atrybutu aria-describedby, który przyjmuje id wskazujące na element opisu, powodując, że czytnik ekranu automatycznie odczyta opis, gdy użytkownik skupi się na polu.

<label for='phone'>Phone number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-hint'
>
<span id='phone-hint'>Format: (555) 555-5555</span>

Jeśli to możliwe, podawaj przykłady, aby doprecyzować oczekiwania — na przykład, jeśli pole daty wymaga formatu MM/DD/YYYY, dołącz przykład w stylu „Wpisz datę w formacie 12/25/2024”. W przypadku pól hasła podaj wymagania z wyprzedzeniem, zamiast ujawniać je po kolei, gdy użytkownik narusza każdą regułę. Jeśli to możliwe, formularze nie powinny być ograniczone limitem czasu, aby umożliwić użytkownikom wypełnienie formularza we własnym tempie — a jeśli limit czasu musi obowiązywać, użytkownik powinien mieć możliwość jego wyłączenia lub wydłużenia.

Atrybut autocomplete to kolejny często pomijany mechanizm dostępności. Ustawienie wartości takich jak autocomplete="email", autocomplete="given-name" czy autocomplete="street-address" umożliwia przeglądarkom i menedżerom haseł prawidłowe automatyczne wypełnianie pól, co dramatycznie zmniejsza obciążenie użytkowników z niepełnosprawnościami ruchowymi, niepełnosprawnościami poznawczymi lub każdego, dla kogo powtarzalne pisanie jest trudne. WCAG 1.3.5 (Identyfikacja celu wprowadzania danych, poziom AA) wymaga tego dla pól zbierających dane osobowe.

Testowanie formularzy pod kątem dostępności

Znajomość zasad to jedno; wiedza, czy Twoje formularze faktycznie ich przestrzegają, to co innego. Najbardziej niezawodnym podejściem jest strategia łączona. Choć narzędzia takie jak Lighthouse i WAVE mogą pomóc w automatycznym wykrywaniu problemów, testy manualne z użyciem samej klawiatury i czytników ekranu są niezbędne do wychwycenia problemów z użytecznością w rzeczywistych warunkach.

Do testów klawiatury po prostu odłącz mysz i spróbuj wypełnić formularz. Powinieneś móc dotrzeć do każdego pola, aktywować każdy przycisk i otrzymać każdy komunikat o błędzie, używając tylko Tab, Shift+Tab, klawiszy strzałek oraz Enter/Spacji. Jeśli utkniesz, to jest porażka. Do testów z czytnikiem ekranu użyj NVDA z Firefoxem w systemie Windows lub VoiceOver z Safari w macOS. Czytniki ekranu zachowują się nieco inaczej — mają różne skróty, różne komunikaty semantyczne i różne wsparcie funkcji; na przykład NVDA działa lepiej z Firefoxem, podczas gdy VoiceOver najlepiej współpracuje z Safari. Testowanie co najmniej dwóch kombinacji pozwoli wychwycić najszerszy zakres problemów.

Narzędzia takie jak WAVE i Axe świetnie nadają się do skanowania formularzy pod kątem brakujących etykiet, nieprawidłowych atrybutów ARIA i słabego kontrastu kolorów. Te zautomatyzowane narzędzia można zintegrować bezpośrednio z pipeline’em CI/CD, aby wychwytywać regresje, zanim trafią na produkcję. Ponieważ wytyczne dotyczące dostępności są złożone, narzędzia automatyczne mogą wykryć jedynie około 30% problemów WCAG — dlatego warstwa automatyczna musi być uzupełniona przeglądem manualnym i, najlepiej, testami z udziałem rzeczywistych użytkowników polegających na technologiach asystujących.

Podczas ręcznego przeglądu znaczników zadaj następujące pytania dla każdego pola formularza: Czy ma widoczną etykietę? Czy ta etykieta jest powiązana programowo przez for/id lub ARIA? Czy tekst podpowiedzi jest połączony za pomocą aria-describedby? Czy każdy stan błędu ustawia aria-invalid="true" i odwołuje się do komunikatu o błędzie przez aria-describedby? Czy atrybut required jest obecny w polach wymaganych? Czy możesz dotrzeć do każdego interaktywnego elementu i obsłużyć go wyłącznie klawiaturą?

Najważniejsze wnioski

• Każde pole wejściowe potrzebuje programistycznej etykiety. Używaj <label for='...'> dla wszystkich pól formularza — nigdy nie polegaj wyłącznie na tekście placeholdera. Każde pole formularza potrzebuje programistycznej etykiety, bez wyjątków — tekst placeholdera nie jest etykietą.
• Komunikaty o błędach muszą nazwać problem i zasugerować rozwiązanie. Komunikaty o błędach muszą identyfikować problem i sugerować, jak go naprawić, i powinny być powiązane ze swoimi polami za pomocą aria-describedby.
• Nigdy nie polegaj wyłącznie na kolorze. Nie polegaj wyłącznie na kolorze przy żadnej informacji o statusie — używaj tekstu, ikon i innych wskaźników niezwiązanych z kolorem obok sygnałów kolorystycznych.
• Zarządzaj fokusem po wysłaniu. Błąd powinien być wyraźnie zidentyfikowany, powinien być zapewniony szybki dostęp do problematycznego elementu, a użytkownik powinien móc łatwo naprawić błąd i ponownie wysłać formularz. Przeniesienie fokusu do podsumowania błędów po nieudanym wysłaniu jest złotym standardem.
• Testuj prawdziwymi narzędziami, nie tylko założeniami. Utrzymanie dostępności formularzy nie jest jednorazowym zadaniem — wymaga regularnych testów i aktualizacji, aby pozostały zgodne z wytycznymi i przyjazne użytkownikom. Łącz automatyczne skanowanie z nawigacją wyłącznie klawiaturą i testami z czytnikami ekranu przy każdej istotnej aktualizacji formularza.