WCAG 2.2 – praktyczny przewodnik po najważniejszych wymaganiach

WCAG 2.2 to aktualny zbiór wytycznych dotyczących dostępności treści internetowych. Pomaga projektować strony, aplikacje, formularze i dokumenty tak, aby mogły z nich korzystać osoby o różnych potrzebach, także przy użyciu technologii asystujących. Ten praktyczny przewodnik wyjaśnia najważniejsze wymagania, pokazuje typowe błędy i podpowiada, jak przełożyć standard na codzienną pracę organizacji.

WCAG nie jest instrukcją obsługi jednego systemu ani listą zaleceń przeznaczoną wyłącznie dla programistów. To zestaw testowalnych kryteriów sukcesu, które dotyczą między innymi struktury treści, obsługi klawiaturą, kontrastu, formularzy, komunikatów o błędach, multimediów oraz działania interfejsu w różnych przeglądarkach i na różnych urządzeniach. Standard został opublikowany przez W3C jako rekomendacja 5 października 2023 roku i zawiera dziewięć nowych kryteriów względem WCAG 2.1.

Co oznacza WCAG 2.2?

Skrót WCAG pochodzi od angielskiej nazwy Web Content Accessibility Guidelines, czyli wytycznych dotyczących dostępności treści internetowych. WCAG 2.2 opisuje oczekiwany efekt, a nie konkretną technologię. Dzięki temu te same zasady można stosować do klasycznych stron internetowych, aplikacji webowych, serwisów transakcyjnych, systemów intranetowych, platform edukacyjnych czy cyfrowych formularzy.

Wytyczne opierają się na czterech zasadach. Treść i interfejs powinny być:

• postrzegalne – użytkownik może odebrać informację wzrokiem, słuchem albo za pomocą technologii asystującej;
• funkcjonalne – wszystkie operacje da się wykonać, także bez myszy;
• zrozumiałe – komunikaty, nawigacja i sposób działania systemu są przewidywalne;
• kompatybilne – treść współpracuje z różnymi przeglądarkami, urządzeniami i technologiami asystującymi.

W ramach tych zasad WCAG 2.2 obejmuje 13 wytycznych oraz kryteria sukcesu na trzech poziomach zgodności: A, AA i AAA. To właśnie kryteria sukcesu, a nie same ogólne wytyczne, są podstawą oceny zgodności.

Poziomy zgodności A, AA i AAA

Poziomy zgodności określają, jak szeroki zakres wymagań spełnia strona lub aplikacja. Poziom A obejmuje minimum niezbędne do usunięcia najbardziej podstawowych barier. Poziom AA zawiera wszystkie kryteria A oraz AA i jest najczęściej przyjmowanym celem organizacji. Poziom AAA obejmuje także kryteria najwyższego poziomu, ale W3C nie rekomenduje wymagania pełnej zgodności AAA dla całych serwisów, ponieważ nie zawsze jest możliwe spełnienie wszystkich kryteriów dla każdego rodzaju treści.

W praktyce deklaracja zgodności z poziomem AA oznacza, że spełniono wszystkie kryteria poziomu A i AA, a nie tylko wybrane wymagania uznane za najważniejsze. Dlatego przed przygotowaniem deklaracji warto przeprowadzić audyt obejmujący reprezentatywne podstrony, funkcje, formularze, dokumenty i procesy użytkownika.

Dlaczego sam automatyczny skan nie wystarcza?

Narzędzia automatyczne mogą szybko wykryć część problemów, na przykład brak alternatywy tekstowej, nieprawidłową strukturę nagłówków, błędy w kodzie lub zbyt niski kontrast. Nie potrafią jednak wiarygodnie ocenić wszystkich aspektów dostępności. Nie rozstrzygną, czy tekst alternatywny rzeczywiście przekazuje sens grafiki, czy instrukcja jest zrozumiała, czy kolejność przechodzenia klawiszem Tab jest logiczna albo czy komunikat o błędzie pomaga poprawić formularz.

Ocena zgodności powinna więc łączyć testy automatyczne, analizę ekspercką, testy klawiaturą i – w miarę możliwości – badania z udziałem osób korzystających z technologii asystujących. W3C podkreśla, że kryteria są testowalne, ale część oceny wymaga pracy człowieka i rozumienia sposobu, w jaki różne osoby korzystają z internetu.

Najważniejsze wymagania WCAG 2.2 w praktyce

1. Tekst alternatywny i dostępne multimedia

