Dostępny formularz firmowy: jak projektować pola, błędy i obsługę klawiaturą

Klient wypełnia długi formularz zgłoszenia. Po wysłaniu pojawia się czerwony napis „Wystąpił błąd”, a część wcześniej wpisanych informacji znika. Nie wiadomo, które pole trzeba poprawić. Osoba korzystająca z klawiatury wraca na początek, a czytnik ekranu nie zapowiada komunikatu. Z perspektywy firmy formularz nadal istnieje. Z perspektywy klienta zadanie właśnie przestało być wykonalne.

Dostępność zaczyna się od prostej obietnicy: człowiek powinien wiedzieć, o co prosimy, móc wprowadzić odpowiedź, znaleźć błąd i dokończyć sprawę. Dotyczy to zarówno formularza kontaktowego, jak i wniosku w portalu pracowniczym albo zgłoszenia serwisowego. Narzędzia mogą podpowiedzieć część problemów, ale potrzebna jest również próba całej drogi: od pierwszej instrukcji po potwierdzenie przyjęcia danych.

Poniższe przykłady są hipotetyczne. W jednym formularzu zbieramy zgłoszenie usterki, w innym dane do zapisania na szkolenie. Nie zakładamy, że każda organizacja potrzebuje takich samych pól. Właśnie decyzja o tym, co naprawdę jest potrzebne, bywa pierwszą poprawką dostępności i pierwszą ulgą dla osoby, która ma ten formularz wypełnić.

Zacznij od zadania, nie od listy wszystkich możliwych pól

Zapytaj zespół, co musi wiedzieć, żeby wykonać następny krok. Przy zgłoszeniu usterki może to być lokalizacja, opis objawu i sposób kontaktu. Numer seryjny bywa pomocny, lecz nie zawsze jest pod ręką. Jeśli brak numeru nie uniemożliwia przyjęcia sprawy, zastanówcie się, czy pole powinno być obowiązkowe. Formularz nie powinien zatrzymywać całego zgłoszenia tylko dlatego, że ktoś nie wie, gdzie producent umieścił naklejkę.

Podobnie działa rejestracja na wydarzenie. Jeśli rozliczeniem zajmujecie się dopiero po potwierdzeniu udziału, dane do faktury mogą należeć do kolejnego etapu. Ustalcie, kto ich rzeczywiście potrzebuje, kiedy i co się wydarzy, jeśli osoba ich nie poda. W platformie edukacyjnej obsługującej zapisy i dostęp formularz jest tylko częścią procesu: po nim musi nastąpić jasne potwierdzenie, dalsza informacja i właściwe nadanie dostępu.

Decyzje o polach dobrze sprawdzić na prototypie. Poproście osobę spoza zespołu projektowego, by bez podpowiedzi zgłosiła prostą sprawę. Obserwujcie, przy czym się zatrzymuje i jakie informacje musi znaleźć gdzie indziej. Nie chodzi o egzamin dla użytkownika. Jeżeli kilka osób czyta pytanie inaczej, projekt dostał cenną informację przed napisaniem kolejnej instrukcji. Taką próbę łatwiej wykonać wcześnie, dlatego przydaje się podejście opisane w artykule o testowaniu prototypu z pracownikami.

Zapytaj także, co stanie się ze zgłoszeniem po drugiej stronie ekranu. Formularz może zebrać informacje poprawnie, a mimo to skierować je do skrzynki, której nikt regularnie nie sprawdza. Wyznaczcie osobę lub zespół odpowiedzialny za odbiór oraz sposób przekazania sprawy podczas nieobecności. To ustalenie pomaga projektować potwierdzenie zgodne z rzeczywistą obsługą.

Nazwij pola i wyjaśnij wymagania tam, gdzie są potrzebne

Widoczna etykieta powinna mówić, jakiej informacji oczekujecie. „Adres e-mail do odpowiedzi” jest bardziej pomocny niż samo „Dane”, zwłaszcza gdy obok prosicie również o numer telefonu. Wskazówka wpisana wewnątrz pola może pokazywać przykład, ale znika podczas pisania. Dlatego nie powinna być jedyną nazwą pola. Osoba wracająca do częściowo wypełnionego formularza nadal potrzebuje wiedzieć, co wpisała i czego dotyczy dana odpowiedź.

W kodzie etykietę trzeba powiązać z właściwym polem. W3C opisuje takie powiązanie jako sposób przekazania nazwy użytkownikom czytników ekranu i sterowania głosem. Ma też zwykłą, praktyczną zaletę: kliknięcie etykiety może przenieść uwagę do pola. Dla grupy odpowiedzi, na przykład wyboru preferowanego sposobu kontaktu, przydatne jest wyraźne pytanie obejmujące całą grupę, a nie kilka przycisków bez wspólnego kontekstu.

