EAA i WCAG 2.1, jak wdrożyć dostępność cyfrową

#Czym jest europejski akt o dostępności (EAA) i WCAG 2.1

Od 28 czerwca 2025 r. stosuje się przepisy wdrażające Europejski Akt o Dostępności (EAA). Nie obejmują one każdej strony w UE, tylko usługi dla konsumentów wymienione w dyrektywie, m.in. handel elektroniczny, bankowość detaliczną, łączność elektroniczną i elementy transportu pasażerskiego. Mikroprzedsiębiorstwa świadczące usługi są zwolnione. Pełną listę, wyjątki i krajowe kary omawiamy w przewodniku po dostępności WordPress i WCAG 2.2. Ten tekst dotyczy czegoś innego: jak przebiega samo wdrożenie na stronie WordPress.

Dyrektywa nie wymienia WCAG z nazwy, ale jej wymagania opierają się na tych samych czterech zasadach, dlatego audyty mierzy się kryteriami WCAG 2.1 lub 2.2 na poziomie AA. To zestaw wytycznych, które sprawiają, że treści cyfrowe są dostępne dla osób z różnymi niepełnosprawnościami, seniorów oraz wszystkich użytkowników, którzy mogą napotkać tymczasowe trudności w korzystaniu z internetu.

WCAG 2.1 (Web Content Accessibility Guidelines) to międzynarodowy standard, który określa, jak projektować i kodować strony, by były one postrzegalne, operowalne, zrozumiałe i solidne. Za nieprzestrzeganie krajowych przepisów wdrażających EAA grożą konsekwencje finansowe i prawne.

#Dlaczego dostępność cyfrowa jest tak ważna

• Według Komisji Europejskiej w UE żyje 90 milionów osób z niepełnosprawnościami, to ogromna grupa potencjalnych klientów i użytkowników Twojej strony.
• Dostępność cyfrowa to nie tylko osoby z trwałymi ograniczeniami. Skorzystają na niej także seniorzy, osoby z czasowymi urazami, osoby z zaburzeniami koncentracji czy korzystające z urządzeń mobilnych.
• Lepsza dostępność to lepsze doświadczenie użytkownika (UX) dla wszystkich, prostsza nawigacja, czytelniejsza treść, intuicyjny interfejs.
• Wyższe pozycje w Google, wiele wymagań WCAG pokrywa się z dobrymi praktykami SEO (np. responsywność, logiczna struktura, atrybuty ALT).
• Wzrost konwersji i zaangażowania, łatwiejszy proces zakupowy, czytelne formularze, lepsza obsługa klienta.
• Budowanie pozytywnego wizerunku marki jako firmy odpowiedzialnej społecznie i nowoczesnej.
• Minimalizacja ryzyka prawnego i finansowego. Kary ustala każde państwo członkowskie: w Polsce ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności (art. 73) przewiduje karę pieniężną do dziesięciokrotności przeciętnego miesięcznego wynagrodzenia, nie większą niż 10% rocznego obrotu.

#Co oznacza zgodność z WCAG 2.1 AA w praktyce

Przykłady wymagań, które należy wdrożyć na stronie internetowej:

• Nawigacja klawiaturą, cała strona musi być obsługiwana bez użycia myszy.
• Zgodność ze screen readerami, poprawne oznaczenia HTML, nagłówki, opisy obrazków (ALT), etykiety formularzy.
• Odpowiedni kontrast kolorów, tekst czytelny dla osób niedowidzących.
• Napisy i transkrypcje do materiałów wideo i audio.
• Jasna struktura treści, poprawne użycie nagłówków, logiczny układ sekcji.
• Informowanie o błędach w formularzach, czytelne komunikaty i wskazówki, jak poprawić błędy.
• Dostępność plików PDF i innych dokumentów, poprawnie sformatowane, czytelne dla czytników ekranu.
• Responsywność, strona działa poprawnie na różnych urządzeniach i rozdzielczościach.

Przykład wdrożenia: W projekcie uczelniadostepna.pl skupiono się na semantycznym HTML, poprawnym oznaczaniu nagłówków (H1-H6), dostępnych formularzach i nawigacji oraz kontrastach kolorystycznych. Dzięki temu serwis jest przyjazny zarówno dla osób z niepełnosprawnościami, jak i wszystkich użytkowników.

#Jak wygląda proces wdrożenia dostępności WCAG 2.1 z wppoland.com