Każda informacja przekazywana za pomocą obrazu powinna być dostępna także w formie tekstowej. Zdjęcie przedstawiające osobę, wykres, infografika, ikona pełniąca funkcję przycisku i grafika zawierająca istotny tekst wymagają odpowiedniego opisu albo rozwiązania równoważnego.

Tekst alternatywny powinien odpowiadać na pytanie: co użytkownik musi wiedzieć, aby zrozumieć treść lub wykonać zadanie? Nie chodzi o mechaniczne opisywanie każdego szczegółu. W przypadku zdjęcia dekoracyjnego często wystarczy pusty atrybut alternatywny, natomiast wykres powinien mieć opis trendu, wartości lub wniosków, które są ważne dla odbiorcy.

Materiały wideo powinny mieć napisy, a w zależności od charakteru publikacji także audiodeskrypcję lub alternatywę tekstową. Samo umieszczenie filmu na stronie nie gwarantuje dostępności, nawet jeśli odtwarzacz działa poprawnie.

2. Struktura treści i semantyka

Dostępna strona powinna mieć logiczną strukturę. Nagłówki muszą odzwierciedlać hierarchię informacji, listy powinny być zapisane jako listy, a tabele powinny zawierać oznaczone nagłówki. Dzięki temu osoba korzystająca z czytnika ekranu może szybko przejść do interesującej sekcji i zrozumieć zależności między elementami.

Ważne jest także poprawne określenie języka strony i fragmentów w innym języku. Semantyczny HTML zwykle poprawia dostępność, wydajność i możliwość utrzymania serwisu, ale nie zastępuje testów całego procesu użytkownika.

3. Kontrast i informacje niezależne od koloru

Kolor nie może być jedynym sposobem przekazywania informacji. Jeśli formularz oznacza błąd wyłącznie czerwoną ramką, część użytkowników może go nie zauważyć. Do koloru warto dodać tekst, ikonę, komunikat lub inne jednoznaczne oznaczenie.

Należy sprawdzać kontrast tekstu, elementów interfejsu i stanów aktywnych. Dotyczy to nie tylko podstawowej wersji strony, lecz także menu, przycisków, pól formularzy, komunikatów, linków oraz elementów widocznych po najechaniu kursorem lub uzyskaniu fokusu.

4. Pełna obsługa klawiaturą

Użytkownik powinien móc przejść przez całą stronę i wykonać wszystkie działania bez używania myszy. Dotyczy to otwierania menu, wyboru opcji, przesyłania formularza, obsługi okien modalnych, galerii, odtwarzaczy i komponentów dynamicznych.

Fokus klawiatury powinien być widoczny i logiczny. Nie może znikać pod nagłówkiem przyklejonym do górnej części ekranu ani pozostawać uwięziony w elemencie, z którego nie da się wyjść. Warto regularnie wykonać prosty test: odłączyć mysz i zrealizować najważniejsze zadanie wyłącznie za pomocą klawiszy Tab, Shift+Tab, Enter, Spacja i strzałek.

5. Czytelna nawigacja i przewidywalne działanie

Menu, tytuły stron, linki i układ serwisu powinny pomagać w orientacji. Link opisany jako „więcej” lub „kliknij tutaj” często nie mówi, dokąd prowadzi. Lepszy jest opis wskazujący cel, na przykład „Pobierz formularz zgłoszeniowy” albo „Sprawdź szkolenia z dostępności cyfrowej”.

Element nie powinien niespodziewanie zmieniać kontekstu po samym uzyskaniu fokusu lub wybraniu opcji, chyba że użytkownik został o tym wcześniej poinformowany. Powtarzalne elementy nawigacji powinny pojawiać się w podobnym układzie, a mechanizmy pomocy – takie jak kontakt, wyszukiwarka lub FAQ – powinny być dostępne w spójny sposób.

6. Formularze i komunikaty o błędach

Każde pole formularza powinno mieć jednoznaczną etykietę. Instrukcje powinny wyjaśniać wymagany format, a komunikaty o błędach – wskazywać konkretne pole i sposób poprawy. Sam komunikat „Wystąpił błąd” jest zwykle niewystarczający.

Warto ograniczać konieczność ponownego wpisywania tych samych danych. Jeśli użytkownik wcześniej podał nazwisko, adres lub dane kontaktowe, system powinien – tam, gdzie to możliwe – wykorzystać je ponownie albo umożliwić automatyczne uzupełnienie. Dotyczy to szczególnie długich formularzy, rejestracji i procesów zakupowych.

Nowe kryteria sukcesu w WCAG 2.2

