Formularz zakupowy z AI: protokół testu klawiatury i błędów

Co sprawdza ten protokół, a czego nie

Formularz zamówienia albo kontaktu wygenerowany przez AI zwykle wygląda poprawnie od pierwszego podglądu. Pola są wyrównane, przycisk ma kontrastowy kolor, a czerwona ramka pojawia się tam, gdzie trzeba. Ten wygląd nie mówi jednak nic o tym, czy formularz da się wypełnić bez myszy i czy osoba, która popełni błąd, dowie się, co poprawić. Protokół poniżej sprawdza właśnie te dwie rzeczy: obsługę z klawiatury i zachowanie w stanie błędu.

Całość opiera się na syntetycznym przebiegu. Przyjmujemy fikcyjny formularz z pięcioma elementami: adres e-mail, imię i nazwisko, kod pocztowy, pole zgody na regulamin i przycisk Zamawiam. Wyniki w tabelach są przykładem, jak zapisać próbę, a nie raportem z istniejącego sklepu. Dziewięć kontroli nie zastępuje pełnego audytu WCAG. Obejmuje pięć kryteriów sukcesu, które bezpośrednio dotyczą wypełniania formularza: 2.1.1, 2.4.7, 1.3.1, 3.3.1 i 3.3.2.

Przygotuj środowisko i dane testowe

Zanim zaczniesz, zapisz nazwę przeglądarki, system, szerokość okna, datę i wersję formularza. Bez tych danych nie porównasz później wyniku po poprawce. Jeśli formularz należy do sklepu, uruchom tryb testowy płatności według instrukcji swojego operatora. Nie używaj zamówienia prawdziwego klienta ani własnej karty, gdy celem jest kontrola formularza, a nie rozliczenia.

Przygotuj trzy zestawy danych. Pierwszy jest poprawny w całości. Drugi zostawia puste pole e-mail. Trzeci zawiera kod pocztowy wpisany bez myślnika, czyli 00000. Wszystkie dane są fikcyjne. Odłóż mysz i gładzik poza zasięg ręki, bo odruchowe kliknięcie potrafi ukryć usterkę, którą test ma wykryć. Do poruszania się używasz wyłącznie klawiszy Tab, Shift+Tab, Enter, spacji i strzałek.

Dziewięć kontroli krok po kroku

Każdą kontrolę zapisz w dwóch kolumnach: co powinno się stać i co faktycznie widzisz. Oczekiwanie wpisujesz przed wykonaniem kroku, nie po nim. To chroni przed dopasowaniem wymagań do tego, co akurat zrobił generator. Wynik ma tylko dwie wartości: zaliczona albo niezaliczona. Stan częściowo działa prowadzi do dyskusji zamiast do poprawki.

W syntetycznym przebiegu kontrole K1 i K3 sprawdzają samą obsługę klawiaturą: kolejność przechodzenia oraz wysłanie formularza klawiszem Enter i spacją na przycisku. K2 dotyczy widoczności fokusu. K4 sprawdza pole zgody, które w kodzie z generatora bywa stylizowanym elementem zamiast natywnego pola wyboru. K5 i K6 dotyczą etykiet i instrukcji, a K7, K8 i K9 obejmują stan błędu: brak wartości, zły format, poprawkę oraz powiązanie komunikatu z polem.

W tym przykładzie 6 kontroli zostało zaliczonych, a 3 nie. Zwróć uwagę na K4. Pole zgody nie reaguje na spację i nie dostaje fokusu przy przechodzeniu klawiszem Tab. Mysz nie ma z nim problemu, więc przy samym oglądaniu podglądu usterka pozostaje niewidoczna. Dopiero próba bez myszy pokazuje, że zamówienia nie da się złożyć.

Dziennik usterek: trzy błędy i ich waga

Każda niezaliczona kontrola trafia do dziennika jako osobna usterka. Waga zależy od skutku dla osoby, która korzysta z klawiatury, a nie od tego, jak łatwo coś poprawić. W przykładzie stosujemy trzy poziomy. Krytyczna oznacza, że zadania nie da się ukończyć. Wysoka oznacza, że zadanie da się ukończyć, ale użytkownik traci informację potrzebną do poprawki. Średnia oznacza utrudnienie, które zmusza do zgadywania.

Wynik syntetycznego przebiegu to 1 usterka krytyczna, 1 wysoka i 1 średnia. U1 blokuje zamówienie, więc formularz nie może zostać opublikowany przed jej usunięciem. U2 sprawia, że osoba, która nie rozróżnia kolorów albo korzysta z czytnika ekranu, dostaje sygnał błędu bez treści. U3 jest najłatwiejsza do przeoczenia, bo dotyczy tylko jednego elementu. Ten element to jednak przycisk, który kończy całe zadanie.

Jak przypisać kontrolę do kryterium WCAG

Kryterium 2.1.1 Klawiatura wymaga, by cała funkcjonalność treści była dostępna z poziomu klawiatury bez konieczności zachowania określonego czasu pojedynczych naciśnięć. K1, K3 i K4 odnoszą się właśnie do niego. Kryterium 2.4.7 Widoczny fokus, na poziomie AA, wymaga trybu działania, w którym wskaźnik fokusu klawiatury jest widoczny. Usunięcie obrysu stylem bez zastępczego oznaczenia, jak w U3, łamie ten warunek.

