WCAG 2.2 zmienia przede wszystkim obsługę interfejsu: widoczność fokusu, rozmiar elementów klikalnych, przeciąganie, formularze i logowanie. To aktualizacja wytycznych WCAG 2.1. Jeśli strona była porządnie przygotowana pod poprzednią wersję, startujesz z dobrego miejsca.
Czym różni się WCAG 2.2 od 2.1 (w skrócie)
WCAG 2.2 dodaje 9 nowych kryteriów sukcesu i usuwa kryterium 4.1.1 Parsing – pełną listę zmian opisuje W3C w materiale „What’s New in WCAG 2.2″ (EN). Fundament zostaje ten sam: poziomy A, AA i AAA się nie zmieniają, a dla większości firm i sklepów internetowych praktycznym celem nadal jest poziom AA.
Najprościej: jeśli znasz WCAG 2.1, nie zaczynasz od zera. Jeśli dopiero wchodzisz w temat, zacznij od naszego przewodnika po dostępności cyfrowej stron (WCAG). WCAG 2.2 rozwija poprzednią wersję i dopowiada kilka rzeczy, które mocno dotyczą codziennego korzystania ze stron: fokusu klawiatury, małych przycisków, przeciągania elementów, logowania, formularzy i powtarzania danych.
W praktyce porównanie WCAG 2.1 vs 2.2 sprowadza się do pytania: czy Twoja strona da się wygodnie obsłużyć wtedy, gdy ktoś nie korzysta z niej „idealnie”? Bez precyzyjnej myszy, na małym ekranie, z gorszą pamięcią albo bez pewności, gdzie aktualnie jest kursor klawiatury.
Dla właściciela firmy albo sklepu internetowego to dobra wiadomość. Te zmiany są konkretne i da się je sprawdzić na realnych elementach strony: w koszyku, checkoucie, formularzu kontaktowym, logowaniu, popupie z rabatem, przyklejonym nagłówku i menu mobilnym. To tam najczęściej wychodzą problemy.
Nowe kryteria sukcesu w WCAG 2.2
Nowa wersja dodaje 2 kryteria na poziomie A, 4 na poziomie AA i 3 na poziomie AAA. Najwięcej pracy przy typowej stronie firmowej albo sklepie zwykle dotyczy poziomu AA, czyli fokusu, przeciągania, rozmiaru elementów klikalnych i logowania.
Na poziomie A dochodzą Consistent Help oraz Redundant Entry. Pierwsze dotyczy spójnego miejsca na pomoc, jeśli taka pomoc pojawia się w procesie na kilku podstronach. Drugie ogranicza sytuacje, w których użytkownik musi wpisywać te same dane drugi raz w ramach jednego procesu.
Na poziomie AA pojawiają się Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum) oraz Accessible Authentication (Minimum). Brzmi technicznie, ale sens jest prosty: użytkownik ma widzieć, gdzie jest na stronie, trafiać w przyciski bez chirurgicznej precyzji, wykonać akcję bez przeciągania i zalogować się bez zbędnych łamigłówek.
Poziom AAA dodaje Focus Not Obscured (Enhanced), Focus Appearance oraz Accessible Authentication (Enhanced). To wyższy próg. Dla większości biznesów priorytetem będzie AA, ale kryteria AAA też warto znać, bo pokazują dobry kierunek projektowania.
Widoczny fokus: Focus Not Obscured i Focus Appearance
Fokus to podświetlenie elementu, na którym aktualnie znajduje się użytkownik poruszający się po stronie klawiaturą. Jeśli naciskasz Tab i przechodzisz przez linki, pola formularza oraz przyciski, strona powinna jasno pokazywać, gdzie jesteś.
Nowa wersja mocniej pilnuje tego tematu. Kryterium Focus Not Obscured (Minimum) wymaga, żeby element z fokusem nie był całkowicie zasłonięty przez treści dodane przez stronę. Najprostszy przykład: przyklejony nagłówek. Użytkownik przechodzi Tabem do linku, ale link chowa się pod belką menu. Formalnie coś się dzieje, praktycznie człowiek traci orientację.
Podobny problem robią popupy, banery cookies, paski promocji, czaty i boczne widgety. Same w sobie mogą być potrzebne. Kłopot zaczyna się wtedy, gdy przykrywają przycisk, link albo pole formularza, które właśnie dostało fokus.
Focus Appearance na poziomie AAA idzie dalej i dotyczy jakości samego oznaczenia fokusu. Obramowanie powinno być widoczne, mieć odpowiedni kontrast i nie znikać na tle przycisku. Cienka, jasnoszara ramka na białym tle zwykle nie wystarczy. Użytkownik nie powinien zgadywać, gdzie jest.
Najprostszy test? Otwórz stronę, odłóż mysz i przejdź przez główne ścieżki klawiszem Tab. Sprawdź menu, formularz kontaktowy, wyszukiwarkę, koszyk i checkout. Jeśli w którymś momencie nie wiesz, gdzie jesteś, masz konkretny trop do poprawy.
Obsługa dotykiem i myszą: Dragging Movements i Target Size
Wytyczne 2.2 biorą pod lupę obsługę strony wskaźnikiem, czyli myszą, palcem na ekranie albo rysikiem. Dwa nowe kryteria są tu szczególnie praktyczne: Dragging Movements i Target Size (Minimum).
Dragging Movements mówi, że jeśli jakaś akcja wymaga przeciągania, powinna mieć alternatywę wykonalną prostszym ruchem. Przykład? Sortowanie elementów metodą drag and drop. Dla części osób przeciągnięcie elementu w konkretne miejsce jest trudne albo niemożliwe. Dobra alternatywa to przyciski „w górę” i „w dół”, wybór z listy albo zwykły klik.
W sklepie internetowym może to dotyczyć suwaków cen, galerii zdjęć, konfiguratorów produktów albo modułów do ustawiania kolejności. Jeśli użytkownik musi przytrzymać, przesunąć i puścić dokładnie w jednym miejscu, sprawdź, czy da się osiągnąć ten sam efekt prościej.
Target Size (Minimum) dotyczy rozmiaru elementów klikalnych. Wytyczne wskazują minimum 24 × 24 piksele CSS, z wyjątkami. Nie każdy link w tekście musi nagle stać się wielkim przyciskiem. Jeśli jednak masz małe ikony obok siebie, miniaturowe przyciski zamknięcia, strzałki karuzeli albo checkboxy ustawione ciasno w checkoutcie, ryzyko rośnie.
Mały cel to realny koszt, a szczególnie widać to na telefonie. Użytkownik chce zatwierdzić zamówienie, a trafia w „usuń”. Chce rozwinąć wariant produktu, a klika sąsiednią opcję. Taki detal potrafi zepsuć sprzedaż szybciej niż brzydki nagłówek.
Łatwiejsze formularze: Consistent Help i Redundant Entry
Formularze są jednym z tych miejsc, gdzie dostępność bardzo szybko spotyka się z biznesem. Jeśli formularz jest męczący, część osób po prostu go porzuci – po cichu, bez żadnej wiadomości.
Consistent Help mówi o spójności pomocy. Jeśli w procesie pojawia się mechanizm pomocy, powinien być ustawiony w tym samym względnym miejscu na kolejnych stronach. Może to być link do kontaktu, czat, numer telefonu, sekcja pomocy albo przycisk wsparcia. Użytkownik nie powinien szukać go od nowa na każdym kroku.
W sklepie ma to sens choćby w checkoutcie. Jeśli pomoc przy dostawie jest przy formularzu adresowym, nie chowaj jej potem w zupełnie innym miejscu przy płatności. Jeśli ktoś utknie, ma szybko znaleźć ratunek.
Redundant Entry dotyczy ponownego wpisywania tych samych danych w ramach jednego procesu. Jeżeli użytkownik podał już imię, e-mail, adres albo numer telefonu, nie zmuszaj go do wpisywania tego drugi raz, jeśli strona może te dane uzupełnić albo pozwolić je wybrać.
Najprostszy przykład to adres dostawy i adres rozliczeniowy. Jeśli są takie same, wystarczy checkbox. Przy rezerwacji wizyty nie pytaj ponownie o e-mail na ostatnim kroku, skoro użytkownik podał go na początku. Każde powtórzenie zwiększa ryzyko błędu i frustracji.
Są sytuacje, w których ponowne podanie danych ma sens, na przykład ze względów bezpieczeństwa. Nowe wytyczne nie zabierają zdrowego rozsądku. Wymagają tylko, żeby nie robić z formularza toru przeszkód bez powodu.
Logowanie bez barier: Accessible Authentication
Accessible Authentication dotyczy logowania i potwierdzania tożsamości. Strona nie powinna wymagać od użytkownika testów poznawczych, jeśli nie daje mu dostępnej alternatywy albo mechanizmu wsparcia.
Problemem bywa przepisywanie zniekształconych znaków z obrazka, zapamiętywanie skomplikowanych kodów, łamigłówki, blokowanie wklejania hasła albo kodu jednorazowego i utrudnianie pracy menedżerom haseł.
Dla sklepu internetowego to temat bardzo praktyczny. Użytkownik chce sprawdzić zamówienie, pobrać fakturę, wrócić do porzuconego koszyka albo zmienić dane konta. Jeśli logowanie jest zbyt wymagające, część osób wybierze drogę na skróty: słabe hasło, rezygnację z konta albo porzucenie zakupu.
Dobre rozwiązania są dość proste. Pozwól wklejać hasła i kody. Nie blokuj autouzupełniania. Zadbaj o sensowne komunikaty błędów. Jeśli używasz CAPTCHA, wybierz rozwiązanie, które ma dostępną alternatywę. Przy kodach z SMS-a albo maila daj czas i możliwość ponownego wysłania.
Standard nie oczekuje, że logowanie będzie banalne kosztem bezpieczeństwa. Chodzi o to, żeby zabezpieczenia nie odcinały osób, które korzystają z technologii asystujących, mają trudności z pamięcią albo po prostu działają na telefonie w mało wygodnych warunkach.
Co usunięto z WCAG 2.2: kryterium 4.1.1 Parsing
Z WCAG 2.2 usunięto kryterium 4.1.1 Parsing (EN), bo współczesne przeglądarki i technologie asystujące radzą sobie z parsowaniem inaczej niż wtedy, gdy powstawały wcześniejsze wytyczne. Przy audycie pod nową wersję nie raportuje się go jako osobnego kryterium, ale błędy w kodzie nadal mogą powodować realne problemy.
Parsing dotyczył między innymi poprawności znaczników HTML: domkniętych tagów, zagnieżdżeń, unikalnych identyfikatorów i zdublowanych atrybutów. Kiedyś takie błędy częściej psuły odczyt strony przez technologie asystujące. Dziś wiele z tych sytuacji obsługują przeglądarki, a część problemów łapią inne kryteria.
To nie jest zaproszenie do bałaganu w kodzie. Jeśli przycisk ma zły atrybut, formularz nie ma poprawnej etykiety albo dwa elementy mają ten sam identyfikator i skrypt wariuje, użytkownik nadal może mieć kłopot. Taki problem może wejść pod inne kryteria, na przykład Name, Role, Value albo Info and Relationships.
W audycie trzeba więc jasno określić wersję standardu. Jeśli sprawdzasz zgodność z wersją 2.2, 4.1.1 Parsing wypada z checklisty jako osobny punkt. Jeśli umowa, regulamin albo wymaganie przetargowe odwołuje się do WCAG 2.1, audytor może nadal uwzględnić to kryterium, bo pracuje według starszej wersji.
Czy WCAG 2.2 oznacza zmiany na Twojej stronie
Najczęściej WCAG 2.2 oznacza punktowe poprawki w konkretnych komponentach. Przebudowa całego serwisu to rzadkość. Najpierw sprawdź miejsca, w których użytkownik coś wpisuje, klika, wybiera, przeciąga albo potwierdza.
W stronie firmowej będą to zwykle formularze kontaktowe, formularze rezerwacji, menu, popupy, czat, baner cookies i elementy przyklejone do ekranu. W sklepie dochodzą karta produktu, warianty, koszyk, checkout, płatność, logowanie i panel klienta.
Jeśli masz WooCommerce, zwróć uwagę na drobne elementy, które łatwo przeoczyć: małe przyciski plus i minus przy liczbie produktów, ikonę usuwania pozycji z koszyka, link do kuponu, checkbox akceptacji regulaminu i komunikaty błędów po nieudanej płatności. To są miejsca, gdzie dostępność wpływa prosto na sprzedaż.
Nowe wymagania szczególnie szybko odczują e-commerce, serwisy z kontami użytkowników i strony z dłuższymi formularzami. Tam każdy dodatkowy wysiłek boli bardziej. Jeśli klient musi dwa razy wpisać dane, nie widzi fokusu albo nie może zalogować się z menedżera haseł, problem blokuje konkretną akcję.
Dobra kolejność prac? Najpierw ścieżki, które mają znaczenie biznesowe: zakup, wysłanie zapytania, rezerwacja terminu, założenie konta i pobranie materiału. Dopiero potem mniej używane podstrony i drobniejsze widoki.
Jak sprawdzić zgodność z WCAG 2.2
Zacznij od skanu automatycznego, potem przejdź klawiaturą przez najważniejsze ścieżki i ręcznie sprawdź nowe kryteria. Zapisuj miejsce problemu, opis, wpływ na użytkownika i proponowaną poprawkę.
Skan automatyczny jest dobrym początkiem, bo szybko pokaże część błędów: kontrast, brak etykiet, problemy z nazwami elementów, strukturą nagłówków albo atrybutami. Nie złapie jednak wszystkiego. Narzędzie nie oceni sensownie, czy pomoc jest w przewidywalnym miejscu, czy alternatywa dla przeciągania naprawdę działa, ani czy użytkownik widzi fokus w trudnym układzie.
Drugi krok to test klawiaturą. Wejdź na stronę główną i przejdź Tabem do najważniejszych miejsc. Otwórz menu. Zamknij popup. Wypełnij formularz. Dodaj produkt do koszyka. Przejdź checkout. Spróbuj się zalogować. Przy każdym kroku pytaj prosto: czy wiem, gdzie jestem, czy mogę wykonać akcję, czy nic nie zasłania aktywnego elementu?
Trzeci krok to ręczny przegląd nowych kryteriów. Sprawdź, czy elementy klikalne mają sensowny rozmiar i odstępy. Zobacz, czy przeciąganie ma alternatywę. Przejrzyj formularze pod kątem powtarzania danych. Sprawdź, czy mechanizmy pomocy nie wędrują po ekranie bez logiki. Przetestuj logowanie z menedżerem haseł, wklejaniem hasła i kodem jednorazowym.
W notatkach nie zapisuj samego „niezgodne z WCAG”. To za mało. Lepszy zapis wygląda tak: „Checkout, krok dostawy: fokus na polu kodu pocztowego chowa się pod przyklejonym nagłówkiem. Użytkownik klawiatury traci orientację. Poprawka: dodać offset przewijania albo zmienić zachowanie sticky headera przy fokusie”. Taki opis da się przekazać projektantowi albo developerowi bez zgadywania.
Audyt u specjalisty ma sens, gdy strona ma dużo formularzy, konto użytkownika, płatności, integracje z zewnętrznymi systemami albo podlega formalnym wymaganiom dostępności. Ma też sens po większym redesignie. Automatyczny raport jest szybki, ale dopiero ręczne testy pokazują, czy użytkownik naprawdę przejdzie przez proces od początku do końca.
Nowa wersja nie przewraca stolika. Porządkuje rzeczy, które na dobrych stronach i tak powinny działać: widoczny fokus, wygodne kliknięcia, sensowne formularze i logowanie bez zbędnych przeszkód. Dla użytkownika to mniej frustracji. Dla biznesu: mniej porzuconych akcji i mniej sytuacji, w których strona przeszkadza tam, gdzie powinna pomagać.
FAQ – WCAG 2.2 vs 2.1
-
Formalnie WCAG 2.2 to nowsza rekomendacja W3C, ale strona zgodna z 2.2 spełnia też 2.1 (poza usuniętym Parsing). W umowach i wymaganiach prawnych liczy się wskazana wersja – sprawdź, do której odwołuje się Twój dokument.
-
Dziewięć: dwa na poziomie A (Consistent Help, Redundant Entry), cztery na AA (Focus Not Obscured, Dragging Movements, Target Size, Accessible Authentication – wszystkie w wariancie Minimum) i trzy na AAA.
-
Najczęściej nie. Zmiany zwykle oznaczają punktowe poprawki w konkretnych komponentach: przyklejonym nagłówku, popupach, koszyku, checkoutcie i logowaniu. Przebudowa ma sens dopiero wtedy, gdy problemy siedzą w całym szablonie.
-
W audycie pod WCAG 2.2 – nie, zostało usunięte. Jeśli wymaganie odwołuje się do WCAG 2.1, audytor może je nadal uwzględniać. Poprawny kod i tak się opłaca: te same błędy potrafią wejść pod inne kryteria.
-
Dla większości firm i sklepów internetowych poziom AA – to on pojawia się w wymaganiach projektowych, przetargowych i prawnych. AAA traktuj jako dobry kierunek na przyszłość; obowiązkowy zwykle nie jest.