Czym jest audyt dostępności? Jak sprawdzić, czy Twoja strona internetowa jest zgodna z WCAG

Zgodnie z najnowszym raportem WebAIM Million wykryto 56 milionów odrębnych błędów dostępności na milionie stron głównych — średnio 56 błędów na stronę. Oznacza to, że przytłaczająca większość witryn internetowych aktywnie zawodzi użytkowników z niepełnosprawnościami każdego dnia. Jeśli jesteś właścicielem strony, deweloperem lub osobą odpowiedzialną za zgodność i zastanawiasz się, czy Twoja witryna jest zgodna z WCAG, odpowiedź niemal na pewno obejmuje przeprowadzenie właściwego audytu dostępności. Pytanie brzmi: co to tak naprawdę oznacza i jak zrobić to dobrze?

Dlaczego audyty dostępności stały się nie do pominięcia

Dostępność stron internetowych dawno wyszła poza sferę dobrych chęci. Jest obecnie wymogiem prawnym w rosnącej liczbie jurysdykcji, a konsekwencje braku zgodności są konkretne i mierzalne. Ponad 4 000 pozwów dotyczących dostępności stron internetowych zostało złożonych w Stanach Zjednoczonych w 2024 roku i trend nadal rośnie. Sądy w USA konsekwentnie orzekają, że strony internetowe firm otwartych dla publiczności muszą być dostępne zgodnie z ADA Title III. Tymczasem European Accessibility Act stał się egzekwowalny we wszystkich państwach członkowskich UE w czerwcu 2025 roku, rozszerzając wymagania poza serwisy rządowe na aplikacje bankowe, platformy e-commerce, produkty SaaS i inne.

Liczby rysują wyraźny obraz. Około 16% światowej populacji — około 1,3 miliarda osób — żyje z jakąś formą niepełnosprawności. Tylko w Stanach Zjednoczonych mniej więcej co czwarty dorosły ma niepełnosprawność. To nie są użytkownicy z marginesu. To klienci, pracownicy, studenci i obywatele, którzy napotykają bariery na stronach internetowych, o których większość deweloperów nawet nie myśli.

Poza ryzykiem prawnym istnieje mierzalny argument biznesowy. Dostępne strony osiągają lepsze wyniki w wyszukiwarkach, ponieważ ta sama przejrzysta struktura, która pomaga czytnikom ekranu — semantyczne nagłówki, opisowy tekst alternatywny, czysty kod — pomaga również robotom indeksującym. Projektowanie inkluzywne konsekwentnie poprawia użyteczność dla wszystkich: napisy pomagają osobom w hałaśliwym otoczeniu, wysoki kontrast pomaga osobom w jasnym świetle, a nawigacja klawiaturą wspiera zaawansowanych użytkowników. Audyt dostępności jest pierwszym krokiem do wykorzystania wszystkich tych korzyści.

Jeszcze jedna ważna zmiana: ADA Title II obecnie wprost wymaga dostępności stron internetowych dla stanowych i lokalnych jednostek rządowych w USA, przy czym DOJ przyjął WCAG 2.1 Level AA jako standard techniczny. Podmioty obsługujące populacje liczące 50 000 lub więcej mają termin na zapewnienie zgodności do 26 kwietnia 2026 roku. Jeśli pracujesz z klientami z sektora publicznego lub działasz w branżach regulowanych, audyt nie jest już opcjonalny — jest pilny.

Czym dokładnie jest audyt dostępności WCAG?

Audyt dostępności strony internetowej to systematyczna ocena zgodności Twojej witryny z Web Content Accessibility Guidelines (WCAG) — międzynarodowo uznanym standardem technicznym dla dostępności cyfrowej, opracowanym przez W3C. W praktyce audyt identyfikuje konkretne bariery, które uniemożliwiają użytkownikom z niepełnosprawnościami postrzeganie, rozumienie, nawigowanie i interakcję z Twoimi treściami. Mapuje te bariery na kryteria sukcesu WCAG, przypisuje poziomy istotności i tworzy plan naprawczy.

WCAG jest obecnie w wersji 2.2, opublikowanej pod koniec 2023 roku i formalnie potwierdzonej przez W3C w maju 2025 roku jako najwyższy standard dostępności stron internetowych. Zawiera dziewięć nowych kryteriów sukcesu w stosunku do WCAG 2.1, obejmujących obszary takie jak widoczność fokusu klawiatury, minimalne rozmiary celów dotykowych, alternatywy dla przeciągania oraz spójne mechanizmy pomocy. Co ważne, WCAG 2.2 jest wstecznie kompatybilne — spełnienie 2.2 oznacza, że spełniasz również 2.1 i 2.0.

