Jakie kryteria obowiązują dla WCAG 2.2

WCAG 2.2 Pełna aktualna lista kryteriów A i AA z wyjaśnieniami

Wdrażane w Europie przez EAA oraz obowiązujące w Polsce od 28 Czerwca 2025 nowe wytyczne dostępności WCAG 2.2 mogą sprawiać kłopoty z uwagi na dużą liczbę kryteriów oraz zmiany wprowadzane w poszczególnych wersjach WCAG. Aby pomóc w pracach nad dostępnością WCAG stron internetowych, przygotowaliśmy kompletną listę i wyjaśnienie wszystkich 60 kryteriów sukcesu dla poziomów A i AA: WCAG 2.2 Checklista.

Dlaczego skupiamy się na poziomach A i AA oraz pomijamy poziom dostępności AAA?

Wytyczne WCAG mają trzy poziomy dostępności: A (podstawowy), AA (rozszerzony) i AAA (najwyższy). W kontekście prawnym, w tym polskiej ustawy wdrażającej Europejski Akt o Dostępności, standardem, który należy osiągnąć, jest poziom AA. Oznacza to, że Twoja strona musi spełniać wszystkie kryteria z poziomów A oraz AA. Poziom AAA dotyczy bardziej zaawansowanych i specjalistycznych zaleceń, które nie są obowiązkowym wymogiem dla większości serwisów komercyjnych.

Poniższa lista kryteriów WCAG 2.2, to zestawienie kryteriów, które pomoże zrozumieć zakres ewentualnych zmian. Pełną, oficjalną dokumentację techniczną w języku angielskim można znaleźć na stronie organizacji W3C.

Warto zauważyć, że w tej chwili nie ma jeszcze oficjalnego tłumaczenia na język polski kryteriów dla WCAG 2.2. Tłumaczenie istnieje tylko dla poprzedniego standardu 2.1.

Lista zasad i kryteriów WCAG 2.2 Checklista dla dostępności cyfrowej

Pierwsza zasada WCAG: Postrzegalność

WCAG 2.2 Checklista cz. 1: Informacje i komponenty interfejsu użytkownika muszą być przedstawione użytkownikom w sposób, który mogą oni postrzegać.

