WCAG 2.2: priorytety naprawcze — co poprawić w pierwszej kolejności

Implementacja WCAG 2.2 w istniejącym sklepie internetowym lub stronie firmowej rzadko wygląda jak kompleksowy projekt „od zera do zgodności”. W rzeczywistości audyt dostępności ujawnia kilkanaście do kilkudziesięciu błędów różnej wagi — i pojawia się pytanie, od czego zacząć. Nie każdy błąd WCAG jest równie ważny: niektóre powodują, że serwis jest całkowicie nieużywalny dla określonych grup użytkowników, inne są kosmetycznymi niezgodnościami, które warto poprawić, ale nie blokują korzystania z funkcji. Ten artykuł to przewodnik po priorytetyzacji napraw WCAG 2.2 — dla firm, które mają wyniki audytu i chcą wiedzieć, co robić pierwsze.

Jeśli nie miałeś jeszcze audytu WCAG lub dopiero zaczynasz temat dostępności cyfrowej w kontekście Polskiego Aktu o Dostępności — zapoznaj się najpierw z artykułem o WCAG w e-commerce i wymaganiami dotyczącymi informacji o dostępności. Tutaj zakładamy, że masz już wyniki audytu i szukasz mapy priorytetów naprawczych.

Jak klasyfikować błędy WCAG według priorytetu

Błędy WCAG klasyfikujemy według dwóch osi: waga techniczna (A, AA, AAA w standardzie WCAG) oraz wpływ na użytkownika. Poziom A to wymagania bazowe — ich niespełnienie może całkowicie wykluczać użytkowników z korzystania z serwisu. Poziom AA — wymagany przez PAD i dyrektywy unijne — dotyczy szerokiej dostępności dla osób z niepełnosprawnościami. Poziom AAA to zalecenia najwyższej dostępności, nie wymagane przez prawo. Ale sama waga techniczna to za mało do priorytetyzacji — błąd poziomu A w stopce, którą nikt nie używa, jest mniej pilny niż błąd AA w formularzu zamówienia, przez który osoba niewidoma nie może kupić produktu.

Właściwa priorytetyzacja uwzględnia: (1) wagę techniczną (A przed AA), (2) częstość występowania na krytycznych ścieżkach użytkownika (checkout, wyszukiwanie, rejestracja — przed stopką i „o nas”), (3) liczbę użytkowników, których dotyczy (błąd kontrastu kolorów dotyczy zarówno słabowidzących, jak i osób korzystających z urządzeń na słońcu), (4) koszt naprawy (niektóre błędy naprawia się w 5 minut, inne wymagają przeprojektowania komponentu). Te cztery czynniki razem dają matrycę priorytetów — nie tylko listę błędów, ale plan ich naprawy.

Kategoria 1: naprawy natychmiastowe (blokujące dostępność)

Najwyższy priorytet mają błędy, które skutecznie wykluczają określone grupy użytkowników z korzystania z podstawowych funkcji serwisu. W e-commerce to przede wszystkim: brak tekstu alternatywnego na zdjęciach produktów (screen readery nie mogą opisać produktu), brak etykiet dla pól formularzy (użytkownik z czytnikiem ekranu nie wie, co wpisać), brak możliwości nawigacji klawiaturą przez checkout (użytkownik nieużywający myszy nie może złożyć zamówienia), przyciski i linki bez czytelnych etykiet (np. ikona koszyka bez tekstu „Dodaj do koszyka”).

Kryterium 1.1.1 (Pozalekcyjna zawartość — tekst alt) to jeden z najczęstszych błędów w polskich sklepach. WebAIM Million — coroczne badanie dostępności miliona najpopularniejszych stron — konsekwentnie wskazuje brak tekstu alt jako błąd nr 1, występujący na ponad 58% stron. W e-commerce, gdzie strona produktowa może mieć 5–10 zdjęć, brak alt oznacza, że osoba niewidoma słyszy tylko „grafika grafika grafika” zamiast opisu produktu. Naprawa: uzupełnienie atrybutu alt na wszystkich obrazach produktowych — koszt: niski (jeśli WooCommerce uzupełnia alt automatycznie z nazwy produktu lub pola alt w bibliotece mediów), ale wymaga przejrzenia istniejącego katalogu.

Nawigacja klawiaturą (kryterium 2.1.1) to drugi krytyczny element. Każda funkcja serwisu powinna być dostępna wyłącznie klawiaturą: Tab do nawigacji, Enter/Spacja do aktywacji, Escape do zamknięcia dialogów. Dropdown menu, modalne okna (quick view, gallery), filtry w shopie — wszystkie muszą być obsługiwalne klawiaturą. W WooCommerce standardowy checkout jest relatywnie dostępny, ale niestandardowe wtyczki (custom quick view, ajax cart, newsletter popup) często łamią nawigację klawiaturową. Naprawa wymaga testów klawiaturą i korekty w JS/CSS komponentów.

Kategoria 2: kontrast kolorów i czytelność