WCAG 2.2 zachowuje większość kryteriów WCAG 2.1, ale dodaje dziewięć nowych. Są one szczególnie istotne z perspektywy projektowania interfejsów, formularzy i procesów uwierzytelniania. Jednocześnie kryterium 4.1.1 Parsing zostało oznaczone jako przestarzałe i usunięte z WCAG 2.2.

• 2.4.11 Fokus nieprzesłonięty – minimum – aktywny element nie powinien być całkowicie zasłonięty przez inne elementy interfejsu, na przykład przyklejony nagłówek.
• 2.4.12 Fokus nieprzesłonięty – rozszerzone – wymaga bardziej rygorystycznej widoczności fokusu i należy do poziomu AAA.
• 2.4.13 Wygląd fokusu – określa dodatkowe wymagania dotyczące widoczności obszaru fokusu; jest kryterium AAA.
• 2.5.7 Przeciąganie – funkcje obsługiwane przez przeciąganie powinny mieć alternatywę niewymagającą tego gestu.
• 2.5.8 Minimalny rozmiar celu – interaktywne cele powinny być wystarczająco duże i odpowiednio oddalone od siebie, z określonymi wyjątkami.
• 3.2.6 Spójna pomoc – powtarzalne mechanizmy pomocy, takie jak kontakt lub wyszukiwarka, powinny występować w spójnym miejscu.
• 3.3.7 Nadmiarowe wprowadzanie danych – system powinien ograniczać konieczność wielokrotnego podawania tych samych informacji.
• 3.3.8 Dostępne uwierzytelnianie – minimum – logowanie nie powinno wymagać testów pamięci lub przepisywania danych bez dostępnej alternatywy.
• 3.3.9 Dostępne uwierzytelnianie – rozszerzone – wprowadza bardziej wymagające zasady dla poziomu AAA.

Nowe wymagania nie powinny być traktowane jako osobny dodatek wdrażany dopiero na końcu projektu. Najlepiej uwzględnić je już podczas projektowania komponentów, makiet, formularzy i procesów logowania. Szczegółowy opis nowych kryteriów znajduje się w materiałach W3C poświęconych zmianom w WCAG 2.2.

WCAG 2.2 a dostępność cyfrowa w Polsce

W przypadku podmiotów publicznych wymagania dotyczące dostępności cyfrowej wynikają z przepisów krajowych i odnoszą się do normy EN 301 549. W praktyce analiza dostępności obejmuje między innymi wymagania dotyczące stron internetowych, aplikacji mobilnych i treści cyfrowych. WCAG jest ważnym punktem odniesienia, ale zakres obowiązków może wynikać także z konkretnych przepisów, rodzaju podmiotu i charakteru usługi.

Nie warto więc ograniczać działań do deklaracji „strona spełnia WCAG”. Rzetelna deklaracja powinna wynikać z przeprowadzonej oceny, wskazywać poziom zgodności, znane problemy i dostępne rozwiązania alternatywne. W raporcie z monitoringu dostępności cyfrowej podmiotów publicznych wskazano powiązanie wymagań ustawy o dostępności cyfrowej z normą EN 301 549, w szczególności z wymaganiami dotyczącymi treści internetowych i aplikacji.

Jak wdrażać WCAG 2.2 krok po kroku?

1. Ustal zakres. Zidentyfikuj strony, aplikacje, dokumenty, formularze i procesy, które mają zostać ocenione.
2. Wybierz najważniejsze zadania użytkownika. Sprawdź logowanie, kontakt, zakup, rejestrację, pobieranie dokumentu lub zapis na wydarzenie.
3. Wykonaj przegląd automatyczny. Potraktuj jego wynik jako punkt wyjścia, a nie pełny audyt.
4. Przetestuj klawiaturę i czytnik ekranu. Zwróć uwagę na fokus, kolejność elementów, nazwy przycisków i komunikaty.
5. Przeanalizuj treści. Sprawdź nagłówki, alternatywy tekstowe, język, prostotę komunikatów, linki i dokumenty.
6. Uporządkuj problemy. Nadaj im priorytety według wpływu na możliwość wykonania zadania, a nie wyłącznie według łatwości naprawy.
7. Wprowadź poprawki i przetestuj je ponownie. Zmiana jednego komponentu może wpłynąć na wiele miejsc w serwisie.
8. Ustal odpowiedzialność za utrzymanie. Dostępność wymaga procedur dla redakcji, projektantów, programistów i osób publikujących dokumenty.

Checklista WCAG 2.2 dla organizacji

