Najczęstsze błędy przy przechodzeniu z WCAG 2.1 na WCAG 2.2

Przejście z WCAG 2.1 na WCAG 2.2 nie polega na całkowitym rozpoczęciu pracy od nowa. WCAG 2.2 rozwija wcześniejszą wersję standardu, zachowuje większość znanych kryteriów i dodaje nowe wymagania, które odpowiadają na realne problemy użytkowników stron internetowych, aplikacji i usług cyfrowych.

W praktyce wiele organizacji popełnia jednak ten sam błąd: traktuje WCAG 2.2 jako drobną aktualizację formalną, a nie jako zmianę, która wymaga ponownej analizy wybranych elementów strony. Szczególnie dotyczy to fokusu klawiatury, małych przycisków, elementów wymagających przeciągania, formularzy wieloetapowych, pomocy dostępnej w serwisie oraz procesów logowania.

WCAG 2.2 zostało opublikowane jako rekomendacja W3C 5 października 2023 r. i wprowadza nowe kryteria sukcesu względem WCAG 2.1. Jednocześnie kryterium 4.1.1 Parsowanie zostało w WCAG 2.2 oznaczone jako przestarzałe i usunięte.

Błąd 1. Założenie, że zgodność z WCAG 2.1 automatycznie oznacza zgodność z WCAG 2.2

To jeden z najczęstszych błędów. Jeżeli strona była audytowana według WCAG 2.1 i uzyskała pozytywny wynik, nie oznacza to automatycznie, że spełnia WCAG 2.2.

WCAG 2.2 dodaje nowe kryteria sukcesu. Dla poziomu A i AA, czyli najczęściej wymaganego poziomu zgodności, szczególne znaczenie mają:

2.4.11 Fokus niezasłonięty — minimum (AA) [zobacz więcej]
2.5.7 Ruchy przeciągania (AA) [zobacz więcej]
2.5.8 Rozmiar celu — minimum (AA) [zobacz więcej]
3.2.6 Spójna pomoc (A) [zobacz więcej]
3.3.7 Nadmiarowe wprowadzanie danych (A) [zobacz więcej]
3.3.8 Dostępne uwierzytelnianie — minimum (AA) [zobacz więcej]

Jeżeli te obszary nie zostały wcześniej sprawdzone, nie można rzetelnie powiedzieć, że serwis spełnia WCAG 2.2.

W praktyce dobrym rozwiązaniem jest wykonanie audytu uzupełniającego. Nie zawsze trzeba badać całą stronę od początku, ale trzeba sprawdzić nowe kryteria oraz te elementy, które mogą zostać przez nie objęte: nagłówki przyklejone do góry strony, popupy, formularze, konta użytkowników, przyciski, linki, paginacje, moduły cookies, czaty i elementy mobilne.

Błąd 2. Ignorowanie kryterium 2.4.11 Fokus niezasłonięty

Nowe kryterium 2.4.11 Fokus niezasłonięty — minimum dotyczy sytuacji, w której element posiadający fokus klawiatury jest całkowicie zasłonięty przez inną treść utworzoną przez autora strony.

To bardzo częsty problem w nowoczesnych serwisach. Element aktywny może zostać zasłonięty przez:

przyklejony nagłówek,
pasek cookies,
okno czatu,
popup,
wysuwane menu,
sticky footer,
baner promocyjny,
boczny panel kontaktowy.

Właściciele stron często testują stronę myszką, ale nie sprawdzają jej klawiaturą. W efekcie nie widzą, że użytkownik przechodzący przez stronę klawiszem Tab trafia na link lub przycisk, którego nie może zobaczyć, bo znajduje się pod stałym nagłówkiem albo inną warstwą.

To nie jest drobny problem wizualny. Jeżeli użytkownik nie widzi, gdzie znajduje się fokus, traci kontrolę nad obsługą strony.

Co należy zrobić?

Trzeba przejść przez stronę klawiaturą i sprawdzić, czy każdy aktywny element jest widoczny w momencie otrzymania fokusu. Szczególną uwagę należy zwrócić na strony z przyklejonym menu, wyszukiwarką, filtrowaniem, popupami, paskiem cookies oraz długimi formularzami.

Błąd 3. Zbyt małe przyciski i linki

Kryterium 2.5.8 Rozmiar celu — minimum wymaga, aby cele wskaźnika miały odpowiedni rozmiar albo odpowiedni odstęp od innych celów. W WCAG 2.2 minimalny rozmiar celu to 24 na 24 piksele CSS, z określonymi wyjątkami.

