7 obszarów dostępności do przetestowania: checklista WCAG 2.2 z przykładami błędów

Obszary dostępności to grupy wymagań WCAG 2.2, które razem decydują, czy z Waszej strony albo aplikacji skorzysta osoba niewidoma z czytnikiem ekranu, ktoś obsługujący komputer samą klawiaturą, użytkownik oglądający wideo bez dźwięku i senior powiększający tekst do 200 procent. Poniżej rozpisujemy 7 obszarów do przetestowania, każdy z numerami kryteriów WCAG 2.2, przykładami błędów, które najczęściej widzimy w projektach, i sposobem sprawdzenia.

To praktyczny przegląd, a nie tekst o prawie. Kogo obowiązują przepisy i od kiedy, opisujemy w artykule Europejski Akt o Dostępności a testy WCAG, zmiany w samym standardzie w tekście WCAG 2.2: wymagania, zmiany i kogo obowiązują, a narzędzia i kolejność pracy krok po kroku w poradniku testowanie dostępności: jak, kiedy i jakimi narzędziami. Tutaj odpowiadamy na jedno pytanie: co konkretnie sprawdzić, żeby nie przeoczyć żadnej grupy użytkowników.

Jak obszary dostępności mają się do zasad POUR w WCAG 2.2?

WCAG 2.2 porządkuje wymagania według czterech zasad: postrzegalność, funkcjonalność, zrozumiałość i solidność (po angielsku Perceivable, Operable, Understandable, Robust, stąd skrót POUR). Każda zasada dzieli się na wytyczne, a te na kryteria sukcesu z poziomem A, AA albo AAA. Według specyfikacji W3C WCAG 2.2 z 2023 roku (aktualizacja z 12 grudnia 2024) wersja 2.2 dodała 9 nowych kryteriów i usunęła jedno, 4.1.1 Parsowanie. Standardem rynkowym i punktem odniesienia norm jest poziom AA.

Zasady POUR są dobre do raportu, ale trudne do planowania pracy, bo jeden ekran logowania dotyka wszystkich czterech naraz. Dlatego w testach dzielimy produkt na 7 obszarów dostępności, które odpowiadają temu, jak użytkownik faktycznie korzysta z interfejsu. Tabela pokazuje, gdzie który obszar ląduje w POUR i od których kryteriów warto zacząć.

Obszar 1: czy całą stronę da się obsłużyć klawiaturą?

Klawiatura to pierwszy obszar, bo z niej korzystają nie tylko osoby z niepełnosprawnością ruchową, ale też użytkownicy czytników ekranu, przełączników i sterowania głosem. Kryterium 2.1.1 (poziom A) wymaga, żeby każdą funkcję dało się obsłużyć z klawiatury, a 2.1.2 (A), żeby fokus nigdzie nie utknął. Do tego dochodzą logiczna kolejność fokusa (2.4.3, A) i widoczny wskaźnik fokusa (2.4.7, AA).

Nowością WCAG 2.2 jest kryterium 2.4.11 Fokus niezasłonięty (AA): element z fokusem nie może być całkowicie zasłonięty przez treść autora, na przykład przyklejony nagłówek, czat albo baner cookies. W praktyce to jeden z najczęstszych błędów, jakie znajdujemy w sklepach internetowych: tester przechodzi klawiszem Tab na dół listy produktów, a fokus chowa się pod paskiem „Dodaj do koszyka”, który zawsze wisi na dole ekranu.

Jak sprawdzić? Odłóżcie mysz i przejdźcie kluczową ścieżkę klawiszami Tab, Shift+Tab, Enter, Spacja, strzałkami i Esc. Zapisujcie każde miejsce, w którym nie widać, gdzie jest fokus, w którym kolejność skacze po ekranie albo w którym okno modalne nie daje się zamknąć klawiszem Esc. Najczęstsze przyczyny w kodzie to elementy div z obsługą kliknięcia zamiast natywnego przycisku, styl outline: none bez zamiennika i atrybut tabindex z wartością dodatnią.

Obszar 2: czy tekst i kolory są czytelne dla każdego?

