Testowanie dostępności: jak, kiedy i jakimi narzędziami, z checklistą krok po kroku

Testowanie dostępności to sprawdzenie, czy z Waszej strony, aplikacji albo dokumentu mogą korzystać osoby z niepełnosprawnościami: niewidome z czytnikiem ekranu, obsługujące komputer samą klawiaturą, niesłyszące i z trudnościami poznawczymi. Miarą jest standard WCAG 2.2 na poziomie AA. Ten poradnik pokazuje, jak testować w praktyce: którymi narzędziami, w jakiej kolejności, kiedy w cyklu wytwarzania i czego żaden skaner za Was nie zrobi.

Jeśli szukacie listy, co dokładnie sprawdzić w produkcie, zajrzyjcie do tekstu 7 obszarów dostępności do przetestowania. Kogo obowiązują przepisy, opisujemy w artykule Europejski Akt o Dostępności a testy WCAG, a nowe kryteria standardu w tekście WCAG 2.2: wymagania, zmiany i kogo obowiązują. Tutaj skupiamy się na warsztacie testera.

Czym jest testowanie dostępności i co właściwie sprawdza?

Testowanie dostępności (accessibility testing) to rodzaj testów niefunkcjonalnych: nie pyta, czy funkcja zwraca poprawny wynik, tylko czy da się z niej skorzystać w różny sposób. Punktem odniesienia jest WCAG 2.2, standard W3C opublikowany jako rekomendacja w 2023 roku i zaktualizowany 12 grudnia 2024. Kryteria są ułożone według czterech zasad: postrzegalność, funkcjonalność, zrozumiałość i solidność, w skrócie POUR, a każde kryterium ma poziom A, AA albo AAA.

Dobry test dostępności kończy się nie oceną „dostępne albo nie”, tylko listą konkretnych barier: na którym ekranie, które kryterium WCAG, jak bardzo przeszkadza użytkownikowi i co zmienić w kodzie. Taki wynik da się wpiąć w backlog jak każdy inny defekt. Z naszego doświadczenia największą różnicę robi właśnie ten ostatni krok, bo raport bez numerów kryteriów i bez priorytetów zespoły odkładają na później, czyli na nigdy.

Jakie rodzaje dostępności i barier obejmuje test?

Mówi się o czterech głównych rodzajach dostępności, odpowiadających rodzajom barier. Każdy wymaga innej techniki testu, dlatego plan, który obejmuje tylko skaner i kontrast, pomija połowę użytkowników.

Pamiętajcie, że te same rozwiązania pomagają osobom z ograniczeniem chwilowym albo sytuacyjnym. Według WHO z 2023 roku znaczącej niepełnosprawności doświadcza około 1,3 mld ludzi, czyli 16 procent populacji świata, a do tego dochodzi każdy z ręką w gipsie albo z telefonem w pełnym słońcu.

Ile błędów znajdzie automat, a ile tylko człowiek?

W starszej wersji tego artykułu stało, że automaty wychwytują 30 do 40 procent problemów, bez podania źródła. Dane są ciekawsze, bo zależą od tego, co liczymy. W eksperymencie brytyjskiego Government Digital Service z 2017 roku zespół zbudował stronę ze 143 celowymi barierami i puścił na nią 10 darmowych narzędzi. Żadne narzędzie nie wykryło 29 procent barier, a najlepsze pojedyncze znalazło 37 procent, 41 procent licząc podpowiedzi do ręcznej oceny.

Z kolei raport Deque Automated Accessibility Coverage Report liczy nie typy barier, tylko wszystkie zgłoszenia z prawdziwych audytów. W danych z ponad 13 000 stron i stanów stron testy automatyczne axe-core znalazły średnio 57,38 procent wszystkich problemów, bo najczęstsze błędy, takie jak kontrast i brak tekstu alternatywnego, powtarzają się setki razy. Wniosek dla Was jest ten sam w obu badaniach: automat wychwyci dużą część zgłoszeń, ale nie wszystkie rodzaje barier, i nigdy nie oceni, czy coś ma sens.

Jakie narzędzia do sprawdzania dostępności wybrać?