1. Audyt dostępności, przeprowadzamy szczegółowy audyt Twojej strony WordPress, łącząc automatyczne testy z ręczną weryfikacją zgodności z WCAG 2.1 AA.
2. Optymalizacja motywów i wtyczek, rekomendujemy lub wdrażamy rozwiązania, które są dostępne od podstaw, albo modyfikujemy obecne komponenty, by spełniały standardy.
3. Poprawki i usprawnienia, wprowadzamy zmiany w kodzie, strukturze treści, nawigacji, formularzach czy plikach multimedialnych.
4. Szkolenia i wsparcie, uczymy Twój zespół, jak tworzyć i publikować treści dostępne cyfrowo, a także oferujemy stałe wsparcie przy kolejnych aktualizacjach.
5. Oświadczenie o dostępności i mechanizm zgłaszania uwag, pomagamy przygotować stronę z oświadczeniem i wdrożyć system zgłaszania problemów z dostępnością.

Przykład wdrożenia: Dla dużej sieci wydawniczej przebudowano szablony treści, zoptymalizowano kod i usprawniono nawigację, co poprawiło obsługę przez czytniki ekranu i umożliwiło bezproblemowe korzystanie z serwisu osobom z niepełnosprawnościami. Klient zyskał nie tylko zgodność z EAA, ale i lepsze doświadczenie dla wszystkich użytkowników.

Kolejne sekcje rozpisują te kroki na konkretne decyzje. Punktem odniesienia jest WCAG-EM 2.0, metodologia oceny zgodności z WCAG opublikowana przez W3C jako Group Note 23 lipca 2026 r. Dzieli ona ocenę na pięć kroków: określenie zakresu, rozpoznanie serwisu, wybór reprezentatywnej próby, ocenę próby i raport z wynikami.

#Jak określić zakres audytu dostępności strony WordPress

Pierwszy krok WCAG-EM ma cztery elementy: zakres serwisu, docelowy poziom zgodności, bazę wsparcia dostępności i opcjonalne wymagania dodatkowe. Na stronie WordPress każdy z nich przekłada się na konkretną decyzję.

Zakres serwisu. Trzeba wskazać, co wchodzi do oceny: sama domena główna czy także subdomena ze sklepem, panel klienta, wersje językowe, strony lądowania z kampanii. W instalacjach multisite każda witryna sieci może mieć inny motyw i inne wtyczki, więc wyłączenie którejś z nich musi być zapisane wprost, a nie domyślne.

Docelowy poziom zgodności. Dla usług objętych EAA praktycznym celem jest poziom AA. Wybór między WCAG 2.1 a 2.2 warto zapisać w zakresie, bo od niego zależy lista kryteriów, które audytor sprawdza. WordPress dla własnego kodu przyjął WCAG 2.2 AA, co opisuje nasz przewodnik po WCAG 2.2.

Baza wsparcia dostępności. WCAG-EM wymaga ustalenia, na jakich kombinacjach przeglądarek i technologii asystujących ocena się opiera. Przykładowo: NVDA z Firefoksem lub Chrome na Windows, VoiceOver z Safari na macOS i iOS, TalkBack z Chrome na Androidzie. Bez tej listy dwa audyty tej samej strony mogą dać różne wyniki i żadnego nie da się powtórzyć.

Wymagania dodatkowe. Tu trafia to, co wykracza poza samą zgodność: na przykład ocena wybranych kryteriów AAA albo test użyteczności z udziałem osób z niepełnosprawnościami.

#Jak dobrać strony do próby w audycie WCAG

Drugi krok WCAG-EM to rozpoznanie serwisu: wspólne widoki, kluczowe funkcje, rodzaje stron i technologie, na których treść polega. Metodologia definiuje wspólne widoki jako te, które dotyczą całego serwisu, zwykle linkowane bezpośrednio z punktu wejścia: strona główna, pomoc, informacje prawne, kontakt.

W WordPressie rozpoznanie dobrze jest prowadzić według hierarchii szablonów, bo jeden szablon renderuje setki adresów. Typowa lista rodzajów stron:

Trzeci krok to wybór próby. WCAG-EM łączy trzy części. Próba ustrukturyzowana obejmuje wspólne widoki, kluczowe funkcje i przykład każdego rodzaju strony. Próba losowa to według metodologii 10% liczby stron z próby ustrukturyzowanej, dobierane dodatkowo: przy 30 stronach w części ustrukturyzowanej dochodzą 3 losowe. Pełne procesy oznaczają, że jeśli strona należy do procesu, w próbie musi znaleźć się każdy jego krok, łącznie z punktem startowym, domyślną ścieżką i ważnymi odgałęzieniami.

Dla sklepu WooCommerce pełny proces zakupu to koszyk, dane klienta, wybór dostawy i płatności, potwierdzenie zamówienia oraz ścieżka z błędem walidacji. Dla formularza kontaktowego to formularz pusty, formularz z błędami i komunikat po wysłaniu. Audyt, który pomija stan błędu, pomija miejsce, w którym użytkownik czytnika ekranu najczęściej utknie.

#Co mówią wyniki próby losowej w audycie dostępności

