Audyt dostępności to systematyczny proces oceny, czy strona internetowa jest użyteczna dla wszystkich użytkowników — niezależnie od tego, czy korzystają z klawiatury zamiast myszy, czytnika ekranu zamiast monitora, lub czy mają ograniczenia poznawcze wpływające na odbiór treści. Szacuje się, że ponad 15% populacji świata żyje z jakąś formą niepełnosprawności, co oznacza, że niedostępna strona wyklucza realną część potencjalnych użytkowników.
Wyniki dobrze przeprowadzonego audytu wskazują konkretne bariery techniczne i projektowe, a nie ogólne zalecenia. Różnica między rzetelnym audytem a pobieżnym skanem narzędziem automatycznym jest ogromna — i warto ją rozumieć, zanim przystąpimy do oceny własnego serwisu.
Z naszego artykułu dowiesz się:
Standardy WCAG jako punkt odniesienia audytu
Każdy audyt dostępności zaczyna się od ustalenia, względem jakiego kryterium oceniamy stronę. Dziś branżowym standardem są wytyczne WCAG (Web Content Accessibility Guidelines) w wersji 2.1, a coraz częściej także 2.2, opublikowanej w 2023 roku przez W3C. Wytyczne te organizują wymagania wokół czterech zasad: percepcja, obsługa, zrozumienie i niezawodność — w skrócie POUR.
Każda zasada rozkłada się na kryteria sukcesu podzielone na trzy poziomy:
- Poziom A — minimalne wymagania, których niespełnienie uniemożliwia korzystanie ze strony przez część użytkowników
- Poziom AA — standard stosowany w europejskich przepisach prawnych, m.in. w dyrektywie o dostępności cyfrowej z 2016 roku
- Poziom AAA — wymagania rozszerzone, trudne do spełnienia globalnie, ale istotne w wybranych kontekstach np. serwisów dla osób z niepełnosprawnościami
Podczas audytu określamy zakres zgodności z góry — najczęściej jest to zgodność na poziomie AA w odniesieniu do WCAG 2.1 lub 2.2. Decyzja o wersji standardu powinna uwzględniać wymagania prawne obowiązujące w danej branży. Sektor publiczny w Polsce podlega ustawie o dostępności cyfrowej z 2019 roku, która wprost odwołuje się do WCAG 2.1 AA.
Warto wiedzieć, że WCAG 2.2 dodało nowe kryteria sukcesu, m.in. związane z rozmiarem obszarów dotykalnych na urządzeniach mobilnych czy widocznością focusu klawiatury. Jeśli audytujemy serwis, który ma być zgodny z najnowszym standardem, te kryteria też wchodzą do metodologii oceny.
Metodologia audytu — automatyczne skany i testy ręczne
Żaden skaner automatyczny nie zastąpi ręcznej weryfikacji. Badania pokazują, że narzędzia automatyczne wykrywają od 30% do 40% problemów z dostępnością — resztę można odkryć dopiero przez interakcję z interfejsem. Dlatego rzetelna metodologia audytu dostępności łączy oba podejścia.
Automatyczne narzędzia skanujące — co wykrywają, a czego nie
Do skanów automatycznych używamy narzędzi takich jak Axe, WAVE, Lighthouse (dostępny bezpośrednio w Chrome DevTools) czy IBM Equal Access Checker. Każde z nich analizuje kod HTML, ARIA i CSS pod kątem znanych błędów.
Automaty dobrze radzą sobie z wykrywaniem: brakujących atrybutów alt na obrazach, nieprawidłowego kontrastu kolorów (narzędzia mierzą stosunek jasności i porównują z progami WCAG — 4,5:1 dla normalnego tekstu), brakujących etykiet formularzy, nieprawidłowej hierarchii nagłówków czy błędnie zastosowanych ról ARIA.
Czego nie wykrywają? Nie ocenią, czy tekst alternatywny obrazu jest sensowny (tylko czy istnieje), nie sprawdzą, czy treść odczytana przez screen reader brzmi logicznie, nie wykryją pułapek fokusowych, które możesz napotkać tylko obsługując stronę klawiaturą.
Testy ręczne z klawiaturą i czytnikiem ekranu
Testy ręczne dzielimy na dwie kategorie: nawigacja klawiaturą i testy z rzeczywistymi screen readers. Nawigacja klawiaturą polega na całkowitym odłożeniu myszy — używamy wyłącznie klawisza Tab, Shift+Tab, Enter, Escape i klawiszy strzałek. Sprawdzamy, czy fokus jest zawsze widoczny, czy kolejność tabulacji odpowiada wizualnej strukturze strony, czy wszystkie interaktywne elementy są osiągalne i obsługiwalne.
Testy z czytnikami ekranu przeprowadzamy w kombinacjach najczęściej używanych przez osoby niewidome: NVDA z Firefox, JAWS z Chrome lub Edge, VoiceOver na macOS i iOS. Weryfikujemy, czy screen reader poprawnie odczytuje nazwy przycisków, etykiety pól formularzy, komunikaty o błędach, zmiany stanu komponentów (np. rozwinięcie menu) i powiadomienia dynamiczne.
ARIA — kiedy pomaga, a kiedy szkodzi dostępności
Specyfikacja ARIA (Accessible Rich Internet Applications) to zestaw atrybutów HTML, który pozwala deweloperom przekazywać informacje semantyczne tam, gdzie standardowy HTML jest niewystarczający. W kontekście audytu dostępności ARIA jest tematem szczególnie ważnym, bo błędnie zastosowane atrybuty ARIA często bardziej szkodzą niż pomagają.
Pierwsza zasada ARIA mówi wprost: jeśli możesz użyć natywnego elementu HTML o odpowiedniej semantyce, zrób to. Przycisk powinien być znacznikiem , nie z role="button" — bo natywny button automatycznie obsługuje fokus klawiatury i komunikuje swoją rolę czytnikowi bez dodatkowego kodu.
Najczęstsze błędy ARIA wykrywane w audytach
Podczas audytów regularnie spotykamy kilka powtarzających się problemów. Nadmierne stosowanie aria-hidden="true" na elementach, które faktycznie zawierają treść istotną dla użytkownika — programista chciał ukryć dekoracyjny element, ale przez błędny selektor CSS ukrył cały blok treści. Brakujące aria-label lub aria-labelledby na ikonach-przyciskach bez widocznego tekstu — screen reader odczyta wtedy tylko „przycisk” bez kontekstu. Źle używane aria-live do ogłaszania zmian dynamicznych — zbyt agresywne ustawienie assertive przerywa narrację czytnika, a brak aria-live w ogóle sprawia, że użytkownik nie wie, że coś się zmieniło.
Kolejny problem to role ARIA przypisane do złych elementów lub niekompletne implementacje wzorców interakcji. Specyfikacja ARIA Authoring Practices Guide opisuje dokładnie, jakie klawisze i zachowania powinien obsługiwać każdy wzorzec (menu, dialog, tabpanel) — w audycie weryfikujemy zgodność z tymi wzorcami, nie tylko obecność atrybutów.
Zakres audytu — strony, przepływy i komponenty
Zakres audytu dostępności to decyzja, która bezpośrednio przekłada się na czas i koszt pracy. Niemal żaden serwis nie może pozwolić sobie na audyt każdej podstrony — zamiast tego definiujemy reprezentatywną próbę.
Dobra metodologia obejmuje:
- Strony szablonowe — stronę główną, stronę artykułu/wpisu, stronę kategorii, stronę statyczną (np. „O nas”), stronę wyników wyszukiwania
- Krytyczne przepływy użytkownika — rejestracja, logowanie, formularz kontaktowy, proces zakupowy (jeśli dotyczy), obsługa błędów walidacji
- Komponenty interaktywne — modalne okna, rozwijane menu nawigacji, suwaki, karuzele, datepickery, alerty, taby
Każdy z tych elementów oceniamy osobno, ale raportujemy problemy w kontekście wzorca — jeśli przycisk CTA na każdej stronie ma ten sam błąd kontrastu, raportujemy to jako jeden problem komponentu, nie jako kilkadziesiąt osobnych błędów. Taka agregacja ułatwia priorytetyzację napraw.
Priorytetyzację opieramy na dwóch wymiarach: powadze bariery (czy blokuje użytkownika całkowicie, częściowo, czy utrudnia tylko korzystanie) i zasięgu (ile stron i przepływów dotyczy problemu). Błąd powodujący, że osoba niewidoma nie może przesłać formularza kontaktowego, ma wyższy priorytet niż nieprawidłowy poziom nagłówka na stronie „O nas”.
Od raportu do naprawy — jak wdrażać wyniki audytu
Raport z audytu dostępności ma wartość tylko wtedy, gdy prowadzi do konkretnych działań. Dobry raport zawiera dla każdego znaleziska: opis problemu, odwołanie do konkretnego kryterium WCAG (np. 1.4.3 Kontrast — poziom AA), screenshota lub nagrania ekranu ilustrującego problem, wskazanie kodu źródłowego (XPath lub selektor CSS) oraz sugestię naprawy.
Jak organizować naprawy w zespole
Naprawy dzielimy na trzy grupy. Szybkie wygrane to zmiany zajmujące godziny — dodanie brakującego alt, zmiana koloru tekstu na bardziej kontrastowy, dodanie etykiety do pola formularza. Zmiany wymagające pracy designera i dewelopera to np. przeprojektowanie komponentu, który nie obsługuje klawiatury. Zmiany systemowe to problemy wynikające z architektury CMS lub frameworka, których rozwiązanie wymaga decyzji na poziomie technicznym — tu warto zaplanować sprint lub dedykowaną iterację.
Warto wdrożyć automatyczny skan dostępności jako element CI/CD — narzędzia takie jak Axe-core można zintegrować z pipelines testowymi, by nowe błędy były wykrywane zanim trafią na produkcję. To nie zastępuje audytu, ale zapobiega regresji po naprawach.
Ponowne testy po wdrożeniu poprawek to obowiązkowy etap. Naprawy dostępności bywają wymagające — deweloper może usunąć jeden błąd ARIA, tworząc przy okazji nowy. Weryfikacja końcowa, nawet uproszczona, zamyka pętlę i daje pewność, że raport przełożył się na rzeczywistą poprawę doświadczenia użytkowników korzystających z technologii wspomagających.