• 1.1.1 Treść nietekstowa (Poziom A): Każdy obrazek, ikona czy grafika musi mieć swój tekstowy odpowiednik (tzw. atrybut ALT), który opisuje, co się na nim znajduje.
• 1.2.1 Tylko audio lub tylko wideo (nagranie) (Poziom A): Jeśli na stronie jest nagranie dźwiękowe (np. podcast) lub film bez dźwięku, musi być dostępna ich alternatywa tekstowa (transkrypcja).
• 1.2.2 Napisy (nagranie) (Poziom A): Wszystkie nagrania wideo z dźwiękiem muszą posiadać zsynchronizowane napisy dla osób niesłyszących.
• 1.2.3 Audiodeskrypcja lub alternatywa dla mediów (nagranie) (Poziom A): Dla nagrań wideo należy dostarczyć alternatywną wersję z audiodeskrypcją (opisem tego, co dzieje się na ekranie) lub pełną transkrypcję tekstową.
• 1.2.4 Napisy (na żywo)(Poziom AA): Dla wszystkich transmisji na żywo, które zawierają dźwięk (np. webinary, konferencje online, transmisje sportowe), musza być dostępne napisy tworzone w czasie rzeczywistym dla osób niesłyszących.
• 1.2.5 Audiodeskrypcja (nagranie) (Poziom AA): Wszystkie nagrania wideo muszą posiadać zsynchronizowaną audiodeskrypcję dla osób niewidomych.
• 1.3.1 Informacje i relacje (Poziom A): Struktura treści musi być logiczna i poprawnie oznaczona w kodzie (np. nagłówki, listy, tabele), aby technologie asystujące mogły ją poprawnie zinterpretować.
• 1.3.2 Zrozumiała kolejność (Poziom A): Kolejność, w jakiej treści są prezentowane i odczytywane, musi być logiczna i intuicyjna.
• 1.3.3 Charakterystyka zmysłowa (Poziom A): Instrukcje dotyczące obsługi strony nie mogą opierać się wyłącznie na cechach zmysłowych, takich jak kształt, kolor, rozmiar czy lokalizacja (np. „kliknij okrągły przycisk po prawej stronie”).
• 1.3.4 Układ (Poziom AA): Strona musi być czytelna i funkcjonalna zarówno w orientacji pionowej, jak i poziomej (np. na obróconym telefonie), bez utraty treści.
• 1.3.5 Określenie przeznaczenia danych wejściowych (Poziom AA): Pola formularzy powinny być w kodzie oznaczone zgodnie z ich przeznaczeniem (np. „imię”, „e-mail”), co ułatwia autouzupełnianie.
• 1.4.1 Użycie koloru (Poziom A): Kolor nie może być jedynym sposobem przekazywania informacji, wskazywania akcji czy rozróżniania elementów.
• 1.4.2 Kontrola odtwarzania dźwięku (Poziom A): Jeśli na stronie automatycznie odtwarza się dźwięk trwający dłużej niż 3 sekundy, użytkownik musi mieć możliwość jego zatrzymania lub wyciszenia.
• 1.4.3 Minimalny kontrast (Poziom AA): Tekst (oraz jego graficzna prezentacja) musi mieć odpowiednio wysoki kontrast w stosunku do tła, aby był czytelny dla osób słabowidzących.
• 1.4.4 Zmiana rozmiaru tekstu (Poziom AA): Użytkownik musi mieć możliwość powiększenia tekstu na stronie o co najmniej 200% bez utraty treści lub funkcjonalności.
• 1.4.5 Obrazy tekstu (Poziom AA): Należy unikać umieszczania tekstu w formie obrazków. Jeśli jest to konieczne (np. w logo), tekst powinien być możliwy do dostosowania przez użytkownika.
• 1.4.10 Dopasowanie do ekranu (Poziom AA): Treść strony musi dopasowywać się do szerokości ekranu, aby unikać konieczności przewijania w poziomie (z wyjątkiem np. map czy tabel).
• 1.4.11 Kontrast elementów nietekstowych (Poziom AA): Ważne elementy interfejsu (np. przyciski, pola formularzy) oraz istotne części grafik muszą mieć wystarczający kontrast z otoczeniem.
• 1.4.12 Odstępy w tekście (Poziom AA): Użytkownik musi mieć możliwość dostosowania odstępów między wierszami, akapitami, słowami i literami bez utraty funkcjonalności.
• 1.4.13 Treść na wskazaniu lub fokusie (Poziom AA): Jeśli po najechaniu myszką lub ustawieniu fokusu na elemencie pojawia się dodatkowa treść (np. podpowiedź, „dymek”, submenu), musi ona pozostać widoczna, pozwolić na interakcję i dać się łatwo zamknąć bez przypadkowego przesuwania kursora.

Druga zasada WCAG: Funkcjonalność

WCAG 2.2 Checklista cz. 2: Komponenty interfejsu użytkownika i nawigacja muszą być możliwe do użycia.