Pokaż wymagany format przed wprowadzeniem danych, a nie dopiero po błędzie. Jeżeli numer sprawy ma określoną postać, podaj przykład bez prawdziwych danych klienta. Oznacz pola obowiązkowe czytelnie i nie opieraj tego rozróżnienia wyłącznie na kolorze. Gwiazdka może być użyteczna, jeśli wcześniej wyjaśnisz, co oznacza. Jeszcze prostsza bywa informacja „opcjonalne” przy nielicznych polach, które rzeczywiście nie są potrzebne do rozpoczęcia obsługi.

Pozwól przejść cały formularz bez myszy

Sprawdź formularz samą klawiaturą. Przechodząc klawiszem Tab, osoba powinna trafiać kolejno do pól, przycisków i pomocniczych odnośników. Widoczne oznaczenie aktualnego elementu, nazywane fokusem, pokazuje, gdzie znajduje się sterowanie. Jeśli ramka znika na tle strony albo przesuwa się w nieoczekiwane miejsce, wykonanie prostego zadania staje się zgadywanką. W dobrym teście przejdź również wstecz i spróbuj zmienić wcześniej wybraną odpowiedź.

Zwróć uwagę na elementy pojawiające się po wyborze. Gdy zaznaczenie „firma” odsłania dodatkowe pola, sprawdź, czy kolejność nadal ma sens i czy nowa część ma czytelną nazwę. Po zamknięciu okna pomocniczego użytkownik powinien móc wrócić do miejsca, z którego je otworzył. Unikaj przesuwania fokusu bez wyraźnego powodu: nagłe przeniesienie do innej części strony może przerwać czytanie lub pisanie.

Warto też sprawdzić sterowanie na telefonie i w powiększeniu. Długie etykiety powinny się zawijać, a komunikaty pozostać widoczne przy polu, którego dotyczą. Układ przycisków nie może wymagać przewijania całej strony w poszukiwaniu potwierdzenia. To nie oznacza projektowania osobnego produktu dla każdego urządzenia. Oznacza wykonanie kilku rzeczywistych prób, zanim interfejs trafi do użytkowników. Wybór technologii i sposobu obsługi urządzeń warto wcześniej omówić przy porównaniu aplikacji webowej, PWA i mobilnej.

Błąd ma pomóc poprawić dane, a nie zacząć od nowa

Komunikat „Nieprawidłowe dane” nie wskazuje, co dalej. Lepszy opis nazywa pole i powód: na przykład prosi o poprawny adres e-mail albo wyjaśnia, że wybrany termin jest już niedostępny. Przy polu pokaż odpowiednią informację, a na początku formularza możesz przedstawić listę problemów z odnośnikami do miejsc wymagających poprawy. W długim wniosku taka lista skraca drogę. W krótkim formularzu jeden wyraźny komunikat przy polu może wystarczyć.

Wskazówki W3C zwracają uwagę również na zachowanie danych po błędzie: osoba nie powinna ponownie wpisywać całego formularza tylko dlatego, że jedno pole wymaga poprawy. Wyjątki dotyczą niektórych informacji szczególnie wrażliwych, takich jak hasła. Decyzję o tym, co zachować i jak długo, trzeba powiązać z charakterem procesu oraz sposobem działania aplikacji. Dla prostego zgłoszenia oznacza to przede wszystkim, że poprawny opis problemu nie znika po literówce w adresie kontaktowym.

W formularzu rejestracji do gabinetu dochodzi stan dostępności terminu. Wybór widoczny kilka chwil temu mógł już zostać zajęty. System powinien wyjaśnić, co się zmieniło, i pozwolić wybrać inny termin bez ponownego wpisywania wszystkich pozostałych danych. Podobnie przy zgłoszeniu zwrotu lub reklamacji komunikat powinien wskazywać konkretny brak, a nie zmuszać klienta do ustalania przez telefon, który krok formularza zawiódł.

Sprawdź komunikaty w różnych sposobach korzystania

Czytnik ekranu odczytuje informacje przekazane przez strukturę strony i dostępne nazwy kontrolek. W praktycznej próbie sprawdź, czy po przejściu do pola słychać jego nazwę, informację o wymaganiu oraz powiązaną wskazówkę. Potem wywołaj błąd i ustal, czy osoba jest w stanie odnaleźć komunikat oraz przypisać go do właściwego pola. Nie zakładaj, że sam widoczny czerwony obrys zostanie przekazany w innej formie. Sposób powiadomienia trzeba dobrać do działania formularza i sprawdzić w obsługiwanych środowiskach.

Przy polu z wyborem daty sprawdź również, co oznacza puste pole, jaki format jest oczekiwany i czy wybór można zmienić bez użycia myszy. Jeżeli kalendarz jest dodatkowym oknem, osoba korzystająca z klawiatury musi móc go otworzyć, poruszać się po nim i zamknąć. W niektórych procesach prostsze pole daty z dobrze opisaną instrukcją może okazać się łatwiejsze niż rozbudowany kalendarz. Decyzję warto oprzeć na zadaniu i wynikach prób z osobami, które będą z niego korzystać.

