Najważniejsze wnioski
- Test klawiaturą sprawdza osiągalność, kolejność i widoczność fokusu oraz możliwość obsługi i opuszczenia komponentów bez myszy.
- Test czytnikiem ekranu powinien sprawdzać nazwę, rolę, stan i komunikaty elementów, a nie tylko to, czy treść jest odczytywana.
- Najlepszym zakresem testu jest kompletne zadanie użytkownika, na przykład produkt → koszyk → płatność, a nie wyłącznie pojedynczy widok.
- Widget dostępności może wspierać użytkownika funkcjami kontrastu, typografii, skupienia lub czytania treści, ale nie naprawia źródłowo błędnej semantyki, kolejności fokusu ani wadliwej obsługi formularza.
- Wyniki testów warto zapisywać wraz z krokiem, środowiskiem, skutkiem dla użytkownika i decyzją o naprawie, aby uniknąć regresji po zmianie motywu lub aplikacji.
Dla zarządzającego
Testy klawiaturą i czytnikiem ekranu są szybkim sposobem sprawdzenia ryzyka w kluczowych ścieżkach biznesowych. Nie zastępują audytu WCAG, ale pomagają ustalić kolejność napraw: najpierw bariery blokujące zakup, kontakt lub obsługę usługi, potem problemy wpływające na wygodę.
Dla sprzedaży
W rozmowie z klientem warto odróżnić funkcje wspierające dostępność od napraw źródłowych. WCAGbot może być prostym pierwszym krokiem uruchamianym jedną linią kodu, natomiast problemy takie jak pułapka klawiaturowa, pusty przycisk czy nieogłoszony błąd formularza wymagają sprawdzenia i poprawy w stronie lub aplikacji.
Testy klawiaturą i czytnikiem ekranu warto wykonywać razem, ponieważ badają inne warstwy doświadczenia użytkownika. Klawiatura odpowiada na pytanie, czy da się przejść przez interfejs bez myszy. Czytnik ekranu pozwala dodatkowo ocenić, czy użytkownik rozumie, na czym jest fokus, co może zrobić i co zmieniło się po wykonaniu akcji.
W e-commerce nie wystarczy sprawdzić strony głównej albo pojedynczego przycisku. Najważniejszy jest przebieg zadania: wyszukanie produktu, wybór wariantu, dodanie do koszyka, użycie kodu rabatowego, wypełnienie danych i przejście do płatności. Ten artykuł ma charakter informacyjny i praktyczny. Nie jest indywidualną oceną zgodności strony z WCAG, EN 301 549 ani Polskim Aktem o Dostępności.
Najważniejsze wnioski
- Przejdź krytyczne zadanie samą klawiaturą, zanim uruchomisz czytnik ekranu.
- Notuj nie tylko błąd techniczny, lecz także moment, w którym użytkownik nie może ukończyć zadania.
- Testuj menu, filtry, formularze, koszyk, płatność, okna modalne oraz komunikaty po zmianie stanu.
- Sprawdzaj stronę po zmianie motywu, aplikacji, checkoutu lub komponentu. To ogranicza ryzyko regresji opisane w artykule o regresji dostępności po zmianie motywu lub aplikacji.
- Używaj widgetu jako funkcji wspierającej dostępność, a nie jako zamiennika audytu i naprawy źródłowej.
Dlaczego test klawiaturą nie zastępuje testu czytnikiem ekranu?
Test klawiaturą sprawdza przede wszystkim mechanikę obsługi interfejsu. Tester odkłada mysz i używa klawiszy Tab, Shift + Tab, Enter, spacji, strzałek oraz Escape, gdy wzorzec komponentu tego wymaga. W3C wskazuje, że w takim teście należy zweryfikować dostęp do funkcji, logiczną kolejność fokusu, jego widoczność oraz brak pułapki klawiaturowej.
Jednak element może być osiągalny klawiszem Tab, a mimo to niezrozumiały dla osoby korzystającej z czytnika. Przykładowo ikonowy przycisk otwierający koszyk może działać z klawiatury, lecz zostać odczytany jako „przycisk” bez nazwy. Podobnie filtr produktów może otwierać się poprawnie, ale czytnik nie musi komunikować, czy lista jest rozwinięta.
Test czytnikiem ekranu weryfikuje więc dodatkowo:
- nazwę dostępną elementu,
- rolę, na przykład link, przycisk, pole wyboru lub zakładka,
- stan, na przykład rozwinięte, zaznaczone, wymagane albo nieaktywne,
- powiązanie etykiet, instrukcji i błędów z właściwymi polami,
- komunikowanie zmian dynamicznych, takich jak wynik wyszukiwania, dodanie produktu lub błąd walidacji.
Dostępny komponent nie tylko reaguje na klawisz. Musi też jasno powiedzieć użytkownikowi, czym jest, w jakim jest stanie i co wydarzyło się po akcji.
Co sprawdzić klawiaturą na stronie i w sklepie?
Najprostsza metoda to przejście jednej konkretnej ścieżki bez dotykania myszy. Nie oceniaj przy tym wyłącznie liczby kliknięć czy naciśnięć klawisza. Oceń, czy użytkownik stale wie, gdzie się znajduje i czy może wykonać zamierzoną akcję.
1. Czy fokus dociera do wszystkich potrzebnych elementów?
Używaj Tab, aby przechodzić dalej, oraz Shift + Tab, aby wracać. Fokus powinien trafiać do linków, przycisków, pól, przełączników, filtrów, kontrolek galerii, menu i funkcji checkoutu. Nie powinien zatrzymywać się na elementach ukrytych, dekoracyjnych albo nieaktywnych.
Sprawdź też, czy kolejność odpowiada kolejności zadania. Jeśli po polu „Kod pocztowy” fokus przechodzi do linku w stopce, a dopiero potem do „Miasta”, użytkownik może stracić orientację lub uznać formularz za uszkodzony.
2. Czy fokus jest zawsze widoczny i nie jest zasłonięty?
Widoczny fokus jest wymaganiem kryterium 2.4.7 WCAG na poziomie AA. WCAG 2.2 wprowadza również kryterium 2.4.11 Focus Not Obscured na poziomie AA: element z fokusem nie może być całkowicie zasłonięty przez treść dodaną przez autora, na przykład przyklejony nagłówek, pasek cookies lub czat.
WCAGbot Accessibility Path dla testów interakcji
W praktyce przetestuj stronę przy otwartym banerze, po przewinięciu oraz na mniejszej szerokości okna. Błąd często ujawnia się dopiero wtedy, gdy fokus trafia w dolną część ekranu pod sticky footerem.
3. Czy da się otworzyć, obsłużyć i zamknąć komponent?
Dotyczy to zwłaszcza menu, filtrów, list rozwijanych, galerii, dialogów, paneli logowania i wyboru dostawy. Po otwarciu dialogu fokus powinien znaleźć się w sensownym miejscu. Po zamknięciu powinien wrócić do kontrolki, która dialog otworzyła. Użytkownik nie może zostać uwięziony ani w samym komponencie, ani poza aktywnym oknem modalnym.
Jeżeli strona używa niestandardowych kontrolek, nie zakładaj, że zachowują się jak natywne elementy HTML. Warto porównać implementację z zasadami opisanymi w tekście ARIA bez pułapek: kiedy pomaga, a kiedy psuje dostępność.
4. Czy formularz można poprawić bez utraty danych?
W formularzu testuj kolejno: wejście do pola, odczyt etykiety, wprowadzenie danych, wywołanie błędu, dotarcie do komunikatu i poprawę wartości. Zwróć uwagę, czy błąd wskazuje właściwe pole oraz czy po wysłaniu formularza użytkownik wie, co się stało.
Praktyczne przykłady dla koszyka i płatności znajdziesz w materiale o dostępnych komunikatach błędów w koszyku i płatności, a podstawową listę problemów z etykietami, kontrastem i linkami w artykule Kontrast, alt i błędy formularza: checklista WCAG.
Jak testować stronę czytnikiem ekranu?
Test czytnikiem ekranu nie polega na biernym odsłuchaniu strony od początku do końca. Użytkownicy korzystają z różnych metod nawigacji: po nagłówkach, linkach, przyciskach, formularzach i regionach strony. W badaniu WebAIM nagłówki były najczęściej wskazywanym sposobem poruszania się po długiej stronie. Dlatego nieprawidłowa struktura nagłówków może utrudnić orientację nawet wtedy, gdy wizualny układ wygląda poprawnie.
Na start wybierz jedną kombinację zgodną z używanym systemem i przeglądarką, a następnie zapisuj środowisko testowe. Wynik może zależeć od kombinacji systemu operacyjnego, przeglądarki, czytnika ekranu i sposobu implementacji komponentu. Przy problemie krytycznym dobrze jest potwierdzić wynik w drugim środowisku lub przekazać go do weryfikacji audytorowi.
| Obszar | Test klawiaturą | Test czytnikiem ekranu | Przykład bariery |
|---|---|---|---|
| Przycisk koszyka | Czy można do niego dotrzeć i aktywować go? | Czy ma nazwę „Koszyk” i właściwą rolę? | Ikona odczytana jako pusty przycisk. |
| Menu i filtry | Czy można je otworzyć, obsłużyć i zamknąć? | Czy ogłaszany jest stan rozwinięcia? | Lista się otwiera, ale stan nie jest komunikowany. |
| Pole formularza | Czy fokus dociera do pola w dobrej kolejności? | Czy odczytana jest etykieta, wymaganie i błąd? | Czytnik mówi tylko „edycja”. |
| Komunikat po akcji | Czy po akcji można dojść do informacji? | Czy zmiana jest ogłoszona automatycznie? | Produkt dodano do koszyka bez informacji dla czytnika. |
| Dialog | Czy fokus nie ucieka i można zamknąć okno? | Czy czytnik komunikuje tytuł i kontekst dialogu? | Fokus trafia pod modal, a treść dialogu nie jest jasna. |
WCAGbot Accessibility Path: jak zorganizować test bez chaosu?
WCAGbot Accessibility Path to prosty schemat porządkujący pierwszy cykl testowy. Nie jest metodą certyfikacji i nie zastępuje profesjonalnego audytu. Pomaga zespołowi przejść od obserwacji do naprawy oraz retestu.
- Wybierz zadanie krytyczne. Dla sklepu będzie to zwykle produkt → wariant → koszyk → dostawa → płatność. Dla usługi cyfrowej: oferta → formularz → potwierdzenie.
- Przejdź zadanie klawiaturą. Zapisz miejsca, do których nie można dotrzeć, których nie da się aktywować albo opuścić.
- Powtórz zadanie z czytnikiem ekranu. Sprawdź nazwy, role, stany, strukturę nagłówków i komunikaty dynamiczne.
- Opisz skutek. Zamiast notatki „ARIA nie działa”, zapisz: „Po otwarciu filtrów użytkownik nie otrzymuje informacji, że lista jest rozwinięta i nie wie, gdzie kontynuować”.
- Rozdziel wsparcie od naprawy źródłowej. Ustal, które działania są zmianą w kodzie, treści, konfiguracji komponentu lub integracji zewnętrznej.
- Wykonaj retest. Powtórz dokładnie ten sam krok po wdrożeniu poprawki i po większej aktualizacji strony.
Klawiatura a czytnik ekranu — co wykrywa każdy test
Mini-scenariusz: test zakupu w sklepie internetowym
Scenariusz ilustracyjny — nie jest opisem wdrożenia klienta. Sklep sprzedaje produkty w kilku wariantach. Zespół wybiera zadanie: „Znajdź produkt, wybierz rozmiar, dodaj go do koszyka, zmień liczbę sztuk i przejdź do danych dostawy”.
- Tester przechodzi stronę klawiszem
Tab. Zauważa, że fokus przycisku „Dodaj do koszyka” jest niemal niewidoczny na zdjęciu produktu. - Po wybraniu rozmiaru przyciskiem klawiatury tester widzi zmianę wizualną, ale po dodaniu produktu nie dostaje jasnego potwierdzenia bez patrzenia na ekran.
- W teście czytnikiem przycisk wyboru wariantu jest odczytywany bez informacji, który wariant jest zaznaczony.
- W koszyku po zmianie liczby sztuk cena aktualizuje się wizualnie, lecz czytnik nie komunikuje nowej wartości ani sumy.
W tym przykładzie narzędzia typograficzne, kontrastowe lub funkcje skupienia mogą ułatwić części użytkowników korzystanie z strony. Nie rozwiązują jednak błędnej informacji o stanie wariantu ani braku komunikatu o aktualizacji koszyka. Te bariery wymagają naprawy źródłowej w komponencie i ponownego testu.
Jeżeli planujesz zakres testów dla sklepu, połącz go z mapą dostępności sklepu: od produktu do kontaktu. Dla testu samego czytnika pomocnym rozwinięciem będzie też plan startowy testowania sklepu czytnikiem ekranu.
Jak zapisywać wyniki, aby dało się je naprawić?
Lista błędów bez kontekstu szybko traci wartość. Każde zgłoszenie powinno zawierać adres, krok zadania, użyte środowisko, oczekiwane i rzeczywiste zachowanie oraz skutek dla użytkownika. Dodaj informację, czy problem blokuje ukończenie zadania, czy przede wszystkim spowalnia i dezorientuje.
Przykładowy zapis:
- Krok: koszyk, zmiana liczby produktów.
- Środowisko: [wpisać użyty system, przeglądarkę i czytnik].
- Rzeczywiste zachowanie: cena zmienia się na ekranie, ale zmiana nie jest komunikowana przez czytnik.
- Skutek: użytkownik nie wie, czy akcja się powiodła ani jaka jest aktualna wartość zamówienia.
- Decyzja: sprawdzić komunikat statusu, nazwę kontrolki i obsługę aktualizacji komponentu; po naprawie wykonać retest.
Przy większym zakresie lub przy wymaganiach formalnych warto zamówić audyt z jasno opisanym zakresem i kryteriami odbioru. Pomocny będzie artykuł Jak zamówić audyt WCAG: brief i kryteria odbioru.
Gdzie widget dostępności pomaga, a gdzie kończy się jego rola?
WCAGbot można uruchomić po dodaniu jednej linii kodu. Widget udostępnia między innymi tryby kontrastu, skalę szarości i nasycenie, powiększenie tekstu, interlinię i odstępy, czytanie treści, większy kursor, funkcje skupienia i przewodnik do czytania. Może więc wspierać użytkownika podczas korzystania z istniejącej strony oraz stanowić pierwszy krok do dostępności.
Otwórz panel WCAGbot na własnej stronie, zwiększ tekst, przetestuj kontrast i sprawdź, czy podczas nawigacji klawiaturą fokus pozostaje widoczny. To doświadczenie pomoże rozróżnić funkcję wspierającą komfort od błędu, który trzeba usunąć w kodzie lub treści.
Widget nie zastąpi testów klawiaturą, testów z czytnikiem ekranu, audytu WCAG ani trwałej naprawy takich problemów jak nieprawidłowa kolejność fokusu, pułapka klawiaturowa, puste przyciski, źle zbudowany dialog czy brak komunikatu o błędzie. Więcej o tym wyborze przeczytasz w artykule Widget dostępności czy audyt WCAG przy małym budżecie?.
Podsumowanie dla zarządzającego i sprzedaży
Dla zarządzającego testy są sposobem na znalezienie barier w procesach ważnych dla przychodu, obsługi klienta i reputacji usługi. Najbardziej użyteczny rezultat to uporządkowana lista: co blokuje zadanie, kto odpowiada za naprawę i jak zostanie potwierdzona poprawa.
Karta zgłoszenia bariery w koszyku
Dla sprzedaży i zespołu obsługi ważne jest precyzyjne komunikowanie zakresu. Funkcje WCAGbot wspierają dostępność i mogą zostać uruchomione szybko bez przebudowy strony. Nie są jednak deklaracją pełnej zgodności z WCAG, EN 301 549 czy Polskim Aktem o Dostępności. W przypadku krytycznych ścieżek warto połączyć szybkie wsparcie użytkownika z planem audytu i napraw źródłowych.
FAQ: testy klawiaturą i czytnikiem ekranu
Czy test klawiaturą wystarczy do sprawdzenia dostępności strony?
Nie. Test klawiaturą jest konieczny, ale nie sprawdza w pełni nazw, ról, stanów, etykiet i komunikatów odczytywanych przez czytnik ekranu. Trzeba go uzupełnić co najmniej podstawowym testem czytnikiem oraz szerszą oceną zależną od zakresu strony.
Od jakiej ścieżki zacząć test sklepu internetowego?
Zacznij od ścieżki mającej największe znaczenie dla użytkownika i biznesu: wyszukanie produktu, wybór wariantu, koszyk, dostawa, płatność i potwierdzenie. Następnie przetestuj kontakt, logowanie, rejestrację i odzyskiwanie hasła.
Jakie klawisze wykorzystać w podstawowym teście?
Podstawą są Tab, Shift + Tab, Enter, spacja, strzałki i Escape. Konkretne zachowanie zależy od typu komponentu. Dobrze zbudowany komponent nie powinien wymagać zgadywania niestandardowych skrótów.
Co oznacza pułapka klawiaturowa?
To sytuacja, w której użytkownik może wejść fokusem do komponentu, ale nie potrafi go opuścić klawiaturą. Często dotyczy źle wdrożonych okien modalnych, filtrów, osadzonych elementów lub niestandardowych kontrolek.
Czy widoczny fokus musi być sprawdzany na urządzeniach mobilnych?
Warto oceniać interfejs także w widokach mobilnych, zwłaszcza gdy strona ma przyklejone nagłówki, dolne paski lub otwierane panele. Sam sposób interakcji może być inny, ale zasada niezasłaniania aktywnego elementu i czytelnej informacji o stanie nadal ma znaczenie.
Czy wystarczy użyć jednego czytnika ekranu?
Na pierwszy test można wybrać jedno środowisko. W przypadku problemu blokującego zadanie warto jednak powtórzyć test w drugim środowisku albo zlecić weryfikację specjaliście. Różne kombinacje czytnika, systemu i przeglądarki mogą dawać różne rezultaty.
Co sprawdzić czytnikiem ekranu w formularzu?
Sprawdź, czy pole ma etykietę, czy wymaganie jest komunikowane, czy instrukcja jest dostępna, czy błąd jest związany z właściwym polem oraz czy po wysłaniu formularza użytkownik otrzymuje zrozumiałą informację o wyniku.
Czy nagłówki mają znaczenie w teście czytnikiem?
Tak. Nagłówki pomagają poruszać się po strukturze długiej strony. Należy sprawdzić, czy opisują sekcje, zachowują sensowną hierarchię i nie są wykorzystywane wyłącznie dla efektu wizualnego. Zobacz także Nagłówki i linki: strona zrozumiała bez wzroku.
Czy WCAGbot naprawi problemy wykryte czytnikiem ekranu?
Nie wszystkie. WCAGbot oferuje funkcje wspierające dostępność, a w wykrywalnych przypadkach może automatycznie uzupełniać wybrane atrybuty ARIA, alt i title. Nie zastąpi jednak naprawy błędnej semantyki, logiki komponentu, kolejności fokusu, etykiet formularzy czy komunikatów dynamicznych w kodzie źródłowym.
Jak często powtarzać testy?
Powtarzaj test po zmianach w motywie, checkoutcie, formularzach, aplikacjach zewnętrznych, menu i komponentach interaktywnych. Warto również wykonywać okresowy przegląd krytycznych ścieżek, ponieważ aktualizacje mogą wprowadzić regresję.
Kiedy potrzebny jest audyt WCAG?
Audyt jest wskazany, gdy potrzebujesz szerszej, udokumentowanej oceny, planu napraw według kryteriów WCAG, weryfikacji wielu widoków albo niezależnego potwierdzenia problemów wykrytych wewnętrznie. Testy opisane w tym artykule pomagają dobrze przygotować taki zakres.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot. Sprawdź na własnym przykładzie kontrast, powiększenie tekstu, czytanie treści i funkcje skupienia, a równocześnie zaplanuj audyt oraz naprawy źródłowe dla barier w kluczowych ścieżkach. Dodaj funkcje dostępności.
