Testowanie dostępności: przewodnik na start

Wiele zespołów traktuje dostępność jak temat z kategorii „dobrze byłoby, ale teraz mamy ważniejsze rzeczy na głowie”. Tylko że dostępność nie przestaje być ważna dlatego, że macie sprint, termin i plan sprzedażowy. Jej brak pokazuje się w innej formie. W porzuconych koszykach, w nieudanych rejestracjach, w ciszy po stronie użytkownika, który nie napisze do wsparcia, bo uzna, że to nie jego problem. Kliknie wstecz i pójdzie do konkurencji. Dostępność to nie miły dodatek. To test, czy da się u Was skorzystać z produktu.

Do tego doszła presja regulacyjna. Europejski Akt o Dostępności, dyrektywa 2019/882, obowiązuje od 28 czerwca 2025 roku, a w Polsce od tego samego dnia stosowana jest ustawa wdrażająca go dla produktów i usług podmiotów prywatnych, w tym handlu elektronicznego i bankowości detalicznej. Niezależnie od tego, czy Wasza organizacja już to czuje, w wielu branżach dostępność przestała być ciekawostką, a stała się wymogiem. I jest jeszcze powód najbardziej pragmatyczny: gdy usuwacie bariery, zmniejszacie tarcie. Gdy zmniejszacie tarcie, więcej osób przechodzi przez proces. Ten przewodnik pokazuje, jak zacząć testować dostępność bez wielkiego audytu, w cztery tygodnie, na krytycznych ścieżkach.

WCAG 2.2 w praktyce: cztery zasady, które da się testować

WCAG 2.2 brzmi dla wielu osób jak dokument dla audytorów, ale dla QA może być bardzo praktyczną mapą ryzyk, o ile przetłumaczycie ją na pytania testowe. Standard W3C opiera się na czterech zasadach: postrzegalność, funkcjonalność, zrozumiałość i solidność. Możecie potraktować je jak cztery filtry na krytycznych ścieżkach.

Jedno zdanie, które dobrze ustawia głowę QA na start: nie pytajcie, czy strona wygląda dobrze. Pytajcie, czy da się na niej wykonać cel bez myszy, bez perfekcyjnego wzroku i bez domyślania się, co autor miał na myśli. WCAG 2.2 dołożyło do wcześniejszej wersji kilka kryteriów, które dla e-commerce są szczególnie praktyczne: fokus nie może być zasłonięty przez inne elementy, cele dotykowe muszą mieć minimalny rozmiar, użytkownik nie powinien wpisywać drugi raz danych, które już podał w tym samym procesie, a logowanie nie może wymagać testu poznawczego bez alternatywy. Każde z nich da się sprawdzić w checkoucie w kwadrans.

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

To miejsce, gdzie wiele zespołów popełnia ten sam błąd. Odpalają automatyczny skaner, widzą listę błędów, robią kilka poprawek, a potem zakładają, że temat jest z głowy. Narzędzia automatyczne są świetne, ale tylko w jednej roli: szybkiego filtra i wykrywacza regresji. Potrafią złapać brak etykiet, brak opisów alternatywnych, część problemów semantycznych, czasem kontrast. Nie potrafią przejść doświadczenia jak człowiek. Nie ocenią, czy fokus porusza się logicznie, czy komunikat błędu jest zrozumiały, czy czytnik ekranu prowadzi użytkownika przez checkout w sensownej kolejności. Dlatego dostępność zawsze testuje się hybrydowo: automat daje szybki sygnał, człowiek daje prawdę.

Najkrótsza definicja testowania dostępności brzmi: odpowiedź na pytanie, czy da się wykonać kluczowy cel użytkownika bez przeszkód, kiedy korzysta z klawiatury, czytnika ekranu, wysokiego kontrastu albo powiększenia. I tu wchodzi zasada, która ratuje czas: nie testujcie wszystkiego. Testujcie tam, gdzie są pieniądze i ryzyko. Logowanie, 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, macie problem, którego nie przykryje żadna kampania.

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

Pierwszy test jest najprostszy i jednocześnie najbardziej bezlitosny. Jeśli utkniecie Wy, utknie część użytkowników. Test trzeci to obszar, w którym „coś poszło nie tak” kosztuje realne pieniądze, bo formularz z niejasnym błędem to porzucony koszyk. Test piąty nie wymaga zostania ekspertem: wybierzcie checkout i przejdźcie go raz z czytnikiem ekranu. Po dziesięciu minutach będziecie wiedzieli więcej o swoim produkcie niż po miesiącu raportów. Jak wpiąć dostępność w definicję ukończenia, żeby te testy nie były jednorazowym zrywem, opisujemy w tekście o tym, dlaczego dostępność nie jest opcją i jak zrobić z WCAG element DoD.