• 2.1.1 Klawiatura (Poziom A): Wszystkie funkcje strony muszą być dostępne i możliwe do obsłużenia za pomocą samej klawiatury, bez użycia myszki.
• 2.1.2 Brak pułapki na klawiaturę (Poziom A): Użytkownik nawigujący klawiaturą nie może utknąć w żadnym elemencie strony, z którego nie da się wyjść.
• 2.1.4 Jednoznakowe skróty klawiszowe (Poziom A): Jeśli strona używa skrótów klawiszowych składających się z jednego znaku, musi istnieć mechanizm, aby je wyłączyć, zmienić lub aktywować tylko po ustawieniu na nich fokusu.
• 2.2.1 Możliwość regulacji czasu (Poziom A): Jeśli na stronie istnieją limity czasowe (np. na wypełnienie formularza), użytkownik musi mieć możliwość ich wyłączenia, dostosowania lub przedłużenia.
• 2.2.2 Pauza, zatrzymanie, ukrycie (Poziom A): Dla wszelkich ruchomych, migających lub przewijających się treści (np. banerów) musi istnieć mechanizm, aby je zatrzymać lub ukryć.
• 2.3.1 Trzy błyski lub mniej (Poziom A): Strona nie może zawierać niczego, co błyska częściej niż trzy razy na sekundę, aby nie wywoływać ataków padaczki.
• 2.4.1 Możliwość pominięcia bloków (Poziom A): Musi istnieć mechanizm (np. link „przejdź do treści”), który pozwala użytkownikom nawigującym klawiaturą ominąć powtarzające się bloki, takie jak menu nawigacyjne.
• 2.4.2 Tytuły stron (Poziom A): Każda podstrona musi mieć unikalny i opisowy tytuł, który informuje o jej zawartości.
• 2.4.3 Kolejność fokusu (Poziom A): Elementy, po których można nawigować klawiaturą, muszą otrzymywać fokus w logicznej i intuicyjnej kolejności.
• 2.4.4 Widoczny cel linku (w kontekście) (Poziom A): Cel każdego linku musi być zrozumiały z jego tekstu lub z otaczającego go kontekstu.
• 2.4.5 Wiele dróg (Poziom AA): Musi istnieć więcej niż jeden sposób na znalezienie danej podstrony w serwisie (np. przez menu, wyszukiwarkę, mapę strony).
• 2.4.6 Nagłówki i etykiety (Poziom AA): Nagłówki i etykiety pól formularzy muszą jasno opisywać temat lub przeznaczenie danej sekcji lub pola.
• 2.4.7 Widoczny fokus (Poziom AA): Każdy element, który otrzymuje fokus klawiatury, musi mieć wyraźnie widoczny wskaźnik tego fokusu (np. ramkę).
• 2.4.11 Fokus niezasłonięty (Minimum) (Poziom AA) [Obowiązuje od WCAG 2.2]: Element, na którym znajduje się fokus klawiatury, nie może być całkowicie zasłonięty przez inne treści, np. „przylepione” nagłówki czy banery cookie.
• 2.5.1 Gesty dotykowe (Poziom A): Jeśli funkcjonalność wymaga złożonego gestu (np. uszczypnięcia, aby powiększyć), musi istnieć prostsza alternatywa (np. przyciski +/-).
• 2.5.2 Wskaźnik anulowania (Poziom A): Jeśli użytkownik przez przypadek aktywuje jakąś funkcję (np. klikając i przytrzymując), musi mieć możliwość jej anulowania przed puszczeniem przycisku.
• 2.5.3 Etykieta w nazwie (Poziom A): Jeśli element interfejsu ma widoczną etykietę tekstową, ten tekst musi być zawarty w jego dostępnej nazwie odczytywanej przez czytniki ekranu.
• 2.5.4 Aktywacja przez ruch (Poziom A): Jeśli jakaś funkcja jest uruchamiana przez poruszenie urządzeniem (np. potrząśnięcie), musi istnieć alternatywny sposób jej aktywacji.
• 2.5.7 Ruchy przeciągania (Poziom AA) [Obowiązuje od WCAG 2.2]: Jeśli funkcjonalność opiera się na przeciąganiu elementów (drag-and-drop), musi istnieć alternatywny, prostszy sposób jej obsługi (np. za pomocą przycisków).
• 2.5.8 Rozmiar celu (Minimum) (Poziom AA) [Obowiązuje od WCAG 2.2]: Przyciski, linki i inne klikalne elementy muszą być wystarczająco duże (min. 24×24 piksele), aby łatwo było w nie trafić palcem na ekranie dotykowym.

Trzecia zasada WCAG: Zrozumiałość

WCAG 2.2 Checklista cz. 3: Informacje i obsługa interfejsu użytkownika muszą być zrozumiałe.

