Najważniejsze wnioski
- Test klawiaturą pozwala szybko sprawdzić, czy użytkownik może dotrzeć do kluczowych funkcji strony, uruchomić je i bezpiecznie z nich wyjść.
- Sama obecność fokusu nie wystarcza. Fokus musi być widoczny, logicznie uporządkowany i nie może być zasłonięty przez nagłówek, baner cookie lub modal.
- Najważniejsze miejsca do sprawdzenia w e-commerce to menu, wyszukiwarka, filtry, koszyk, formularze, logowanie, płatność i komunikaty błędów.
- Test 15-minutowy jest screeningiem. Nie zastępuje audytu WCAG, testów z użytkownikami ani napraw źródłowych w kodzie i treści.
- WCAGbot może wspierać użytkowników funkcjami skupienia, większego kursora, przewodnika do czytania i narzędziami typograficznymi, ale nie naprawia samodzielnie błędnej kolejności fokusu ani pułapek klawiaturowych w kodzie.
Dla zarządzającego
Nawigacja klawiaturą jest podstawowym warunkiem użyteczności usługi cyfrowej. Krótki test pomaga ustalić, czy ścieżki istotne biznesowo — od wyszukania produktu do wysłania formularza — są dostępne bez myszy, oraz które problemy wymagają pilnej naprawy źródłowej.
Dla sprzedaży
Jeżeli klient nie może klawiaturą otworzyć menu, wybrać wariantu, dodać produktu do koszyka albo poprawić błędu w formularzu, może przerwać proces niezależnie od jakości oferty. Test warto wykonywać na stronie głównej, stronie produktu, koszyku i formularzu kontaktowym.
Nawigacja klawiaturą powinna umożliwiać przejście przez najważniejsze funkcje strony bez używania myszy. Jeżeli użytkownik nie może klawiszem Tab dotrzeć do menu, wyszukiwarki, koszyka, formularza lub przycisku płatności, sama obecność tych elementów na stronie nie rozwiązuje problemu. Poniższy test zajmuje umownie 15 minut i pomaga znaleźć bariery wymagające dalszej analizy.
To praktyczny test ręczny, a nie potwierdzenie zgodności z WCAG. Nie zastępuje audytu, testów z użytkownikami ani naprawy kodu i treści. Jest jednak dobrym pierwszym krokiem, szczególnie dla właściciela e-commerce, zespołu UX, agencji lub osoby odpowiedzialnej za utrzymanie strony.
Najważniejsze wnioski
- Każda kluczowa funkcja powinna być osiągalna i obsługiwana z klawiatury.
- Fokus musi być widoczny, mieć logiczną kolejność i nie może znikać pod elementami przyklejonymi do ekranu.
- Menu, modal, filtr oraz formularz trzeba nie tylko otworzyć, ale też zamknąć i opuścić bez pułapki klawiaturowej.
- Błędy znalezione w teście warto dokumentować jako konkretne kroki, a nie ogólną uwagę „strona nie działa na Tabie”.
- Widget dostępności wspiera komfort części użytkowników, lecz błędne zachowanie komponentów wymaga naprawy źródłowej.
Czym jest nawigacja klawiaturą i kogo wspiera?
Nawigacja klawiaturą oznacza korzystanie z interaktywnych części strony przy użyciu klawiszy zamiast myszy. Dotyczy to nie tylko osób niewidomych. Z klawiatury, przełączników, sterowania głosem oraz innych technologii wejścia korzystają również osoby z ograniczeniami ruchowymi, osoby słabowidzące i użytkownicy, dla których taka forma pracy jest po prostu wygodniejsza.
W WCAG 2.2, kryterium 2.1.1 Keyboard zapisano, że cała funkcjonalność treści powinna być dostępna przez interfejs klawiaturowy, poza ściśle określonymi wyjątkami. W sklepie internetowym dotyczy to między innymi wyszukiwania, wyboru produktu, wariantu, liczby sztuk, filtrów, koszyka, logowania, formularza dostawy i płatności.
Szerszy kontekst standardów opisuje artykuł WCAG 2.1, WCAG 2.2 i EN 301 549 — czym się różnią?. Warto pamiętać, że WCAG jest zbiorem wytycznych, a norma EN 301 549 obejmuje również wymagania wykraczające poza samo WCAG.
Fokus jest dla użytkownika klawiatury tym, czym kursor myszy dla użytkownika wskazującego: musi mówić jasno, gdzie można wykonać następne działanie.
Jak wykonać 15-minutowy test strony bez myszy?
Piętnaście minut nie jest limitem wynikającym z WCAG ani formalną metodą audytową. To celowo krótki screening. Ma odpowiedzieć na jedno pytanie: czy podstawowa ścieżka użytkownika działa bez myszy, czy też wymaga pilnej analizy technicznej?
1. Przygotuj test i wybierz ścieżkę użytkownika
Otwórz stronę w zwykłej przeglądarce, odłóż mysz i odśwież widok. Dla e-commerce nie ograniczaj się do strony głównej. Wybierz jedną konkretną ścieżkę, na przykład: strona główna → wyszukiwarka → karta produktu → wybór wariantu → koszyk → formularz.
Przygotuj prostą notatkę z pięcioma polami: adres URL, krok, użyty klawisz, oczekiwany rezultat i rzeczywisty rezultat. Dzięki temu zgłoszenie będzie użyteczne dla developera lub dostawcy platformy.
2. Sprawdź punkt wejścia klawiszem Tab
Po odświeżeniu strony naciśnij Tab. Obserwuj, gdzie pojawia się fokus. Powinien być wyraźnie widoczny, odróżniać się od tła i wskazywać aktualnie aktywny element.
Na wielu stronach pierwszym istotnym elementem jest link pozwalający pominąć powtarzalny nagłówek i przejść do głównej treści. Taki link często nazywa się „Przejdź do treści” lub „Pomiń nawigację”. Po aktywacji powinien prowadzić do właściwego obszaru strony, a nie tylko zmieniać pozycję przewijania bez sensownego przeniesienia fokusu.
W raporcie WebAIM Million 2025 link typu skip wykryto na 15,3% badanych stron głównych. Około 10% wykrytych linków było niesprawnych. To nie jest miara dostępności klawiaturowej całego internetu, ale pokazuje, że nawet prosty mechanizm wymaga realnego testu.
15-minutowy test nawigacji klawiaturą
3. Przejdź przez kolejność fokusu
Naciskaj Tab, aby przechodzić do przodu, oraz Shift + Tab, aby cofać się po elementach. Patrz nie tylko na to, czy fokus się przemieszcza, lecz także czy robi to w przewidywalnej kolejności.
Zgodnie z WCAG 2.2, kryterium 2.4.3 Focus Order, kolejność ma zachowywać znaczenie i operacyjność. Problemem będzie na przykład przejście z przycisku „Dodaj do koszyka” do linku w stopce, a następnie z powrotem do wyboru rozmiaru. Takie skoki utrudniają wykonanie zadania i dezorientują użytkownika.
Odnotuj także elementy, które niepotrzebnie trafiają do kolejności tabulacji: dekoracyjne ikony, puste linki, niewidoczne kontrolki albo duplikaty. Z drugiej strony sprawdź, czy nie są pomijane ważne przyciski, pola lub opcje filtrów.
4. Uruchom linki, przyciski i pola
Dotarcie do elementu nie oznacza jeszcze, że da się z niego skorzystać. Dla każdego istotnego komponentu wykonaj działanie:
- Enter — uruchom link lub przycisk,
- Spacja — sprawdź przyciski, checkboxy i przełączniki,
- strzałki — sprawdź komponenty, które wymagają wyboru opcji, na przykład część list, zakładek lub grup radiowych,
- Escape — zamknij menu, modal, podpowiedź lub inny wyskakujący komponent.
Dokładne zachowanie może zależeć od typu komponentu i przeglądarki. Instrukcja DWP rekomenduje sprawdzanie tych podstawowych klawiszy oraz komponentów takich jak menu, popupy i modale.
5. Zbadaj menu, modal i pułapkę klawiaturową
Otwórz główne menu, filtr, wyszukiwarkę z podpowiedziami, popup newslettera, baner cookie i okno logowania. Następnie odpowiedz na cztery pytania:
- Czy można otworzyć komponent z klawiatury?
- Czy można przejść do wszystkich dostępnych opcji?
- Czy można go zamknąć i wrócić do elementu otwierającego?
- Czy fokus nie przechodzi pod aktywny modal albo nie zostaje w nim bez możliwości wyjścia?
Kryterium 2.1.2 No Keyboard Trap zabrania sytuacji, w której użytkownik może wejść do komponentu klawiaturą, lecz nie może go opuścić. Typowa pułapka pojawia się w źle wdrożonym modalu: klawisz Tab krąży po przypadkowych elementach lub fokus znika, a użytkownik nie ma jasnej metody zamknięcia okna.
6. Przetestuj formularz i komunikaty błędów
Przejdź przez formularz kontaktowy, logowanie albo etap zamówienia. Nie wypełniaj tylko pierwszego pola. Sprawdź kolejność pól, checkboxów, wyboru dostawy, zgód i przycisku wysłania. Celowo zostaw wymagane pole puste, aby zobaczyć, co dzieje się po błędzie.
Dobry wynik oznacza, że komunikat błędu jest zauważalny, zrozumiały i osiągalny z klawiatury, a użytkownik wie, które pole poprawić. Jeżeli błąd jest widoczny wyłącznie jako czerwony obrys albo fokus trafia w niepowiązane miejsce, problem wymaga naprawy w formularzu.
WebAIM Million 2025 wskazuje, że brakujące etykiety formularzy wykryto na 48,2% analizowanych stron, a 34,2% badanych pól nie miało prawidłowego opisu. Dane dotyczą automatycznie wykrywalnych problemów i nie zastępują ręcznego testu formularza. Więcej praktycznych punktów kontroli znajdziesz w materiale Dostępność sklepu internetowego — checklista pierwszych kroków.
Jak ocenić fokus klawiatury?
Widoczny fokus powinien spełniać jednocześnie kilka warunków. Użytkownik ma go zauważyć bez zgadywania, rozpoznać element, który jest aktywny, i widzieć, że element nie został przykryty przez interfejs strony.
| Obszar testu | Dobry wynik | Sygnał błędu | Kierunek działania |
|---|---|---|---|
| Widoczność fokusu | Wyraźny obrys lub inne czytelne oznaczenie. | Fokus znika na zdjęciu, jasnym tle lub po wejściu w element. | Napraw style fokusu w kodzie źródłowym. |
| Kolejność Tab | Przejście odpowiada układowi i zadaniu użytkownika. | Skoki do stopki, bannerów lub odległych części widoku. | Sprawdź strukturę DOM, tabindex i komponenty. |
| Element sticky | Aktywny element pozostaje widoczny. | Nagłówek, cookie banner lub czat zakrywa fokus. | Napraw pozycjonowanie i zachowanie po fokusie. |
| Modal | Fokus działa w otwartym oknie i wraca do wyzwalacza po zamknięciu. | Fokus ucieka pod modal lub użytkownik nie może go zamknąć. | Napraw obsługę fokusu oraz mechanizm zamknięcia. |
| Formularz | Pola i błędy są osiągalne w logicznej kolejności. | Brak etykiety, pominięte pole albo błąd bez wskazania miejsca. | Popraw etykiety, walidację i komunikaty. |
Problem wykryty w teście a właściwy kierunek działania
WCAG 2.2 rozszerza oczekiwania dotyczące widoczności aktywnego elementu. Kryterium 2.4.11 Focus Not Obscured (Minimum) na poziomie AA wymaga, aby element otrzymujący fokus nie był całkowicie zasłonięty przez treść utworzoną przez autora strony. W praktyce sprawdź zwłaszcza przyklejony nagłówek, panel zgód, pasek promocji i widżet czatu.
Mini-scenariusz: test karty produktu w sklepie
Scenariusz ilustracyjny: osoba odpowiedzialna za sklep testuje kartę produktu bez myszy. Po odświeżeniu strony naciska Tab. Fokus przechodzi przez logo, menu i wyszukiwarkę, ale nie pokazuje się na przycisku wyboru rozmiaru. Następnie fokus trafia bezpośrednio do przycisku „Dodaj do koszyka”.
To nie musi oznaczać jednego problemu. Możliwe są co najmniej trzy przyczyny: wybór rozmiaru został zbudowany jako niestandardowy komponent bez obsługi klawiatury, element jest wizualnie podobny do przycisku, ale technicznie nie jest kontrolką, albo został pominięty przez błędne zarządzanie focusem.
W zgłoszeniu warto zapisać: „URL karty produktu → po trzech naciśnięciach Tab fokus omija wybór rozmiaru → oczekiwane: możliwość wyboru wariantu klawiaturą → rzeczywiste: przejście od wyszukiwarki do Dodaj do koszyka → wpływ: użytkownik nie może określić wariantu produktu”. Tak sformułowany opis pozwala zespołowi technicznemu odtworzyć błąd.
WCAGbot Accessibility Path: co zrobić po teście?
Wyniki screeningu warto uporządkować, aby nie kończyć na liście przypadkowych uwag. Schemat WCAGbot Accessibility Path porządkuje dalsze działania od szybkiego sprawdzenia do trwałej poprawy.
- Wykryj: przejdź kluczową ścieżkę wyłącznie klawiaturą.
- Opisz: zapisz URL, kroki, klawisz, rezultat i wpływ bariery.
- Uszereguj: najpierw popraw problemy blokujące zakup, kontakt, logowanie lub wysłanie formularza.
- Napraw źródłowo: zleć poprawę semantyki HTML, obsługi zdarzeń, fokusu, etykiet i komunikatów.
- Zweryfikuj: wykonaj test ponownie, a przy złożonych komponentach rozszerz go o audyt i testy z użytkownikami.
- Wesprzyj użytkownika: dodaj funkcje poprawiające komfort korzystania ze strony.
WCAGbot może być elementem ostatniego kroku: oferuje między innymi funkcje skupienia, większy kursor, przewodnik do czytania, kontrast oraz narzędzia typograficzne. Zobacz, jak działają kontrast, większy tekst i czytanie treści w WCAGbot. Te funkcje wspierają użytkownika, ale nie zastępują poprawy źle zbudowanego menu, pułapki w modalu czy pominiętego pola formularza.
Doświadczeniowe CTA: otwórz panel WCAGbot na własnej stronie, przetestuj kontrast, zwiększ tekst i sprawdź funkcje skupienia. Następnie ponownie wykonaj test klawiszem Tab, pamiętając, że zachowanie podstawowych komponentów strony nadal powinno wynikać z prawidłowego kodu.
Widget dostępności czy audyt: czego nie pomylić?
Widget dostępności może dać użytkownikowi dodatkowe możliwości dostosowania sposobu odbioru strony. Nie jest jednak narzędziem, które automatycznie zapewnia zgodność z WCAG lub usuwa wszystkie bariery. Szczególnie nie zastąpi naprawy logiki komponentów, kolejności fokusu, etykiet formularzy, komunikatów błędów i obsługi klawiatury.
To rozróżnienie omawiamy szczegółowo w artykule Widget dostępności a zgodność z WCAG: uczciwe porównanie. Jeżeli chcesz najpierw uruchomić funkcje wspierające dostępność bez przebudowy serwisu, przeczytaj też Jak zainstalować WCAGbot na stronie w 5 minut.
Karta zgłoszenia błędu klawiaturowego
Podsumowanie dla zarządzającego i sprzedaży
Test klawiaturą jest prostą kontrolą jakości ścieżki użytkownika. Nie wymaga specjalistycznego oprogramowania, a może ujawnić problemy, które bezpośrednio blokują realizację celu na stronie: zakup, wysłanie zapytania, logowanie, pobranie dokumentu lub znalezienie informacji.
Warto włączyć go do odbioru nowych funkcji, aktualizacji motywu WordPress, zmian w Shopify i wdrożeń kampanii z formularzami lub popupami. W przypadku e-commerce sprawdzaj przede wszystkim proces od znalezienia produktu do potwierdzenia działania w koszyku. Jeżeli działasz w obszarze usług objętych wymaganiami dostępności, przydatnym kontekstem będzie również artykuł Czy Polski Akt o Dostępności dotyczy sklepu online?.
Najważniejsza zasada jest prosta: szybki test ma prowadzić do konkretnych decyzji naprawczych, a nie do deklaracji, że strona została „sprawdzona”.
FAQ: nawigacja klawiaturą
Czy test klawiaturą wystarczy, aby potwierdzić zgodność z WCAG?
Nie. Test klawiaturą sprawdza istotny obszar dostępności, ale nie ocenia wszystkich kryteriów WCAG ani wszystkich scenariuszy użycia. Pełniejsza ocena wymaga audytu, analizy kodu, treści i testów odpowiednich komponentów.
Jakimi klawiszami testować stronę bez myszy?
Podstawowy zestaw to Tab, Shift+Tab, Enter, Spacja, Escape i strzałki. Ich zastosowanie zależy od rodzaju kontrolki. Tab służy zwykle do przechodzenia między elementami, a Enter lub Spacja do ich aktywacji.
Czy każdy element na stronie powinien otrzymywać fokus?
Nie. Fokus powinien trafiać do elementów interaktywnych i potrzebnych do obsługi strony. Elementy wyłącznie dekoracyjne, puste linki lub przypadkowe kontenery nie powinny zaśmiecać kolejności tabulacji.
Co oznacza widoczny fokus?
To czytelne oznaczenie elementu aktualnie wybranego klawiaturą. Może być obrysem, zmianą tła lub innym wyróżnieniem, o ile użytkownik łatwo rozpoznaje aktywny element.
Dlaczego fokus znika pod nagłówkiem sticky?
Zwykle przyczyną jest połączenie przewijania do aktywnego elementu z przyklejonym nagłówkiem, panelem cookie albo inną warstwą zasłaniającą treść. Tę sytuację należy naprawić w zachowaniu i stylach strony.
Co to jest pułapka klawiaturowa?
To sytuacja, w której użytkownik może wejść do komponentu klawiaturą, ale nie może go opuścić. Często występuje w błędnie wykonanych modalach, menu i niestandardowych widgetach.
Czy menu rozwijane musi działać strzałkami?
To zależy od zastosowanego wzorca komponentu. Najważniejsze jest, aby menu było osiągalne, możliwe do obsługi i zamknięcia z klawiatury oraz aby jego zachowanie było przewidywalne. Nie należy dodawać złożonych wzorców ARIA bez potrzeby i bez poprawnej implementacji.
Jak sprawdzić koszyk klawiaturą?
Przejdź od listy produktów do karty produktu, wybierz wariant, dodaj produkt, otwórz koszyk, zmień liczbę sztuk, usuń produkt i przejdź do kolejnego kroku. Zapisz każdy moment, w którym nie możesz wykonać działania albo tracisz orientację, gdzie znajduje się fokus.
Czy WCAGbot naprawi pułapkę klawiaturową w modalu?
Nie. Pułapka klawiaturowa wynika z logiki i implementacji komponentu, dlatego wymaga naprawy źródłowej w kodzie. WCAGbot może wspierać użytkownika dodatkowymi funkcjami dostępności, ale nie zastępuje takiej poprawki.
Jak często wykonywać test nawigacji klawiaturą?
Wykonuj go przy odbiorze nowych widoków i komponentów oraz po zmianach w menu, formularzach, popupach, koszyku, systemie płatności i motywie strony. Warto też okresowo powtarzać test na kluczowych ścieżkach, ponieważ aktualizacje mogą zmienić zachowanie fokusu.
Dodaj funkcje dostępności: przetestuj WCAGbot i dodaj funkcje wspierające dostępność swojej strony. Potraktuj je jako rozsądny pierwszy krok, równolegle planując audyt i naprawę barier wykrytych w kodzie oraz treści.
Źródła i materiały
- W3C, Web Content Accessibility Guidelines 2.2
- W3C, Web Content Accessibility Guidelines 2.2
- W3C, Web Content Accessibility Guidelines 2.2
- W3C, Web Content Accessibility Guidelines 2.2
- W3C, Web Content Accessibility Guidelines 2.2
- DWP Accessibility Manual
- WebAIM Million 2025
- www.w3.org
- www.w3.org
- design.homeoffice.gov.uk
- accessibility-manual.dwp.gov.uk
- accessibility-manual.dwp.gov.uk
