Testowanie dostępności: przewodnik na start

Dostępność to nie miły dodatek. To test, czy da się u Ciebie skorzystać z produktu

Wiele zespołów traktuje dostępność jak temat z kategorii dobrze byłoby, ale teraz mamy ważniejsze rzeczy. Tylko że dostępność nie znika dlatego, że masz sprint, deadline i plan sprzedażowy. Ona po prostu wraca w innej formie. W porzuconych koszykach, w nieudanych rejestracjach, w ciszy po stronie użytkownika, który nie napisze do supportu, bo uzna, że to nie jego problem. Kliknie wstecz i pójdzie dalej. I dokładnie dlatego testowanie dostępności jest dziś twardym tematem jakości, a nie grzecznym dodatkiem do backlogu.

Skala jest większa, niż wielu osobom się wydaje. W Polsce w 2024 roku było 3,9 mln osób z ważnym orzeczeniem o niepełnosprawności, czyli około 10,5 procent populacji. To dane publiczne, stabilne i niewygodne dla każdego, kto lubi myśleć o dostępności jak o niszy. Równolegle rośnie udział osób starszych. W Unii Europejskiej osoby 65+ stanowiły 22 procent populacji na 1 stycznia 2025, a starzenie się społeczeństwa jest trendem, który nie pyta o to, czy mamy na to budżet w tym kwartale. Jeśli połączysz te fakty z tym, jak ludzie realnie korzystają z internetu, na szybko, w stresie, z gorszym światłem, czasem jedną ręką, to zobaczysz, że dostępność nie dotyczy małej grupy. Ona dotyczy bardzo wielu sytuacji, które zdarzają się codziennie, nawet Twoim najbardziej typowym użytkownikom.

Do tego dochodzi presja regulacyjna. Europejski Accessibility Act wyznacza kierunek, a obowiązki dostępnościowe dla wybranych produktów i usług cyfrowych wchodzą w życie w praktyce rynkowej od 28 czerwca 2025 roku. Niezależnie od tego, czy Twoja organizacja już to „czuje”, w wielu branżach wkrótce zacznie to być standardem, a nie ciekawostką. I wreszcie, jest jeszcze powód najbardziej pragmatyczny. Dostępność ma bezpośredni wpływ na to, co w e commerce jest święte, czyli na konwersję. Baymard, który od lat rozkłada checkouty na czynniki pierwsze, pokazuje, że poprawki w obszarze doświadczenia zakupowego, w tym te dotyczące czytelności, komunikatów błędów i obsługi formularzy, potrafią dać mierzalny wzrost wyników. Nie trzeba nawet spierać się o to, jaki procent tego efektu jest „czystą dostępnością”. Wystarczy zrozumieć mechanikę. Gdy usuwasz bariery, zmniejszasz tarcie. Gdy zmniejszasz tarcie, więcej osób przechodzi przez proces.

WCAG 2.2 w praktyce. Cztery zasady, które da się testować bez filozofii

WCAG 2.2 brzmi dla wielu osób jak dokument dla audytorów, ale dla QA to może być bardzo praktyczna mapa ryzyk, o ile przetłumaczysz ją na pytania testowe. Standard opiera się na czterech zasadach, które W3C opisuje jasno, a Ty możesz potraktować jak cztery filtry na krytycznych ścieżkach.

Postrzegalność to pytanie o to, czy informacja dociera. Czy komunikat o błędzie ma sens bez widzenia koloru. Czy kluczowe informacje nie są zaszyte w ikonach bez etykiet. Czy zdjęcie produktu ma sensowny alt tam, gdzie obraz niesie informację. Czy przy powiększeniu do 200 procent strona nadal jest czytelna i klikalna. Operowalność to pytanie o to, czy da się obsłużyć interfejs bez myszy. Czy przejdziesz całą ścieżkę Tabem i Shift Tab. Czy fokus jest widoczny. Czy nie ma pułapek fokusu w modalach. Czy dropdowny działają strzałkami. Czy slider nie jest jedyną drogą ustawienia wartości. Zrozumiałość to pytanie o to, czy użytkownik rozumie, co ma zrobić, zwłaszcza gdy popełni błąd. Czy formularz mówi wprost, co poprawić. Czy błąd jest powiązany z polem. Czy po błędzie fokus trafia tam, gdzie jest problem. Solidność to wreszcie pytanie o semantykę i odporność kodu na technologie asystujące. Czy przyciski są przyciskami, a nie udającymi je divami. Czy label jest połączony z inputem. Czy struktura nagłówków ma sens. Czy ARIA jest użyta tam, gdzie trzeba, a nie tam, gdzie ktoś ją dopisał dla świętego spokoju.

