Dlaczego zautomatyzowane skanery dostępności wykrywają tylko 30% problemów (i co z tym zrobić)

Uruchamiasz automatyczne skanowanie dostępności, pulpit wraca na zielono i z ulgą odetchniesz. Ale oto niewygodna prawda: ten czysty raport może ukrywać większość rzeczywistych barier dostępności w Twojej witrynie. Badania i niezależne analizy konsekwentnie pokazują, że automatyczne skanery wykrywają od 30% do 57% faktycznych naruszeń WCAG — co oznacza, że od połowy do dwóch trzecich problemów, z którymi Twoi użytkownicy z niepełnosprawnościami mierzą się każdego dnia, jest całkowicie niewidocznych dla narzędzi, na których polega większość zespołów.

Stan automatycznego testowania dostępności

Automatyczne testowanie dostępności zyskało ogromną popularność — i to z dobrego powodu. Coraz więcej zespołów sięga po automatyzację, aby wychwycić problemy z dostępnością: 50% respondentów w jednym badaniu z 2024 roku stwierdziło, że używa automatycznych narzędzi dostępności do identyfikowania potencjalnych problemów, w porównaniu do 40% w 2023. Atrakcyjność jest oczywista — skanery są szybkie, relatywnie tanie i można je zintegrować bezpośrednio z potokami CI/CD. Wychwytują oczywiste, powtarzalne, oparte na regułach naruszenia na dużą skalę: brakujący atrybut alt, pole formularza bez etykiety, przycisk z pustą nazwą dostępną.

Ale sufit pokrycia jest uporczywym problemem, którego żaden dostawca skanerów nie zdołał przebić. Według Deque „można automatycznie znaleźć średnio 57% problemów WCAG”, a nawet wtedy narzędzia zwracają komponenty jako niekompletne, gdy potrzebna jest ręczna weryfikacja. Ta wartość 57% reprezentuje optymistyczny koniec spektrum, osiągnięty przez jeden z najbardziej dojrzałych i szeroko zaufanych silników dostępności na rynku, wykorzystujący pragmatyczną, osadzoną w rzeczywistości metodologię pomiaru. Inne szacunki są znacznie niższe. Narzędzia automatyczne wychwytują około 30–40% naruszeń WCAG, a pozostałe 60–70% wymaga testów manualnych.

Różnica między 30% a 57% sprowadza się do tego, jak zdefiniujesz mianownik. Deque uzyskało wartość 57%, przyjmując pragmatyczne, osadzone w rzeczywistości podejście zamiast teoretycznego — próbkując dużą liczbę witryn i mierząc, ile z faktycznie udokumentowanych defektów dostępności zostałoby wykrytych przy użyciu axe-core. Gdy badacze mierzą pokrycie względem wszystkich kryteriów sukcesu WCAG jako teoretycznego zbioru, liczby gwałtownie spadają. W momencie pisania tego tekstu, filtrowanie dla WCAG 2.2 poziomów A i AA, aby pokazać tylko zatwierdzone reguły testów automatycznych, ujawnia częściowe lub pełne pokrycie tylko dla 17 z 55 kryteriów sukcesu. Niezależnie od sposobu liczenia, testy automatyczne pozostawiają istotną — i prawnie niebezpieczną — lukę.

Problem potęguje fakt, jak trudno tę lukę dostrzec z zewnątrz. Pozytywny wynik skanowania aktywnie sygnalizuje bezpieczeństwo, czyli dokładnie ten moment, w którym zespoły najczęściej przestają szukać dalej. Pulpit jest zielony. Wysyłka następuje. Prawdziwi użytkownicy z niepełnosprawnościami napotykają prawdziwe bariery.

Do czego skanery są tak naprawdę dobre

Zanim zagłębimy się w lukę pokrycia, warto jasno powiedzieć, w czym narzędzia automatyczne rzeczywiście są dobre. Są szybkie, spójne i niestrudzone w sprawdzaniu rzeczy, które można ocenić wyłącznie na podstawie odczytu DOM. Automatyzacja dostępności może wiarygodnie wychwytywać typowe naruszenia WCAG, takie jak brakujący tekst alternatywny, puste linki, nieprawidłowe etykiety formularzy i zbyt niski kontrast kolorów. To strukturalne, binarne sprawdzenia — albo atrybut istnieje, albo nie, albo współczynnik kontrastu spełnia 4,5:1, albo nie.

