Formularz kontaktowy na stronie firmowej ma zrobić jedną prostą rzecz: pomóc użytkownikowi wysłać wiadomość bez zgadywania, kombinowania i walki z interfejsem. Tymczasem czasem wygląda to tak, jakby ktoś urządził mały test cierpliwości. Pole bez opisu, tajemniczy komunikat „Wystąpił błąd”, przycisk działający tylko po kliknięciu myszą. I nagle zwykłe zapytanie zaczyna przypominać zadanie specjalne.
Dostępny formularz kontaktowy warto sprawdzić w trzech obszarach: etykiet pól, komunikatów o błędach oraz obsługi samą klawiaturą. Nie trzeba od razu zaglądać do kodu ani odpalać programistycznych czarów. Kilka prostych prób w przeglądarce pokaże, czy formularz prowadzi użytkownika za rękę, czy raczej zostawia go na środku skrzyżowania z mapą narysowaną kredką.
Formularz kontaktowy nie powinien być testem cierpliwości
Osoba, która trafia na formularz, powinna od razu wiedzieć, co ma wpisać i co stanie się po wysłaniu wiadomości. To nie jest miejsce na zagadki w stylu „domyśl się, czy chodzi o telefon, e-mail czy może numer buta”. Każde pole powinno mieć jasny opis, a wymagane informacje powinny być rozpoznawalne bez szukania podpowiedzi lupą.
Problem w tym, że formularz może wyglądać schludnie, a mimo to być trudny w użyciu. Sama estetyka nie mówi, czy etykiety są poprawnie przypisane do pól, czy komunikaty błędów coś wyjaśniają i czy da się przejść całość bez myszy. Dostępność ocenia się więc nie tylko oczami, ale też przez konkretne zachowania użytkownika.
Dobrze działający formularz nie powinien zmuszać do:
- zgadywania, jakie dane wpisać w konkretne pole,
- szukania błędu na całej stronie po komunikacie „Coś poszło nie tak”,
- sięgania po mysz, gdy ktoś chce przejść dalej, zaznaczyć opcję albo wysłać wiadomość.
To podstawy, ale właśnie na takich podstawach potrafi wyłożyć się formularz, który na pierwszy rzut oka wygląda całkiem porządnie.
Etykieta pola to nie ozdobnik
Każde pole, w którym użytkownik ma podać dane, powinno mieć widoczną etykietę albo instrukcję. Etykieta ma odpowiedzieć na proste pytanie: „Co mam tutaj wpisać?”. Konkretne przykłady to „Imię i nazwisko”, „Adres e-mail” oraz „Numer telefonu”. Taki opis jest znacznie bardziej pomocny niż samotna ikonka albo pole, które liczy na domyślność użytkownika.
Warto uważać na placeholder, czyli tekst wyświetlany wewnątrz pola. Może być dodatkową podpowiedzią, ale nie powinien być jedyną informacją. Gdy użytkownik zacznie pisać, placeholder znika. Jeśli nie ma osobnej, widocznej etykiety, po chwili może już nie być jasne, czego dotyczy pole. To szczególnie irytujące w dłuższych formularzach, gdzie kilka pól wygląda niemal identycznie.
Widoczna etykieta to jedna sprawa, a poprawne powiązanie jej z konkretnym polem w kodzie to druga. Obie są ważne. Sam techniczny opis dostępny dla technologii asystujących nie zastępuje etykiety widocznej dla wszystkich użytkowników. Z kolei tekst widoczny na ekranie nie powinien być przypadkowym ozdobnikiem, który technicznie nie wskazuje właściwego pola.
Co użytkownik powinien wiedzieć przed wpisaniem danych
Przed rozpoczęciem wypełniania formularza użytkownik powinien rozumieć, które informacje są wymagane, a które opcjonalne. Jeśli formularz ma pola dodatkowe, ich status także powinien być czytelny. Nie każdy chce podawać numer telefonu, jeśli tak naprawdę wystarczy odpowiedź e-mailowa. Nie każ mu tego zgadywać.
Jeśli dane muszą mieć określony format, trzeba go podpowiedzieć. Dotyczy to choćby adresu e-mail albo numeru telefonu. Zamiast liczyć na to, że użytkownik domyśli się, czy numer ma zawierać prefiks, spacje lub myślniki, można dodać krótką instrukcję albo przykład. Taka podpowiedź oszczędza czas i zmniejsza ryzyko błędu.
Prosty test etykiet wygląda tak: spójrz na formularz i sprawdź, czy bez wpisywania czegokolwiek potrafisz nazwać cel każdego pola. Potem zacznij wpisywać dane i zobacz, czy nadal wiadomo, czego dotyczy dana rubryka. Jeśli odpowiedź brzmi „niekoniecznie”, formularz prosi się o poprawkę.
Co zrobić z błędami, żeby użytkownik nie zgadywał
Błąd w formularzu może zdarzyć się każdemu. Problemem nie jest samo odrzucenie niepoprawnych danych, tylko sposób, w jaki strona o tym informuje. Użytkownik powinien zobaczyć tekstowy komunikat wskazujący, które pole zawiera problem i na czym ten problem polega.
Komunikat „Wystąpił błąd” jest zwykle za ogólny. Nie wiadomo, czy chodzi o adres e-mail, brak zgody, pusty temat czy może numer telefonu. Użytkownik zostaje z zadaniem detektywistycznym, choć przyszedł tylko wysłać wiadomość. Znacznie lepiej, gdy komunikat prowadzi do konkretu, na przykład informuje, że trzeba uzupełnić adres e-mail albo wpisać go w oczekiwanym formacie.
Błąd może być pokazany przy konkretnym polu, na początku formularza, w osobnym komunikacie albo w kilku miejscach. Nie ma jednego obowiązkowego układu. Ważne, żeby informacja była przekazana tekstem lub równoważną informacją tekstową i dało się ją łatwo znaleźć.
Komunikat, który mówi co poprawić
Dobry komunikat błędu składa się z trzech prostych elementów:
- wskazuje pole, którego dotyczy problem,
- opisuje problem, zamiast ograniczać się do słowa „błąd”,
- podpowiada poprawkę, jeśli użytkownik może nie znać wymaganego formatu.
Czerwone obramowanie, kolor albo ikonka mogą pomóc szybko zauważyć problem, ale nie powinny być jedyną wskazówką. Sam kolor nie mówi wszystkim użytkownikom, co właściwie się stało. Tekst powinien wyjaśniać sytuację również wtedy, gdy ktoś nie rozpoznaje oznaczenia wizualnego.
Po celowym wpisaniu błędnych lub pustych danych sprawdź, czy wiadomo, gdzie trzeba wrócić. Jeśli komunikat pojawia się tylko na górze strony, a formularz jest długi, użytkownik może nadal nie wiedzieć, które pole poprawić. Jeśli błąd jest przy polu, ale nie mówi, co jest nie tak, sytuacja wygląda niewiele lepiej. Liczy się jasna informacja, nie samo czerwone kółeczko.
Test formularza samą klawiaturą
Teraz czas na test, który można zrobić bez narzędzi programistycznych. Odłóż mysz i przejdź formularz wyłącznie klawiszem Tab. W ten sposób sprawdzisz, czy kolejne pola, opcje i przyciski są osiągalne oraz czy kolejność przechodzenia ma sens.
Najpierw zobacz, czy widać aktualne miejsce fokusu, czyli element, który jest właśnie zaznaczony. Użytkownik powinien wiedzieć, gdzie znajduje się na stronie. Jeśli obramowanie lub inne oznaczenie znika na tle formularza, nawigacja klawiaturą staje się zgadywanką.
Następnie przejdź przez wszystkie pola. Wpisz dane, zaznacz dostępne opcje i spróbuj uruchomić wysyłkę bez myszy. Sprawdź, czy przycisk wysyłki można osiągnąć i aktywować z klawiatury. Zwróć uwagę, czy nie ma elementu, w którym fokus nagle utknie albo przeskoczy w nielogiczne miejsce.
Na co patrzeć podczas przechodzenia klawiszem Tab
Podczas testu warto przejść formularz spokojnie, bez klikania „na ratunek”. Zwróć uwagę na kilka rzeczy:
- czy kolejność pól i przycisków odpowiada kolejności czytania formularza,
- czy aktualnie zaznaczony element jest wyraźnie widoczny,
- czy można wpisać dane i zaznaczyć opcje bez myszy,
- czy da się uruchomić wysyłkę z klawiatury,
- czy po błędzie wiadomo, do którego pola trzeba wrócić.
Jeżeli formularz korzysta z dodatkowych elementów, na przykład niestandardowych kontrolek, sprawdź je również. Sam fakt, że kilka pól przechodzi się klawiszem Tab, nie oznacza jeszcze, że cała funkcjonalność działa poprawnie.
Szybka checklista dla właściciela firmy
Nie musisz od razu organizować wielkiej operacji pod kryptonimem „audyt formularza”. Na początek wystarczy krótka kontrola w zwykłej przeglądarce. Najlepiej wykonać ją na formularzu, z którego naprawdę korzystają klienci, a nie na przypadkowym przykładzie.
Cztery szybkie próby
- Przejdź formularz klawiszem Tab. Nie używaj myszy i sprawdź, czy docierasz do każdego pola oraz przycisku.
- Oceń etykiety. Zobacz, czy każda rubryka ma jasny, widoczny opis i czy wiadomo, które pola są wymagane.
- Wyślij puste albo błędne dane. Sprawdź, czy komunikaty wskazują konkretne pola i wyjaśniają problem.
- Sprawdź sposób sygnalizowania błędów. Upewnij się, że tekst przekazuje informację, a kolor lub ikonka są tylko wsparciem.
Możesz także użyć narzędzia do wstępnej oceny dostępności, ale potraktuj jego wynik jako punkt startowy. Automatyczne sprawdzenie może pomóc zauważyć część problemów, jednak nie zastąpi zwykłego przejścia formularza i oceny tego, czy komunikaty są po prostu zrozumiałe.
Jeśli korzystasz z checklisty, zapisz konkretne obserwacje. „Formularz niedostępny” niewiele mówi. „Po błędzie nie wiadomo, które pole poprawić” albo „przycisk nie jest osiągalny z klawiatury” to już informacje, z którymi da się coś zrobić.
Czego taki test nie załatwia
Szybki test jest dobrym początkiem, ale nie jest pełną oceną dostępności strony. Przejście formularza klawiszem Tab może wykryć część problemów, lecz nie sprawdza wszystkich sytuacji, w których użytkownik może napotkać barierę. Pozytywny wynik kilku prostych prób nie oznacza automatycznie pełnej zgodności z WCAG.
W praktyce dużo zależy od konkretnej konfiguracji: przeglądarki, urządzenia, wtyczki, motywu, zastosowanych skryptów oraz technologii asystujących. Formularz może zachowywać się inaczej w różnych warunkach. Dlatego ogólne zasady są mapą, ale nie potwierdzeniem, że każda implementacja działa poprawnie.
Dokładniejsza ocena powinna uwzględniać nie tylko etykiety, błędy i klawiaturę, ale też sposób działania całego formularza w jego konkretnej wersji. Nie chodzi o przyklejenie magicznej naklejki „dostępne” po jednym teście. Chodzi o sprawdzenie, czy człowiek może wykonać podstawową czynność bez niepotrzebnych przeszkód.
Najważniejsze są trzy rzeczy: etykieta ma jasno mówić, czego oczekuje pole; komunikat błędu ma wskazywać problem tekstem; formularz ma dać się przejść i wysłać z klawiatury. Od tych punktów można zacząć samodzielnie, a potem zdecydować, czy potrzebne jest dokładniejsze sprawdzenie konkretnej strony. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.