Jeśli miałbym dać Ci jedno zdanie, które dobrze ustawia głowę QA na start, brzmiałoby ono tak. Nie pytaj, czy strona wygląda dobrze. Pytaj, czy da się na niej wykonać cel bez myszy, bez perfekcyjnego wzroku i bez domyślania się, co autor miał na myśli.

Automaty pomagają, ale nie testują dostępności

To jest miejsce, gdzie wiele zespołów popełnia ten sam błąd. Odpalają Lighthouse, podpinają axe, widzą listę błędów, robią kilka poprawek, a potem zakładają, że temat jest z głowy. Automatyczne narzędzia są świetne, ale tylko w jednej roli. One są szybkim filtrem i wykrywaczem regresji. Potrafią złapać brak etykiet, brak alt, część problemów semantycznych, czasem kontrast. Nie potrafią natomiast przejść doświadczenia jak człowiek. Nie ocenią, czy fokus porusza się logicznie. Nie sprawdzą, czy komunikat błędu jest zrozumiały. Nie powiedzą Ci, czy screen reader prowadzi użytkownika przez checkout w sensownej kolejności. Dlatego dostępność zawsze testuje się hybrydowo. Automat daje szybki sygnał, manual daje prawdę.

Najkrótsza definicja testowania dostępności

Testowanie dostępności to odpowiedź na pytanie, czy da się wykonać kluczowy cel użytkownika bez przeszkód, kiedy użytkownik korzysta z klawiatury, czytnika ekranu, wysokiego kontrastu albo powiększenia. I tu wchodzi zasada, która ratuje czas i zdrowie psychiczne. Nie testuj wszystkiego. Testuj tam, gdzie są pieniądze i ryzyko. Login, rejestracja, wyszukiwarka, listing, filtry, karta produktu, koszyk, checkout, płatność, reset hasła. Jeśli tam jest dobrze, reszta jest do zrobienia w procesie. Jeśli tam jest źle, masz problem, którego nie przykryje żadna kampania.

Siedem testów manualnych, które zrobisz od razu

Pierwszy test jest najprostszy i jednocześnie najbardziej bezlitosny. Test klawiaturą. Odkładasz mysz i przechodzisz całą krytyczną ścieżkę Tabem, Shift Tab, Enterem, Space i strzałkami. Oczekiwany wynik jest jasny. Da się przejść całą ścieżkę, fokus jest widoczny, nie ma pułapek fokusu, nie da się utknąć w komponencie. Jeśli utkniesz Ty, utknie część użytkowników. Drugi test to test kolejności fokusu. Czasem da się przejść Tabem, ale kolejność jest tak nielogiczna, że użytkownik ma wrażenie, jakby interfejs robił mu psikus. Fokus powinien iść zgodnie z czytaniem i logiką ekranu, a nie zgodnie z przypadkową strukturą DOM. Trzeci test to formularze i błędy. Bierzesz krytyczny formularz, generujesz błędy i sprawdzasz, czy komunikat mówi co poprawić, czy błąd jest powiązany z polem, czy fokus po błędzie trafia tam, gdzie trzeba, i czy screen reader odczyta błąd. To jest obszar, w którym „coś poszło nie tak” kosztuje realne pieniądze.

