Formularz kontaktowy działa, testowałeś go i wiadomości przychodzą. Mimo to liczba zgłoszeń jest mniejsza, niż sugerowałby ruch na stronie. Podobna sytuacja może występować w sklepie: użytkownicy dodają produkty do koszyka, ale część z nich nie kończy checkoutu.
Przyczyna nie zawsze leży w wyglądzie formularza. Czasami wystarczy niewłaściwy typ pola, brak poprawnego autouzupełniania albo walidacja uruchamiana w złym momencie, żeby prosty formularz stał się znacznie trudniejszy do wypełnienia na telefonie.
Zacznij od liczby pól
Formularz powinien zbierać dane, które rzeczywiście są potrzebne na danym etapie procesu.
W formularzu kontaktowym zwykle wystarczą informacje potrzebne do rozpoczęcia rozmowy. Dodatkowe pytania można zadać później, gdy kontakt z klientem już został nawiązany.
Podobna zasada dotyczy checkoutu. Dane powinny wystarczyć do poprawnego przyjęcia zamówienia, dostarczenia przesyłki, obsługi płatności i przygotowania wymaganych dokumentów.
Badania Baymard pokazują, że dla użyteczności checkoutu liczba pól, z którymi użytkownik musi sobie poradzić, ma większe znaczenie niż sama liczba kroków procesu. Według ich analizy większość checkoutów może ograniczyć się do około 8 pól, podczas gdy badana średnia wynosiła 11,3 pola.
Dlatego przed zmianą wyglądu formularza warto przejrzeć każde pole i sprawdzić, czy zebrana informacja rzeczywiście będzie wykorzystana.
Nie każda wartość złożona z cyfr jest liczbą
Jednym z częstszych błędów technicznych jest używanie type="number" wszędzie tam, gdzie użytkownik ma wpisać cyfry.
Ten typ pola powinien być używany dla rzeczywistych wartości liczbowych, takich jak liczba produktów, wiek czy określona wartość, którą można zwiększyć lub zmniejszyć.
Numer telefonu, kod pocztowy, NIP, PIN czy numer zamówienia mogą składać się głównie z cyfr, ale nie są liczbami w tym znaczeniu.
Specyfikacja HTML wprost wskazuje, że type="number" nie powinien być stosowany do wartości, które jedynie składają się z cyfr. Jako przykłady podaje między innymi numery kart płatniczych i kody pocztowe.
Dobrym testem jest zastanowienie się, czy przy danym polu sens miałyby przyciski zwiększające i zmniejszające wartość o jeden. Przy liczbie produktów tak. Przy kodzie pocztowym albo numerze telefonu nie.
type="number" może również zmienić wartość pola
Problem nie ogranicza się do wyglądu pola.
HTML definiuje type="number" jako kontrolkę przeznaczoną do wartości będącej prawidłową liczbą zmiennoprzecinkową. Przeglądarka nie powinna traktować dowolnego ciągu znaków jako poprawnej wartości takiego pola.
Dlatego kod pocztowy w formacie 80-180 nie pasuje do type="number". Podobnie numer telefonu zawierający +, spacje lub inne znaki używane w jego zapisie.
W zależności od sposobu implementacji może to doprowadzić do zablokowania wysłania formularza albo do sytuacji, w której aplikacja nie otrzyma wartości w postaci oczekiwanej przez programistę.
Bezpieczniejszym rozwiązaniem dla danych będących identyfikatorami lub ciągami cyfr jest zazwyczaj pole tekstowe połączone z odpowiednim inputmode.
Zmiana pola na tekstowe nie oznacza, że użytkownik telefonu musi otrzymać zwykłą klawiaturę literową.
Atrybut inputmode pozwala podpowiedzieć przeglądarce, jaki rodzaj klawiatury ekranowej najlepiej pasuje do oczekiwanych danych, bez zmiany sposobu przechowywania samej wartości.
| Ustawienie |
Zastosowanie |
inputmode="numeric" |
ciągi cyfr, np. wybrane kody, PIN lub inne identyfikatory numeryczne |
inputmode="decimal" |
wartości dziesiętne, np. waga lub wymiar |
type="tel" |
numer telefonu |
type="email" |
adres e-mail |
Przy type="tel" i type="email" przeglądarka może sama dopasować odpowiednią klawiaturę. inputmode jest szczególnie przydatny wtedy, gdy pole powinno pozostać tekstowe, ale oczekujemy określonego sposobu wprowadzania danych.
Autouzupełnianie nie powinno opierać się na zgadywaniu przeglądarki
Drugim często pomijanym elementem formularzy jest autocomplete.
Nie chodzi tylko o ustawienie autocomplete="on" dla całego formularza. HTML definiuje konkretne tokeny opisujące znaczenie poszczególnych pól.
Przykładowo można używać:
name dla pełnego imienia i nazwiska,given-name dla imienia,family-name dla nazwiska,email dla adresu e-mail,tel dla numeru telefonu,organization dla nazwy organizacji,postal-code dla kodu pocztowego,address-line1 dla pierwszej linii adresu.
Warto używać dokładnie wartości przewidzianych przez standard. Wymyślony token, taki jak postalcode zamiast postal-code, nie przekazuje przeglądarce prawidłowej informacji o przeznaczeniu pola.
Adres dostawy i adres rozliczeniowy trzeba rozróżnić
Autouzupełnianie staje się szczególnie ważne w checkoutach, gdzie te same informacje mogą pojawiać się więcej niż raz.
Sklep może mieć osobny adres dostawy i adres rozliczeniowy. Samo oznaczenie obu pól jako postal-code nie przekazuje pełnego kontekstu.
HTML przewiduje do tego między innymi tokeny shipping i billing oraz możliwość tworzenia nazwanych sekcji.
<input
name="shipping_postcode"
autocomplete="section-dostawa shipping postal-code"
>
<input
name="billing_postcode"
autocomplete="section-faktura billing postal-code"
>
Dzięki temu przeglądarka może lepiej rozpoznać, jakie dane powinna zaproponować w konkretnym miejscu formularza.
W WooCommerce warto sprawdzić pola dodane przez wtyczki i własny kod
Standardowe pola WooCommerce mają przygotowane wartości autocomplete dla podstawowych danych adresowych.
Większą uwagę warto poświęcić polom dodanym później przez własny kod lub dodatkowe wtyczki.
Może to być NIP, dodatkowy numer telefonu, niestandardowe dane firmy albo informacje potrzebne konkretnej integracji.
Samo dodanie pola do checkoutu nie oznacza, że automatycznie otrzyma ono prawidłową semantykę i konfigurację autouzupełniania. Po każdej większej zmianie formularza warto więc przejść checkout na prawdziwym telefonie z zapisanymi w przeglądarce danymi adresowymi.
autocomplete ma znaczenie również dla dostępności
Poprawne określenie przeznaczenia pól nie służy wyłącznie wygodzie.
WCAG 2.2 w kryterium 1.3.5 Identify Input Purpose na poziomie AA wymaga, aby przeznaczenie określonych pól zbierających informacje o użytkowniku mogło zostać programowo określone, jeżeli technologia na to pozwala.
W HTML jednym ze sposobów realizacji tego wymagania są prawidłowe wartości autocomplete.
Poprawienie formularza może więc jednocześnie usprawnić autouzupełnianie i usunąć część problemów wykrywanych podczas audytu dostępności.
Nie pokazuj błędu, zanim użytkownik skończy wpisywać
Kolejnym źródłem niepotrzebnego tarcia jest walidacja uruchamiana w niewłaściwym momencie.
Jeżeli użytkownik zaczyna wpisywać adres e-mail, komunikat o jego niepoprawnym formacie nie powinien pojawiać się po pierwszych kilku znakach. Adres jest wtedy niekompletny, ponieważ użytkownik jeszcze go nie skończył.
Badania Baymard dotyczące walidacji formularzy wskazują, że komunikaty nie powinny pojawiać się przedwcześnie. Jednocześnie warto informować użytkownika o problemie jeszcze przed próbą wysłania całego formularza.
W wielu przypadkach dobrym momentem na pierwszą walidację jest opuszczenie pola. Jeżeli użytkownik później zacznie poprawiać wartość, komunikat powinien odpowiednio reagować na zmianę zamiast pozostawać na ekranie do kolejnej próby wysłania formularza.
Wyjątkiem mogą być pola, w których użytkownik musi na bieżąco poznać spełnienie mniej oczywistych wymagań. Typowym przykładem jest tworzenie hasła z określonymi regułami.
Komunikat błędu powinien wyjaśniać, co poprawić
Samo zaznaczenie pola na czerwono nie wystarcza.
Komunikat powinien znajdować się przy odpowiednim polu i jasno informować, czego oczekuje formularz.
Tekst „Niepoprawna wartość” zmusza użytkownika do odgadnięcia przyczyny. Znacznie bardziej pomocna będzie konkretna instrukcja, na przykład „Podaj numer telefonu w formacie 123 456 789 lub +48 123 456 789”.
Nie należy również przekazywać informacji o błędzie wyłącznie kolorem. Formularz powinien udostępnić komunikat w sposób możliwy do odczytania również przez technologie asystujące.
Placeholder nie zastępuje etykiety
Popularnym sposobem upraszczania formularzy jest usuwanie widocznych etykiet i umieszczanie nazwy pola w placeholder.
Problem pojawia się po rozpoczęciu wpisywania. Placeholder znika i użytkownik może stracić informację o tym, czego dotyczy pole.
Widoczny label jest szczególnie istotny przy dłuższych formularzach, autouzupełnianiu oraz poprawianiu błędów po nieudanej próbie wysłania.
Placeholder można wykorzystać jako dodatkową podpowiedź lub przykład formatu, ale nie powinien być jedyną informacją opisującą pole.
Nie trzeba zaczynać od przebudowy całego formularza. Najpierw warto przejść jego istniejącą wersję i sprawdzić kilka konkretnych elementów.
- Sprawdź wszystkie pola z
type="number". Jeżeli przechowują identyfikator, kod, telefon albo inną wartość, której nie zwiększa się i nie zmniejsza matematycznie, zweryfikuj zastosowany typ pola.
- Przetestuj formularz na telefonie. Sprawdź, czy przy każdym polu pojawia się wygodna klawiatura.
- Włącz autouzupełnianie. Przejdź formularz na urządzeniu, na którym masz zapisane imię, adres, telefon i e-mail, i zobacz, które pola zostają pominięte.
- Sprawdź tokeny
autocomplete. Porównaj je z wartościami przewidzianymi przez HTML zamiast polegać na własnych nazwach.
- Przetestuj błędne dane. Sprawdź, kiedy pojawia się komunikat i czy po poprawieniu wartości znika lub aktualizuje się bez dodatkowej próby wysłania formularza.
- Sprawdź etykiety. Każde istotne pole powinno mieć czytelną nazwę również po rozpoczęciu wpisywania.
- Usuń niepotrzebne pola. Jeżeli informacja nie jest potrzebna do obsługi pierwszego kontaktu lub realizacji zamówienia, zastanów się, czy trzeba zbierać ją właśnie teraz.
- Wyślij formularz i sprawdź cały proces. Zweryfikuj nie tylko komunikat sukcesu, ale również zapis danych, wysyłkę powiadomienia i miejsce, do którego trafia zgłoszenie.
Test polegający na wpisaniu danych i kliknięciu „Wyślij” potwierdza tylko podstawowe działanie formularza. Nie pokazuje, jak zachowuje się on na różnych telefonach, czy współpracuje z autouzupełnianiem ani jak użytkownik radzi sobie z błędną wartością.
W Dock przy rozwoju stron internetowych i sklepów internetowych sprawdzamy formularze jako część całej ścieżki użytkownika. W przypadku checkoutu oznacza to przejście procesu od koszyka do potwierdzenia zamówienia, a przy stronie firmowej od wejścia na formularz do faktycznego otrzymania zgłoszenia.
Jeżeli formularz lub checkout działa, ale podejrzewasz, że utrudnia użytkownikom wysłanie danych, napisz do nas. Możemy sprawdzić implementację, zachowanie na urządzeniach mobilnych, autouzupełnianie, walidację i dalszą obsługę wysłanego zgłoszenia.