Ten problem bardzo często występuje w elementach, które projektanci i programiści traktują jako drobne detale:

ikony społecznościowe,
przyciski paginacji,
strzałki karuzeli,
małe linki „więcej”,
przyciski w tabelach,
ikony edycji, usuwania lub pobierania,
linki w stopce,
przyciski zamykania okien,
elementy menu mobilnego,
przełączniki i checkboxy.

Na komputerze kliknięcie małej ikony myszką może wydawać się proste. Na telefonie, ekranie dotykowym albo przy ograniczonej sprawności ruchowej mały cel może być poważną barierą.

Co należy zrobić?

Trzeba sprawdzić wszystkie elementy klikalne, szczególnie te małe i blisko siebie. Jeżeli element nie ma 24 na 24 piksele CSS, należy ocenić, czy spełnia jeden z wyjątków albo czy ma odpowiedni odstęp od innych celów. W praktyce często najlepszym rozwiązaniem jest zwiększenie pola klikalnego przez padding, a nie tylko powiększenie samej ikony.

Błąd 4. Brak alternatywy dla przeciągania elementów

Kryterium 2.5.7 Ruchy przeciągania dotyczy funkcji, które wymagają przeciągania. WCAG 2.2 nie zakazuje stosowania mechanizmów drag and drop, ale wymaga, aby użytkownik miał alternatywną metodę wykonania tej samej czynności, o ile przeciąganie nie jest niezbędne.

Problem może wystąpić w takich elementach jak:

przeciąganie plików do formularza,
sortowanie elementów na liście,
przesuwanie kart,
układanie kolejności modułów,
suwaki,
mapy,
kreatory,
przesuwane galerie,
narzędzia do konfiguracji produktu.

Błąd polega na założeniu, że skoro mechanizm jest wygodny dla użytkownika myszki, to jest wystarczający dla wszystkich. Dla wielu osób przeciąganie jest trudne lub niemożliwe.

Co należy zrobić?

Każda funkcja oparta na przeciąganiu powinna mieć prostszą alternatywę: przyciski góra/dół, klasyczny przycisk wyboru pliku, pola formularza, listę rozwijaną, sterowanie klawiaturą albo inny mechanizm niewymagający przeciągania.

Błąd 5. Niespójna pomoc na podstronach

Kryterium 3.2.6 Spójna pomoc jest często bagatelizowane, ponieważ na pierwszy rzut oka wydaje się proste. W praktyce może jednak ujawniać problemy w strukturze całego serwisu.

Jeżeli mechanizmy pomocy występują na wielu stronach, powinny pojawiać się w tej samej względnej kolejności. Dotyczy to między innymi:

danych kontaktowych,
formularza kontaktowego,
czatu,
infolinii,
centrum pomocy,
bazy wiedzy,
linku do pomocy technicznej,
informacji o dostępności.

Błąd pojawia się wtedy, gdy na jednej podstronie pomoc jest w nagłówku, na drugiej w stopce, na trzeciej w bocznym panelu, a na czwartej pod inną nazwą albo w innej kolejności. Użytkownik, który raz nauczył się układu strony, powinien móc przewidywalnie znaleźć pomoc również w innych miejscach serwisu.

Co należy zrobić?

Należy ustalić stałe miejsce i kolejność elementów pomocy. Najlepiej potraktować je jako część powtarzalnego układu strony, a nie przypadkowy element dodawany osobno do wybranych podstron.

Błąd 6. Powtarzanie tych samych danych w formularzach

Kryterium 3.3.7 Nadmiarowe wprowadzanie danych dotyczy sytuacji, w której użytkownik musi ponownie wpisywać informacje, które już wcześniej podał lub które są dostępne w tym samym procesie.

To szczególnie ważne w:

formularzach wieloetapowych,
rejestracjach,
zamówieniach,
systemach rezerwacji,
wnioskach online,
formularzach urzędowych,
panelach klienta,
procesach zakładania konta.

Typowy błąd: użytkownik wpisuje dane kontaktowe w pierwszym kroku, a w kolejnym kroku system ponownie wymaga tych samych danych do potwierdzenia, faktury, dostawy albo zgłoszenia.

Dla części użytkowników powtarzanie danych jest męczące, zwiększa ryzyko błędów i może uniemożliwić ukończenie procesu.

Co należy zrobić?