• Czy najważniejsze zadania można wykonać bez myszy?
• Czy fokus klawiatury jest widoczny i nie jest zasłonięty?
• Czy strona ma logiczną hierarchię nagłówków?
• Czy grafiki informacyjne mają adekwatne opisy?
• Czy multimedia zawierają napisy i inne potrzebne alternatywy?
• Czy informacje nie są przekazywane wyłącznie kolorem?
• Czy tekst i elementy interfejsu mają odpowiedni kontrast?
• Czy przyciski i linki jasno opisują swoje działanie?
• Czy etykiety pól formularza są jednoznaczne?
• Czy błędy są opisane w sposób pomagający je poprawić?
• Czy system nie wymaga niepotrzebnego ponownego wpisywania danych?
• Czy logowanie jest możliwe bez niedostępnych testów pamięci?
• Czy pomoc i nawigacja są spójne na całej stronie?
• Czy po wdrożeniu zmian zaplanowano ponowną weryfikację?

Najczęstsze błędy przy wdrażaniu dostępności

Jednym z częstych błędów jest traktowanie dostępności jako zadania wyłącznie technicznego. Nawet poprawny kod nie rozwiąże problemu, jeśli redakcja publikuje skany dokumentów bez warstwy tekstowej, grafiki bez opisów albo nagłówki dobrane wyłącznie ze względu na wygląd.

Drugim problemem jest odkładanie testów do końca projektu. Im później wykryte zostaną błędy w architekturze informacji, komponentach lub procesie logowania, tym droższa i bardziej czasochłonna będzie ich naprawa. Dostępność powinna być częścią projektowania, tworzenia treści, programowania, testów i późniejszego utrzymania.

Nie należy także utożsamiać dostępności z jednym narzędziem lub jednym użytkownikiem. Wynik automatycznego testu, opinia jednej osoby albo pojedynczy test czytnikiem ekranu nie opisują całego doświadczenia. Najlepsze rezultaty daje połączenie różnych metod oraz analiza rzeczywistych scenariuszy korzystania z usługi.

Audyt, szkolenie i dalsze działania

Jeśli organizacja nie wie, od czego zacząć, dobrym pierwszym krokiem jest przegląd najważniejszych procesów i określenie ryzyk. Pomocne może być także zapoznanie się z materiałem Checklista przed audytem WCAG oraz z przewodnikiem jak przeprowadzić audyt dostępności cyfrowej.

Sam audyt nie wystarczy, jeśli pracownicy nie wiedzą, jak utrzymać dostępność w codziennej pracy. Dlatego warto połączyć ocenę serwisu z warsztatem dla osób odpowiedzialnych za treści, dokumenty, obsługę klienta i rozwój systemów. EmpatiaLAB prowadzi między innymi szkolenia z dostępności cyfrowej, które można dopasować do specyfiki instytucji, zespołu i używanych narzędzi.

Organizacje planujące rozwój kompetencji mogą również sprawdzić możliwości dofinansowania szkoleń z dostępności w BUR. Dobór finansowania zależy od programu, operatora i sytuacji organizacji, dlatego przed rozpoczęciem procesu warto zweryfikować aktualne warunki.

Podsumowanie

WCAG 2.2 to praktyczne ramy projektowania stron, aplikacji i treści, z których może korzystać możliwie szeroka grupa odbiorców. Najważniejsze działania obejmują zapewnienie tekstowych alternatyw, logicznej struktury, odpowiedniego kontrastu, pełnej obsługi klawiaturą, widocznego fokusu, zrozumiałych formularzy i przewidywalnej nawigacji. Nowe kryteria zwracają szczególną uwagę na fokus, przeciąganie, rozmiar celów interaktywnych, spójną pomoc, nadmiarowe dane i dostępne uwierzytelnianie.

Dostępność nie jest jednorazowym projektem. To sposób pracy, który wymaga dobrych standardów, kompetentnego zespołu i regularnego sprawdzania zmian. Jeśli chcesz przygotować audyt, szkolenie lub plan wdrożenia dostępności cyfrowej, skontaktuj się z EmpatiaLAB. Pomożemy przełożyć wymagania WCAG na konkretne rozwiązania możliwe do zastosowania w Twojej organizacji.

Źródła

• Web Content Accessibility Guidelines (WCAG) 2.2 – W3C Recommendation
• What’s New in WCAG 2.2 – W3C Web Accessibility Initiative
• Understanding WCAG 2.2 – W3C Web Accessibility Initiative
• Understanding Conformance – W3C Web Accessibility Initiative
• WCAG 2 Overview – W3C Web Accessibility Initiative
• Dostępność cyfrowa podmiotów publicznych – monitoring za lata 2022–2024