WCAG jest zorganizowane wokół trzech poziomów zgodności. Poziom A obejmuje najbardziej krytyczne bariery — błędy na tym poziomie sprawiają, że treść jest całkowicie nieużywalna dla części użytkowników. Poziom AA jest celem wymaganym przez większość przepisów dotyczących dostępności na świecie, w tym ADA, European Accessibility Act i Section 508. Poziom AAA reprezentuje najwyższy próg i zazwyczaj jest aspiracyjny, a nie prawnie wymagany. Gdy ktoś mówi, że jego strona jest „zgodna z WCAG”, prawie zawsze ma na myśli WCAG 2.1 lub 2.2, Poziom AA.

WCAG opiera się na czterech głównych zasadach, często zapamiętywanych akronimem POUR: treść musi być Perceivable (użytkownicy mogą ją postrzegać), Operable (użytkownicy mogą z nią wchodzić w interakcję), Understandable (użytkownicy mogą ją zrozumieć) oraz Robust (działa niezawodnie z technologiami asystującymi). Każde kryterium sukcesu odnosi się do jednej z tych czterech zasad, a dokładny audyt sprawdza zgodność z każdą z nich.

Najczęstsze błędy ujawniane przez audyty

Około 96% wszystkich wykrytych błędów dostępności mieści się w zaledwie sześciu kategoriach. Wiedza, czego szukać, jest najszybszym sposobem na priorytetyzację wysiłku audytowego:

• Tekst o niskim kontraście. To konsekwentnie najczęstszy błąd. Prawie 84% stron głównych zawiera tekst, który nie spełnia progu kontrastu WCAG 2 AA wynoszącego 4,5:1 dla zwykłego tekstu. Audytorzy sprawdzają współczynniki kolorów pierwszego planu i tła za pomocą narzędzi takich jak TPGi Colour Contrast Analyser.
• Brak tekstu alternatywnego. Ponad 16% wszystkich obrazów na stronach głównych nie ma żadnego atrybutu alt, pozostawiając użytkowników czytników ekranu bez możliwości zrozumienia treści obrazu. Obrazy będące linkami bez tekstu alt są szczególnie szkodliwe — stają się bezsensownymi celami nawigacyjnymi.
• Puste linki. Linki, które nie zawierają widocznego tekstu ani dostępnej nazwy, tworzą ślepe zaułki dla użytkowników klawiatury i czytników ekranu, którzy nie mogą ustalić, dokąd prowadzi link.
• Brak etykiet pól formularza. Formularze bez programistycznie powiązanych etykiet są nieużywalne dla użytkowników czytników ekranu. Dotyczy to zarówno widocznych etykiet, jak i ukrytych etykiet z użyciem aria-label lub aria-labelledby.
• Puste przyciski. Przyciski zawierające wyłącznie ikony, bez dostępnej nazwy — powszechne w nawigacji i sliderach — uniemożliwiają użytkownikom niewidzącym zidentyfikowanie działania przycisku.
• Brak języka dokumentu. Atrybut lang w elemencie <html> informuje czytniki ekranu, jakiego języka użyć. Jego brak powoduje błędną wymowę i dezorientację u użytkowników polegających na syntezie mowy.

Audyty konsekwentnie pokazują, że najbardziej szkodliwe błędy są jednocześnie najłatwiejsze do naprawienia. Niski kontrast, brak tekstu alt i nieoznaczone pola formularzy można często naprawić w ciągu dni, a nie miesięcy.

Poza tymi sześcioma, dokładny audyt wychwyci również brak linków do pomijania nawigacji (które zmuszają użytkowników klawiatury do przechodzenia przez każdy element nagłówka na każdej stronie), nieprawidłową hierarchię nagłówków, niedostępne okna modalne i dialogi, które nieprawidłowo przechwytują fokus, filmy bez napisów, pliki PDF bez otagowanej struktury oraz niestandardowe widżety JavaScript, które nie udostępniają ról i stanów dostępnych przez ARIA.

Jak przeprowadzić audyt dostępności: krok po kroku

Prawidłowy audyt dostępności to nie pojedyncze skanowanie — to wieloetapowy proces łączący narzędzia automatyczne z ekspercką oceną człowieka. Oto jak podejść do tego w sposób systematyczny:

Krok 1: Zdefiniuj zakres