Jeżeli dane zostały już podane, system powinien je automatycznie uzupełnić albo umożliwić ich wybór. Ponowne wpisywanie powinno być wymagane tylko wtedy, gdy jest rzeczywiście konieczne, na przykład ze względów bezpieczeństwa lub gdy dane straciły ważność.

Błąd 7. Niedostępne logowanie

Kryterium 3.3.8 Dostępne uwierzytelnianie — minimum dotyczy logowania i potwierdzania tożsamości. To jedno z najważniejszych nowych kryteriów WCAG 2.2 dla serwisów z kontami użytkowników.

Problemem może być wymaganie od użytkownika wykonania testu funkcji poznawczych bez dostępnej alternatywy. Przykłady:

przepisywanie tekstu z obrazka,
rozwiązywanie zagadek,
wykonywanie obliczeń,
zapamiętywanie kodu i wpisywanie go na innym ekranie,
blokowanie możliwości wklejenia hasła,
utrudnianie korzystania z menedżera haseł,
niedostępna CAPTCHA.

Błąd polega na tym, że bezpieczeństwo logowania jest projektowane bez uwzględnienia użytkowników z trudnościami poznawczymi, osób starszych, osób korzystających z technologii wspomagających lub użytkowników, którzy potrzebują menedżera haseł.

Co należy zrobić?

Należy umożliwić korzystanie z menedżerów haseł, autouzupełniania i wklejania danych. Jeżeli stosowana jest CAPTCHA lub inne zadanie poznawcze, trzeba zapewnić dostępną alternatywę. Warto też rozważyć logowanie linkiem, kody jednorazowe obsługiwane przez autouzupełnianie lub inne metody niewymagające zapamiętywania i przepisywania złożonych informacji.

Błąd 8. Dalsze raportowanie 4.1.1 Parsowanie jako aktywnego kryterium WCAG 2.2 [zobacz więcej]

WCAG 2.2 usuwa kryterium 4.1.1 Parsowanie. To istotna zmiana dla audytorów, wykonawców i właścicieli stron.

W starszych raportach często wskazywano błędy walidacji HTML jako naruszenie 4.1.1. Dotyczyło to na przykład zduplikowanych identyfikatorów id, nieprawidłowych zagnieżdżeń elementów albo błędów składniowych.

W WCAG 2.2 takie podejście jest przestarzałe. Nie oznacza to jednak, że kod może być byle jaki. Jeżeli błąd w kodzie powoduje realny problem dostępności, należy przypisać go do właściwego kryterium, na przykład:

1.3.1 Informacje i relacje,
2.4.3 Kolejność fokusu,
3.3.2 Etykiety lub instrukcje,
4.1.2 Nazwa, rola, wartość,
4.1.3 Komunikaty o stanie.

Przykład: zduplikowany identyfikator id sam w sobie nie powinien być automatycznie raportowany jako 4.1.1 w WCAG 2.2. Jeżeli jednak przez ten błąd etykieta formularza zostaje powiązana z niewłaściwym polem, mamy realny problem dostępności i należy go przypisać do odpowiedniego kryterium.

Co należy zrobić?

Trzeba zaktualizować metodologię audytu i szablony raportów. Błędy techniczne powinny być oceniane przez ich wpływ na użytkownika, a nie przez samo wystąpienie błędu walidacji.

Błąd 9. Opieranie audytu wyłącznie na automatycznych narzędziach

Automatyczne narzędzia są pomocne, ale nie wystarczą do oceny zgodności z WCAG 2.2.

Narzędzie może wykryć część błędów kontrastu, brakujące atrybuty, problemy z etykietami lub strukturą kodu. Nie oceni jednak rzetelnie wielu nowych wymagań WCAG 2.2, na przykład:

czy fokus jest zasłonięty w realnej ścieżce klawiatury,
czy pomoc pojawia się w tej samej względnej kolejności,
czy proces formularza wymaga niepotrzebnego powtarzania danych,
czy mechanizm przeciągania ma funkcjonalną alternatywę,
czy logowanie nie wymaga niedostępnego testu poznawczego.

Co należy zrobić?

Audyt WCAG 2.2 powinien łączyć testy automatyczne z ręczną oceną ekspercką. Konieczne są testy klawiaturą, analiza formularzy, sprawdzenie procesów użytkownika, ocena komponentów interaktywnych oraz weryfikacja działania z technologiami wspomagającymi.

Błąd 10. Sprawdzanie tylko strony głównej

Nowe kryteria WCAG 2.2 bardzo często ujawniają problemy nie na stronie głównej, ale w podstronach funkcjonalnych.

