Formularz może wyglądać poprawnie, a mimo to być trudny albo niemożliwy do użycia. Problem często nie ujawnia się podczas zwykłego oglądania strony. Pojawia się dopiero wtedy, gdy użytkownik próbuje przejść przez pola za pomocą klawiatury, popełnia błąd, zwiększa rozmiar tekstu albo korzysta z czytnika ekranu.
Nie każdy pracownik urzędu, redaktor serwisu czy właściciel strony dysponuje specjalistycznym oprogramowaniem do audytu dostępności. Podstawowe problemy można jednak wykryć samodzielnie. Wystarczy przejść przez formularz krok po kroku i sprawdzić, czy użytkownik rozumie, czego się od niego oczekuje, może wprowadzić dane bez użycia myszy i otrzymuje jasną informację o błędach.
Taki test nie zastępuje pełnego audytu WCAG, ale pozwala wychwycić bariery, które najczęściej blokują wysłanie formularza.
Zacznij od celu formularza
Przed testowaniem warto ustalić, do czego formularz służy i co użytkownik powinien zrobić po jego otwarciu. Inaczej ocenia się prosty formularz kontaktowy, inaczej zapis na wydarzenie, wniosek elektroniczny, zgłoszenie usterki albo rezerwację wizyty.
Użytkownik powinien od razu wiedzieć, jaki jest cel formularza, ile informacji musi podać i co stanie się po jego wysłaniu. Jeśli formularz jest wieloetapowy, należy wskazać liczbę kroków oraz aktualny etap.
Niejasny początek procesu zwiększa ryzyko porzucenia formularza. Użytkownik nie powinien dopiero po kilku minutach odkrywać, że potrzebuje dodatkowego dokumentu, numeru sprawy albo danych, których nie ma pod ręką.
Przed pierwszym polem warto zamieścić krótką informację o wymaganych danych, czasie potrzebnym na wypełnienie i sposobie dalszej obsługi zgłoszenia.
Każde pole powinno mieć widoczną etykietę
Najprostszym testem jest sprawdzenie, czy przy każdym polu znajduje się jasna nazwa. Użytkownik musi wiedzieć, czy ma wpisać imię, adres e-mail, numer telefonu, nazwę instytucji czy treść zgłoszenia.
Tekst umieszczony wewnątrz pola nie powinien być jedyną etykietą. Po rozpoczęciu wpisywania znika i użytkownik może przestać pamiętać, czego dotyczyło pole. Problem nasila się w długich formularzach i na telefonach, gdzie widoczny jest tylko niewielki fragment strony.
Etykieta powinna pozostać widoczna również po wpisaniu danych. Powinna być krótka, jednoznaczna i umieszczona blisko właściwego pola.
Nie należy zastępować etykiet samymi ikonami. Symbol koperty może sugerować adres e-mail, ale nie dla każdego będzie oczywisty. Ikona bez opisu może również nie zostać prawidłowo rozpoznana przez technologię wspomagającą.
Instrukcja musi pojawić się przed wykonaniem czynności
Jeżeli pole wymaga określonego formatu, użytkownik powinien otrzymać tę informację przed wpisaniem danych. Dotyczy to dat, numerów telefonów, kodów pocztowych, numerów spraw, haseł i załączników.
Zamiast czekać, aż użytkownik popełni błąd, lepiej wcześniej podać przykład lub krótką instrukcję. Informacja „Data w formacie dzień-miesiąc-rok” jest bardziej użyteczna niż komunikat o błędzie wyświetlony dopiero po wysłaniu formularza.
Instrukcja powinna być widoczna i powiązana z właściwym polem. Nie należy umieszczać wszystkich objaśnień w jednym długim akapicie na początku strony, jeśli później trudno ustalić, którego pola dotyczą.
W formularzach z hasłami wymagania powinny być opisane przed rozpoczęciem wpisywania. Użytkownik musi wiedzieć, czy hasło wymaga określonej długości, cyfr, znaków specjalnych lub innych elementów.
Pola obowiązkowe trzeba oznaczyć jednoznacznie
Formularz powinien jasno wskazywać, które pola są obowiązkowe, a które opcjonalne. Sama gwiazdka może nie wystarczyć, jeżeli nie wyjaśniono jej znaczenia.
Dobrą praktyką jest zamieszczenie przed formularzem informacji, że pola oznaczone określonym symbolem są wymagane. Jeszcze czytelniejszym rozwiązaniem może być użycie słowa „wymagane” przy konkretnym polu.
Nie należy oznaczać obowiązkowości wyłącznie kolorem. Czerwone obramowanie albo czerwona etykieta może być trudna do zauważenia przez osoby z zaburzeniami rozpoznawania barw. Informacja powinna być przekazana również tekstowo.
Warto także sprawdzić, czy formularz nie żąda danych, które nie są rzeczywiście potrzebne. Każde dodatkowe pole wydłuża proces, zwiększa ryzyko błędu i może budzić wątpliwości dotyczące zakresu zbieranych informacji.
Przejdź cały formularz za pomocą klawiatury
Jednym z najważniejszych testów jest odłożenie myszy i przejście przez formularz klawiszem Tab. Fokus powinien kolejno przechodzić przez wszystkie pola, przyciski, pola wyboru i inne elementy interaktywne.
Aktualnie wybrany element musi być wyraźnie widoczny. Jeśli użytkownik nie wie, gdzie znajduje się fokus, nie jest w stanie bezpiecznie obsługiwać formularza.
Kolejność przechodzenia powinna odpowiadać logicznemu układowi pól. Fokus nie może przeskakiwać z początku formularza na koniec, wracać do wcześniejszych elementów ani trafiać do niewidocznych części strony.
Każde pole powinno dać się wypełnić bez myszy. Listy rozwijane, pola wyboru, przyciski radiowe, kalendarze i mechanizmy dodawania załączników również muszą działać z klawiatury.
Szczególną uwagę trzeba zwrócić na niestandardowe elementy. Graficzny kalendarz może wyglądać nowocześnie, ale jeśli nie można w nim wybrać daty klawiaturą, staje się barierą. Użytkownik powinien mieć możliwość wpisania daty ręcznie albo skorzystania z dostępnej alternatywy.
Sprawdź, czy fokus nie zostaje uwięziony
Podczas testu klawiaturą może się zdarzyć, że fokus wejdzie do określonego elementu i nie da się z niego wyjść. Taka sytuacja nazywana jest pułapką klawiatury.
Problem może wystąpić w kalendarzu, oknie modalnym, mechanizmie dodawania pliku, rozwijanej liście albo polu z automatycznymi podpowiedziami. Użytkownik powinien móc przejść dalej za pomocą standardowych klawiszy albo zamknąć dodatkowy element.
Jeżeli formularz otwiera okno modalne, fokus powinien zostać przeniesiony do tego okna i pozostać w nim do momentu zamknięcia. Po zamknięciu powinien wrócić do elementu, który uruchomił okno.
Nie może dojść do sytuacji, w której użytkownik naciska Tab, ale fokus przechodzi po elementach ukrytych pod otwartym oknem.
Wywołaj błędy celowo
Formularza nie należy testować wyłącznie przy prawidłowo wpisanych danych. Najważniejsze bariery często pojawiają się dopiero po popełnieniu błędu.
Warto pozostawić obowiązkowe pole puste, wpisać nieprawidłowy adres e-mail, użyć niewłaściwego formatu daty albo dodać niedozwolony plik. Następnie trzeba sprawdzić, jak formularz reaguje.
Komunikat powinien jasno wskazywać, co jest nieprawidłowe i jak naprawić problem. Informacja „Błąd formularza” nie pomaga użytkownikowi. Znacznie lepszy jest komunikat „Wpisz adres e-mail w formacie [nazwa@domena.pl](mailto:nazwa@domena.pl)”.
Błąd powinien być przedstawiony przy właściwym polu oraz w sposób możliwy do zauważenia. Sama zmiana koloru obramowania nie wystarcza.
Jeżeli błędów jest kilka, formularz może wyświetlić ich podsumowanie na początku. Każdy komunikat powinien prowadzić do odpowiedniego pola lub jednoznacznie je wskazywać.
Formularz nie może usuwać poprawnych danych
Po wykryciu błędu użytkownik nie powinien tracić informacji wpisanych w pozostałych polach. Konieczność ponownego wypełnienia całego formularza jest szczególnie uciążliwa dla osób korzystających z klawiatury, technologii wspomagających albo urządzeń mobilnych.
Problem może dotyczyć również załączników. Jeśli formularz odrzuci jeden plik, nie powinien bez potrzeby usuwać wszystkich pozostałych.
W formularzu wieloetapowym powrót do wcześniejszego kroku nie powinien kasować danych. Użytkownik musi mieć możliwość poprawienia jednej informacji bez rozpoczynania całego procesu od początku.
Utrata danych obniża zaufanie do serwisu i zwiększa ryzyko, że użytkownik zrezygnuje z wysłania zgłoszenia.
Sprawdź komunikaty dynamiczne
Niektóre formularze reagują na działania bez przeładowania strony. Po wybraniu opcji pojawiają się nowe pola, po dodaniu pliku wyświetla się jego nazwa, a po wysłaniu formularza pojawia się potwierdzenie.
Taki komunikat może być widoczny, ale niedostępny dla użytkownika czytnika ekranu, jeśli technologia wspomagająca nie otrzyma informacji o zmianie.
Bez specjalistycznych narzędzi trudno sprawdzić wszystkie aspekty techniczne, ale można ocenić podstawową logikę. Nowe pole powinno pojawić się w przewidywalnym miejscu, a użytkownik powinien wiedzieć, że formularz się zmienił.
Po dodaniu załącznika musi być widoczna jego nazwa, rozmiar lub status. Po usunięciu pliku użytkownik powinien otrzymać potwierdzenie.
Po wysłaniu formularza powinien pojawić się wyraźny komunikat o powodzeniu albo błędzie. Użytkownik nie może zastanawiać się, czy zgłoszenie zostało zapisane.
Potwierdzenie wysłania musi być jednoznaczne
Po prawidłowym wysłaniu formularza użytkownik powinien otrzymać jasną informację o zakończeniu procesu. Komunikat powinien potwierdzać, że dane zostały przyjęte, i wskazywać, co wydarzy się dalej.
W zależności od rodzaju formularza może zawierać numer zgłoszenia, przewidywany termin odpowiedzi, informację o wiadomości e-mail albo dane kontaktowe do właściwej komórki.
Nie wystarczy wyczyścić pól albo przenieść użytkownika na stronę główną. Taki mechanizm nie daje pewności, czy formularz został wysłany.
Jeżeli system wysyła potwierdzenie e-mailem, komunikat na stronie powinien o tym informować. Warto również wskazać, co zrobić, jeśli wiadomość nie dotrze.
Przy formularzach wywołujących skutki prawne lub finansowe potwierdzenie powinno być możliwe do zapisania albo pobrania.
Sprawdź formularz po powiększeniu
Po zwiększeniu tekstu lub powiększeniu strony formularz powinien nadal działać. Etykiety nie mogą nachodzić na pola, komunikaty błędów nie powinny być ucinane, a przyciski muszą pozostawać widoczne.
Warto zwrócić uwagę na układy wielokolumnowe. Formularz, który na komputerze umieszcza imię i nazwisko obok siebie, po powiększeniu powinien ułożyć pola jedno pod drugim.
Nie należy wymuszać poziomego przewijania całej strony. Użytkownik powinien móc odczytać etykietę, wpisać dane i przejść do kolejnego pola bez przesuwania widoku na boki.
Powiększenie często ujawnia sztywne wysokości elementów. Tekst instrukcji może nie zmieścić się w przeznaczonym obszarze, a przycisk może uciąć część etykiety.
Przetestuj formularz na telefonie
Formularz działający na komputerze może być bardzo trudny do obsługi na telefonie. Klawiatura ekranowa zajmuje część widoku, małe przyciski są trudne do dotknięcia, a komunikaty błędów mogą pojawiać się poza widocznym obszarem.
Aktywne pole powinno pozostać widoczne po otwarciu klawiatury. Użytkownik musi jednocześnie widzieć jego etykietę i wpisywaną treść.
Przyciski powinny mieć odpowiedni obszar aktywny. Pola wyboru i opcje nie mogą być rozmieszczone zbyt blisko siebie.
Warto sprawdzić, czy formularz pokazuje właściwy rodzaj klawiatury. Pole numeru telefonu powinno ułatwiać wpisywanie cyfr, a pole adresu e-mail zapewniać łatwy dostęp do znaku „@”.
Trzeba również obrócić urządzenie i sprawdzić formularz w orientacji poziomej. Okna, paski i przyklejone elementy nie mogą zasłaniać aktywnego pola ani przycisku wysyłania.
Załączniki wymagają jasnych zasad
Jeżeli formularz umożliwia dodawanie plików, użytkownik powinien wcześniej wiedzieć, jakie formaty i rozmiary są dozwolone. Informacja nie może pojawić się dopiero po nieudanej próbie wysłania.
Przycisk dodawania załącznika powinien mieć jednoznaczną nazwę. Sam symbol spinacza może być niewystarczający.
Po wybraniu pliku formularz powinien wyświetlić jego nazwę i umożliwić usunięcie. Jeśli przesyłanie trwa, użytkownik powinien otrzymać informację o postępie lub statusie.
Komunikat o odrzuceniu pliku musi wskazywać przyczynę. Może to być zbyt duży rozmiar, niedozwolony format albo błąd techniczny.
Nie należy wymagać przeciągania pliku jako jedynej metody dodawania dokumentu. Powinna być dostępna standardowa możliwość wyboru pliku z urządzenia.
Zgody i oświadczenia muszą być zrozumiałe
Pola wyboru dotyczące zgód, regulaminów i oświadczeń powinny być opisane pełnym, zrozumiałym tekstem. Użytkownik musi wiedzieć, co zatwierdza.
Nie należy stosować domyślnie zaznaczonych zgód, jeżeli wymagają one świadomego działania użytkownika. Nie powinno się również łączyć kilku odrębnych oświadczeń w jednym polu wyboru.
Link do regulaminu lub informacji o przetwarzaniu danych powinien mieć opisową nazwę. Tekst „więcej” albo „tutaj” nie informuje, jaki dokument zostanie otwarty.
Jeżeli użytkownik musi potwierdzić zapoznanie się z dokumentem, powinien mieć możliwość łatwego otwarcia go bez utraty danych wpisanych w formularzu.
Limit czasu może uniemożliwić ukończenie zadania
Niektóre systemy automatycznie kończą sesję po określonym czasie. Taki mechanizm może być uzasadniony bezpieczeństwem, ale nie powinien zaskakiwać użytkownika.
Jeżeli czas jest ograniczony, formularz powinien ostrzec o zbliżającym się końcu sesji i umożliwić jej przedłużenie. Użytkownik nie może stracić wszystkich danych bez wcześniejszej informacji.
Osoby korzystające z technologii wspomagających, mające trudności z koncentracją, czytaniem lub obsługą klawiatury mogą potrzebować więcej czasu. Sztywny limit staje się wtedy realną barierą.
Warto sprawdzić, czy formularz zapisuje wersję roboczą albo pozwala wrócić do procesu. Jest to szczególnie ważne w rozbudowanych wnioskach.
CAPTCHA nie może blokować dostępu
Mechanizmy chroniące przed automatycznymi zgłoszeniami często wymagają rozpoznawania obrazów, przepisywania zniekształconego tekstu albo rozwiązywania prostych zadań. Takie rozwiązania mogą być trudne dla osób niewidomych, słabowidzących, z dysleksją lub trudnościami poznawczymi.
Jeżeli formularz korzysta z CAPTCHA, musi zapewniać dostępną alternatywę. Nie należy zakładać, że wersja dźwiękowa zawsze rozwiązuje problem. Nagrania bywają niewyraźne, zawierają zakłócenia i wymagają szybkiego zapamiętywania znaków.
Lepsze są mechanizmy działające w tle, które nie wymagają wykonywania dodatkowego zadania przez użytkownika. Ochrona formularza powinna być możliwie najmniej obciążająca.
Warto również sprawdzić, czy CAPTCHA nie pojawia się dopiero po długim wypełnianiu formularza i nie powoduje utraty danych po nieudanej próbie.
Język formularza powinien być prosty i konkretny
Dostępność formularza zależy nie tylko od kodu. Równie ważny jest sposób formułowania pytań, instrukcji i komunikatów.
Użytkownik powinien rozumieć, jakie dane ma podać i dlaczego są potrzebne. Należy unikać urzędowego żargonu, wielokrotnie złożonych zdań i niejasnych nazw pól.
Zamiast „Dane podmiotu wnioskującego” można użyć bardziej konkretnego określenia dopasowanego do sytuacji. Zamiast „dokonać wskazania” wystarczy „wybierz”.
Komunikaty błędów nie powinny obwiniać użytkownika. Tekst „Nieprawidłowo wypełniłeś formularz” jest mniej pomocny niż wskazanie konkretnego problemu i sposobu jego poprawy.
Prosty język skraca czas wypełniania i ogranicza liczbę błędów. Pomaga wszystkim użytkownikom, nie tylko osobom ze szczególnymi potrzebami.
Podstawowy test powinien obejmować cały proces
Nie wystarczy sprawdzić pojedyncze pola. Formularz należy przejść od początku do końca, zarówno z prawidłowymi, jak i błędnymi danymi.
Trzeba ocenić sposób otwarcia formularza, instrukcje, przechodzenie między polami, dodawanie załączników, poprawianie błędów, wysłanie oraz potwierdzenie zakończenia procesu.
Warto przeprowadzić test na komputerze i telefonie, za pomocą myszy i samej klawiatury, przy standardowym oraz powiększonym tekście.
Nawet prosty test może wykazać poważne problemy: brak etykiet, niewidoczny fokus, niejasne błędy, utratę danych, niedostępny kalendarz albo brak potwierdzenia wysłania.
Takie bariery nie są drobnymi niedogodnościami. Mogą całkowicie uniemożliwić złożenie wniosku, zapisanie się na wydarzenie lub przekazanie informacji urzędowi.
Dostępny formularz prowadzi użytkownika przez cały proces. Wyjaśnia, czego wymaga, pozwala popełnić i poprawić błąd, nie usuwa wcześniej podanych danych i jednoznacznie potwierdza zakończenie zadania. Jeżeli formularz spełnia te warunki podczas zwykłego, praktycznego testu, istnieje znacznie większa szansa, że będzie rzeczywiście użyteczny.