Przed uruchomieniem choćby jednego testu zdecyduj, co audytujesz. W przypadku dużej witryny testowanie każdej strony jest niepraktyczne. Zamiast tego zastosuj podejście WCAG-EM (Website Accessibility Conformance Evaluation Methodology) opracowane przez W3C: zdefiniuj reprezentatywną próbkę obejmującą wszystkie unikalne szablony stron, wszystkie istotne ścieżki użytkownika i wszystkie odrębne typy treści. Próbka dla serwisu e-commerce może obejmować stronę główną, stronę kategorii, stronę szczegółów produktu, koszyk, proces realizacji zamówienia, logowanie do konta, formularz kontaktowy i wpis na blogu. Upewnij się, że uwzględnione są stany dynamiczne — otwarte menu, komunikaty o błędach formularzy, okna modalne i załadowane wyniki wyszukiwania wymagają oceny.

Krok 2: Uruchom skany automatyczne

Narzędzia automatyczne są fundamentem każdego efektywnego audytu. Szybko skanują Twój kod HTML, oznaczają jednoznaczne naruszenia reguł i dają bazową listę problemów. Kluczowe narzędzia to:

• axe DevTools (rozszerzenie przeglądarki lub CLI) — szeroko stosowane, o niskim odsetku fałszywych trafień, integruje się z pipeline’ami CI/CD
• WAVE (WebAIM) — wizualnie oznacza strony ikonami błędów, co czyni je intuicyjnym dla członków zespołu nietechnicznych
• Lighthouse (wbudowany w Chrome DevTools) — zapewnia wynik dostępności obok metryk wydajności i SEO
• Colour Contrast Analyser (TPGi) — wybiera dowolny kolor na ekranie i sprawdza go względem progów WCAG
• PAC 2024 — dedykowane narzędzie do sprawdzania dostępności plików PDF do pobrania

Kluczowe ograniczenie: narzędzia automatyczne są w stanie wykryć jedynie od 30% do 40% problemów WCAG. Świetnie sprawdzają się przy oznaczaniu błędów opartych na regułach, takich jak brakujące atrybuty, nieprawidłowe role ARIA i współczynniki kontrastu. Nie są jednak w stanie ocenić, czy tekst alt jest sensowny, czy formularz jest logicznie zorganizowany ani czy użytkownik faktycznie może ukończyć zadanie. Dlatego automatyzacja to Krok 2, a nie cały audyt.

Krok 3: Ręczne testy eksperckie

Ręczne testy przeprowadzane przez kompetentną osobę — lub najlepiej zespół — decydują o głębokości audytu. Obejmują one:

• Nawigację wyłącznie klawiaturą. Odłącz mysz i spróbuj zrealizować każdą kluczową ścieżkę użytkownika, używając tylko Tab, Shift+Tab, Enter, Spacji i klawiszy strzałek. Czy możesz dotrzeć do każdego elementu interaktywnego? Czy wskaźnik fokusu jest zawsze widoczny? Czy fokus kiedykolwiek znika w komponencie?
• Testy z użyciem czytników ekranu. Użyj NVDA z Chrome lub Firefox na Windows oraz VoiceOver z Safari na macOS i iOS. Nawiguj po nagłówkach, obszarach (landmarks), linkach i formularzach. Czy strona ma sens bez kontekstu wizualnego? Czy wszystkie elementy interaktywne są poprawnie ogłaszane?
• Przegląd wizualny i poznawczy. Sprawdź hierarchię nagłówków pod kątem logicznej struktury, upewnij się, że komunikaty o błędach są opisowe i powiązane z właściwym polem, potwierdź, że media zależne od czasu mają napisy i transkrypcje oraz że instrukcje nie opierają się wyłącznie na kolorze, kształcie lub położeniu.
• Inspekcję kodu. Przejrzyj semantykę HTML, użycie ARIA, zarządzanie fokusem w niestandardowych widżetach i obszary typu landmark. Okno modalne, które nie przechwytuje fokusu, lub region ARIA live, który uruchamia się przy każdym naciśnięciu klawisza, zostaną wykryte tylko na tym poziomie.

Krok 4: Testy z technologiami asystującymi z udziałem prawdziwych użytkowników

Złotym standardem — i często najbardziej odkrywczym etapem — są testy z rzeczywistymi użytkownikami, którzy na co dzień polegają na technologiach asystujących. Osoby korzystające z czytników ekranu, urządzeń sterowanych przełącznikami czy oprogramowania do sterowania głosem nawigują w sposób, którego nawet eksperci od testów ręcznych nie są w stanie w pełni odtworzyć. Włączenie osób z niepełnosprawnościami do ewaluacji ujawnia realne tarcia, których narzędzia i checklisty po prostu nie są w stanie przewidzieć.

Krok 5: Dokumentuj i priorytetyzuj ustalenia

