Klient opisał problem w kilku zdaniach, wybrał temat i nacisnął przycisk. Serwer zwrócił błąd. Czy treść została w polu? Czy wiadomo, co poprawić? Czy można ponowić próbę bez szukania przycisku pod bannerem?
Takie pytania warto wpisać do odbioru strony obok poprawnego dostarczenia zapytania. Zrzut pustego formularza pokazuje niewiele z tego, co dzieje się podczas rzeczywistej rozmowy z firmą. Poniższy scenariusz pozwala przejść przez stany, które najłatwiej pominąć przy oglądaniu projektu.
Zacznij od jednej kompletnej drogi
Przygotuj testowy adres i opis sprawy, które nie zawierają danych klienta. Test wysyłki wykonuj w uzgodnionym środowisku z kontrolowanym odbiornikiem. Samo przeglądanie publicznego formularza nie wymaga wysłania wiadomości do działu sprzedaży.
Przejdź od linku prowadzącego do kontaktu do ostatniej kontrolki. Używaj Tab i Shift+Tab, a przyciski oraz listy obsługuj klawiaturą. Zanotuj kolejność pól, miejsce pojawienia się błędu i element, na który trafia fokus po zamknięciu dodatkowego panelu. W formularzu wieloetapowym wróć do wcześniejszego kroku i sprawdź, czy decyzje nadal są widoczne.
Do protokołu wystarczą konkretne obserwacje: „po zamknięciu listy tematów fokus wraca do wyboru tematu” albo „po błędzie serwera opis znika”. Ogólne „formularz działa” nie pozwala później ustalić, co zostało sprawdzone.
Sprawdź fokus razem z elementami przyklejonymi
Widoczny obrys i widoczność samego pola to dwa osobne warunki odbioru. Pole może mieć poprawny styl focusu, a mimo to znaleźć się pod przyklejonym nagłówkiem lub bannerem. Wyjaśnienie WCAG 2.2 dla kryterium 2.4.11 wskazuje, że komponent otrzymujący fokus nie może być całkowicie zasłonięty przez treść utworzoną przez autora strony. Istotne są także elementy, które pojawiają się w trakcie interakcji. W3C: Focus Not Obscured (Minimum).
W odbiorze firmowego formularza proponujemy mocniejszy, prosty warunek: całe aktywne pole, jego etykieta oraz obrys powinny dać się zobaczyć bez zgadywania miejsca wpisywania. Sprawdź to przy bannerze otwartym i po zwykłym odrzuceniu opcjonalnej analityki. Zgoda na analitykę nie powinna być warunkiem znalezienia przycisku kontaktu.
Powtórz przejście na wąskim ekranie i z powiększonym tekstem. Zwróć uwagę na ostatnią kontrolkę dokumentu: często nie ma już miejsca, aby przewinąć ją wyżej. Zanotuj również, czy menu wyboru ma własne przewijanie i czy aktywna opcja pozostaje w jego widocznej części.
Nie każ odgadywać znaczenia błędu
Komunikat „Niepoprawne dane” nie wskazuje, którego pola dotyczy problem. Lepszy opis nazywa pole i podaje oczekiwaną poprawkę. Przy większym formularzu przydaje się zbiorcza lista błędów z odnośnikami do pól. Komunikat przy kontrolce powinien być z nią programowo powiązany, na przykład przez aria-describedby; sam czerwony kolor nie przekazuje instrukcji. Takie podejście opisuje tutorial W3C poświęcony powiadomieniom w formularzach. W3C WAI: User Notification.
W praktycznym scenariuszu celowo pomiń jedno wymagane pole. Następnie popraw je i wywołaj inny błąd. Sprawdź, czy stary komunikat znika, czy nowy pojawia się przy właściwym miejscu i czy po przejściu do pola nadal widać instrukcję. Jeżeli wynik jest ogłaszany przez czytnik ekranu, posłuchaj całej sekwencji: kilka powtórzeń tej samej wiadomości może utrudniać poprawienie danych.
Zachowaj pracę po nieudanej próbie
Błąd formatu e-maila i błąd dostarczenia wiadomości wymagają różnych komunikatów. W pierwszym przypadku użytkownik poprawia konkretną wartość. W drugim powinien zobaczyć, że problem dotyczy wysyłki, oraz zachować możliwość skorzystania z wpisanego już opisu.
WCAG 2.2 w kryterium 3.3.7 dotyczy informacji wymaganych ponownie w tym samym procesie: powinny być uzupełnione automatycznie albo dostępne do wybrania, z określonymi wyjątkami. Nie oznacza to obowiązku przechowywania formularza między oddzielnymi sesjami. W3C: Redundant Entry.
Dla odbioru ustal osobno zachowanie zwykłych pól, załączników i zabezpieczeń antyspamowych. Nie oczekuj, że każdy token weryfikacyjny da się użyć ponownie. Ważne, aby odnowienie zabezpieczenia nie usuwało opisu sprawy i nie uruchamiało kolejnej wysyłki bez świadomej decyzji użytkownika.
| Sytuacja | Co zapisać w protokole |
|---|---|
| Błąd wymaganej wartości | Treść komunikatu, powiązane pole, dalsza droga klawiatury |
| Błąd dostarczenia | Zachowane wartości i możliwość ponowienia |
| Otwarty banner | Widoczność pól, przycisku i aktywnej opcji listy |
| Sukces w środowisku testowym | Treść potwierdzenia i liczba zgłoszeń u odbiornika |
Zostaw wynik, który da się odtworzyć
Dołącz adres, rozmiar okna, przeglądarkę i stan bannera. Krótkie nagranie z przejścia przez błąd bywa bardziej użyteczne niż kilkanaście zrzutów pustego formularza. Usuń dane testowe z udostępnianych kadrów, jeśli mogłyby zostać pomylone z prawdziwym zgłoszeniem.
Taki odbiór uzupełnia rozmowę o dobrym formularzu kontaktowym i ograniczaniu spamu. Nie zastępuje pełnego audytu dostępności. Daje za to konkretną odpowiedź na pytanie, czy osoba próbująca skontaktować się z firmą może dokończyć zadanie również wtedy, gdy coś pójdzie niezgodnie z planem.