Czwarty test to kontrast i skalowanie. Powiększasz stronę do 200 procent, zwiększasz rozmiar tekstu, sprawdzasz czy nic się nie rozjeżdża i czy elementy nadal są klikalne. Piąty test to screen reader na jednej ścieżce. Nie musisz zostać ekspertem. Wybierz checkout i przejdź go z NVDA na Windows albo VoiceOver na macOS. Sprawdzasz, czy nagłówki mają hierarchię, czy elementy są nazwane, czy przyciski mówią co robią, czy pola mają etykiety, czy błędy są ogłaszane. Szósty test to linki i przyciski. Jeśli masz „kliknij tutaj”, masz problem, bo bez kontekstu to nie znaczy nic, zwłaszcza dla osób, które poruszają się po liście linków. Siódmy test to treść i mikrocopy. Dostępność to także język. Zbyt trudne komunikaty, brak kontekstu, brak wskazania co dalej po błędzie, to są bariery równie skuteczne jak popsuty fokus.

Narzędzia na start i bramka w CI. Tylko z głową

Na start wystarczy Ci skaner w przeglądarce. axe DevTools albo Lighthouse jako szybki filtr. Cel nie jest taki, żeby mieć wynik 100. Cel jest taki, żeby złapać oczywiste rzeczy i nie wypuścić regresji. Jeśli chcesz pójść krok dalej, podepnij szybkie testy dostępności do pipeline jako bramkę. Nie jako audyt, tylko jako wykrywacz pogorszenia. Tu świetnie działa zasada minimalizmu. Testuj krytyczne strony, nie cały serwis. Home, listing, product, cart, checkout. Jeśli coś się pogorszy, pipeline ma krzyknąć zanim pójdzie release. W tym podejściu chodzi o utrzymanie standardu, a nie o jednorazowy zryw, co dobrze wpisuje się w ogólne praktyki optymalizacji CI CD i skracania cyklu wdrożenia.

Plan wdrożenia w cztery tygodnie, który naprawdę da się zrobić

Pierwszy tydzień to wybór ścieżek i baseline. Wybierasz trzy do pięciu krytycznych ścieżek, robisz szybki manual klawiaturą i szybki skan automatem, zapisujesz wyniki jako punkt odniesienia. Drugi tydzień to poprawki, które dają największy zwrot. Etykiety, fokus, błędy formularzy, podstawowa semantyka, kontrast w kluczowych miejscach. Trzeci tydzień to testy jak użytkownik. Przejście screen readerem na krytycznych ścieżkach, test powiększenia i wysoki kontrast. Czwarty tydzień to proces i utrzymanie. Checklista w Definition of Done dla kluczowych ekranów, prosta bramka w CI, jasny właściciel regresji dostępności. Bez właściciela temat wraca zawsze, bo dostępność psuje się po cichu i często przy okazji.

Pułapki, które widzę najczęściej

Pierwsza pułapka to myślenie, że automat załatwi temat. To jest kuszące, bo daje szybki wynik, ładny raport i poczucie kontroli. Odpalasz Lighthouse albo axe, dostajesz listę błędów, poprawiasz kilka flag i masz wrażenie, że zrobiłeś robotę. Tylko że automaty łapią głównie to, co da się formalnie wykryć w kodzie. Nie powiedzą Ci, że fokus skacze jak chce. Nie pokażą, że w modalu da się zgubić i wyjść na tło. Nie ocenią, czy komunikat błędu jest zrozumiały, czy tylko „popraw pole”. Najgorsze jest to, że po takim automatycznym sprincie zespół uznaje temat za zamknięty i przestaje patrzeć na dostępność oczami użytkownika. A dostępność nie jest stanem raportu. To jest stan przejścia przez ścieżkę.