Surowa lista błędów to nie raport z audytu — to punkt wyjścia. Użyteczny dokument z audytu powinien określać: dotknięty adres URL lub komponent, naruszone kryterium sukcesu WCAG, istotność (krytyczna, wysoka, średnia, niska), wpływ na użytkowników oraz konkretne wskazówki naprawcze z przykładami kodu, gdzie to możliwe. Priorytety należy nadawać przede wszystkim na podstawie wpływu na użytkownika, a nie wygody technicznej. Uszkodzona etykieta formularza, która uniemożliwia finalizację zakupu, jest pilniejsza niż nieoptymalny poziom nagłówka w pasku bocznym bloga.

Krok 6: Napraw, zweryfikuj i monitoruj

Po wdrożeniu poprawek zweryfikuj je — nie zakładaj, że naprawa zadziałała. Przetestuj każdą poprawkę tym samym zestawem narzędzi i kontroli ręcznych, których użyto podczas pierwotnego audytu. Po osiągnięciu bazowego poziomu zgodności wprowadź ciągłe monitorowanie. Nowe treści, aktualizacje CMS i skrypty stron trzecich mogą w każdej chwili wprowadzić regresje. Traktuj dostępność jak bezpieczeństwo: coś, co się utrzymuje, a nie coś, co osiąga się raz i zapomina.

Skany automatyczne vs pełne audyty: na czym polega różnica

To rozróżnienie ma ogromne znaczenie, zwłaszcza w kontekście prawnym. Skan automatyczny uruchamia kontrolę opartą na regułach względem renderowanego HTML. Trwa sekundy lub minuty i zwraca listę wykrytych naruszeń. Świetnie nadaje się do wychwytywania oczywistych, masowych problemów i do integracji z workflow CI/CD, aby zapobiegać wdrażaniu nowych regresji. Wiele produktów typu overlay i widżetów — w tym narzędzia dostępności — oferuje panele skanowania automatycznego jako część zestawu funkcji i są one rzeczywiście przydatne do bieżącego monitorowania.

Pełny audyt natomiast ocenia Twoją stronę względem każdego mającego zastosowanie kryterium sukcesu WCAG, używając kombinacji skanowania automatycznego, ręcznej oceny eksperckiej, testów z czytnikami ekranu i nawigacji wyłącznie klawiaturą. Kompleksowy audyt łączący metody automatyczne i ręczne może ujawnić ponad 90% problemów z dostępnością, w porównaniu z pułapem 30–40% w przypadku samej automatyzacji. Jeśli stajesz w obliczu pisma przedsądowego, wymogu przetargowego lub zapytania regulatora, tylko pełny audyt dostarcza dokumentacji, której potrzebujesz.

Wiele organizacji stosuje praktyczną strategię hybrydową: skany automatyczne są uruchamiane ciągle w CI/CD, aby wcześnie wychwytywać regresje, podczas gdy pełny audyt ręczny jest przeprowadzany raz w roku lub po istotnych zmianach w projekcie strony. Równoważy to dokładność z efektywnością i pozwala utrzymać zgodność w dłuższej perspektywie.

Żadne narzędzie samo w sobie nie jest w stanie określić, czy strona spełnia standardy dostępności. Do ustalenia, czy strona jest rzeczywiście dostępna, wymagana jest kompetentna ocena człowieka. — W3C Web Accessibility Initiative

Co zrobić z wynikami audytu: planowanie napraw

Ukończony audyt ma wartość tylko wtedy, gdy prowadzi do działania. To, jak priorytetyzujesz prace naprawcze, jest równie ważne jak samo zidentyfikowanie problemów. Praktyczne ramy priorytetyzacji napraw wyglądają następująco:

1. Krytyczne (napraw natychmiast): Problemy, które całkowicie blokują użytkownikom realizację kluczowych zadań — uszkodzony formularz zakupu, niedostępne okno logowania, menu nawigacyjne nieosiągalne z klawiatury. Stanowią one najwyższe ryzyko prawne i największy wpływ na użytkowników.
2. Wysokie (napraw w bieżącym sprincie lub cyklu wydawniczym): Problemy, które znacząco utrudniają korzystanie osobom z niepełnosprawnościami, ale nie blokują ich całkowicie — brak tekstu alt przy obrazach produktów, niski kontrast tekstu głównego, nieoznaczone przyciski z ikonami w całym interfejsie.
3. Średnie (zaplanowane naprawy): Problemy, które powodują tarcia, ale mają obejścia — niespójne wskaźniki fokusu, brak linków do pomijania nawigacji, nieoptymalna hierarchia nagłówków.
4. Niskie (backlog z przypisanym właścicielem): Problemy będące ulepszeniami dobrych praktyk, ale mało prawdopodobne, by wpływały na użyteczność w większości przypadków — usprawnienia na poziomie AAA, drobne poprawki gadatliwości ARIA.

