Każde pole połącz ze stałą etykietą tekstową, wymagaj tylko niezbędnych danych, opisz błąd przy polu i w podsumowaniu, a po wysłaniu jasno potwierdź wynik.
Formularz to rozmowa między człowiekiem a systemem. Jeśli opiera się wyłącznie na placeholderze, nie oznacza pól obowiązkowych lub po błędzie kasuje dane, problem nie dotyczy tylko użytkowników technologii asystujących. Niejasność zwiększa liczbę poprawek, obciążenie wsparcia i ryzyko, że ktoś wyśle nieprawidłowe lub wrażliwe informacje.
Dostępność wynika z połączenia krótkiego zakresu, poprawnego HTML, zrozumiałych instrukcji i niezawodnych stanów. Walidacja po stronie klienta pomaga poprawić błąd, ale nie zastępuje kontroli bezpieczeństwa po stronie serwera. Formularz należy testować za pomocą klawiatury, czytnika ekranu, przy powiększeniu oraz przy wolnym połączeniu, z poszanowaniem prywatności i prawnego celu zbierania danych.
Cel i zakres pola muszą być zrozumiałe przed rozpoczęciem pisania
Należy pytać wyłącznie o dane potrzebne w danym procesie i wyjaśniać, dlaczego są potrzebne, jeśli nie jest to oczywiste. Pola obowiązkowe i opcjonalne trzeba rozróżniać tekstem, a nie tylko gwiazdką bez legendy. Kolejność powinna odpowiadać naturalnej rozmowie. Długi formularz warto podzielić na logiczne kroki i informować o postępie bez sztucznego wydłużania.
Instrukcję należy umieścić przed polem lub w jego pobliżu, zwłaszcza przy nietypowym formacie, haśle czy przesyłaniu pliku. Nie należy czekać, aż człowiek popełni błąd, by poznał zasadę. Komunikat powinien mówić, co wpisać i do czego dane zostaną użyte, a nie podawać wewnętrznej nazwy kolumny w bazie danych.
Etykieta (label) to stała nazwa, placeholder to jedynie pomocniczy przykład
Należy użyć elementu label poprawnie powiązanego z unikalnym identyfikatorem pola. Kliknięcie etykiety powinno aktywować odpowiedni element, a czytnik ekranu powinien odczytać jego nazwę. Placeholder znika po rozpoczęciu pisania, często ma słaby kontrast i nie może być jedynym źródłem informacji o przeznaczeniu lub formacie.
Grupy przycisków opcji i pól wyboru należy opisać wspólną legendą, a poszczególnym opcjom pozostawić własne etykiety. Przycisk powinien nazywać wynik, na przykład „Wyślij wniosek”, a nie ogólne „OK”. Własnych komponentów należy używać tylko wtedy, gdy natywny element nie spełnia potrzeby i potrafią Państwo zaimplementować całe jego zachowanie.
- widoczna etykieta dla każdej kontrolki
- unikalne id i prawidłowe powiązanie for
- fieldset i legend dla powiązanej grupy
- przycisk nazwany zgodnie z rzeczywistą akcją
Typ pola i autocomplete ograniczają zbędne przepisywanie
Należy wybrać odpowiedni typ pola dla e-maila, telefonu, daty lub liczby, ale dopuścić formaty, których użytkownik faktycznie potrzebuje. Numer telefonu nie jest wartością matematyczną i może zawierać numer kierunkowy czy spacje. Automatyczne formatowanie nie może zmieniać znaczenia ani przesuwać kursora w nieprzewidywalny sposób.
Dla typowych danych osobowych i kontaktowych ustaw odpowiedni atrybut autocomplete, aby przeglądarka i technologie wspomagające rozpoznały ich przeznaczenie. Nie blokuj wklejania tekstu do pola hasła lub kodu weryfikacyjnego bez uzasadnienia bezpieczeństwa. Menedżer haseł i kopiowanie mogą ograniczyć błędy i wspierać użytkowników z ograniczeniami motorycznymi lub pamięciowymi.
Komunikat błędu wskazuje pole, przyczynę i sposób poprawy
Po nieudanym wysłaniu zachowaj poprawnie wprowadzone dane i wyświetl podsumowanie błędów na początku formularza. Każda pozycja podsumowania może odsyłać do konkretnego pola. Komunikat o błędzie powinien znajdować się także przy polu i musi być do niego programowo przypisany. Czerwona ramka bez tekstu nie wyjaśnia problemu i nie działa bez rozróżniania kolorów.
Przenieście fokus na podsumowanie lub pierwszy błąd zgodnie ze spójnym modelem i ogłoście zmianę technologii wspomagającej bez uciążliwego powtarzania. Walidujcie w odpowiednim momencie; agresywny komunikat o błędzie przy każdej wpisanej cyfrze przeszkadza. Serwer ponownie weryfikuje dane wejściowe i zwraca bezpieczny komunikat bez technicznego stack trace ani ujawniania wewnętrznych szczegółów.
- jasne podsumowanie po nieudanym wysłaniu
- tekstowy komunikat błędu przypisany do konkretnego pola
- zachowane poprawne wartości i logiczny fokus
- ta sama kontrola po stronie klienta i serwera
- tekst pomocniczy dostępny razem z polem
- brak usuwania poprawnie wprowadzonych wartości
- potwierdzenie wyniku po autorytatywnej odpowiedzi
- test regresji z klawiaturą i czytnikiem ekranu
Potwierdzenie i testy zamykają cały proces
Po sukcesie proszę jednoznacznie poinformować, co zostało przyjęte, co stanie się dalej i jak można poprawić pomyłkę. Nie należy stwarzać wrażenia wysłania wyłącznie animacją przycisku. Przy podwójnym kliknięciu trzeba zapobiec zduplikowaniu rekordu i wyświetlić stabilny stan. Wrażliwych wartości nie należy powtarzać w potwierdzeniu ani w URL.
Należy przetestować pusty formularz, wartości graniczne, wolną odpowiedź, awarię serwera, powrót wstecz i odświeżenie strony. Cały proces warto przejść bez myszy oraz z czytnikiem ekranu. Automatyczny audyt wykryje część problemów, ale nie zweryfikuje zrozumiałości pytań, adekwatności zbieranych danych ani tego, czy użytkownik zrozumiał wynik.
Najczęstsze pytania
Czy placeholder może zastąpić label?
Nie. Po rozpoczęciu pisania znika i nie musi być niezawodnie odczytany. Pole potrzebuje stałej i programowo powiązanej nazwy.
Czy walidacja po stronie klienta jest wystarczająca?
Nie. Pomaga użytkownikowi, ale dane wejściowe trzeba bezpiecznie zweryfikować również na serwerze. Komunikaty o błędach z obu warstw powinny pozostać zrozumiałe i spójne.
Czy trzeba oznaczać pola obowiązkowe lub opcjonalne?
Wybierz spójny model i wyjaśnij go w tekście. W formularzu, w którym większość pól jest obowiązkowa, czytelniej może być wyraźnie oznaczyć zarówno wyjątki, jak i wymagania.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