Narzędzia do sprawdzania dostępności dzielą się na trzy grupy: skanery automatyczne, narzędzia pomocnicze do ręcznej oceny i technologie wspomagające, których używają realni użytkownicy. Zestaw startowy jest darmowy, więc budżet nie jest tu wymówką.

Na start wystarczą trzy: axe DevTools albo WAVE do skanu, Colour Contrast Analyser do kontrastu i NVDA do testu „uchem”. Według ankiety WebAIM Screen Reader User Survey #10 z 2024 roku głównym czytnikiem na komputerze był JAWS u 40,5 procent badanych i NVDA u 37,7 procent, więc wyniki z NVDA dobrze oddają doświadczenie dużej części użytkowników.

Jak wygląda testowanie dostępności krok po kroku?

Poniższy proces stosujemy, kiedy testujemy jedną kluczową ścieżkę, na przykład rejestrację albo zakup. Na takiej ścieżce zajmuje od jednego do kilku dni, zależnie od liczby ekranów i stanów.

Najczęściej pomijany jest test klawiaturą, bo wydaje się banalny. Tymczasem to on najszybciej pokazuje bariery blokujące, czyli takie, przez które użytkownik nie skończy zadania. Oto checklista, którą możecie skopiować do swojego narzędzia do zarządzania testami.

Jak testować czytnikiem ekranu, jeśli robicie to pierwszy raz?

Pierwsza sesja z czytnikiem ekranu bywa frustrująca, bo czytnik mówi szybko i dużo. Dlatego zacznijcie od jednej strony, którą dobrze znacie, i od kilku poleceń. W NVDA klawiszem modyfikującym jest domyślnie Insert, a w trybie przeglądania pojedyncze litery przenoszą między elementami. Według podręcznika NVDA: H przechodzi do następnego nagłówka, cyfry 1 do 6 do nagłówka danego poziomu, F do pola formularza, K do linku, D do landmarku, a NVDA+F7 otwiera listę elementów.

Na Macu VoiceOver włączacie i wyłączacie skrótem Command+F5, a klawiszami VoiceOver są Control+Option albo Caps Lock, co opisuje podręcznik VoiceOver firmy Apple. Najwygodniejszy jest rotor, czyli lista nagłówków, linków i pól formularza, którą przegląda się strzałkami. Na iPhonie i Androidzie testujcie gestami: przesunięcie w prawo przechodzi do następnego elementu, dwukrotne stuknięcie go uruchamia.

Jeśli chcecie, żeby cały zespół pewnie poruszał się w czytniku ekranu i w kryteriach WCAG, najszybciej pomoże szkolenie z testowania dostępności cyfrowej prowadzone na żywo albo kurs online z testowania dostępności WCAG, przez który przejdziecie we własnym tempie.

Kiedy testować dostępność w cyklu wytwarzania?

Najkrócej: jak najwcześniej i w małych porcjach. Bariera zauważona w makiecie kosztuje zmianę koloru, ta sama bariera po wdrożeniu wymaga poprawki w kodzie, testów regresji i nowego wydania. Dlatego testowanie dostępności rozkładamy na cały cykl, a nie na jeden audyt przed premierą.

U naszych klientów najlepiej działa połączenie dwóch ostatnich wierszy z pipeline: automat pilnuje regresji codziennie, a człowiek co jakiś czas sprawdza to, czego automat nie widzi. To ta sama logika co w testach regresyjnych, tylko z innym zestawem kryteriów.

Jak wpiąć testy dostępności w CI/CD z Playwright i axe?

Najprostszy sposób na strażnika dostępności w CI to dodanie skanu axe do testów end to end, które i tak już macie. Poniższy test uruchomiliśmy 10 października 2026 roku na Playwright 1.64 z pakietem @axe-core/playwright 4.13 na dwóch wersjach tej samej strony koszyka: z błędami i poprawionej. Pierwsza wersja oblała test z czterema regułami (button-name, color-contrast, html-has-lang, image-alt), poprawiona przeszła oba testy.

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const ADRES = process.env.ADRES ?? 'https://example.com/koszyk';