Kryterium 1.3.1 Informacje i relacje dotyczy tego, czy struktura i powiązania widoczne na ekranie są dostępne także programowo. Etykieta, która tylko stoi obok pola, ale nie jest z nim powiązana, wygląda dobrze, a czytnik ekranu jej nie odczyta. Kryterium 3.3.2 Etykiety lub instrukcje wymaga etykiet albo instrukcji tam, gdzie treść wymaga danych od użytkownika. Kryterium 3.3.1 Identyfikacja błędu mówi, że automatycznie wykryty błąd ma wskazywać pole i opisywać problem tekstem. Czerwona ramka z U2 robi tylko połowę tej pracy.

Jedna kontrola może dotyczyć dwóch kryteriów. W przykładzie dziewięć kontroli daje 11 przypisań, bo K4 i K5 odnoszą się do dwóch kryteriów jednocześnie. Trzy usterki dotykają 4 z 5 badanych kryteriów: 2.4.7, 2.1.1, 1.3.1 i 3.3.1. Bez usterek pozostaje tylko 3.3.2. Takie zestawienie pokazuje, że niewielka liczba usterek nie oznacza, że problem jest wąski.

Poprawka i ponowny przebieg

Do poprawki opisz oczekiwane zachowanie, a nie konkretną technikę. Pole zgody ma przyjmować fokus i zmieniać stan spacją, a jego stan musi być dostępny programowo. Najprostsza droga to natywne pole wyboru z powiązaną etykietą zamiast elementu odtwarzającego jego wygląd. Komunikat błędu ma być tekstem przy polu, który mówi, czego brakuje. Przycisk ma mieć widoczny wskaźnik fokusu.

Po poprawce wykonaj ponownie wszystkie 9 kontroli, nie tylko trzy niezaliczone. Zmiana stylów fokusu potrafi zepsuć kolejność albo wygląd innego pola, a nowy komunikat błędu może przesunąć układ na wąskim ekranie. Zapisz nowy przebieg z nową datą i wersją. Usterkę zamykasz dopiero wtedy, gdy kontrola przechodzi w ponownym przebiegu, a nie wtedy, gdy ktoś zgłosi, że poprawka jest wdrożona.

Telefon, powiększenie i publiczny widok

Na telefonie otwarta klawiatura ekranowa zmniejsza widoczny obszar. Sprawdź, czy komunikat błędu pojawia się w miejscu, które da się zobaczyć bez zamykania klawiatury, i czy przycisk pozostaje osiągalny. Przy powiększeniu tekstu komunikat nie powinien zasłaniać pola ani przycisku. Jeżeli formularz ma animację wejścia, przy włączonej preferencji ograniczonego ruchu nie powinien kazać czekać na możliwość poprawki.

Powtórz przebieg na opublikowanej stronie. Generator, podgląd i rzeczywisty checkout mogą korzystać z różnych komponentów, a motyw sklepu może nadpisać style z podglądu. Poprawny formularz w makiecie nie potwierdza działania integracji płatności. Jeśli model AI przygotował komponent, człowiek nadal musi sprawdzić jego zachowanie na żywo i zapisać wynik z datą.

Najczęstsze błędy przy odbiorze formularza

Pierwszy błąd to test wykonany myszą z okazjonalnym naciśnięciem Tab. Taka próba nie wykryje pola, które w ogóle nie przyjmuje fokusu. Drugi to sprawdzenie tylko poprawnego przebiegu. Przebieg z poprawnymi danymi w ogóle nie uruchamia stanu błędu, więc nie sprawdza komunikatów przy pustym polu i złym formacie. Trzeci to uznanie automatycznego skanera za wystarczający dowód. Skaner znajdzie brakującą etykietę, ale nie oceni, czy komunikat mówi zrozumiale, co poprawić.

Czwarty błąd to dopisywanie oczekiwań po fakcie, żeby tabela wyglądała na zieloną. Piąty to zamknięcie usterki bez ponownego przebiegu. Szósty to przyjęcie, że skoro AI wygenerowało kod zgodny z dobrymi praktykami w jednym miejscu, zrobiło to wszędzie. Każdy z tych skrótów oszczędza kilka minut przy odbiorze i przenosi problem na klienta, który nie może złożyć zamówienia.

• Oczekiwanie zapisane przed wykonaniem kroku.
• Trzy zestawy danych: poprawny, pusty, zły format.
• Każda niezaliczona kontrola ma usterkę z wagą.
• Każda kontrola ma przypisane kryterium WCAG.
• Ponowny przebieg obejmuje wszystkie kontrole.
• Wynik z publicznej strony zapisany z datą.

Pobierz dane do własnego ćwiczenia

CSV zawiera wyłącznie przypadek syntetyczny opisany powyżej. To karta do samodzielnego sprawdzenia, nie wynik rzeczywistego przypadku ani plik do importu.

Otwórz ćwiczenie CSV

Źródła i metoda

Autorski protokół kontroli z syntetycznym przebiegiem: formularz, dziewięć kontroli, ich wyniki i trzy usterki są założeniami przykładu, a nie wynikami testu sklepu, danymi klientów ani audytem WCAG. Treść kryteriów sukcesu opisano na podstawie dokumentacji W3C sprawdzonej 13.10.2026.

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — sprawdzono: 2026-10-13
• W3C WAI: Understanding 3.3.1 Error Identification — sprawdzono: 2026-10-13
• W3C WAI: Forms Tutorial — sprawdzono: 2026-10-13
• W3C WAI: Forms Tutorial, User Notification — sprawdzono: 2026-10-13

Daty sprawdzenia podano przy źródłach. Przykłady liczbowe są ilustracją obliczeń, a nie danymi konkretnego sklepu.