WCAG 2.2

Wytyczne dotyczące dostępności treści internetowych (Web Content Accessibility Guidelines) publikuje W3C. Wersja 2.2 ukazała się 5 października 2023 r., a 12 grudnia 2024 r. opublikowano ją ponownie z poprawkami. Standard ma trzy warstwy: cztery zasady (postrzegalność, funkcjonalność, zrozumiałość i kompatybilność), wytyczne w ramach każdej zasady i kryteria sukcesu w ramach każdej wytycznej. To kryteria sukcesu może sprawdzić zamawiający. W3C formułuje je jako sprawdzalne stwierdzenia, niezależne od konkretnej technologii.

Każde kryterium sukcesu ma poziom. W WCAG 2.2 jest 31 kryteriów na poziomie A, 24 na AA i 31 na AAA, razem 86. Zgodność z danym poziomem oznacza spełnienie wszystkich kryteriów tego poziomu i poziomów niższych, więc AA to wszystkie 55 kryteriów z poziomów A i AA. Zgodność dotyczy wyłącznie całych stron i nie można jej deklarować, jeśli wyłącza się z niej część strony. Gdy strona jest jednym z kroków procesu, na przykład zamówienia albo wypełniania wniosku, zgodne muszą być wszystkie strony tego procesu.

WCAG 2.2 rozwija wersję 2.1 i jest z nią wstecznie zgodna: treść zgodna z WCAG 2.2 jest zgodna także z WCAG 2.0 i 2.1. Wersja 2.2 dodaje dziewięć kryteriów sukcesu i usuwa jedno, 4.1.1 Poprawność kodu, oznaczone teraz jako nieaktualne. W3C wymienia jako grupy, na których skupia się ta wersja, użytkowników z niepełnosprawnościami poznawczymi lub trudnościami w uczeniu się, osoby słabowidzące i osoby z niepełnosprawnościami korzystające z urządzeń mobilnych. W praktyce element, na który trafia fokus klawiatury, musi pozostać przynajmniej częściowo widoczny, cele wskazywane kursorem lub palcem muszą mieć co najmniej 24 na 24 piksele CSS, chyba że zachodzi wyjątek, wszystko, co robi się przeciąganiem, musi działać też pojedynczym wskazaniem, a logowanie nie może zależeć od testu funkcji poznawczych, takiego jak zapamiętanie hasła, chyba że jest alternatywa albo mechanizm, który w tym pomaga.

W sprawie poziomu AAA W3C zaznacza, że nie zaleca się wymagania zgodności z poziomem AAA jako ogólnej zasady dla całych serwisów, bo dla części treści nie da się spełnić wszystkich kryteriów AAA. Dwa przykłady to 1.4.6 Kontrast (wzmocniony), który podnosi wymagany kontrast tekstu z 4,5:1 do 7:1, i 3.1.5 Poziom umiejętności czytania, który wymaga prostszej wersji tekstu, jeśli jego zrozumienie wymaga umiejętności powyżej poziomu niższych klas szkoły średniej. To kryterium szczegółowo opisuje hasło tekst łatwy do czytania.

Dla podmiotu publicznego albo firmy objętej europejskim aktem o dostępności WCAG jest miarą przy odbiorze. Umowy, która mówi "dostępna" albo "zgodna z WCAG" bez wersji i poziomu, nie da się sprawdzić. Wymagania dla zamawianej aplikacji:

• Umowa podaje wersję, poziom i zakres, na przykład WCAG 2.2 na poziomie AA dla aplikacji webowej, aplikacji mobilnych i dokumentów generowanych przez system. EN 301 549 opisuje dokumenty nieinternetowe i oprogramowanie w osobnych rozdziałach, więc eksporty takie jak DOCX czy PDF wymagają osobnych testów.
• Jeśli chcesz AAA, wymień konkretne kryteria AAA, na przykład kontrast 7:1 albo prostszą wersję trudnego tekstu, zamiast wszystkich 31 kryteriów AAA na każdym ekranie.
• Każde wymaganie w backlogu ma numer kryterium sukcesu, któremu służy, a każde kryterium ma test, który zamawiający może wykonać przy odbiorze.
• Etykiety dla czytnika ekranu, komunikaty o błędach i komunikaty o stanie to treść. Trzymaj je w jednym katalogu, pisz prostym językiem i recenzuj jak każdy inny tekst. Kryterium 4.1.3 wymaga, żeby komunikaty o stanie docierały do technologii wspomagających bez przenoszenia fokusu.
• Testy łączą narzędzia i ludzi. Automatyczne skanery znajdą brakujące etykiety i zbyt niski kontrast. Obsługę samą klawiaturą, czytniki ekranu na każdej platformie i powiększenie do 200% musi sprawdzić człowiek.
• Nowe kryteria z wersji 2.2 wpływają na projekt od początku: wielkość celów dotykowych, przyklejone nagłówki zasłaniające aktywne pole, alternatywy dla przeciągania, linki do pomocy w tej samej kolejności na wszystkich stronach, brak ponownego wpisywania danych podanych wcześniej w tym samym procesie i logowanie bez testu pamięci.
• Jeśli system generuje tekst za pomocą AI, wynik też jest treścią. Dotyczą go poziom trudności, struktura i etykiety, a ich sprawdzanie należy do ewaluacji modelu.
• Odbiór kończy się raportem i ponownym testem. W Polsce podmiot publiczny musi też opublikować deklarację dostępności dla każdej wersji językowej strony lub aplikacji.