Druga pułapka to próba naprawienia wszystkiego naraz. Zaczyna się niewinnie. Ktoś mówi: zróbmy audyt całego serwisu, bo inaczej to nie ma sensu. I nagle zamiast realnej poprawy w checkoutcie masz tabelę z setkami punktów, pół backlogu, frustrację po stronie zespołu i naturalne pytanie: kiedy my to zrobimy. Efekt bywa paradoksalny. Organizacja ma najwięcej energii na starcie, a potem temat grzęźnie w skali. Dlatego dostępność wdraża się przez krytyczne ścieżki. Nie przez totalny audyt, tylko przez miejsca, gdzie użytkownik podejmuje decyzję, wpisuje dane, płaci, resetuje hasło, kończy proces. Naprawiasz to, co blokuje, a nie to, co ładnie wygląda w raporcie.

Trzecia pułapka to brak rytuału utrzymania. Jednorazowy projekt nie działa, działa nawyk. Dostępność psuje się najczęściej przy okazji. Nowy komponent. Zmiana w CSS. Banner promocyjny. Pop up z zapisem do newslettera. Drobna refaktoryzacja, po której znika widoczny fokus. I jeśli nie masz prostego rytmu, to regresje wchodzą cicho, bez alarmu, a potem wracasz do punktu wyjścia. Rytuał w praktyce to nie rewolucja. To mały standard w Definition of Done, checklisty na kluczowych ekranach, szybkie testy na krytycznych ścieżkach przy release i prosta bramka w CI, która nie pozwoli przepchnąć oczywistych regresji.

Czwarta pułapka jest najbardziej ludzka i przez to najbardziej zdradliwa. Myślenie, że dostępność jest dla kogoś innego. Dla osób z niepełnosprawnościami, których nie widzimy w naszych danych. Dla instytucji publicznych, nie dla nas. Dla dużych firm, nie dla zespołu, który ma dowieźć wynik w tym kwartale. Tylko że w realnym życiu każdy z nas bywa użytkownikiem z ograniczeniami. Czasem to trwa godzinę, bo masz gorsze światło, rozbitą szybę w telefonie albo jedną rękę zajętą dzieckiem i zakupami. Czasem to trwa miesiące, bo jesteś po kontuzji albo przemęczony i nie masz zasobów poznawczych na zgadywanie, co autor formularza miał na myśli. A czasem to trwa lata. Dostępność jest więc mniej o tym, czy robisz coś „dla innych”, a bardziej o tym, czy Twoje produkty są odporne na prawdziwe życie.

Jest jeszcze jedna pułapka, o której rzadko mówi się wprost, a która potrafi wysadzić najlepsze intencje. Traktowanie dostępności jak tematu czysto technicznego. Jakby wystarczyło dopisać trochę ARIA, zmienić kilka tagów i po sprawie. Tymczasem ogromna część barier rodzi się w treści, w mikrocopy, w kolejności kroków, w sposobie walidacji, w tym, co komunikujesz użytkownikowi w stresie. Jeśli chcesz wygrać z tą pułapką, musisz testować nie tylko kod, ale też doświadczenie. A to z definicji wymaga manuala, choćby krótkiego, ale regularnego.

Jeśli miałbym to spiąć w jedno zdanie, byłoby takie. Największym wrogiem dostępności nie jest brak wiedzy o WCAG. Największym wrogiem jest przekonanie, że to da się zrobić raz i mieć z głowy.

Podsumowanie

Testowanie dostępności to nie checkbox do raportu. To strategia ochrony przychodu, zasięgu i jakości doświadczenia. Automaty są potrzebne, ale manualne testy decydują, czy człowiek naprawdę może skorzystać z Twojego produktu. Jeśli dziś nie testujesz dostępności ręcznie, to nie znaczy, że jej nie potrzebujesz. To znaczy, że jeszcze nie widzisz kosztu jej braku.

W Quality Island pomagamy zespołom QA i IT wdrażać praktyczne testowanie dostępności bez wielkich, papierowych programów. Zaczynamy od krytycznych ścieżek, manualnych testów i prostych bramek w CI, żeby efekt był widoczny w tygodniach, nie w kwartałach. Jeśli chcesz, przygotuję dla Twojego zespołu gotową checklistę Definition of Done pod WCAG 2.2 oraz zestaw minimalnych testów regresji dostępności dla kluczowych ekranów.