Drugi obszar dotyczy osób słabowidzących, z daltonizmem, ze starszymi oczami i każdego, kto czyta telefon w słońcu. Kryterium 1.4.3 (AA) wymaga kontrastu co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego, czyli według definicji WCAG co najmniej 18 punktów albo 14 punktów pogrubionych. Kryterium 1.4.11 (AA) dokłada kontrast 3:1 dla elementów interfejsu, na przykład ramki pola formularza i ikony bez podpisu, a 1.4.1 (A) zakazuje przekazywania informacji wyłącznie kolorem.

Dwa kolejne kryteria sprawdzają, czy tekst przetrwa zmianę ustawień. 1.4.4 (AA) wymaga powiększenia tekstu do 200 procent bez utraty treści i funkcji, a 1.4.12 (AA) każe, żeby układ wytrzymał zwiększenie interlinii do 1,5 wielkości czcionki, odstępu po akapicie do 2, odstępów między literami do 0,12 i między słowami do 0,16. Ten ostatni test najłatwiej zrobić skryptozakładką, która wstrzykuje takie style, i sprawdzić, czy przyciski nie obcinają napisów.

Tu warto sprostować popularny mit, który krążył także w starszej wersji tego artykułu. WCAG nie wymaga czcionki 16 px ani kroju bezszeryfowego. To dobre praktyki projektowe, ale nie kryteria sukcesu, więc nie zapisujcie ich w raporcie jako niezgodności z WCAG. Kto zgłasza Times New Roman jako błąd krytyczny, ten zwykle ma potem długą rozmowę z działem marki, i to nie o dostępności.

Do kontrastu wystarczą Colour Contrast Analyser albo panel kontrastu w narzędziach deweloperskich przeglądarki. Zamiast przestarzałej wtyczki NoCoffee do symulacji wad wzroku użyjcie wbudowanej w Chrome DevTools funkcji Emulate vision deficiencies w panelu Rendering, która pokazuje stronę oczami osoby z deuteranopią, protanopią, tritanopią, achromatopsją albo z rozmytym widzeniem. Według raportu WebAIM Million z 2026 roku niski kontrast miało 83,9 procent stron głównych, więc ten obszar prawie zawsze coś znajduje.

Obszar 3: czy czytnik ekranu rozumie strukturę i komponenty?

Czytnik ekranu zamienia stronę na mowę albo pismo Braille’a, ale widzi tylko to, co jest w kodzie: nagłówki, punkty orientacyjne (landmarki), etykiety i role elementów. Dlatego trzeci obszar sprawdza strukturę i nazwy, a nie wygląd. Kryteria do zapamiętania: 1.1.1 tekst alternatywny (A), 1.3.1 informacje i relacje (A), 2.4.6 nagłówki i etykiety (AA), 4.1.2 nazwa, rola, wartość (A) oraz 4.1.3 komunikaty o stanie (AA), czyli na przykład informacja „dodano do koszyka” odczytana bez przenoszenia fokusa.

Którym czytnikiem testować? Według ankiety WebAIM Screen Reader User Survey #10 z przełomu 2023 i 2024 roku (1539 odpowiedzi) głównym czytnikiem na komputerze był JAWS u 40,5 procent badanych, NVDA u 37,7 procent i VoiceOver u 9,7 procent, a NVDA regularnie używało 65,6 procent respondentów. Rozsądne minimum to więc darmowy NVDA na Windows, VoiceOver na iOS i macOS oraz TalkBack na Androidzie dla aplikacji mobilnych.

Najczęstsze błędy z tego obszaru są banalne i dlatego bolesne: przycisk z samą ikoną lupy odczytany jako „przycisk”, zdjęcie produktu z tekstem alternatywnym „IMG_2041.jpg”, tabela zbudowana z elementów div, nagłówki dobrane według wielkości czcionki, a nie hierarchii. Z naszego doświadczenia jedna sesja z NVDA na stronie koszyka znajduje więcej problemów, które naprawdę blokują zakup, niż godzina czytania raportu ze skanera.

Obszar 4: czy wideo i audio mają napisy, transkrypcje i audiodeskrypcję?

Czwarty obszar dotyczy osób niesłyszących, słabosłyszących i niewidomych, a w praktyce także każdego, kto ogląda wideo w pociągu bez słuchawek. Kryterium 1.2.2 (A) wymaga napisów do nagranego wideo z dźwiękiem, 1.2.4 (AA) napisów na żywo, 1.2.3 (A) audiodeskrypcji albo alternatywy tekstowej, a 1.2.5 (AA) audiodeskrypcji nagranego wideo. Dla samego dźwięku, na przykład podcastu, kryterium 1.2.1 (A) wymaga transkrypcji. Kryterium 1.4.2 (A) każe dać możliwość zatrzymania dźwięku, który gra sam dłużej niż 3 sekundy.