Raport WebAIM Million, który co roku analizuje milion najpopularniejszych stron głównych, daje wyrazisty obraz tego, jak powszechne pozostają te wykrywalne błędy. 95,9% stron głównych miało wykryte błędy WCAG 2. Sześć najczęstszych kategorii — tekst o niskim kontraście, brakujący tekst alternatywny, brakujące etykiety formularzy, puste linki, puste przyciski i brak języka dokumentu — odpowiada za 96% wszystkich wykrytych błędów, a te najczęstsze błędy są takie same od siedmiu lat. Narzędzia automatyczne są naprawdę pomocne w ujawnianiu tych częstych, mało złożonych naruszeń na dużą skalę. Problem w tym, że naprawienie tylko tych kwestii nadal pozostawia witrynę z większością jej rzeczywistych barier nienaruszonych.

Dlaczego istnieje luka: czego skanery nie potrafią ocenić

Sufit pokrycia nie jest porażką inżynierii — to fundamentalne ograniczenie tego, co maszyna może ocenić bez ludzkiego osądu. Luka istnieje, ponieważ maszyny nie rozumieją kontekstu, intencji użytkownika ani kwestii subiektywnych, takich jak to, czy hierarchia nagłówków ma sens lub czy tekst alternatywny jest trafny. Skaner może potwierdzić, że obraz ma atrybut alt. Nie powie Ci jednak, czy ten atrybut brzmi „photo-123-final-v2.jpg”, czy stanowi faktycznie użyteczny opis. Narzędzia mogą oznaczyć, że obraz ma tekst alternatywny, ale tylko człowiek może ocenić, czy ten tekst rzeczywiście dobrze opisuje obraz.

Oto główne kategorie problemów, które konsekwentnie wymykają się automatycznemu wykrywaniu:

• Doświadczenie użytkowników czytników ekranu: Narzędzia automatyczne nie mogą „posłuchać”, jak czytnik ekranu ogłasza treść. Mogą sprawdzić poprawność atrybutów ARIA, ale nie są w stanie ocenić, czy wynikające z nich komunikaty mają sens dla użytkowników. Pole formularza może mieć technicznie poprawny aria-label, który dla realnego użytkownika NVDA lub JAWS odczytuje się jako mylący ciąg znaków.
• Logiczna kolejność odczytu i fokusu: W praktyce kolejność odczytu często nie ma sensu, gdy użytkownicy czytników ekranu uzyskują dostęp do informacji, które wizualnie mogą wyglądać zupełnie poprawnie. W układzie kolumnowym czytnik ekranu odczytuje pierwszą linię kolumny 1, a potem kolumny 2, co prowadzi do dezorientacji. Skanery analizują kolejność DOM w oderwaniu od kontekstu tego, jak układ wizualny przekształca tę kolejność dla użytkownika widzącego.
• Znaczący tekst linków i przycisków w kontekście: Narzędzia automatyczne mogą sprawdzić, czy link istnieje i czy zawiera tekst, ale nie zawsze potrafią ocenić, czy cel tego linku jest jasny. Pięć linków „Czytaj więcej” na tej samej stronie przejdzie testy automatyczne i jednocześnie zawiedzie realnych użytkowników, którzy muszą zrozumieć, dokąd każdy z nich prowadzi.
• Treści dynamiczne i regiony live: Narzędzia automatyczne nie wychwycą problemów z dynamicznie ładowaną treścią. Trzeba uruchomić test ponownie po dodaniu aktualizacji dynamicznej — ale nawet wtedy narzędzie nie powie, czy czytnik ekranu ją odczyta, czy nie.
• Dostępność poznawcza i prosty język: Automatyzacja może wykryć problemy strukturalne, takie jak kolejność nagłówków czy obecność etykiet, ale nie oceni czytelności, jasności ani tego, czy instrukcje są łatwe do zrozumienia. Złożony, wieloetapowy proces zakupu z mylącymi komunikatami o błędach może być strukturalnie „czysty”, a jednocześnie głęboko niedostępny dla użytkowników z niepełnosprawnościami poznawczymi.
• Nawigacja klawiaturą w złożonych interakcjach: Automatyzacja może testować podstawowy fokus klawiatury i możliwość obsługi, ale nie jest w stanie w pełni zweryfikować złożonych, wieloetapowych interakcji, niestandardowych gestów czy alternatywnych urządzeń wejścia. Niestandardowy widget wyboru daty może być w teorii w pełni obsługiwalny klawiaturą, a w praktyce stanowić pułapkę.
• Nakładające się elementy wizualne i kontrast w gradientach: Narzędzia automatyczne mogą oceniać współczynniki kontrastu, ale nie zawsze uwzględniają nakładające się elementy, obrazy za tekstem czy dynamicznie zmieniającą się treść, która utrudnia czytelność.

