Formularz nie jest poprawny tylko dlatego, że przeglądarka pozwoliła go wysłać. Dane można przesłać z pominięciem interfejsu, zmienić w narzędziach deweloperskich albo wysłać bezpośrednio do API. Dlatego walidacja formularza musi działać co najmniej na dwóch poziomach: w przeglądarce, aby szybko pomóc użytkownikowi, oraz na serwerze, aby chronić system przed błędnymi lub celowo spreparowanymi danymi.
Najczęstszy problem nie polega jednak na braku zaawansowanej biblioteki JavaScript. Znacznie częściej formularz wymaga zbyt wielu informacji, odrzuca poprawne nazwiska i numery telefonów, pokazuje komunikat „Nieprawidłowe dane” albo kasuje całą zawartość po jednym błędzie. To wystarczy, aby użytkownik porzucił rejestrację, zakup lub wysłanie zapytania.
Frontend podpowiada, serwer podejmuje decyzję
Walidacja po stronie przeglądarki powinna wychwytywać proste problemy jeszcze przed wysłaniem danych. Do wielu formularzy wystarczą natywne mechanizmy HTML:
required— oznacza pole obowiązkowe,type="email"— sprawdza podstawową budowę adresu e-mail,type="number"— ogranicza pole do wartości liczbowych,minimax— określają dopuszczalny zakres,minlengthimaxlength— kontrolują długość tekstu,pattern— pozwala ustawić własny wzorzec,step— określa dopuszczalny skok wartości,accept— ogranicza typy plików wybieranych w polu przesyłania.
Taką walidację można uzupełnić JavaScriptem, gdy reguły zależą od innych pól. Przykład: zaznaczenie opcji „Faktura dla firmy” może powodować wyświetlenie i wymaganie numeru NIP. W formularzu rezerwacji data zakończenia nie może przypadać przed datą rozpoczęcia. W koszyku liczba zamawianych sztuk nie powinna przekraczać dostępnego stanu.
Walidacja frontendowa nie jest zabezpieczeniem. Atrybuty HTML i skrypty można ominąć. Backend musi ponownie sprawdzić każde pole, niezależnie od tego, czy przeglądarka uznała formularz za poprawny. Dotyczy to zwłaszcza:
- identyfikatorów użytkowników i zamówień,
- kwot, rabatów i kosztów dostawy,
- liczby produktów,
- danych logowania,
- adresów e-mail i numerów telefonów,
- NIP-u oraz danych do faktury,
- zgód wymaganych do realizacji procesu,
- przesyłanych plików.
Kwota płatności powinna być obliczana na serwerze na podstawie cen zapisanych w systemie. Nie wolno przyjmować ceny przesłanej z formularza jako wartości wiążącej. Podobnie identyfikator produktu nie może wystarczyć do potwierdzenia, że użytkownik ma prawo go kupić, edytować albo usunąć.
Trzeci poziom kontroli stanowi baza danych. Ograniczenia takie jak unikalność adresu e-mail, brak wartości pustej w wymaganej kolumnie czy powiązanie rekordu z istniejącym użytkownikiem chronią przed zapisaniem niespójnych danych. Baza nie zastępuje walidacji aplikacji, ale zatrzymuje część błędów, które przeszły przez wcześniejsze warstwy.
Trzeba odróżnić walidację od porządkowania danych. Usunięcie spacji z początku i końca adresu e-mail jest rozsądną normalizacją. Podobnie numer telefonu można zapisać w jednym formacie, na przykład z kodem kraju i bez separatorów. Nie należy jednak automatycznie „poprawiać” danych w sposób zmieniający ich znaczenie. Literówka w nazwie firmy albo adresie dostawy wymaga decyzji użytkownika, a nie zgadywania przez system.
Szczególnie ostrożnie trzeba traktować wyrażenia regularne. Rozbudowany wzorzec adresu e-mail często odrzuca legalne adresy, których autor formularza nie przewidział. W większości przypadków wystarczy podstawowa kontrola składni, ograniczenie rozsądnej długości oraz — jeżeli adres ma zostać potwierdzony — wysłanie wiadomości z linkiem aktywacyjnym.
Komunikat błędu musi mówić, co poprawić
Tekst „Formularz zawiera błędy” nie pomaga w wykonaniu zadania. Dobry komunikat odpowiada na trzy pytania:
- które pole jest błędne,
- dlaczego wartość została odrzucona,
- jak wygląda poprawna wartość.
Zamiast „Nieprawidłowy numer telefonu” lepiej wyświetlić: „Podaj 9-cyfrowy numer, na przykład 600 000 000, albo numer z prefiksem kraju, na przykład +48 600 000 000”.
Zamiast „Hasło jest za słabe” należy podać regułę: „Hasło musi mieć co najmniej 12 znaków”. Wymuszanie jednej wielkiej litery, jednej cyfry i jednego znaku specjalnego nie zawsze poprawia jakość hasła. Długie hasło lub fraza może być trudniejsza do odgadnięcia, a jednocześnie łatwiejsza do zapamiętania. Formularz nie powinien też blokować wklejania ani utrudniać działania menedżerów haseł.
Moment wyświetlenia błędu ma znaczenie. Pokazywanie czerwonego komunikatu po wpisaniu pierwszego znaku irytuje i tworzy wrażenie, że użytkownik robi coś źle, choć nie skończył jeszcze wprowadzać danych. Najlepiej sprawdzają się trzy momenty:
- po opuszczeniu wypełnionego pola,
- przy próbie przejścia do kolejnego etapu,
- po naciśnięciu przycisku wysyłki.
Walidacja podczas pisania ma sens wtedy, gdy informacja rzeczywiście pomaga. Dotyczy to między innymi licznika znaków, oceny długości hasła, sprawdzania dostępności loginu czy informowania, że użytkownik przekroczył maksymalną liczbę załączników.
W dłuższym formularzu sam komunikat pod polem może nie wystarczyć. Po nieudanej próbie wysłania warto:
- wyświetlić listę błędów nad formularzem,
- przenieść fokus do pierwszego błędnego pola lub do podsumowania,
- oznaczyć niepoprawne pole tekstem i ikoną,
- zachować wszystkie prawidłowo wpisane informacje,
- połączyć komunikat z polem programowo,
- poinformować czytnik ekranu o pojawieniu się błędu.
Czerwone obramowanie nie może być jedynym sygnałem. Część osób nie rozróżnia kolorów, korzysta z trybu wysokiego kontrastu albo nie widzi całego formularza na ekranie telefonu. Tekst błędu musi być czytelny także bez koloru.
Najbardziej kosztownym błędem jest wyczyszczenie formularza po nieudanej wysyłce. Użytkownik, który właśnie wpisał dane firmy, adres, numer telefonu i dłuższą wiadomość, nie powinien zaczynać od początku z powodu jednej brakującej zgody. Należy zachować poprawne wartości i pozwolić zmienić tylko te pola, które wymagają korekty.
Wyjątek stanowią dane poufne. Hasła, pełne dane karty płatniczej i kody jednorazowe nie powinny być bezrefleksyjnie odtwarzane po błędzie. Formularz musi jasno wskazać, że konkretne pole trzeba wprowadzić ponownie.
Najpierw uprość formularz, później dodawaj automatyzację
Walidacja nie naprawi formularza, który pyta o informacje zbędne na danym etapie. Każde dodatkowe pole oznacza kolejną decyzję, możliwość błędu oraz powód do przerwania procesu.
Przy zapisie do newslettera zazwyczaj wystarczy adres e-mail i odpowiednio obsłużona zgoda. Imię może służyć personalizacji wiadomości, ale numer telefonu, nazwa firmy, stanowisko i budżet marketingowy trudno uzasadnić, jeżeli nie są potrzebne do realizacji zapisu.
Przy formularzu kontaktowym warto ustalić, co jest konieczne do udzielenia odpowiedzi. Często będą to:
- adres e-mail lub telefon,
- treść wiadomości,
- wybór tematu zgłoszenia,
- wymagane informacje dotyczące przetwarzania danych.
Pola obowiązkowe trzeba wyraźnie oznaczyć. Sam symbol gwiazdki nie wystarczy, jeżeli formularz nie wyjaśnia jego znaczenia. Można napisać „Pola oznaczone * są wymagane” albo oznaczyć pola opcjonalne słowem „opcjonalnie”, gdy większość pól jest obowiązkowa.
Maski wprowadzania danych pomagają tylko przy naprawdę przewidywalnym formacie. Maska 00-000 jest użyteczna dla polskiego kodu pocztowego, gdy formularz obsługuje wyłącznie adresy w Polsce. Staje się przeszkodą, gdy klient może podać adres niemiecki, czeski lub brytyjski.
Podobny problem dotyczy numerów telefonów. Sztywne wymaganie dziewięciu cyfr blokuje numery zagraniczne. Nawet w Polsce użytkownicy wpisują numery ze spacjami, myślnikami, prefiksem +48 albo bez niego. Interfejs powinien akceptować rozsądne warianty, a backend zapisywać numer w ujednoliconym formacie.
Nie należy zakładać, że nazwisko składa się wyłącznie z liter od A do Z. Poprawne dane mogą zawierać:
- polskie znaki,
- myślniki,
- apostrofy,
- spacje,
- kilka członów,
- litery używane w innych językach.
Walidacja imienia i nazwiska oparta na restrykcyjnym wyrażeniu regularnym przynosi zwykle więcej szkody niż pożytku. Bezpieczniej kontrolować maksymalną długość, usuwać przypadkowe spacje na brzegach i blokować wyłącznie znaki, które rzeczywiście stanowią zagrożenie dla konkretnego procesu.
Autouzupełnianie danych firmy po NIP-ie może skrócić formularz, lecz nie zwalnia użytkownika z kontroli wyniku. Rejestr może zawierać dawny adres, a działalność może być prowadzona pod innym adresem korespondencyjnym. Dane pobrane automatycznie powinny być widoczne i — tam, gdzie proces na to pozwala — możliwe do poprawienia.
Trzeba też przetestować formularz poza wygodnym środowiskiem programisty. Minimum obejmuje:
- telefon z małym ekranem,
- obsługę samą klawiaturą,
- powiększenie strony,
- wolniejsze połączenie,
- ponowne wysłanie po błędzie serwera,
- długie nazwiska, adresy i wiadomości,
- znaki diakrytyczne,
- wklejanie danych z menedżera haseł,
- utratę połączenia podczas wysyłania.
Ochronę antyspamową warto wdrażać stopniowo. Na początku sprawdzają się honeypot, limit liczby żądań, kontrola czasu wypełnienia formularza, filtrowanie podejrzanych treści i walidacja serwerowa. CAPTCHA powinna pojawić się dopiero wtedy, gdy prostsze zabezpieczenia nie zatrzymują spamu. Dodatkowy test bywa szczególnie uciążliwy na telefonie i może blokować również prawdziwych użytkowników.
FAQ
Czy walidacja HTML wystarczy do zabezpieczenia formularza?
Nie. Pomaga użytkownikowi wykryć błąd przed wysłaniem, ale można ją ominąć. Wszystkie istotne dane muszą zostać ponownie sprawdzone na serwerze.
Czy adres e-mail trzeba sprawdzać rozbudowanym wyrażeniem regularnym?
Zwykle nie. Wystarczy podstawowa kontrola składni i długości. Jeżeli adres musi należeć do użytkownika, właściwą metodą jest wysłanie wiadomości potwierdzającej.
Kiedy pokazywać błąd przy polu?
Najczęściej po opuszczeniu pola albo po próbie wysłania formularza. Nie należy zgłaszać błędu, gdy użytkownik dopiero zaczął wpisywać wartość.
Czy wolno poprawiać dane automatycznie?
Można usuwać zbędne spacje i ujednolicać format telefonu. Nie należy samodzielnie zmieniać nazw, adresów ani innych informacji, których znaczenia system nie potrafi jednoznacznie ustalić.
Czy formularz powinien kasować dane po błędzie?
Nie. Poprawne wartości należy zachować. Ponownego wpisania mogą wymagać wyłącznie dane poufne, takie jak hasło lub kod jednorazowy.
Od czego zacząć poprawę istniejącego formularza?
Najpierw sprawdź, czy backend waliduje dane niezależnie od frontendu. Następnie usuń komunikaty ogólne i pokaż konkretny błąd bezpośrednio przy właściwym polu. Dopiero później wdrażaj maski, autouzupełnianie i walidację w czasie rzeczywistym.
Pierwszym błędem do usunięcia powinien być komunikat „Wypełnij formularz poprawnie”. Zastąp go informacją wskazującą konkretne pole, przyczynę odrzucenia oraz akceptowany format. Następnie upewnij się, że po błędzie nie znikają wcześniej wpisane dane i że serwer ponownie sprawdza każdą wartość wpływającą na konto, płatność, dostawę lub zapis w bazie.
Dodatkowe informacje na: nazwa@domena.pl.
