Przycisk z poprawną nazwą i pułapką klawiaturową
To materiał do artykułu. We wrześniu 2026 przygotowałem dwie wersje tej samej małej strony z przyciskiem „Zamów”, żeby pokazać, że przycisk może mieć poprawną nazwę i rolę, a mimo to zatrzymać użytkownika klawiatury.
Na co patrzyłem
Obie strony mają pole e-mail, przycisk „Zamów” i link „Pomoc”. W pierwszej wersji celowo dodałem skrypt, który blokuje klawisz Tab na przycisku, a w drugiej go usunąłem. To strony napisane tylko do tego testu, a nie strony CometWeb ani klienta.
Skrypt w Playwright wczytał każdą stronę do Chromium bez serwera i najpierw odczytał rolę oraz nazwę przycisku z drzewa dostępności przeglądarki. Potem w dwóch osobnych przebiegach ustawił focus na przycisku i nacisnął trzy razy Tab, a w drugim trzy razy Shift+Tab. Przy wersji bez blokady sprawdzał, czy pierwszy krok w każdą stronę trafia do sąsiedniego elementu.
Wyniki
| Co sprawdziłem | Wersja z blokadą | Wersja bez blokady |
|---|---|---|
| Rola i nazwa w drzewie dostępności | button, „Zamów” | button, „Zamów” |
| Focus po trzech naciśnięciach Tab | cały czas na przycisku | pierwszy Tab przenosi go do linku „Pomoc” |
| Focus po trzech naciśnięciach Shift+Tab | cały czas na przycisku | pierwszy Shift+Tab przenosi go do pola e-mail |
Poprawna nazwa i rola stały więc obok pułapki, z której użytkownik klawiatury nie wyjdzie. Ujawnił ją dopiero osobny test interakcji, co też pokazuje, że automatyczny skrypt może wykryć pułapkę, jeśli ktoś go do tego napisze. Pełną ścieżkę focusu w obu wersjach znajdziesz w pliku JSON.
Taką pułapkę opisuje kryterium 2.1.2 No Keyboard Trap. Wersja z blokadą nie daje żadnej drogi wyjścia. Otwarty modal, który trzyma focus, ale da się go obsłużyć i zamknąć klawiaturą, to inny przypadek.
Czego te dane nie pokażą
- To jeden celowo zepsuty przykład, więc nie mówi, jak często takie pułapki zdarzają się na prawdziwych stronach ani ile z nich wyłapują skanery.
- Nie uruchomiłem axe-core, czytnika ekranu ani badań z użytkownikami, a odczyt drzewa dostępności nie zastępuje testu z czytnikiem ekranu.
- Sprawdziłem tylko Chromium, bez Firefoksa i Safari.
- To ani audyt strony CometWeb, ani ocena zgodności z WCAG czy z prawem, a wynik takiej kontroli nie jest certyfikatem.
Pliki
keyboard-lab-results.json: rola, nazwa i pełna ścieżka focusu dla obu wersjibefore.html.txt: wersja z blokadą klawisza Tabafter.html.txt: ta sama strona bez blokadyrun_keyboard_lab.py.txt: skrypt testu
Strony udostępniam jako tekst, żeby wadliwa wersja nie działała na żywo. Żeby powtórzyć test, zapisz pliki bez końcówki .txt jako lab/fixtures/before.html, lab/fixtures/after.html i lab/run_keyboard_lab.py, utwórz obok katalog evidence i uruchom skrypt z opcją --browser wskazującą Chromium. Ja używałem Playwright 1.57 i Chromium 144.