Dla osób z niepełnosprawnościami poruszanie się po internecie – założenie konta w banku, rejestracja na studia, czasem nawet zrobienie zakupów – potrafi być wyzwaniem. Europejska ustawa o dostępności ma to zmienić, bo na jej mocy standardy WCAG przestają być dla wielu firm „tylko” wskazówkami, a wreszcie stają się częścią obowiązującego w UE prawa. W takiej sytuacji warto wiedzieć, co zmienia WCAG 2.2, czyli najnowsze rozszerzenie do tych wytycznych – i jak się do tego dostosować.
Czego dowiesz się z artykułu?
- Czym jest WCAG i dlaczego najnowsza wersja 2.2 jest tak istotna?
- Jakie strony i systemy muszą być zgodne z WCAG 2.2?
- Jakie są kluczowe zmiany wprowadzone przez WCAG 2.2?
- Jak wdrożyć WCAG 2.2 w praktyce?
- Jakie korzyści, oprócz zgodności, przyniesie Twojej stronie dostosowanie do WCAG 2.2?
- Podsumowanie – co warto zrobić już teraz?
- Najczęściej zadawane pytania
Czym jest WCAG i dlaczego najnowsza wersja 2.2 jest tak istotna?
WCAG, czyli Web Content Accessibility Guidelines, to zestaw wytycznych dotyczących dostępności treści cyfrowych. Stanowią one najlepszy punkt odniesienia dla projektantów, developerów i właścicieli stron, którzy chcą (lub muszą) zadbać o to, by ich serwisy były dostępne dla osób z różnymi ograniczeniami – wzrokowymi, słuchowymi, motorycznymi czy poznawczymi.
Wytyczne WCAG są opracowywane przez World Wide Web Consortium (W3C) już od dekad. Pierwsza wersja (1.0) została opublikowana w 1999 roku i był to zestaw 14 ogólnych zasad, które mają już raczej wartość historyczną. Na dziś ważniejsza jest wersja 2.0 z 2008 roku. To właśnie wtedy twórcy standardów W3C zaproponowali cztery „filary” dostępności, których akronim to POUR. Do teraz opierają się na nich wszystkie kolejne wytyczne w ramach WCAG. Chodzi konkretnie o:
- Postrzegalność
- Funkcjonalność
- Zrozumiałość
- Solidność
W 2018 roku pojawiło się rozszerzenie WCAG 2.1, które dostosowało standardy do realiów urządzeń mobilnych i w większym zakresie uwzględniało ułatwienia dla użytkowników z ograniczeniami poznawczymi. WCAG 2.2 to kolejny krok w tym kierunku. I w pewnym sensie najważniejszy, bo… dla wielu firm obowiązkowy w świetle prawa.
Właśnie. WCAG jako takie nie jest normą prawną, ale stanowi podstawę wielu aktów obowiązujących w Polsce i Unii Europejskiej. W 2016 roku Parlament Europejski uchwalił Dyrektywę o dostępności stron internetowych i aplikacji mobilnych organów sektora publicznego. Zobowiązuje ona wszystkie instytucje publiczne – od ministerstw, przez państwowe uczelnie i placówki medyczne, po urzędy najmniejszych gmin – do wdrożenia zasad dostępności cyfrowej właśnie w oparciu o aktualne wytyczne WCAG.
Jednak dla nas najważniejsza jest Europejska ustawa o dostępności (European Accessibility Act), której przepisy obowiązują w Polsce od 28 czerwca 2025. Jej pełną treść możesz znaleźć na EUR-lex, a najważniejsze punkty – na biznes.gov.pl.
Jakie strony i systemy muszą być zgodne z WCAG 2.2?
EAA rozszerza obowiązek przestrzegania standardów WCAG 2.2 przynajmniej na poziomie AA dla firm, które oferują usługi cyfrowe na terenie UE. Chodzi o:
- sklepy internetowe;
- systemy rezerwacji online i sprzedaży biletów;
- usługi bankowości internetowej i mobilnej;
- platformy dystrybuujące treści audiowizualne (na przykład platformy streamingowe) i e-booki;
- inne e-usługi – platformy e-learningowe, komunikatory do pracy zdalnej itp.
Wyjątkiem są na razie mikroprzedsiębiorstwa – te mają zostać objęte ustawą dopiero w 2030 roku.
Wytyczne WCAG 2.2 muszą też spełniać wszystkie urządzenia, na których można z tych usług skorzystać. Czyli komputery, smartfony i ich systemy operacyjne – ale też np. terminale płatnicze i biletowe.
Jakie są kluczowe zmiany wprowadzone przez WCAG 2.2?
Nowe kryteria WCAG 2.2 nie są liczne – jest ich tylko dziewięć – ale z perspektywy użytkowników, bardzo ważne:
- 2.4.11 Focus Not Obscured (Minimum);
- 2.4.12 Focus Not Obscured (Enhanced);
- 2.4.13 Focus Appearance;
- 2.5.7 Dragging Movements;
- 2.5.8 Target Size (Minimum);
- 3.2.6 Consistent Help;
- 3.3.7 Redundant Entry;
- 3.3.8 Accessible Authentication (Minimum);
- 3.3.9 Accessible Authentication (Enhanced).
Omówmy je bliżej.
-
Focus Not Obscured (Minimum)
Pierwsze nowe kryterium wymaga, by obiekt, na którym znajduje się w danym momencie fokus (przy nawigacji klawiaturą) nie był zasłonięty przez inne elementy interfejsu. Gdy użytkownik porusza się klawiszami po stronie, każdy kolejny aktywny element musi być przynajmniej częściowo widoczny; inaczej nawigacja po prostu nie będzie możliwa.
-
Focus Not Obscured (Enhanced)
Rozszerzenie poprzedniego punktu – z tą różnicą, że tutaj element z fokusem musi być w pełni widoczny, nie tylko częściowo. Żadna jego część nie może być schowana np. pod banerem, stopką, chatem lub innym elementem UI.
-
Focus Appearance
Kryterium 2.4.13 precyzuje natomiast, jak powinien wyglądać fokus, aby był zawsze dostrzegalny i jednoznaczny. W skrócie: nie wystarczy cienka, jasnoszara ramka ledwo widoczna na białym tle. Fokus musi mieć wyraźny kontrast i grubość.
Wytyczne są tu bardzo konkretne: wskaźnik fokusu powinien mieć grubość min. 2 px i zapewniać kontrast co najmniej 3:1 względem tła lub otoczenia. W przypadku prostych ramek wokół przycisków może to oznaczać, powiedzmy, granatowy obrys na jasnoszarym tle – a nie subtelny cień.
-
Dragging Movements
Kolejne kryterium wskazuje, aby wszystkie funkcje, które wymagają przeciągania elementów (na zasadzie drag & drop) miały alternatywny sposób obsługi. To przede wszystkim ułatwienie dla osób z ograniczeniami ruchowymi, które korzystają z klawiatury czy innych technologii wspomagających do poruszania się po interfejsie strony. Przeciąganie palcem lub poruszanie myszką może być dla nich zwyczajnie niewykonalne.
Co może być alternatywą? Choćby… możliwość przesuwania takich elementów strzałkami.
-
Target Size (Minimum)
Kryterium 2.5.8 wprowadza minimalne wymagania dotyczące rozmiaru elementów interaktywnych – takich jak przyciski i linki. Każdy z tych elementów powinien mieć co najmniej 24 piksele wysokości i szerokości, a więc tyle, by można było w niego bez problemu trafić palcem na ekranie dotykowym.
Wystarczy więc albo dokładnie zmierzyć każdy przycisk i link w Figmie przy projektowaniu interfejsu, albo zwiększyć obszar klikalny, manipulując paddingiem w CSSie.
-
Consistent Help
Kolejny punkt wiąże się z tym, aby wsparcie dla użytkownika było dostępne w stałym miejscu i postaci na każdej podstronie danego serwisu. Chodzi tu np. o formularze kontaktowe, numery telefonów i adresy e-mail albo o czat z konsultantem.
-
Redundant Entry
Kryterium 3.3.7 zakłada, że użytkownik nie powinien być zmuszany do ponownego wpisywania tych samych informacji, jeśli system już je zna i może je automatycznie uzupełnić. Dotyczy to np. formularzy zamówień, logowania i rejestracji czy ankiet.
Tu rozwiązań jest kilka: można skorzystać z autocomplete w HTMLu, można też wykorzystać zapisane ciasteczka sesji albo, po prostu, połączyć pola formularza (wiele sklepów łączy w ten sposób np. dane do wysyłki i do faktury podczas checkoutu).
-
Accessible Authentication (Minimum/Extended)
Ostatnie dwie spośród nowych wytycznych sugerują, by nie opierać procesów logowania i uwierzytelniania na uciążliwych dla wielu użytkowników testach CAPTCHA – przepisywaniu zniekształconych znaków z obrazka, rozpoznawaniu przedmiotów na zdjęciach czy przeciąganiu elementów.
Lepszym pomysłem, jeśli chcesz wprowadzić dodatkowy mechanizm uwierzytelniania, byłoby proste 2FA ze smartfonem użytkownika. Albo opcja autoryzacji przez OAuth – czyli na przykład przez profil na Facebooku albo w Gmail.
Jak wdrożyć WCAG 2.2 w praktyce?
Aby z powodzeniem wdrożyć standardy WCAG trzeba z jednej strony przyjrzeć się każdej z wytycznych z osobna, z drugiej – spojrzeć na witrynę i jej dostępność bardziej całościowo. To zaś wymaga:
- przejścia przez szczegółowy audyt witryny;
- wdrożenia odpowiednich narzędzi, wspierających tworzenie naprawdę dostępnych rozwiązań;
- i zbudowania zespołu, który zawsze będzie miał na uwadze standardy WCAG.
Jak przeprowadzić audyt dostępności strony?
Audyt to zawsze pierwszy i najważniejszy krok. Dobrze przeprowadzony pozwoli określić, gdzie faktycznie występują problemy z dostępnością; które elementy nie spełniają wymagań WCAG 2.2, a które potrzebują jedynie mniejszych poprawek.
W ramach audytu dostępności sprawdza się m.in.:
- strukturę nagłówków i hierarchię treści;
- widoczność i kolejność fokusu;
- opisy alternatywne obrazów;
- kontrast kolorów;
- semantykę HTML;
- responsywność i obsługę strony przy pomocy klawiatury.
Elementów jest naprawdę wiele. Audyt można przeprowadzić samodzielnie, przy pomocy łatwo dostępnych narzędzi (o nich za moment) albo zlecić go specjalistom. Najlepiej to połączyć; algorytmy nie wychwycą wszystkiego, co istotne z perspektywy użytkowników.
Jakie narzędzia wspierają wdrażanie WCAG 2.2?
Jeśli chodzi o narzędzia, możliwości jest wiele. Na przykład:
- WAVE – bardzo prosta, webowa aplikacja do analizy zgodności z WCAG w przeglądarce;
- axe DevTools – świetne rozszerzenie do Chrome’a/Firefoxa dla developerów, do testowania dostępności „w locie”;
- Lighthouse – narzędzie wbudowane już w Chrome’a, oceniające nie tylko dostępność, ale też wydajność strony i zgodność z dobrymi praktykami SEO;
- Accessibility Insights – ciekawe narzędzie od Microsoftu, które poradzi sobie z oceną i stron WWW, i aplikacji webowych.
Dla zespołów pracujących w Figmie czy Adobe XD dostępne są też pluginy do testowania dostępności i tworzenia zgodnych z WCAG rozwiązań jeszcze w fazie projektowania.
Jak zorganizować zespół odpowiedzialny za dostępność?
We wdrażanie wytycznych WCAG trzeba oczywiście zaangażować cały zespół projektowy, jednak warto mieć w nim przynajmniej jedną osobę odpowiedzialną stricte za dostępność (to tzw. accessibility lead). Takiemu specjaliście można wtedy powierzyć monitorowanie zgodności projektu z WCAG, ale też zbieranie feedbacku od użytkowników, przygotowywanie szkoleń z projektowania inkluzywnego oraz konkretnych wytycznych dla designerów i developerów.
Jakie korzyści, oprócz zgodności, przyniesie Twojej stronie dostosowanie do WCAG 2.2?
O dostępność warto dbać nie tylko ze względu na przepisy albo na zwykłą empatię.
Wdrożenie WCAG 2.2 może wpłynąć też na SEO, na skuteczność działań marketingowych i to, jak wszyscy użytkownicy (nie tylko ci, którzy tych usprawnień potrzebują najbardziej) będą postrzegać Twoją witrynę.
Czy WCAG 2.2 wpływa na SEO i pozycjonowanie strony?
Tak – i to bardzo konkretnie. Wiele kryteriów WCAG 2.2 pokrywa się z wytycznymi Google dotyczącymi użyteczności strony. Witryny z czytelną strukturą nagłówków i logiczną hierarchią treści są lepiej interpretowane przez roboty Google, nie tylko przez ludzi. A dobra optymalizacja pod urządzenia mobilne (która bardzo mocno wiąże się z dostępnością) jest jednym z najważniejszych czynników rankingowych.
Nie mówiąc o tym, ze Google od lat rozwija narzędzia (jak wspomniany Lighthouse), które oceniają dostępność jako część ogólnej jakości strony – co też może przekładać się w przyszłości na SEO.
Jak WCAG 2.2 poprawia doświadczenia wszystkich użytkowników (UX)?
Zasady dostępności to w większości po prostu dobre praktyki UX. Duże obszary klikalne, wyraźne kontrasty, logiczna struktura treści, przewidywalna nawigacja – to wszystko przecież ułatwia korzystanie z witryny każdemu, nie tylko osobom z niepełnosprawnościami.
Pomyśl o tym: formularz checkoutu, który automatycznie uzupełnia dane użytkownika (zgodnie z „Redundant Entry”), bez powtarzania ich dwa-trzy razy, spodoba się wszystkim użytkownikom, prawda? :)
Czy dostosowanie do WCAG 2.2 może zwiększyć zasięg i konwersję?
Według danych Eurostatu z 2023 roku, 27% mieszkańców UE (czyli 101 milionów osób) mierzyło się z jakąś formą trwałej lub czasowej niepełnosprawności. Nawet jeśli wielu z nich nie ma problemów z poruszaniem się po sieci – to i tak pokazuje, jak ogromną grupę użytkowników możesz stracić, jeśli nie zadbasz o dostępność dla osób z niepełnosprawnościami.
Dostosowując swój serwis do WCAG 2.2 możesz więc liczyć na to, że więcej użytkowników zakończy proces zakupu lub rejestracji… ale też, że wzrośnie liczba sesji z urządzeń mobilnych i przy wykorzystaniu technologii wspomagających.
Jakie są potencjalne konsekwencje braku zgodności z WCAG 2.2?
Z drugiej strony, jeśli do kryteriów dostępności się nie dostosujesz – ryzykujesz nie tylko utratą potencjalnych klientów, ale też wysokimi karami pieniężnymi. Jak podaje rządowy biznes.gov.pl, PFRON może nałożyć karę w wysokości do 10-krotności przeciętnego wynagrodzenia oraz do 10% obrotu firmy za poprzedni rok.
Krótko mówiąc: strona, która nie jest naprawdę dostępna dla wszystkich może kosztować Cię więcej niż myślisz – zarówno finansowo, jak i wizerunkowo.
Podsumowanie – co warto zrobić już teraz?
- Przeprowadź audyt dostępności swojej strony lub aplikacji – zidentyfikuj problemy techniczne, UXowe i contentowe związane z WCAG 2.2 (i ze starszymi kryteriami).
- Zacznij wdrażać narzędzia do monitorowania dostępności – np. axe DevTools, Lighthouse, WAVE.
- Zorganizuj zespół, wyznacz osobę odpowiedzialną za dostępność – i wpisz ten temat na stałe w proces projektowy.
- Popraw najważniejsze elementy UX zgodnie z nowymi kryteriami – szczególnie fokus, rozmiar przycisków i interakcje na urządzeniach mobilnych.
- Analizuj wpływ dostępności na SEO i wskaźniki konwersji – bo wdrożenie WCAG to nie tylko prawny obowiązek, ale też inwestycja.
Najczęściej zadawane pytania
Czy WCAG 2.2 jest obowiązkowe dla mojej strony?
Jeśli odpowiadasz za stronę urzędu lub innej instytucji publicznej – przepisy dotyczące dostępności są w mocy już od kilku lat.
Jeśli prowadzisz sklep internetowy albo oferujesz inną usługę cyfrową – wytyczne WCAG 2.2 obowiązują Cię od 28 czerwca 2025 r., na mocy Europejskiej ustawy o dostępności.
Jaki jest koszt wdrożenia WCAG 2.2?
Gdzie znajdę oficjalną dokumentację WCAG 2.2?
Jakie narzędzia pomogą mi sprawdzić zgodność z WCAG 2.2?
Czy WCAG 2.2 zastępuje WCAG 2.1?
Źródła:
https://digital-strategy.ec.europa.eu/pl/policies/web-accessibility-directive-standards-and-harmonisation
Zapisz się do darmowego newslettera
Zyskaj dodatkową wiedzę o SEO, marketingu i technologiach.