Typowy błąd to napisy wygenerowane automatycznie i nigdy nieprzeczytane przez człowieka. Nazwy własne, liczby i terminy branżowe wychodzą w nich tak, że osoba niesłysząca dostaje inną treść niż reszta. Drugi klasyk to film w tle strony głównej z dźwiękiem i bez przycisku pauzy. Sprawdzajcie też sam odtwarzacz: czy da się go obsłużyć klawiaturą, czy przyciski mają nazwy dla czytnika ekranu i czy napisy da się włączyć bez myszy.

Obszar 5: czy strona działa po powiększeniu i na ekranie dotykowym?

Piąty obszar łączy powiększanie, orientację ekranu i obsługę dotykiem. Kryterium 1.4.10 Dopasowanie do ekranu (AA) wymaga, żeby treść dała się czytać bez przewijania w dwóch kierunkach przy szerokości odpowiadającej 320 pikselom CSS, czyli przy powiększeniu 400 procent na ekranie o szerokości 1280 pikseli. Kryterium 1.3.4 (AA) zabrania blokowania widoku w jednej orientacji, jeśli nie jest to niezbędne.

Dwa nowe kryteria WCAG 2.2 dotyczą bezpośrednio dotyku. 2.5.8 Minimalny rozmiar celu (AA) wymaga celu o wymiarach co najmniej 24 na 24 piksele CSS albo odpowiedniego odstępu od sąsiednich celów, a 2.5.7 Ruchy przeciągania (AA) wymaga, żeby funkcję wykonywaną przeciąganiem dało się też wykonać pojedynczym kliknięciem, na przykład przyciskami plus i minus przy suwaku ceny. Uwaga na drugi mit: 48 na 48 to zalecenie wytycznych projektowych Material Design, a 44 na 44 to poziom AAA w kryterium 2.5.5, nie minimum WCAG. Szerzej o testach na urządzeniach piszemy w artykule best practices testowania aplikacji mobilnych.

Jak testować? Ustawcie w przeglądarce szerokość okna 1280 pikseli i powiększenie 400 procent, potem przejdźcie formularz i koszyk. Na telefonie włączcie największy rozmiar tekstu systemowego, obróćcie ekran i spróbujcie trafić w małe ikony kciukiem. Emulator w DevTools pokaże układ, ale dopiero prawdziwy telefon pokazuje, czy da się trafić w krzyżyk zamykający okno.

Obszar 6: czy formularz prowadzi przez błędy, zamiast je ukrywać?

Szósty obszar to miejsce, w którym niedostępność najszybciej zamienia się w utracony przychód: rejestracja, logowanie, adres dostawy, płatność. Kryteria podstawowe to 3.3.2 etykiety lub instrukcje (A), 3.3.1 identyfikacja błędu (A), 3.3.3 sugestia korekty błędu (AA) i 1.3.5 określenie celu pola (AA), dzięki któremu przeglądarka może podpowiedzieć imię, e-mail czy adres. WCAG 2.2 dodało tu dwa kryteria: 3.3.7 Zbędne powtórne wprowadzanie danych (A), czyli bez ponownego wpisywania tego samego adresu w kolejnym kroku, oraz 3.3.8 Dostępne uwierzytelnianie (AA), czyli logowanie bez testu funkcji poznawczych, na przykład bez przepisywania znaków z obrazka, jeśli nie ma alternatywy, i z dopuszczonym wklejaniem hasła.

Najczęstszy błąd: pole obowiązkowe zaznaczone tylko czerwoną ramką, komunikat pojawia się wizualnie, ale czytnik ekranu go nie odczytuje, a fokus zostaje na przycisku „Wyślij”. Poprawny wzorzec jest prosty i nie wymaga żadnej biblioteki:

<label for="email">Adres e-mail</label>
<input id="email" name="email" type="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-blad">
<p id="email-blad">Podajcie adres w formacie nazwa@domena.pl</p>