Szczególnie trzeba sprawdzić:

formularz kontaktowy,
wyszukiwarkę,
filtrowanie wyników,
listy aktualności,
kalendarze wydarzeń,
logowanie,
koszyk i zamówienie,
rejestrację,
panel użytkownika,
BIP,
dokumenty do pobrania,
strony z popupami,
strony mobilne.

Strona główna może wyglądać poprawnie, a jednocześnie formularz, wyszukiwarka lub panel klienta mogą zawierać poważne bariery.

Co należy zrobić?

Do audytu należy dobrać reprezentatywną próbę widoków i procesów. W WCAG 2.2 szczególne znaczenie mają nie tylko pojedyncze podstrony, ale całe ścieżki użytkownika.

Błąd 11. Brak testów mobilnych

Część nowych kryteriów WCAG 2.2 ma bardzo praktyczne znaczenie na urządzeniach mobilnych. Dotyczy to szczególnie rozmiaru celu, przeciągania elementów, fokusu, popupów i elementów pływających.

Typowe problemy mobilne:

zbyt małe ikony,
linki za blisko siebie,
przyklejony nagłówek zasłaniający treść,
pasek cookies zajmujący dużą część ekranu,
trudne do zamknięcia popupy,
menu mobilne bez poprawnego fokusu,
elementy wymagające gestów bez alternatywy.

Co należy zrobić?

Nie wystarczy sprawdzić strony na komputerze. Trzeba przetestować widoki mobilne, najlepiej przy różnych szerokościach ekranu, z obsługą dotykową i klawiaturą, jeżeli interfejs na to pozwala.

Błąd 12. Brak aktualizacji dokumentacji i deklaracji dostępności

Po przejściu z WCAG 2.1 na WCAG 2.2 trzeba uporządkować dokumentację. Dotyczy to zwłaszcza instytucji publicznych, wykonawców stron i organizacji, które posiadają raporty z audytów.

Częsty błąd polega na tym, że strona jest częściowo sprawdzana według WCAG 2.2, ale dokumentacja nadal odnosi się do WCAG 2.1 albo zawiera nieaktualne odniesienia do 4.1.1 Parsowanie.

Co należy zrobić?

Warto zaktualizować:

checklisty audytowe,
szablony raportów,
wymagania dla wykonawców,
zapisy w OPZ,
procedury odbioru strony,
dokumentację projektową,
informacje o zakresie badania,
deklarację dostępności, jeżeli jej treść odnosi się do zakresu audytu lub zastosowanego standardu.

Dokumentacja powinna jasno wskazywać, według jakiej wersji WCAG strona była sprawdzana i jaki był zakres badania.

Błąd 13. Traktowanie WCAG 2.2 wyłącznie jako obowiązku prawnego

WCAG 2.2 nie powinno być traktowane wyłącznie jako formalny wymóg. Nowe kryteria wynikają z realnych problemów użytkowników.

Zbyt małe przyciski, zasłonięty fokus, niedostępne logowanie, konieczność wielokrotnego wpisywania tych samych danych czy brak alternatywy dla przeciągania to nie są abstrakcyjne problemy techniczne. To bariery, które mogą uniemożliwić skorzystanie z usługi cyfrowej.

Dostępność cyfrowa ma znaczenie nie tylko dla zgodności z przepisami, ale też dla jakości serwisu, konwersji, wizerunku i obsługi klienta.

Jak dobrze przejść z WCAG 2.1 na WCAG 2.2?

Najlepsze podejście to nie panika i nie automatyczne przebudowywanie całej strony, ale uporządkowany audyt uzupełniający.

W praktyce warto wykonać następujące kroki:

Sprawdzić, kiedy i według jakiej wersji WCAG wykonano ostatni audyt.
Zweryfikować nowe kryteria WCAG 2.2 na poziomie A i AA.
Przetestować stronę klawiaturą, szczególnie przy sticky headerach, popupach i paskach cookies.
Sprawdzić rozmiary i odstępy przycisków, linków oraz ikon.
Zweryfikować funkcje wymagające przeciągania.
Przejść przez formularze i procesy wieloetapowe.
Sprawdzić logowanie, CAPTCHA, autouzupełnianie i obsługę menedżerów haseł.
Uporządkować sposób raportowania błędów po usunięciu 4.1.1 Parsowanie.
Zaktualizować dokumentację, checklisty i wymagania dla wykonawców.
Zaplanować wdrożenie poprawek według priorytetów.