• 3.1.1 Język strony (Poziom A): Główny język każdej strony internetowej musi być określony w jej kodzie, aby czytniki ekranu mogły poprawnie odczytywać treść.
• 3.1.2 Język części (Poziom AA): Jeśli na stronie występują fragmenty w innym języku, również muszą być one odpowiednio oznaczone w kodzie.
• 3.2.1 Po otrzymaniu fokusu (Poziom A): Samo ustawienie fokusu na elemencie (np. przejechanie klawiszem Tab) nie może powodować istotnej zmiany na stronie (np. automatycznego wysłania formularza).
• 3.2.2 Przy wprowadzaniu danych (Poziom A): Zmiana ustawienia jakiegoś elementu (np. zaznaczenie checkboxa) nie może automatycznie powodować dużej zmiany kontekstu na stronie.
• 3.2.3 Spójna nawigacja (Poziom AA): Powtarzające się elementy nawigacyjne muszą występować w tej samej kolejności na wszystkich podstronach serwisu.
• 3.2.4 Spójna identyfikacja (Poziom AA): Komponenty, które mają tę samą funkcjonalność w całym serwisie (np. ikona koszyka), muszą być spójnie zidentyfikowane.
• 3.2.6 Spójna pomoc (Poziom A) [Obowiązuje od WCAG 2.2]: Jeśli na stronie dostępna jest pomoc (np. czat, FAQ, numer telefonu), mechanizm dostępu do niej musi być umieszczony w spójny sposób na różnych podstronach.
• 3.3.1 Identyfikacja błędu (Poziom A): Jeśli wystąpi błąd w formularzu, musi on być jasno zidentyfikowany i opisany w sposób tekstowy.
• 3.3.2 Etykiety lub instrukcje (Poziom A): Pola w formularzach muszą mieć widoczne etykiety lub instrukcje, które informują użytkownika, jakie dane należy wprowadzić.
• 3.3.3 Sugestie korekty błędu (Poziom AA): Jeśli błąd w formularzu jest znany i można zasugerować jego poprawkę (np. „Czy chodziło o .pl zamiast .pll?”), należy to zrobić.
• 3.3.4 Zapobieganie błędom (kontekst prawny, finansowy, danych) (Poziom AA): W przypadku operacji o poważnych konsekwencjach (prawnych, finansowych) użytkownik musi mieć możliwość sprawdzenia, potwierdzenia lub cofnięcia danych przed ich ostatecznym wysłaniem.
• 3.3.7 Zbędne wprowadzanie danych (Poziom A) [Obowiązuje od WCAG 2.2]: Użytkownik nie powinien być proszony o ponowne wprowadzanie tych samych informacji w ramach jednego procesu, jeśli dane te zostały już podane lub są dostępne.
• 3.3.8 Dostępne uwierzytelnianie (Minimum) (Poziom AA) [Obowiązuje od WCAG 2.2]: Proces logowania lub weryfikacji nie powinien opierać się na teście poznawczym (np. zapamiętywaniu, przepisywaniu, rozwiązywaniu zagadek typu CAPTCHA), chyba że istnieje alternatywna, łatwiejsza metoda.

Czwarta zasada WCAG: Solidność (Kompatybilność)

WCAG 2.2 Checklista cz. 4: Treść musi być solidnie zbudowana, aby mogła być poprawnie interpretowana przez szeroki zakres aplikacji użytkownika, w tym technologie asystujące.

• 4.1.2 Nazwa, rola, wartość (Poziom A): Wszystkie komponenty interfejsu użytkownika (np. przyciski, linki) muszą mieć w kodzie poprawnie zdefiniowaną nazwę, rolę i wartość, aby technologie asystujące wiedziały, czym są i jak działają.
• 4.1.3 Komunikaty o stanie (Poziom AA): Ważne komunikaty o stanie, które pojawiają się na stronie (np. „Produkt dodany do koszyka”, „Wyniki wyszukiwania zaktualizowane”), muszą być ogłaszane przez technologie asystujące (np. czytniki ekranu) bez przerywania pracy użytkownika.

Nowe kryteria WCAG 2.2 Checklista podsumowanie

Powyższa lista może wydawać się długa i techniczna, ale stanowi ona fundament solidnej i dostępnej dla wszystkich strony internetowej. Wdrożenie tych kryteriów to nie tylko spełnienie wymogu prawnego (Przeczytaj o kontrolach i karach), ale przede wszystkim inwestycja w jakość serwisu i otwarcie się na szersze grono odbiorców.

Rozumiemy, że analiza i wdrożenie wszystkich tych punktów może być przytłaczające. Wiele z nich wymaga specjalistycznej wiedzy technicznej i doświadczenia. (Sprawdź, jakie mogą być koszty audytu i wdrożenia).

Potrzebujesz pomocy? Zacznij od darmowej konsultacji!

Jeśli czujesz, że ta WCAG 2.2 Checklista to dla Ciebie za dużo, lub po prostu chcesz mieć pewność, że Twoja strona będzie w 100% zgodna z nowymi przepisami, jesteśmy tu, aby pomóc.

Skorzystaj z naszej darmowej, niezobowiązującej konsultacji. Omówimy Twoją sytuację i podpowiemy, od czego zacząć. Oferujemy również kompleksowy audyt dostępności, który jest najlepszym pierwszym krokiem do pełnej zgodności z WCAG 2.2. Jeżeli już wiesz czego potrzebujesz, to sprawdź cennik narzędzia, które zapewni pełną dostępność Twojej strony zgodną z najnowszymi kryteriami wprowadzonymi przez EAA i polską ustawę.