WCAG 2.1 AA wymaga spełnienia wszystkich kryteriów sukcesu na poziomie A i AA, co łącznie daje 50 punktów kontrolnych uporządkowanych w ramach czterech zasad: postrzegalność, funkcjonalność, zrozumiałość i solidność. Ta checklista przechodzi przez praktyczne obszary o największym znaczeniu dla typowej strony firmowej, pogrupowane według tych czterech zasad, dzięki czemu można systematycznie sprawdzić własną stronę, zamiast zgadywać, co właściwie obejmuje “zgodność z AA”.

Dwie rzeczy warto wiedzieć przed przejściem przez tę listę. Po pierwsze, to praktyczne omówienie obszarów o największym znaczeniu dla typowej strony firmowej, a nie dosłowne powtórzenie wszystkich 50 kryteriów sukcesu; oficjalna dokumentacja W3C jest autorytatywnym źródłem, jeśli potrzebne jest dokładne sformułowanie prawne. Po drugie, “AA” to poziom, a nie osobny standard: poziom AA obejmuje wszystko wymagane na poziomie A plus dodatkowe kryteria poziomu AA, więc strona deklarująca zgodność z AA musi spełniać oba poziomy razem, a nie kryteria AA w izolacji.

Postrzegalność: czy użytkownicy w ogóle mogą odebrać treść

Kontrast kolorów. Tekst potrzebuje współczynnika kontrastu co najmniej 4,5:1 względem tła (3:1 dla dużego tekstu). Warto sprawdzić to najpierw: raport WebAIM Million 2026 wykazał, że 83,9% stron głównych miało tekst o niskim kontraście, co czyni go najczęstszym błędem w całym zbiorze danych. Jasnoszary tekst na białym tle, wciąż powszechny wybór projektowy w wielu nowoczesnych szablonach stron, to konkretny przypadek wart sprawdzenia.

Tekst alternatywny do zdjęć. Każde znaczące zdjęcie potrzebuje tekstowego odpowiednika opisującego jego cel lub zawartość; czysto dekoracyjne zdjęcia powinny mieć puste atrybuty alt, by czytnik ekranu je pomijał, zamiast zapowiadać coś bez sensu. Zdjęcia produktów, grafiki informacyjne i ikony niosące znaczenie (jak ptaszek oznaczający sukces) to kategorie najczęściej pomijane.

Napisy i transkrypcje. Nagrane wcześniej wideo potrzebuje napisów, a treść wyłącznie audio potrzebuje transkrypcji. Dotyczy to każdej osadzonej treści wideo, nie tylko tej stworzonej samodzielnie.

Skalowalny tekst. Tekst musi dać się powiększyć do 200% bez utraty treści lub funkcjonalności, a treść nie powinna polegać na stałym układzie pikselowym, który psuje się przy powiększeniu.

Nie polegaj wyłącznie na kolorze. Każda informacja przekazywana kolorem (na przykład czerwona ramka oznaczająca błąd w formularzu) potrzebuje też drugiego wskaźnika, jak ikona czy etykieta tekstowa, dla użytkowników, którzy nie mogą odróżnić danego koloru.

Funkcjonalność: czy użytkownicy mogą nawigować i wchodzić w interakcję ze wszystkim

Pełny dostęp z klawiatury. Każdy element interaktywny, linki, przyciski, pola formularzy, niestandardowe widżety jak rozwijane listy czy okna modalne, musi dać się obsłużyć wyłącznie klawiaturą, bez pułapek klawiaturowych uniemożliwiających wyjście z elementu klawiszem Tab.

Widoczny wskaźnik fokusu. Gdy użytkownik przechodzi klawiszem Tab do elementu, musi być widoczny wskaźnik pokazujący, gdzie aktualnie znajduje się fokus. To obszar, który WCAG 2.2 później rozszerzyło, ale już jest to wymóg poziomu AA w wersji 2.1.

Brak nieoczekiwanych zmian treści. Elementy nie powinny automatycznie wywoływać istotnej zmiany kontekstu (jak wczytanie nowej strony) samym otrzymaniem fokusu, a treść nie powinna nieprzewidywalnie przemieszczać się podczas interakcji.

Opisowy tekst linków i nagłówków. Tekst linku powinien mieć sens poza kontekstem (unikaj ogólnikowych linków “kliknij tutaj”), a strony potrzebują logicznej struktury nagłówków, by użytkownicy czytników ekranu mogli nawigować według poziomu nagłówka.

Wiele sposobów na znalezienie treści. Strona zasadniczo potrzebuje więcej niż jednego sposobu na znalezienie danej podstrony, na przykład funkcji wyszukiwania plus menu nawigacji plus mapy strony, zamiast wymagać od użytkowników znajomości dokładnej ścieżki.

Zrozumiałość: czy treść i zachowanie są przewidywalne