Nie kończcie testu na pierwszym urządzeniu. Formularz może być częścią aplikacji pracowniczej używanej na komputerze, ale klient otworzy go na małym ekranie w drodze. Dla każdej ważnej ścieżki ustalcie rozsądny zestaw urządzeń, przeglądarek i sposobów obsługi. Zanotujcie również sytuacje, których nie sprawdzono. Taki zapis pomaga podejmować kolejne decyzje bez składania obietnicy, że jedna automatyczna kontrola sprawdziła wszystkie możliwe warunki.

W briefie do wykonawcy można opisać te próby jako zadania odbiorowe: użytkownik wprowadza dane, celowo popełnia błąd, poprawia go i otrzymuje potwierdzenie. To język zrozumiały zarówno dla zamawiającego, jak i programisty. Dopiero do tak opisanej sytuacji warto dopisać wymagania techniczne, sposób wykonania oraz osobę odpowiedzialną za sprawdzenie wyniku. Uzgodnijcie także sposób sprawdzenia poprawek po odbiorze.

Jeśli formularz ma przyjmować materiały, osobno zaplanuj zachowanie po wybraniu pliku i błędzie wysyłki. Te decyzje omawiamy w artykule o załącznikach do briefu.

Przyjęcie zgłoszenia i chwilowy brak odpowiedzi to różne sytuacje

Po wysłaniu formularza pokaż stan zrozumiały dla osoby, która czeka. Przycisk może na czas wysyłki informować o trwającej operacji. Po potwierdzonym przyjęciu pokaż odpowiedni komunikat i, jeśli proces go przewiduje, identyfikator sprawy. Nie obiecuj terminu odpowiedzi, którego zespół faktycznie nie ustalił. Dobre potwierdzenie mówi, co się wydarzyło i jaki jest następny krok, bez wymyślania zobowiązań w imieniu obsługi.

Przerwane połączenie wymaga osobnego scenariusza. Jeśli przeglądarka nie otrzyma odpowiedzi, użytkownik nie zawsze wie, czy zgłoszenie dotarło. Aplikacja powinna opisać tę niepewność i przewidzieć bezpieczny sposób dalszego postępowania. Przy ponowieniu istotne jest unikanie niezamierzonego mnożenia spraw. Rozwiązanie zależy od formularza i systemu docelowego, dlatego przypadek warto wpisać do testów zamiast zakładać, że każde ponowne kliknięcie utworzy dokładnie jeden rekord.

Kiedy formularz przekazuje dane dalej, zapytajcie też, kto zobaczy błąd po stronie integracji. Użytkownik nie powinien dostać komunikatu o sukcesie tylko dlatego, że przeglądarka zakończyła animację przycisku. Status przyjęcia musi odpowiadać temu, co rzeczywiście potwierdził system. Dalsze etapy i obsługę wyjątków można zaplanować razem z monitorowaniem procesu, tak aby zgłoszenie nie utknęło bez właściciela.

Włącz dostępność do odbioru projektu

Przygotuj krótką listę zadań do wykonania przed odbiorem. Osoba testująca może otworzyć formularz, przejść po polach klawiaturą, wysłać pusty wniosek, poprawić jeden błąd i sprawdzić potwierdzenie. Druga próba może obejmować czytnik ekranu lub powiększenie interfejsu. Istotne jest zanotowanie wyniku przy konkretnym zadaniu, wersji i urządzeniu, zamiast ogólnego stwierdzenia „formularz jest dostępny”. Automatyczny raport może pomóc znaleźć brak etykiety, ale nie zastąpi oceny, czy instrukcja pozwala zrozumieć, co należy zrobić.

W kryteriach odbioru aplikacji warto zapisać również sposób zgłaszania usterek i odpowiedzialność za ich poprawę. Poproście o przykłady danych testowych oraz przewidywane zachowanie po błędzie. Próbę przeprowadźcie z przedstawicielami osób, które faktycznie wykonują zadanie. Uwagi o niezrozumiałym pytaniu potrafią być równie istotne jak uwagi o technicznym powiązaniu etykiety z polem.

Jeżeli dopiero planujesz formularz albo masz zgłoszenia, które regularnie wymagają ręcznego wyjaśniania, opisz ten fragment w briefie. W projekcie aplikacji webowej lub mobilnej możemy wspólnie przejść przez pola, błędy i dalszą obsługę sprawy. Wyślij krótki opis procesu: kto korzysta z formularza, co ma załatwić i w którym miejscu najczęściej potrzebuje pomocy. To wystarczy na początek rozmowy o zakresie.