EN 301 549 to europejska norma dotycząca wymagań dostępności produktów i usług ICT. Wersja V3.2.1 (2021-03) jest normą zharmonizowaną dla dyrektywy (UE) 2016/2102 o dostępności stron internetowych i aplikacji mobilnych sektora publicznego; przywołuje ją decyzja wykonawcza Komisji (UE) 2021/1339. Jej rozdział 9 obejmuje treści internetowe i stwierdza, że zgodność z WCAG 2.1 na poziomie AA jest równoważna spełnieniu punktów 9.1-9.4 i wymagań zgodności z punktu 9.6. Rozdział 10 dotyczy dokumentów nieinternetowych, a rozdział 11 oprogramowania, w tym aplikacji mobilnych. Wersja V4.1.1 (2026-09), przyjęta 24 sierpnia 2026 r., dostosowuje rozdziały 9, 10 i 11 do WCAG 2.2 i powstała na potrzeby europejskiego aktu o dostępności. Sama norma stwierdza, że daje domniemanie zgodności z tym aktem, gdy zostanie przywołana w Dzienniku Urzędowym UE.

Europejski akt o dostępności (European Accessibility Act), dyrektywa (UE) 2019/882, dotyczy wymienionych w niej produktów wprowadzanych do obrotu i usług świadczonych konsumentom po 28 czerwca 2025 r. Wśród usług są handel elektroniczny, bankowość konsumencka, e-booki, łączność elektroniczna i elementy transportu pasażerskiego. Załącznik I wymaga, żeby usługi zapewniały dostępność stron internetowych, powiązanych aplikacji online i usług mobilnych tak, żeby były postrzegalne, funkcjonalne, zrozumiałe i kompatybilne. Produkty i usługi zgodne z opublikowanymi normami zharmonizowanymi są objęte domniemaniem zgodności z wymaganiami. Mikroprzedsiębiorcy świadczący usługi są zwolnieni.

W Polsce podmioty publiczne stosują ustawę z 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Jej załącznik wymienia kryteria sukcesu WCAG 2.1 z poziomów A i AA, a wymagania uznaje się za spełnione, gdy podmiot spełnia punkty 9, 10 i 11 Polskiej Normy wprowadzającej EN 301 549 V3.2.1. Art. 10 wymaga deklaracji dostępności dla każdej wersji językowej strony lub aplikacji. Firmy podlegają ustawie z 26 kwietnia 2024 r., która wdraża w Polsce europejski akt o dostępności i obowiązuje od 28 czerwca 2025 r., z wyjątkiem usług świadczonych przez mikroprzedsiębiorców.

Dla PSONI budujemy Generator ETR, aplikację, która zamienia dokumenty w tekst łatwy do czytania. Specyfikacja projektu wymaga zgodności z WCAG 2.2 na poziomie AAA. Zastrzeżenie W3C wobec AAA dotyczy całych serwisów jako ogólnej zasady; tu użytkownikami są osoby z niepełnosprawnością intelektualną, a aplikacja ma wąski zestaw ekranów i treści. Lista wymagań wiąże poszczególne pozycje z kryteriami sukcesu. Komunikat o błędzie ma mówić, co zrobić, a nie tylko co jest źle, najlepiej z przykładem (3.3.3 Sugestie korekty błędów). Usunięcie dokumentu wymaga okna potwierdzenia z domyślnym fokusem na "Anuluj" (kryterium 3.3.4 Zapobieganie błędom: prawnym, finansowym, w danych). Każda ikona ma mieć widoczną etykietę tekstową (1.1.1 wymaga alternatywy tekstowej; widoczna etykieta wynika z wytycznych W3C o dostępności dla osób z niepełnosprawnościami poznawczymi).

Testy w czerwcu 2026 r. wykazały, że po przekroczeniu limitu długości tekstu zmieniał się tylko kolor i licznik znaków, a przycisk wysyłania szarzał bez żadnego wyjaśnienia. Dodaliśmy komunikat walidacji obok licznika, a ponowny test we wrześniu 2026 r. wypadł pozytywnie. Brak potwierdzenia usunięcia został poprawiony i przeszedł ponowny test 21 września 2026 r.

We wrześniu i październiku 2026 r. dostosowaliśmy aplikację webową i mobilną do czytników ekranu i zebraliśmy wszystkie etykiety ARIA w jednym arkuszu, który służy też jako katalog komunikatów o błędach i stanie. Pierwsze testy w wersji webowej wykazały tekst w ogóle nieodczytywany albo czytany znak po znaku, fokus klawisza Tab omijający nagłówek strony i tytuły dokumentów oraz stany ładowania, o których czytnik nie informował. Tester zalecił weryfikację po stronie klienta, a poprawki z raportu testów czytnika ekranu w wersji webowej są osobnym, otwartym zadaniem.

1 października 2026 r. zakres ustawień tekstu zawężono do trzech rozmiarów czcionki, 100%, 150% i 200%, co obejmuje 200%, o których mówi kryterium 1.4.4 Zmiana rozmiaru tekstu; układ strony przy 200% nadal trzeba przetestować. Ustawienia obejmują też wybór głosu męskiego lub żeńskiego i szybkość czytania w syntezie mowy. Krój pisma, odstępy, marginesy i ustawienia dla pojedynczego dokumentu pozostały poza zakresem. DOCX jest jedynym formatem eksportu, więc generowany plik ma własny test dostępności: nagłówków, list, pogrubień i odczytu czytnikiem ekranu. W październiku 2026 r. ten test trwa.