test('koszyk bez błędów WCAG 2.2 na poziomach A i AA', async ({ page }) => {
  await page.goto(ADRES);
  const wynik = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  for (const b of wynik.violations) {
    console.log(`${b.id} (${b.impact}): ${b.nodes.length} elem. ${b.helpUrl}`);
  }
  expect(wynik.violations).toEqual([]);
});

test('pierwszy Tab trafia w widoczny element', async ({ page }) => {
  await page.goto(ADRES);
  await page.keyboard.press('Tab');
  const fokus = page.locator(':focus');
  await expect(fokus).toBeVisible();
});

Instalacja to jedno polecenie: npm i -D @playwright/test @axe-core/playwright. Tagi w metodzie withTags ograniczają skan do kryteriów WCAG na poziomach A i AA, więc test nie oblewa na regułach „best practice”, które nie są wymaganiem. Opis tej integracji znajdziecie w dokumentacji Playwright o testach dostępności. Na starszym, dużym serwisie zacznijcie od zapisania obecnych błędów jako punktu odniesienia i blokowania tylko nowych, inaczej pierwszy pipeline będzie czerwony przez miesiąc.

Jeśli Wasz zespół dopiero buduje testy end to end, skan dostępności warto zaplanować od pierwszego dnia w ramach automatyzacji testów, a praktykę z samym narzędziem daje szkolenie z automatyzacji testów w Playwright.

Co mówią przepisy i gdzie szukać szczegółów?

Krótko, bo szczegóły opisujemy osobno. Od 28 czerwca 2025 roku stosuje się ustawę z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731, art. 88), która wdraża Europejski Akt o Dostępności i obejmuje także firmy prywatne, między innymi handel elektroniczny i bankowość detaliczną (art. 3). Podmioty publiczne od 2019 roku podlegają ustawie z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848). Kogo dokładnie obejmuje ustawa z 2024 roku, jakie są wyłączenia, terminy przejściowe i kary, rozpisujemy w artykule Europejski Akt o Dostępności a testy WCAG.

Po teście dobrze jest uczciwie opisać stan dostępności. Jak to zrobić bez przepisywania szablonu, pokazuje Strefa QA w artykule o deklaracji dostępności po audycie. Jeśli wolicie, żeby test przeprowadził ktoś z zewnątrz, w ramach testów dostępności łączymy skan, klawiaturę i czytniki ekranu, a po audycie WCAG 2.2 wystawiamy deklarację zgodności dla zbadanego zakresu, w cenie pakietu. Ile kosztuje taki audyt i jak przebiega, opisujemy w tekście audyt dostępności strony: jak wygląda i ile kosztuje.

Powiązane na blogu Quality Island

• 7 obszarów dostępności do przetestowania: checklista WCAG 2.2
• WCAG 2.2: wymagania, zmiany i kogo obowiązują
• Audyt dostępności strony: jak wygląda, ile kosztuje
• Europejski Akt o Dostępności a testy WCAG
• Testy niefunkcjonalne

Pełna lista źródeł

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, rekomendacja z 2023 roku, aktualizacja 12.12.2024.
• Government Digital Service, What we found when we tested tools on the world’s least-accessible webpage, 24.02.2017.
• Deque Systems, Automated Accessibility Coverage Report, wersja strony z 2025 roku.
• WebAIM, The WebAIM Million, raport 2026, dane z lutego 2026.
• WebAIM, Screen Reader User Survey #10 Results, 2024.
• WHO, Disability and health, fact sheet, 2023.
• Google, Lighthouse accessibility scoring, dokumentacja 2026.
• Microsoft, Playwright: Accessibility testing, dokumentacja 2026.
• Deque Systems, axe-core, repozytorium i dokumentacja, wersja 4.13, 2026.
• NV Access, NVDA User Guide, 2026.
• Apple, VoiceOver User Guide: Turn VoiceOver on or off, 2026.
• Sejm RP, ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, Dz.U. 2024 poz. 731, art. 3 i art. 88.
• Sejm RP, ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych, Dz.U. 2019 poz. 848.