Czysty wynik automatycznego skanowania oznacza, że zająłeś się 30–40% problemów, które automatyzacja potrafi wychwycić. Pozostałe 60–70% pozostaje nietestowane. Nigdy nie deklaruj zgodności z WCAG wyłącznie na podstawie testów automatycznych.

Szczególnie uderzający dowód: w jednym badaniu rzecznicy dostępności w rządzie Wielkiej Brytanii celowo stworzyli stronę internetową z 142 barierami dostępności, a następnie przeanalizowali ją za pomocą 13 automatycznych narzędzi dostępności. Najlepiej działające narzędzie było w stanie zidentyfikować tylko 40% barier. Najgorzej działające znalazło zaledwie 13%. Nawet gdy karty były rozdane na korzyść narzędzi — użyto kontrolowanej strony z znanymi, udokumentowanymi problemami — wyniki były otrzeźwiające. A łączenie narzędzi nie rozwiązuje problemu w pełni: nawet przy użyciu sześciu narzędzi równolegle połowa wszystkich kryteriów sukcesu WCAG 2 nie jest pokryta, a 6 na 10 naruszeń pozostaje niewykrytych.

Ryzyko prawne nadmiernego polegania na automatyzacji

To nie jest tylko teoretyczna kwestia doświadczenia użytkownika. Stawka prawna za brak zgodności z wymaganiami dostępności rośnie gwałtownie, a pozytywny wynik automatycznego skanowania oferuje niemal zerową ochronę w pozwie. W 2024 roku w sądach USA wniesiono ponad 4 000 pozwów, w których zarzucano bariery w dostępności stron internetowych lub aplikacji mobilnych. Tylko w pierwszej połowie 2025 roku odnotowano 2 014 pozwów dotyczących stron internetowych w kontekście ADA — to wzrost o 37% w porównaniu z 2024.

Ugody pozasądowe wynoszą średnio 30 000 $, podczas gdy wyroki sądowe średnio 85 000 $. W każdym przypadku dochodzą do tego koszty obrony prawnej w wysokości 30 000–175 000 $. Co gorsza, jednorazowa ugoda nie gwarantuje bezpieczeństwa: 45–46% federalnych pozwów dotyczących cyfrowej dostępności w 2025 roku dotyczyło firm, które były już wcześniej pozywane. Zostać pozwanym i załatać tylko to, co wskażą narzędzia automatyczne, bez zajęcia się szerszymi lukami strukturalnymi, to po prostu namalować sobie na plecach cel dla kolejnego powoda.

Warto też rozprawić się z powszechnym błędnym przekonaniem, że widżety i nakładki dostępnościowe są skrótem do zgodności. Dane z 2025 roku pokazują, że wniesiono 456 pozwów ADA przeciwko witrynom, które miały zainstalowane widżety dostępności, co stanowi 22,64% wszystkich pozwów — podkreślając, że samo dodanie widżetu dostępności nie jest kompleksowym rozwiązaniem. Narzędzia automatyczne są w stanie wykryć tylko 30% problemów WCAG, co oznacza, że każde narzędzie lub widżet opierający się wyłącznie na automatycznym wykrywaniu z definicji pozostawia większość problemów nierozwiązanych. To, co odróżnia rzeczywiście wartościowe SDK dostępności — takie jak Accsible — od produktów typu overlay, które spotkały się z reakcją prawną i regulacyjną, to połączenie automatycznej naprawy z zaangażowaniem w uczciwą, warstwową strategię zgodności, a nie fałszywe gwarancje.

