1 na 4 dorosłych Amerykanów żyje z jakąś formą niepełnosprawności. Jeśli Twój formularz nie jest dostępny, odcinasz ćwierć potencjalnych odbiorców, zanim w ogóle dotrą do przycisku wysyłania.
Dostępny formularz działa dla wszystkich. To znaczy dla osób korzystających wyłącznie z klawiatury. Dla osób słuchających przez czytniki ekranu. Dla osób słabowidzących. Dla osób z drżeniem rąk, które potrzebują więcej czasu na wypełnienie pól. Bez specjalnego projektu, bez dodatkowej złożoności. Po prostu formularz zbudowany tak, by wszystkie te osoby naprawdę mogły z niego korzystać.
Czytelne etykiety. Nawigacja klawiaturą. Komunikaty o błędach, które czytnik ekranu potrafi odczytać. Wystarczający kontrast, by osoby słabowidzące mogły przeczytać tekst. To nie są dodatkowe funkcje. To poziom podstawowy, którego od kwietnia 2026 wymagają WCAG 2.1 AA i amerykańska ustawa o niepełnosprawnych (ADA).
Czym dostępne formularze różnią się od zwykłych
Weź dowolny formularz kontaktowy, a znajdziesz te same błędy. Pole tekstowe z tekstem zastępczym, ale bez widocznej etykiety. Pole wyboru bez wyjaśnienia, co robi. Komunikat o błędzie czerwonym tekstem, którego czytnik ekranu nie odczyta.
Większość formularzy powstaje z myślą o osobach używających myszy, a dostępność dokładana jest później, jako dodatek. Dostępny formularz działa odwrotnie. Od początku zakłada, że ludzie będą z niego korzystać na różne sposoby. Jedni z myszą, inni tylko z klawiaturą. Jedni czytając, inni słuchając czytnika ekranu.
To zmienia sposób budowania formularza. Teksty zastępcze są bezużyteczne bez etykiet. Czerwone gwiazdki są bezużyteczne bez tekstu. Układ wizualny, który działa dla osób z myszą, może uwięzić osoby korzystające z klawiatury. Zbudowanie dostępnego formularza nie jest trudniejsze. Wymaga tylko myślenia o sposobach interakcji wykraczających poza mysz.
Dlaczego to ważne
Termin prawny. Tytuł II ustawy ADA wymaga WCAG 2.1 AA do 24 kwietnia 2026. Brak zgodności nie jest już ryzykiem. To bieżąca odpowiedzialność.
Wpływ na biznes. Odwiedzający z niepełnosprawnościami wydają prawdziwe pieniądze. Dostępny formularz zwiększa odsetek ukończeń u wszystkich, bo czytelne etykiety pomagają każdemu, nie tylko osobom z niepełnosprawnościami. Zapracowanym osobom przeglądającym telefon o 6 rano. Zaawansowanym użytkownikom nawigującym klawiaturą. Wszystkim.
Korzyść dla SEO. Wyszukiwarki preferują strony, na których elementy interaktywne są opisane i dają się obsłużyć klawiaturą. Dostępne formularze wyżej się pozycjonują.
Czego naprawdę potrzebują dostępne formularze
Widoczne etykiety przy każdym polu
Każde pole wprowadzania potrzebuje etykiety. Nie tekstu zastępczego, który znika. Nie atrybutu title. Prawdziwej etykiety widocznej na stronie.
Czytnik ekranu najpierw odczytuje etykietę, a potem typ pola. "Imię, pole tekstowe." Użytkownik wie, co robić. Bez etykiety słyszy tylko "pole tekstowe" i nic więcej. Nie ma pojęcia, co wpisać.
Dla osób widzących etykiety działają tak jak na papierze. Mówią, co wpisać w każdą rubrykę. Powiększają też obszar klikalny. Powiąż etykietę z polem za pomocą atrybutu for, a użytkownicy będą mogli kliknąć albo etykietę, albo pole, żeby je zaznaczyć. Na telefonie ten większy cel kliknięcia ma znaczenie.
Obsługa samą klawiaturą
Wiele osób nigdy nie dotyka myszy. Niepełnosprawność ruchowa, słabowzroczność, czytniki ekranu. Te osoby nawigują wyłącznie klawiaturą. Jeśli Twój formularz wymaga myszy, nie jest dostępny.
Przetestuj to. Odłącz mysz. Przejdź przez formularz samym klawiszem Tab, strzałkami i Enterem. Powinno się dać dotrzeć do każdego pola, wybrać każdą opcję i nacisnąć przycisk wysyłania bez odrywania rąk od klawiatury.
Obrys fokusa musi być widoczny na każdym kroku. Żadnych niewidocznych stanów fokusa. Użytkownicy muszą wiedzieć, w którym miejscu formularza są. Ważna jest też kolejność tabulacji. Pola powinny iść od lewej do prawej, od góry do dołu, tak jak formularz się czyta. Jeśli układ skacze albo ukrywa pola, kolejność tabulacji się psuje, a osoby korzystające z klawiatury się zaplątują.
Komunikaty o błędach, które naprawdę same się zgłaszają
Czerwony tekst na górze formularza nic nie znaczy dla osoby korzystającej z czytnika ekranu. Wysyła formularz, słyszy ciszę i próbuje ponownie. W końcu rezygnuje.
Powiąż błąd z konkretnym polem, w którym wystąpił. Gdy użytkownik czytnika ekranu przejdzie do tego pola, błąd zostanie odczytany. I niech komunikat mówi, co poprawić, a nie tylko "Nieprawidłowe". Zamiast "Nieprawidłowy wpis" napisz "E-mail musi zawierać znak @".
Użyj atrybutów ARIA, takich jak aria-describedby, żeby połączyć komunikat o błędzie z polem. Gdy fokus trafi na pole, czytnik ekranu automatycznie odczyta błąd. Bez zgadywania.
Czytelny tekst dla osób słabowidzących
Jasnoszare etykiety na białym tle są niewidoczne dla osoby słabowidzącej. WCAG 2.1 AA wymaga współczynnika kontrastu 4,5:1 dla zwykłego tekstu. Ciemny tekst na jasnym tle albo jasny tekst na ciemnym. Kontrast musi być wyraźny.
Większy tekst (18 punktów i więcej) może mieć kontrast 3:1. Cała reszta potrzebuje 4,5:1. Narzędzie do sprawdzania kontrastu zajmuje 5 sekund. Przepuść przez nie każdą etykietę, przycisk i komunikat o błędzie przed startem.
Nigdy nie oznaczaj pól wymaganych samym kolorem. Czerwona gwiazdka nic nie znaczy dla osoby z daltonizmem. Dodaj obok pola słowo "wymagane". Czytniki ekranu je odczytają. Osoby widzące je zobaczą. Tekst rozumieją wszyscy.
Wskazówki dla poszczególnych pól dostępnych formularzy
Pola tekstowe i obszary tekstowe
Imię, e-mail, telefon: wszystkie potrzebują etykiety bezpośrednio nad polem lub obok niego. Użyj elementu HTML <label> z atrybutem for, który odpowiada atrybutowi id pola.
Jeśli pole oczekuje konkretnego formatu, powiedz o tym. "Format: 555-123-4567" pomaga wszystkim, zwłaszcza osobom, którym lepiej służą jasne instrukcje.
Obszary tekstowe powinny wyglądać tak, jakby przyjmowały dłuższe odpowiedzi. Jednowierszowe pole z etykietą "Wiadomość" sugeruje krótką odpowiedź. Wyższe pole mówi "napisz więcej". Rozmiar ma znaczenie.
Listy rozwijane i przyciski opcji
Każda lista rozwijana potrzebuje etykiety. "Wybierz opcję" oraz "Tak/Nie" bez kontekstu są bezużyteczne. Użytkownik czytnika ekranu nie ma pojęcia, o co pytasz. Niech etykieta listy jasno mówi, jakiego wyboru dotyczy.
Przyciski opcji powinny być w grupie fieldset z legendą. Legenda zadaje pytanie. Opcje na nie odpowiadają. "Co najlepiej opisuje Twój przypadek użycia?" z opcjami takimi jak "E-commerce", "Media", "SaaS". Czytnik ekranu odczytuje legendę, a potem każdą opcję. Użytkownik rozumie, że wybiera z grupy i czemu ta grupa służy.
Pola wyboru
Etykieta pola wyboru powinna brzmieć naturalnie. "Akceptuję regulamin" jako etykieta, z polem obok. Nie samo pole bez tekstu, każące zgadywać, co robi.
Jeśli są informacje dodatkowe, jak link do pełnego regulaminu, umieść je tuż obok pola. Nie ukrywaj ich. Użytkownicy muszą wiedzieć, na co się zgadzają, zanim zaznaczą pole.
Grupy pól wyboru działają jak grupy przycisków opcji. Legenda nazywa grupę, a każda opcja ma własną etykietę.
Przyciski
Tekst przycisku powinien mówić, co się stanie. "Wyślij." "Zatwierdź." "OK" sprawdza się przy potwierdzeniach. "Dalej" bez kontekstu już nie. Żadnych ogólnikowych etykiet.
Jeśli masz kilka przycisków, zadbaj, by się różniły. "Anuluj" i "Wyślij" są jasne. Dwa przyciski z napisem "Dalej" nie są: użytkownik czytnika ekranu słyszy "przycisk dalej, przycisk dalej" i nie wie, który jest który.
Gdzie na stronie pojawiają się formularze
Formularze kontaktowe w wyskakujących oknach. Zapisy do newslettera w stopkach. Formularze darowizn na stronach o misji. Ankiety w trakcie zamówienia. Każdy formularz, gdziekolwiek, musi być dostępny.
Formularze w wyskakujących oknach tworzą pułapkę fokusa, jeśli nie zadbasz o jego obsługę. Gdy otwiera się okno modalne, fokus przeskakuje do niego. Gdy się zamyka, fokus wraca do przycisku, który je otworzył. Bez tego osoby korzystające z klawiatury utkną, przechodząc tabulatorem przez stronę w tle.
Na długich stronach z formularzami niżej dodaj link pomijający nawigację. Osoby korzystające z klawiatury nie powinny musieć przechodzić tabulatorem przez 50 pozycji menu, by dotrzeć do formularza.
Częste błędy
Poleganie na tekście zastępczym zamiast etykiet
Tekst zastępczy "Wpisz swój e-mail" znika w chwili, gdy ktoś zaczyna pisać. Wtedy nie wiadomo już, do czego służyło pole. Czytniki ekranu w ogóle go nie widzą.
Użyj prawdziwej etykiety. Jeśli chcesz tekstu zastępczego jako podpowiedzi formatu, w porządku. Ale nigdy nie używaj go jako samej etykiety.
Oznaczanie pól wymaganych samym kolorem
Czerwona gwiazdka jest niewidoczna dla osób z daltonizmem. Ikona jest niewidoczna dla czytników ekranu. Użyj słowa "wymagane" w tekście. Tekst rozumieją wszyscy.
Pomijanie testów ręcznych
Właściwa struktura HTML na papierze nie oznacza, że formularz działa w rzeczywistości. Etykiety mogą być umieszczone za daleko od pól. Obrysy fokusa mogą być niewidoczne. Komunikaty o błędach mogą być odczytywane, ale nie przenosić fokusa do pola.
Testuj klawiaturą. Testuj czytnikiem ekranu. Istnieją darmowe czytniki ekranu, a w branży standardem są płatne. Na iOS użyj wbudowanego czytnika, jeśli testujesz tam formularze. Automatyczne narzędzia wychwytują oczywiste problemy. Prawdziwe testy wychwytują resztę.
Dodawanie limitów czasu
Osoba z drżeniem rąk pisze wolno. Użytkownik czytnika ekranu potrzebuje czasu, by wysłuchać wszystkich etykiet i instrukcji. Pięciominutowy limit uwięzi osoby, które potrzebują 10 minut.
Jeśli możesz, usuń limity czasu. Jeśli musisz je mieć, pozwól użytkownikom dwukrotnie wydłużyć czas przed końcem sesji.
Jak WEMASY buduje dostępne formularze
Formularze WEMASY są dostępne od początku, a nie jako dodatek. Każdy szablon zawiera poprawne etykiety. Fokus jest zarządzany automatycznie. Błędy są odczytywane czytnikom ekranu. Kontrast kolorów domyślnie spełnia WCAG 2.1 AA.
Dostosowuj bez psucia dostępności. Dodawaj pola, zmieniaj etykiety, przestawiaj układ. Podstawowa struktura pozostaje dostępna. Wbudowana walidacja ogłasza błędy czytnikom ekranu.
Dowiedz się więcej w naszym kompletnym przewodniku po formularzach albo zobacz, co zawiera każdy pakiet WEMASY.