Kryterium 1.4.3 (Kontrast kolorów, poziom AA) wymaga minimalnego współczynnika kontrastu 4,5:1 dla tekstu normalnego i 3:1 dla dużego tekstu. To jedno z wymagań, które wygląda prosto, ale w praktyce dotyka wielu projektów, gdzie kolory dobierane były „na oko” lub z myślą tylko o wyglądzie na dużym ekranie w optymalnych warunkach. Narzędzia takie jak Contrast Checker (WebAIM), Color Contrast Analyzer lub Chrome DevTools Accessibility tree pozwalają sprawdzić kontrast bez konieczności audytu ręcznego każdego elementu.

Typowe problemy z kontrastem w sklepach: szare placeholder’y w polach formularzy (zwykle kontrast 2,5:1 — zbyt niski), tekst ceny „po obniżce” w jasnoróżowym lub jasnopomarańczowym kolorze na białym tle, etykiety kategorii w jasnych odcieniach na kolorowym tle, linki w treści artykułu niebieskie na szarym tle. Naprawa: zmiana wartości kolorów w CSS — koszt technicznie niski, ale wymaga akceptacji projektanta (zmiany wizualne mogą wpłynąć na brand identity). Warto to zrobić etapami: najpierw krytyczne ścieżki (checkout, karty produktów), potem treści edytorskie.

Kategoria 3: struktura nagłówków i semantyczny HTML

Prawidłowa hierarchia nagłówków (kryterium 1.3.1, Informacje i relacje) to fundament nawigacji dla użytkowników screen readerów. W WooCommerce strona kategorii produktów powinna mieć H1 z nazwą kategorii, H2 lub H3 dla nazw produktów, bez pomijania poziomów i bez użycia nagłówków wyłącznie do celów wizualnych. Najczęstszy błąd: strona główna ma kilka H1 (logo, baner, sekcja wyróżnionych produktów), a sekcja z H2 po H4 bez H3. Narzędzie Headings Map (rozszerzenie przeglądarki) wizualizuje strukturę nagłówków jednym kliknięciem.

Semantyczny HTML to szersza kwestia: czy buttony są tagiem button (nie div z onclick), czy linki to tag a (nie span z JS), czy listy produktów używają ul/li, czy formularze mają poprawne label i fieldset. Te błędy są często artefaktem starszego kodu lub wtyczek, które generowały HTML bez myślenia o dostępności. Naprawa wymaga przeglądu kodu szablonów i wtyczek — niekiedy szybkiej korekty w CSS/JS, a niekiedy refaktoru komponentów.

Kategoria 4: obsługa błędów w formularzach

Kryterium 3.3.1 (Identyfikacja błędu) i 3.3.2 (Etykiety lub instrukcje) wymagają, żeby formularz jasno informował użytkownika o błędach — z tekstem opisującym problem, nie tylko czerwonym obramowaniem. „To pole jest wymagane” w czerwonym border to za mało dla osoby niewidzącej. Poprawna implementacja: komunikat tekstowy („Pole Email jest wymagane”), powiązany z polem przez aria-describedby, umieszczony w miejscu widocznym po złożeniu formularza, z focus zarządzanym tak, żeby screen reader od razu przechodził do pierwszego błędu.

W WooCommerce checkout ma relatywnie dobrą obsługę błędów, ale niestandardowe formularze (newsletter, konfigurator, formularz kontaktowy z wtyczki) często jej nie mają. To jest kategoria błędów, które stosunkowo łatwo naprawić w JS/PHP — i które mają duży wpływ na konwersję nie tylko dla użytkowników niepełnosprawnych, ale dla wszystkich. Badania Baymard Institute pokazują, że nieprecyzyjne komunikaty o błędach w checkout to jeden z top-5 powodów porzucenia koszyka.

Jak zaplanować naprawy: matryca priorytetów

Praktyczny plan napraw WCAG powinien być podzielony na 3 etapy. Etap 1 (pierwsze 30 dni): naprawy blokujące dostępność na krytycznych ścieżkach — tekst alt na produktach, etykiety formularzy, nawigacja klawiaturą w checkout. Etap 2 (30–60 dni): kontrast kolorów, struktura nagłówków, obsługa błędów w formularzach, dostępność mobilna. Etap 3 (60–90 dni): dostępność treści multimedialnych (napisy, audiodeskrypcje), dokumenty PDF, zaawansowane komponenty interaktywne (slider, datepicker, autocomplete).

Po każdym etapie warto przeprowadzić retesting — automatyczny (Axe DevTools, WAVE) i ręczny (nawigacja klawiaturą, test screen readerem). Automatyczne narzędzia wykrywają 30–40% błędów WCAG; reszta wymaga testu manualnego lub z udziałem użytkowników z niepełnosprawnościami. Dla firm objętych PAD, które muszą wykazać zgodność — raport z testów jest dokumentem, który warto mieć i przechowywać. W przypadku skargi do organu kontrolnego (PFRON, UDSCiK) będzie to pierwsze, o co zostanie zapytana firma.