Warstwowa strategia testowania, która naprawdę działa

Odpowiedzią na lukę pokrycia nie jest porzucenie skanerów automatycznych — jest nią właściwe ich użycie, jako pierwszej warstwy w kompleksowej strategii, a nie ostatniej. Spośród 86 kryteriów sukcesu WCAG 2.2 siedemdziesiąt procent wymaga ludzkiej oceny, aby właściwie zinterpretować kryteria i zastosować je do szarych stref poza zasięgiem technologii automatycznej dostępności. Oznacza to, że ludzki osąd nie jest opcjonalny — jest strukturalnie wymagany przez sam standard.

Solidny program testowania dostępności zazwyczaj działa w trzech warstwach:

1. Automatyczne skanowanie (ciągłe): Zintegruj skanery takie jak axe-core z potokiem CI/CD i uruchamiaj je przy każdym buildzie. Wychwytuj strukturalne, binarne naruszenia, zanim trafią na produkcję. Ustal progi i blokuj buildy przy nowych krytycznych naruszeniach. To Twoja siatka bezpieczeństwa dla oczywistych kwestii — szybka, skalowalna i tania. Uruchamiaj narzędzia automatyczne wcześnie i często w trakcie rozwoju. Zintegruj axe lub WAVE z potokiem CI/CD, aby problemy były wychwytywane, zanim kod trafi do QA. To przesuwa testowanie dostępności w lewo, wychwytując problemy wtedy, gdy są najtańsze do naprawy.
2. Ekspercki audyt manualny (okresowy): Przeprowadzaj ustrukturyzowane audyty manualne względem pełnej listy kontrolnej WCAG, wykonywane przez osoby z głęboką wiedzą o dostępności. Manualne testy dostępności są przeprowadzane przez przeszkolonych ekspertów, którzy aktywnie korzystają ze stron internetowych z technologiami asystującymi, takimi jak czytniki ekranu, nawigacja klawiaturą czy oprogramowanie powiększające. Ocenią kontekst i doświadczenie użytkownika — logiczną kolejność fokusu i intuicyjność nawigacji, klarowność formularzy i komunikatów o błędach, czytelność w złożonych treściach. Audyty manualne zazwyczaj odbywają się kwartalnie lub przy wdrażaniu dużych funkcji i powinny obejmować najważniejsze ścieżki użytkowników od początku do końca. Prowadzone audyty manualne dostępności plasują się między w pełni manualnym a w pełni automatycznym testowaniem, zawężając lukę pokrycia; niektóre szacunki wskazują, że pokrycie może sięgać nawet 80% przy takim podejściu.
3. Testy z technologiami asystującymi i użytkownikami (ciągłe): Nie możesz polegać wyłącznie na narzędziach automatycznych przy ustalaniu problemów z dostępnością w swojej witrynie. Każdy projekt strony internetowej potrzebuje strategii testów z użytkownikami i zdecydowanie zaleca się uwzględnienie grup użytkowników z niepełnosprawnościami — użytkowników czytników ekranu, użytkowników korzystających wyłącznie z klawiatury, użytkowników niesłyszących, użytkowników z niepełnosprawnościami ruchowymi. Prawdziwi użytkownicy z niepełnosprawnościami znajdują problemy, których żadna lista kontrolna nie przewiduje. Testuj z NVDA i JAWS na Windows, VoiceOver na macOS i iOS oraz TalkBack na Androidzie. Przejdź cały proces zakupu lub rejestracji, używając wyłącznie klawiatury. Naprawdę posłuchaj, jak Twoje treści brzmią, gdy są odczytywane na głos.

Gdy zespoły wdrażają wszystkie trzy warstwy, łączne pokrycie może zbliżyć się do 80–90% rzeczywistych problemów — to dramatyczna poprawa w porównaniu z sufitem 30–57% przy samej automatyzacji. Celem nie jest perfekcja pierwszego dnia; celem jest systematyczny, udokumentowany proces, który pokazuje autentyczne działanie w dobrej wierze i stale zmniejsza lukę.

Integracja dostępności z procesem wytwarzania oprogramowania