Czwarty krok WCAG-EM to ocena wybranych stron i procesów, a potem porównanie wyników części ustrukturyzowanej i losowej. Jeśli strony losowe ujawniają problemy, których nie było w części ustrukturyzowanej, próba nie była reprezentatywna i trzeba ją poszerzyć. W WordPressie zdarza się to zwykle wtedy, gdy rozpoznanie pominęło rodzaj treści: stary wpis z edytora klasycznego, stronę zbudowaną innym page builderem albo wtyczkę, która wstawia własny widżet tylko w części podstron.

Metodologia zakłada też, że oceniający dobrze rozumie WCAG 2, technologie asystujące i sposób, w jaki osoby z niepełnosprawnościami korzystają z serwisów. Samo uruchomienie narzędzia automatycznego nie spełnia tego założenia, bo narzędzie nie oceni, czy tekst alternatywny opisuje obraz ani czy kolejność fokusu ma sens.

#Jak ustalić kolejność poprawek po audycie dostępności

Raport z audytu zwykle zawiera dziesiątki błędów. Kolejność ich usuwania w WordPressie najlepiej wyznaczać według miejsca, w którym błąd powstaje, a nie według kolejności na liście.

1. Pełne procesy, które blokują cel. Błąd uniemożliwiający złożenie zamówienia lub wysłanie formularza zamyka usługę przed całą grupą użytkowników, więc idzie pierwszy.
2. Wspólne części szablonu. Nagłówek, menu, stopka, baner zgód i wyszukiwarka występują na każdej stronie. Jedna poprawka w części szablonu lub w pliku motywu usuwa błąd z całego serwisu.
3. Komponenty używane wielokrotnie. Własne bloki, wzorce, shortcode’y i widżety wtyczek. Tu decyzja brzmi: poprawić, zastąpić dostępną alternatywą czy usunąć.
4. Treść redakcyjna. Teksty alternatywne, nagłówki w treści wpisów, opisy linków, pliki PDF. Tę część poprawia redakcja, więc razem z poprawkami trzeba przekazać jej zasady i przykłady.

Taki podział ma też skutek budżetowy: poprawki z punktów 2 i 3 wykonuje się raz, a działają na tysiącach adresów, podczas gdy punkt 4 skaluje się z liczbą treści.

#Jak testować stronę z użytkownikami technologii asystujących

Audyt według WCAG mówi, czy strona spełnia kryteria. Nie mówi, czy da się z niej wygodnie korzystać. W3C WAI w materiale „Involving Users in Evaluating Web Accessibility” zaleca włączanie osób z niepełnosprawnościami w ocenę na różnych etapach prac, a nie tylko na końcu, i zaznacza, że krótkie nieformalne sprawdzenia w trakcie projektu dają więcej niż jeden formalny test.

Z tego materiału wynikają konkretne zasady organizacji testu:

• Najpierw przegląd ekspercki. Oczywiste bariery usuwa się przed zaproszeniem użytkowników, żeby ich czas nie szedł na problemy wykryte już przez audyt.
• Kilka osób, różne potrzeby. WAI zaleca udział kilku osób z niepełnosprawnościami, a także starszych użytkowników, jeśli należą do odbiorców serwisu. Poziom doświadczenia uczestników warto dobrać do odbiorców: w publicznej usłudze ważni są także początkujący użytkownicy czytników ekranu.
• Głośne myślenie. Uczestnik mówi, co robi i czego się spodziewa, a prowadzący notuje miejsca, w których bariera powoduje błąd.
• Ostrożne wnioski. WAI ostrzega: „Nie zakładaj, że uwagi jednej osoby z niepełnosprawnością dotyczą wszystkich osób z niepełnosprawnościami” (W3C WAI, tłumaczenie własne). Problem może wynikać z treści strony, z przeglądarki, z technologii asystującej albo z tego, jak dobrze uczestnik ją zna.

Test z użytkownikami nie zastępuje audytu. WAI pisze wprost, że sam w sobie nie pozwala stwierdzić, czy strona jest dostępna, więc łączy się go z oceną według WCAG. W projekcie WordPress dobrym momentem na taki test jest etap, w którym poprawki szablonów są już wdrożone na stagingu, a treść jest prawdziwa, nie testowa.

#Co powinna zawierać deklaracja dostępności strony WordPress

W3C WAI w poradniku o deklaracjach dostępności wskazuje minimum: zobowiązanie do zapewnienia dostępności, zastosowany standard (np. WCAG 2.2) i dane kontaktowe na wypadek problemów. Zaleca też dodanie znanych ograniczeń, działań podjętych przez organizację, wymagań technicznych, środowisk, w których treść przetestowano, oraz odwołań do obowiązujących przepisów.