Jasny język i instrukcje. Pola formularzy potrzebują jasnych etykiet, a instrukcje powinny być zrozumiałe, zwłaszcza w zakresie pól wymaganych i oczekiwanego formatu danych.

Spójna nawigacja. Menu nawigacyjne i powtarzające się komponenty powinny pojawiać się w tej samej względnej kolejności na wszystkich stronach, by użytkownicy budowali dokładny model mentalny witryny.

Identyfikacja błędów i sugestie. Gdy wysłanie formularza się nie powiedzie, konkretny błąd musi zostać zidentyfikowany tekstowo (nie samym kolorem), a tam, gdzie to możliwe, powinna zostać podana sugestia jego naprawy.

Przewidywalne zachowanie przy wprowadzaniu danych. Zmiana wartości lub ustawienia pola formularza nie powinna automatycznie wywoływać nieoczekiwanej zmiany kontekstu, jak wysłanie formularza czy przejście na inną stronę, bez wyraźnego działania użytkownika.

Solidność: czy treść działa z technologią wspomagającą

Poprawny, dobrze ustrukturyzowany kod. Choć stare kryterium 4.1.1 Parsing zostało wycofane w WCAG 2.2, czysty, zgodny ze standardami HTML wciąż ma w praktyce znaczenie dla niezawodnej obsługi technologii wspomagających.

Właściwa nazwa, rola i wartość dla niestandardowych komponentów. Każdy niestandardowy komponent interaktywny (niestandardowa rozwijana lista, panel zakładek czy okno modalne zbudowane od zera zamiast natywnych elementów HTML) potrzebuje poprawnych ról, stanów i właściwości ARIA, by technologia wspomagająca mogła go poprawnie zidentyfikować i obsłużyć.

Komunikaty o stanie. Dynamiczne aktualizacje stanu, jak potwierdzenie “dodano do koszyka” czy wynik walidacji formularza, muszą być zapowiadane użytkownikom czytników ekranu bez konieczności ręcznego przenoszenia fokusu.

Prosta kolejność pracy nad checklistą

Próba naprawienia wszystkich 50 kryteriów naraz zwykle zatrzymuje projekt, zanim się zacznie, więc pomaga zgrubna priorytetyzacja. Zacznij od problemów o dużym wpływie i łatwych do zweryfikowania: kontrast kolorów i brakujący tekst alternatywny, ponieważ oba są powszechne (same błędy kontrastu pojawiły się na 83,9% stron głównych w badaniu WebAIM Million 2026) i proste do sprawdzenia skanerem. Następnie przejdź do obsługi klawiatury w kluczowych ścieżkach konwersji, ponieważ użytkownik, który nie może dokończyć zamówienia czy rejestracji samą klawiaturą, jest całkowicie zablokowany, a nie tylko utrudniony. Potem przejdź przez etykietowanie formularzy i komunikaty o błędach, gdzie często po cichu zawodzi wiele niestandardowo zbudowanych komponentów, nawet na stronach, które poza tym wyglądają na rozsądnie dostępne. Zachowaj kryteria wymagające więcej oceny, jak to, czy struktura nagłówków jest naprawdę logiczna, czy komunikat o stanie poprawnie zapowiada się czytnikowi ekranu, na dedykowane przejście testów ręcznych, gdy bardziej mechaniczne problemy zostaną już usunięte.

Jak faktycznie przejść przez tę checklistę

Narzędzia do skanowania automatycznego, w tym te oparte na szeroko używanym silniku axe-core od Deque, to naprawdę przydatny pierwszy krok i wychwycą realną część tych problemów szybko, zwłaszcza problemy z kontrastem i brakującym tekstem alternatywnym. Ale narzędzia automatyczne nie ocenią wszystkiego z tej listy: to, czy struktura nagłówków jest logiczna, czy etykieta ARIA jest faktycznie trafna, czy użytkownik czytnika ekranu może dokończyć proces zakupowy w sensownej kolejności, wszystko to wymaga ludzkiego testera, najlepiej korzystającego z prawdziwej technologii wspomagającej na kluczowych ścieżkach użytkownika. Niektórzy dostawcy, jak Wawsome, łączą automatyczne kontrole oparte na widżecie z weryfikatorem sprawdzanym przez człowieka specjalnie po to, by pokryć tę lukę, podczas gdy inni, jak UserWay, oferują automatyczny skan z opcjonalnym dodatkiem w postaci profesjonalnego ręcznego audytu dla głębszego przeglądu.

Jeśli nie wiadomo, czy tę checklistę wbudować w proces wewnętrzny, czy zaangażować pomoc zewnętrzną, nasz przewodnik po wyborze między widżetem a ręcznym audytem omawia, jak podjąć tę decyzję na podstawie zasobów własnego zespołu.