Najważniejsza zmiana kulturowa polega na przesunięciu dostępności z listy kontrolnej przed premierą do praktyki ciągłej. Wiele organizacji popełnia błąd, traktując ją jako jednorazowy audyt zlecany wtedy, gdy obawiają się pozwu, zamiast jako standard jakości wbudowany w każdy sprint. W momencie, gdy audyt ujawnia problemy w systemie produkcyjnym, koszt ich naprawy jest pięć do dziesięciu razy wyższy, niż byłby na etapie projektowania.

Zacznij od uczynienia kryteriów dostępności częścią definicji ukończenia zadania. Gdy deweloper dostarcza nowy komponent, szybkie automatyczne sprawdzenie powinno uruchamiać się automatycznie. Gdy projektant tworzy nowy wzorzec, kontrast kolorów i stany fokusu powinny zostać przejrzane, zanim projekt w ogóle zostanie przekazany dalej. Gdy redaktor treści dodaje nowy obraz, powinien mieć jasne wyobrażenie o tym, jak wygląda znaczący tekst alternatywny — nie tylko, że tekst alternatywny jest wymagany.

Dla menedżerów ds. zgodności praktyczną konsekwencją jest dokumentacja. Niektóre zespoły uruchamiają testy automatyczne, ale nigdy nie zajmują się wynikami. Nie przynosi to żadnej wartości i tworzy dokumentację, że wiedzieliście o problemach, ale ich nie naprawiliście — co jest problematyczne w sytuacjach prawnych. Program dostępności jest do obrony tylko wtedy, gdy możesz wykazać rozsądny, prowadzony w dobrej wierze proces ciągłego doskonalenia: regularne skany, udokumentowane ustalenia, plan naprawczy i dowody na to, że działasz na podstawie tego, czego się uczysz. Zgodność z WCAG nie jest binarnym stanem, który osiągasz raz — to postawa, którą utrzymujesz.

Narzędzia takie jak Accsible istnieją po to, by wspierać takie warstwowe podejście — dostarczając SDK, które osadza usprawnienia dostępności bezpośrednio w doświadczeniu użytkownika, ujawnia problemy w czasie rzeczywistym i uzupełnia proces audytu manualnego, zamiast próbować go zastąpić. Właściwa nakładka lub SDK nie jest magiczną tarczą przeciwko pozwom; to jeden z elementów przemyślanego programu, który uznaje, co automatyzacja może, a czego nie może zrobić.

Kluczowe wnioski

• Automatyczne skanery są punktem wyjścia, a nie metą. Nawet najlepsze narzędzia wykrywają od 30% do 57% rzeczywistych naruszeń WCAG. Czysty raport ze skanowania nie oznacza, że Twoja witryna jest dostępna — oznacza, że wykrywalna podgrupa problemów została rozwiązana.
• Większość kryteriów sukcesu WCAG wymaga ludzkiego osądu. Doświadczenie użytkowników czytników ekranu, logiczna kolejność odczytu, znaczący tekst linków w kontekście, klarowność poznawcza i złożone interakcje klawiaturowe to obszary, w których automatyzacja jest strukturalnie niezdolna do udzielenia wiarygodnej odpowiedzi.
• Środowisko prawne jest wrogie samozadowoleniu. Ponad 5 100 federalnych pozwów dotyczących stron internetowych w kontekście ADA wniesiono w 2025 roku, ugody rutynowo kosztują 30 000–85 000 $ plus koszty obrony, a niemal połowa pozwanych była już wcześniej pozywana — co sugeruje, że powierzchowne poprawki nie wystarczają.
• Strategia trójwarstwowa — automatyczne skanowanie, eksperckie audyty manualne i realne testy z technologiami asystującymi — może podnieść pokrycie do 80–90% i daje udokumentowaną, prowadzoną w dobrej wierze postawę zgodności, jakiej oczekują sądy i regulatorzy.
• Przesuń dostępność w lewo. Wychwytywanie problemów na etapie projektowania i rozwoju kosztuje ułamek tego, co kosztuje naprawa po wdrożeniu. Zintegruj automatyczne sprawdzenia z CI/CD, uczynij dostępność częścią definicji ukończenia i przeprowadzaj regularne audyty manualne na najczęściej używanych ścieżkach użytkowników.