Bezpłatny generator deklaracji W3C prowadzi przez te pola. Najwięcej pracy wymaga sekcja ograniczeń, bo dla każdego znanego problemu generator pyta o pięć rzeczy: której części treści dotyczy, na czym polega, dlaczego występuje, co organizacja z tym robi i co użytkownik może zrobić w międzyczasie. Wypełnienie jej uczciwie wymaga wyników audytu, więc deklarację pisze się po ocenie, a nie przed nią. Generator ma też pole na status zgodności (pełna, częściowa, brak zgodności, nieoceniona) i na sposób oceny: samoocena albo ocena zewnętrzna.

Dla usług objętych EAA dochodzi obowiązek z samej dyrektywy. Art. 13 ust. 2 dyrektywy 2019/882 wymaga, by usługodawca przygotował informacje zgodnie z załącznikiem V i wyjaśnił, jak usługa spełnia wymagania dostępności. Informacje muszą być publicznie dostępne w formie pisemnej i ustnej, także w sposób dostępny dla osób z niepełnosprawnościami, i przechowywane przez cały czas świadczenia usługi. Załącznik V wskazuje, że informacje umieszcza się w ogólnych warunkach świadczenia usługi lub równoważnym dokumencie i w miarę potrzeby obejmują:

• ogólny opis usługi w dostępnych formatach,
• opisy i wyjaśnienia potrzebne do zrozumienia działania usługi,
• opis, w jaki sposób usługa spełnia odpowiednie wymagania dostępności z załącznika I.

Dla sklepu na WordPressie oznacza to zwykle dwa dokumenty: stronę z deklaracją dostępności dla użytkowników oraz fragment regulaminu sklepu z informacjami wymaganymi przez załącznik V. Obie warto linkować ze stopki, żeby były osiągalne z każdej strony.

#Jak utrzymać dostępność strony po wdrożeniu poprawek

Dostępność strony WordPress zmienia się przy każdej aktualizacji motywu, wtyczki i przy każdym nowym wpisie. Dyrektywa uwzględnia to w art. 13 ust. 3: usługodawca musi mieć procedury, dzięki którym świadczenie usługi pozostaje zgodne z wymaganiami, i musi brać pod uwagę zmiany w samej usłudze, w wymaganiach oraz w normach, na które się powołuje. Art. 13 ust. 4 dodaje, że w razie niezgodności usługodawca podejmuje działania naprawcze i niezwłocznie informuje właściwe organy krajowe.

W praktyce procedura na stronie WordPress składa się z kilku stałych elementów:

• Powtórna ocena próby po zmianach. Próba z audytu (wspólne widoki, rodzaje stron, pełne procesy) staje się listą kontrolną po aktualizacji motywu, wtyczek formularzy lub sklepu i po zmianie części szablonu.
• Zapis wyników. WCAG-EM w piątym kroku zaleca dokumentowanie wyników każdego kroku, a opcjonalnie także raport w formacie do odczytu maszynowego. Darmowe narzędzie WCAG-EM Report Tool prowadzi przez kroki metodologii i generuje raport, który można porównać z kolejnym audytem.
• Zasady dla redakcji. Większość nowych błędów po wdrożeniu pochodzi z treści: brakujący tekst alternatywny, pominięty poziom nagłówka, PDF zeskanowany jako obraz.
• Obsługa zgłoszeń. Kanał kontaktu z deklaracji musi mieć właściciela i czas odpowiedzi, bo generator W3C pyta właśnie o typowy czas reakcji.

Jeśli firma powołuje się na nieproporcjonalne obciążenie z art. 14, ocenę musi udokumentować i przechowywać przez pięć lat. To kolejny powód, by wyniki audytów i decyzje o poprawkach trzymać w jednym miejscu.

#Kto wdroży dostępność EAA na stronie WordPress

• Doświadczenie WordPress i dostępność, specjalizujemy się w dostępności cyfrowej w środowisku WordPress, także dla sklepów WooCommerce, portali i serwisów firmowych.
• Kompleksowe podejście, nie ograniczamy się do checklisty, ale dbamy o całościowe doświadczenie użytkownika i długofalową zgodność z przepisami.
• Indywidualne podejście, dostosowujemy zakres prac do Twoich potrzeb i budżetu.
• Wzrost widoczności i konwersji, poprawa dostępności to także inwestycja w SEO i UX.
• Bezpieczeństwo prawne, pomagamy uniknąć ryzyka kar i sporów prawnych.
• Budowanie marki, pokazujesz, że Twoja firma jest nowoczesna, otwarta i odpowiedzialna społecznie.

Wyślij krótki opis projektu poprzez formularz lub napisz maila, opisz swoje potrzeby lub wyzwania związane z dostępnością. Razem sprawimy, że Twoja strona będzie gotowa na nowe przepisy i przyjazna dla wszystkich użytkowników.

Dostępność to nie jednorazowy audyt, tylko decyzje w szablonach, formularzach i redakcji treści. Wdrożenie tej części, od kontrastów po obsługę klawiatury, prowadzimy razem z pracą nad motywem.