Etykieta jest powiązana z polem atrybutem for, atrybut autocomplete realizuje kryterium 1.3.5, aria-invalid oznacza błędne pole, a aria-describedby sprawia, że czytnik ekranu odczyta treść błędu razem z etykietą. Testujcie to celowo błędnymi danymi: pustym polem, adresem bez małpy, za krótkim hasłem, i słuchajcie, co mówi NVDA albo VoiceOver. U naszych klientów z e-commerce ten jeden obszar daje zwykle najwięcej poprawek o wysokim priorytecie, bo leży na ścieżce zakupu.

Obszar 7: czy animacje i limity czasu dają się zatrzymać?

Siódmy obszar chroni osoby z epilepsją fotogenną, zaburzeniami przedsionkowymi, ADHD i każdego, kto czyta wolniej. Kryterium 2.3.1 (A) zabrania treści, które migają więcej niż trzy razy na sekundę, chyba że błyski mieszczą się poniżej progów. Kryterium 2.2.2 (A) wymaga możliwości zatrzymania, ukrycia albo wstrzymania ruchomej treści, która trwa dłużej niż 5 sekund, czyli karuzeli, przewijanych banerów i animowanych liczników. Kryterium 2.2.1 (A) każe dać użytkownikowi wyłączenie, wydłużenie albo dostosowanie limitu czasu, na przykład przy wygasającej sesji płatności.

Animacje przy przewijaniu i paralaksa podlegają kryterium 2.3.3 na poziomie AAA, więc nie są twardym wymogiem AA, ale tanim zabezpieczeniem jest uszanowanie systemowego ustawienia ograniczenia ruchu. Strona odczytuje je zapytaniem CSS prefers-reduced-motion; testujcie, włączając w systemie opcję „Ogranicz ruch” na macOS i iOS albo „Pokaż animacje” na Windows. Przy okazji sprawdźcie nowe kryterium 3.2.6 Spójna pomoc (A): jeśli link do pomocy albo czatu jest na wielu stronach, ma być zawsze w tym samym miejscu.

Jak przetestować 7 obszarów dostępności w jeden tydzień?

Siedem obszarów brzmi jak miesiąc pracy, ale na jednej kluczowej ścieżce, na przykład od strony produktu do potwierdzenia zamówienia, da się je przejść w tydzień. Automat zrobi pierwszy filtr, a ręczne testy pokażą resztę. Według raportu Deque Automated Accessibility Coverage Report na danych z ponad 13 000 stron automatyczne testy axe-core znalazły średnio 57,38 procent wszystkich zgłoszonych problemów, co oznacza, że ponad 40 procent wymagało człowieka.

Jeśli chcecie, żeby Wasz zespół robił to sam, najszybciej pomoże szkolenie z testowania dostępności cyfrowej albo kurs online z testowania dostępności WCAG. Jeśli wolicie niezależne spojrzenie z zewnątrz, w ramach testów dostępności przechodzimy wszystkie siedem obszarów na uzgodnionej próbie ekranów, a koszt i przebieg takiej pracy rozpisujemy w tekście audyt dostępności strony: jak wygląda i ile kosztuje. Dobre uzupełnienie to testy użyteczności, bo formularz zgodny z WCAG wciąż może być po prostu niewygodny.

Jeśli przygotowujecie przetarg albo odbiór od dostawcy, przeczytajcie też, jak Strefa QA radzi zamawiać WCAG, żeby dało się je odebrać. Spisanie 7 obszarów w kryteriach odbioru oszczędza sporo dyskusji po wdrożeniu.

Powiązane na blogu Quality Island

• Testowanie dostępności: jak, kiedy i jakimi narzędziami
• 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
• Best practices testowania aplikacji mobilnych

Pełna lista źródeł

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, rekomendacja z 2023 roku, aktualizacja 12.12.2024.
• W3C WAI, What’s New in WCAG 2.2, 2023.
• W3C WAI, Understanding Success Criterion 2.5.8: Target Size (Minimum), 2023.
• W3C WAI, Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum), 2023.
• WebAIM, The WebAIM Million, raport 2026, dane z lutego 2026.
• WebAIM, Screen Reader User Survey #10 Results, 2024.
• Deque Systems, Automated Accessibility Coverage Report, wersja strony z 2025 roku.
• NV Access, NVDA User Guide, 2026.
• Google, Chrome DevTools: Emulate vision deficiencies, dokumentacja 2026.
• MDN Web Docs, prefers-reduced-motion, 2026.