Narzędzia na start i bramka w CI, tylko z głową

Na start wystarczy skaner w przeglądarce jako szybki filtr. Cel nie jest taki, żeby mieć wynik sto na sto. Cel jest taki, żeby złapać oczywiste rzeczy i nie wypuścić regresji. Jeśli chcecie pójść krok dalej, podepnijcie szybkie testy dostępności do pipeline’u jako bramkę. Nie jako audyt, tylko jako wykrywacz pogorszenia. Tu działa zasada minimalizmu: testujcie krytyczne strony, nie cały serwis. Strona główna, listing, karta produktu, koszyk, checkout. Jeśli coś się pogorszy, pipeline ma krzyknąć, zanim pójdzie wydanie. Chodzi o utrzymanie standardu, a nie o jednorazowy zryw. Dostępność testuje się wspólnie z UX, bo większość barier rodzi się na styku projektu i kodu, o czym piszemy w tekście o tym, co może się wydarzyć, gdy QA i UX rozmawiają.

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

Bez właściciela temat wraca zawsze, bo dostępność psuje się po cichu i często przy okazji. Nowy komponent, zmiana w stylach, baner promocyjny, okno z zapisem do newslettera, drobna refaktoryzacja, po której znika widoczny fokus. Jeśli nie macie prostego rytmu, regresje wchodzą bez alarmu, a potem wracacie do punktu wyjścia.

Cztery pułapki, które widzimy najczęściej

Automat załatwi temat. Kuszące, bo daje szybki wynik i ładny raport. Automaty łapią to, co da się formalnie wykryć w kodzie. Nie powiedzą, że fokus skacze, jak chce, ani że komunikat błędu jest niezrozumiały. Dostępność nie jest stanem raportu. To stan przejścia przez ścieżkę.

Naprawimy wszystko naraz. Audyt całego serwisu kończy się tabelą z setkami punktów, pół backlogu i pytaniem „kiedy my to zrobimy”. Organizacja ma najwięcej energii na starcie, a potem temat grzęźnie w skali. Dostępność wdraża się przez krytyczne ścieżki, tam gdzie użytkownik podejmuje decyzję, wpisuje dane, płaci.

Brak rytuału utrzymania. Jednorazowy projekt nie działa, działa nawyk: mały standard w definicji ukończenia, szybkie testy na krytycznych ścieżkach przy wydaniu, bramka w CI.

Dostępność jest dla kogoś innego. Najbardziej ludzka i przez to najbardziej zdradliwa pułapka. W realnym życiu każdy bywa użytkownikiem z ograniczeniami. Czasem przez godzinę, bo ma gorsze światło, rozbitą szybę w telefonie albo jedną rękę zajętą dzieckiem i zakupami. Czasem przez miesiące, po kontuzji albo z przemęczenia. Dostępność jest mniej o tym, czy robicie coś „dla innych”, a bardziej o tym, czy Wasze produkty są odporne na prawdziwe życie.

Podsumowanie

Testowanie dostępności to nie pole do odhaczenia w raporcie. To ochrona przychodu, zasięgu i doświadczenia użytkownika, a od czerwca 2025 także wymóg dla wielu produktów i usług podmiotów prywatnych. Testy automatyczne są potrzebne, ale testy manualne decydują, czy człowiek naprawdę może skorzystać z Waszego produktu. Jeśli dziś nie testujecie dostępności ręcznie, to nie znaczy, że jej nie potrzebujecie. To znaczy, że jeszcze nie widzicie kosztu jej braku. Opisujemy tu wymogi i praktykę testową, nie udzielamy porady prawnej: zakres obowiązków dla Waszych produktów potwierdzacie u prawnika.

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, testów manualnych i prostych bramek w CI, żeby efekt był widoczny w tygodniach, nie w kwartałach. Zespołom, które chcą nauczyć się tego samodzielnie, dajemy kurs online i szkolenie z testowania dostępności według WCAG 2.2. Jeśli chcecie zacząć dziś, zacznijcie od pierwszego testu z listy: odłóżcie mysz i przejdźcie checkout klawiaturą. To najtańszy audyt, jaki kiedykolwiek zrobicie.