Udokumentuj swój plan napraw i harmonogram, nawet zanim wszystkie poprawki zostaną wdrożone. Regulatorzy i sądy zazwyczaj patrzą przychylniej na wykazane, ciągłe, działanie w dobrej wierze niż na bezczynność. Jeśli otrzymasz pismo przedsądowe, posiadanie raportu z audytu oraz harmonogramu napraw stawia Cię w znacznie lepszej sytuacji niż brak jakiejkolwiek dokumentacji.

Widżety typu overlay i narzędzia SDK — takie jak to oferowane przez Accsible — mogą odegrać istotną rolę w fazie napraw. Mogą zapewnić natychmiastowe poprawki dla znacznej części typowych problemów (zwłaszcza preferencji wizualnych, takich jak kontrast, rozmiar czcionki i odstępy), podczas gdy Twój zespół deweloperski pracuje nad głębszymi poprawkami na poziomie kodu. Kluczem jest zrozumienie, co nakładki rozwiązują dobrze, i używanie ich jako elementu strategii warstwowej, a nie jako zamiennika poprawek w kodzie dla krytycznych barier.

Jak często należy przeprowadzać audyt dostępności?

Jednorazowy audyt to migawka Twojej strony w konkretnym dniu. Strony internetowe są żywymi produktami — treści się zmieniają, skrypty stron trzecich są aktualizowane, komponenty są zastępowane, a nowe funkcje wdrażane. Każde z tych zdarzeń może wprowadzić nowe bariery dostępności. Zrównoważony program dostępności zazwyczaj wygląda tak:

• Ciągłe skanowanie automatyczne zintegrowane z pipeline’em CI/CD lub poprzez panel monitorowania, wychwytujące regresje zanim trafią na produkcję
• Kwartalne ręczne kontrole wyrywkowe na stronach o wysokim ruchu i wysokim ryzyku (checkout, logowanie, formularze kontaktowe, kluczowe strony docelowe)
• Coroczny pełny audyt przeprowadzany przez wykwalifikowanych ekspertów ds. dostępności, szczególnie po dużych redesignach lub migracjach platformy
• Audyt na etapie projektowania dla każdej nowej dużej funkcji lub redesignu — dostępność jest znacząco tańsza do wbudowania niż do wdrożenia wstecznego

Najbardziej opłacalne podejście polega na przesunięciu dostępności „w lewo” — zintegrowaniu jej z procesem projektowania i rozwoju od pierwszego dnia, zamiast traktowania jej jako powdrożeniowego ćwiczenia z zakresu zgodności. Deweloperzy, którzy rozumieją wymagania WCAG, wychwytują problemy u źródła. Projektanci, którzy znają zasady kontrastu kolorów i rozmiarów celów dotykowych, domyślnie podejmują decyzje sprzyjające dostępności. Audyt staje się wtedy bramką jakości, a nie interwencją awaryjną.

Kluczowe wnioski

• Większość stron nie spełnia WCAG. Ponad 95% stron głównych ma wykrywalne błędy dostępności, a sześć najczęstszych błędów — niski kontrast, brak tekstu alt, puste linki, brak etykiet formularzy, puste przyciski i brak języka dokumentu — odpowiada za zdecydowaną większość. Wszystkie są możliwe do naprawienia.
• Narzędzia automatyczne są konieczne, ale niewystarczające. Skanery automatyczne wychwytują w najlepszym razie 30–40% problemów WCAG. Kompletny audyt wymaga testów klawiaturą, testów z czytnikami ekranu oraz eksperckiej oceny kodu i przepływów UX.
• WCAG 2.2 Level AA jest celem. To standard, do którego odwołują się ADA, European Accessibility Act, Section 508 i większość innych ram dostępności na świecie. Celowanie w 2.2 AA oznacza, że automatycznie obejmujesz wszystkie niższe wersje.
• Naprawy wymagają ram priorytetów. Zacznij od problemów, które całkowicie blokują kluczowe ścieżki użytkownika, a następnie przechodź przez problemy o wysokim wpływie i wysokiej częstotliwości. Wszystko dokumentuj — raport z audytu i plan napraw to Twoja najlepsza linia obrony prawnej.
• Dostępność to proces ciągły, a nie jednorazowy. Połącz ciągłe monitorowanie automatyczne z okresowymi audytami ręcznymi i wprowadź dostępność do procesu projektowania i rozwoju od początku. Widżet typu overlay, taki jak Accsible, może wypełnić luki, podczas gdy trwają głębsze naprawy.