WCAG 2.2, BFSG i Europejski akt o dostępności: stos zgodności WordPressa na 2026
Trzy dokumenty definiują, co witryna WordPress musi zrobić w 2026 roku, by była prawnie dostępna w Unii Europejskiej: opracowane przez W3C Web Content Accessibility Guidelines 2.2, unijny Akt o dostępności (dyrektywa 2019/882) oraz niemiecka Barrierefreiheitsstärkungsgesetz. Nie są wymienne; warstwują się. Ten artykuł to mapa wdrożenia.
Tekst jest powiązany z filarem usługi headless WordPress, gdzie opisana jest powierzchnia techniczna, oraz z listą wzorców SEO dla headless WordPress, gdzie kilka wzorców dostępności dotyczy też SEO.
TL;DR
- WCAG 2.2 to aktualna rekomendacja W3C, opublikowana 2023-10-05.
- Europejski akt o dostępności obowiązuje od 2025-06-28 w każdym państwie członkowskim.
- Niemiecka BFSG wdraża EAA do prawa federalnego w tym samym dniu.
- Wyjątki dla mikroprzedsiębiorstw istnieją, ale są węższe, niż się zakłada.
- Kary z paragrafu 37 BFSG sięgają górnych pięciocyfrowych kwot w euro.
Trzy warstwy, w kolejności
Trzy warstwy prawne i techniczne nakładają się, definiując obowiązek witryny:
Warstwa pierwsza, WCAG 2.2 (techniczna). Zestaw mierzalnych kryteriów sukcesu definiujących dostępną treść internetową. Opracowany przez Web Accessibility Initiative przy W3C. WCAG 2.2 zostało opublikowane jako rekomendacja 2023-10-05 i wprowadza dziewięć nowych kryteriów sukcesu względem WCAG 2.1, w tym wygląd zaznaczenia fokusu, gesty przeciągania i spójną pomoc.
Warstwa druga, Europejski akt o dostępności (UE). Dyrektywa 2019/882, przyjęta w 2019, obowiązująca od 2025-06-28. Definiuje, które produkty i usługi muszą być dostępne, i odsyła do europejskiej normy EN 301 549, która z kolei włącza WCAG przez odniesienie. EAA nie mówi dosłownie “stosuj WCAG 2.2”; odsyła do europejskiej normy zharmonizowanej, która obecnie obejmuje WCAG 2.1 poziom AA. Krajowe transpozycje mogą wymagać WCAG 2.2.
Warstwa trzecia, transpozycja krajowa (państwo członkowskie). Każde państwo członkowskie uchwala własną ustawę transponującą EAA. Niemiecką jest BFSG, obowiązująca od daty stosowania EAA. Inne państwa transponują pod podobnymi nazwami i z podobnymi (czasem wyższymi) wymaganiami. Witryna musi spełniać prawo transponujące w każdym rynku, na który sprzedaje, nie tylko w kraju siedziby.
Kolejność ma znaczenie. WCAG to próg techniczny. EAA to prawna koperta na poziomie UE. Ustawa krajowa to lokalny instrument egzekwowania. Audyty idą w tej kolejności: najpierw techniczny, potem prawny, lokalny na końcu.
Czego naprawdę wymaga WCAG 2.2
WCAG 2.2 ma 86 kryteriów sukcesu rozłożonych na 13 wytycznych pod 4 zasadami (Postrzegalność, Funkcjonalność, Zrozumiałość, Solidność). Trzy poziomy: A, AA, AAA. Domyślnym poziomem prawnym i kontraktowym jest AA. AAA jest aspiracyjne i nie zawsze praktyczne dla witryn z dużą ilością treści.
Dziewięć nowych kryteriów w WCAG 2.2 względem WCAG 2.1:
- Wygląd fokusu (AA, tylko poziom AA w 2.2)
- Fokus nieprzysłonięty minimum (AA)
- Fokus nieprzysłonięty rozszerzony (AAA)
- Gesty przeciągania (AA)
- Minimalny rozmiar celu (AA, 24 by 24 CSS pixels)
- Spójna pomoc (A)
- Powtórne wprowadzanie (A)
- Dostępne uwierzytelnianie minimum (AA)
- Dostępne uwierzytelnianie rozszerzone (AAA)
Dla witryny WordPress, która już celowała w WCAG 2.1 AA, praktyczna praca w 2026 to weryfikacja dziewięciu nowych kryteriów, gdzie najczęstsze luki to rozmiar celu i gesty przeciągania (małe klikalne ikony, suwaki obsługiwane wyłącznie przeciąganiem).
EAA: zakres, wyjątki, terminy
EAA obejmuje określoną listę produktów i usług wprowadzonych na rynek od 2025-06-28. Lista istotna dla większości operatorów WordPressa:
- Konsumenckie usługi bankowe.
- E-booki i dedykowane oprogramowanie do czytania.
- Usługi łączności elektronicznej.
- Usługi dostępu do mediów audiowizualnych.
- Usługi transportu pasażerskiego (interfejsy webowe i mobilne).
- Usługi e-commerce (kategoria zbiorcza dla większości sklepów WooCommerce).
Dyrektywa definiuje wyjątki dla mikroprzedsiębiorstw: mniej niż 10 pracowników ORAZ roczny obrót lub suma bilansowa poniżej 2 mln EUR. Wyjątki dotyczą usługodawców; próg dla producentów jest surowszy. Częsta błędna interpretacja brzmi “mała witryna, brak obowiązków”; faktyczna zasada brzmi “mały operator, węższy obowiązek, węższe zwolnienie”.
Okres przejściowy: umowy o świadczenie usług zawarte przed 2025-06-28 mogą trwać na warunkach sprzed EAA do 2030-06-28 najpóźniej. Samoobsługowe terminale już używane mogą działać do końca okresu użytkowania, z twardym pułapem 20 lat.
BFSG: niemiecka implementacja
Niemcy uchwaliły Barrierefreiheitsstärkungsgesetz (Ustawa o wzmocnieniu dostępności) w celu transpozycji EAA. Weszła w życie 2025-06-28.
Trzy rzeczy, które BFSG dodaje ponad bazę EAA:
Po pierwsze, egzekwowanie na poziomie federalnym. Bundesanstalt für Arbeitsschutz und Arbeitsmedizin oraz federalne organy nadzoru rynku nadzorują zgodność. Struktury państw członkowskich różnią się; w Niemczech mechanizmem jest nadzór federalny.
Po drugie, struktura kar (paragraf 37 BFSG). Kary za brak zgodności określa paragraf 37 BFSG. Konkretne typy naruszeń przyciągają kary w górnym pięciocyfrowym przedziale euro za naruszenie. Powtarzające się lub systemowe niedopełnienie obowiązków kumuluje się.
Po trzecie, wymóg deklaracji dostępności. Witryna musi opublikować deklarację dostępności linkowaną z miejsca łatwego do odnalezienia (stopka jest standardem). Deklaracja deklaruje poziom zgodności, zgłoszone wyjątki oraz mechanizm kontaktu w sprawie skarg dotyczących dostępności.
Operatorzy sprzedający do Niemiec bez niemieckiej rejestracji nadal podlegają BFSG, gdy ich produkty lub usługi są wprowadzane na rynek niemiecki. Obrona “nie jestem niemiecką firmą” nie istnieje.
Co to oznacza dla witryny WordPress
Praca wdrożeniowa rozkłada się na cztery kolumny.
Motyw i rdzeń. Wybierz motyw oznaczony accessibility-ready na WordPress.org i zweryfikuj go względem WCAG 2.2 AA. Audytuj panel administracyjny WordPressa, nie tylko front-end; BFSG obejmuje też interfejs użytkownika, którego używają pracownicy, jeśli podlegają wymogom inkluzywnego zatrudnienia. Rdzeń WordPressa jest generalnie świadomy dostępności (zespół Accessibility jest aktywny), ale wtyczki i kod własny regularnie łamią próg.
Wtyczki. Audytuj wyjście front-endowe każdej aktywnej wtyczki. Konkretne wzorce niezgodności, które widzimy audyt po audycie:
- Kreatory stron (Elementor, Divi, WPBakery): emitują
<h1>dla tekstu hero w każdej sekcji, łamiąc hierarchię nagłówków. Niespełnione WCAG 2.4.6 (Nagłówki i etykiety) oraz 1.3.1 (Informacje i relacje). Naprawa: nadpisz poziomy nagłówków na poziomie szablonu motywu lub przejdź na edytor blokowy. - Domyślne dodaj do koszyka WooCommerce na archiwach: tylko ikona z
aria-label, bez widocznego tekstu i bez widocznego wskaźnika fokusa. Niespełnione WCAG 2.4.7 (Widoczny fokus) oraz 2.5.8 (Minimalny rozmiar celu, 24×24 piksele CSS w WCAG 2.2). Naprawa: zwiększ obszar klikalny do 24×24, dodaj widoczny pierścień fokusa o kontraście 3:1, przywróć widoczny tekst tam, gdzie to możliwe. - Wtyczki slajdowe (Slick, Owl Carousel, MetaSlider, Smart Slider): brak obsługi klawiszy strzałek, brak kontrolki pauzy w slajdach z automatyczną rotacją. Niespełnione WCAG 2.2.2 (Pauza, zatrzymanie, ukrycie) oraz 2.1.1 (Klawiatura). Naprawa: zastąp statyczną siatką obrazów tam, gdzie to możliwe; jeśli slajder jest wymagany, dodaj widoczne przyciski pauzy oraz poprzedni/następny z prawidłowymi etykietami.
- Wtyczki formularzy (Contact Form 7, Gravity Forms, Ninja Forms): pomijają powiązania
<label for>, używają placeholdera jako jedynej etykiety. Niespełnione WCAG 1.3.1 oraz 3.3.2 (Etykiety lub instrukcje). Naprawa: jawny<label for="id">, komunikaty błędów przezaria-describedby, pola wymagane zaria-required="true".
Audytuj też panel, jeśli korzysta z niego personel niedeweloperski.
Treść i dyscyplina redakcyjna. Egzekwowanie WCAG na poziomie redakcyjnym wymaga stałych zasad: każdy obraz potrzebuje tekstu alt, każdy link tekstu opisowego (nie “kliknij tutaj”), każda hierarchia nagłówków jest sekwencyjna, każde wideo ma napisy, każdy PDF osadzony w stronie jest sam testowany. CMS umożliwia zgodność techniczną; zespół redakcyjny sprawia, że dzieje się ona naprawdę.
Deklaracja dostępności i mechanizm skarg. Deklaracja jest obowiązkowa w Niemczech na mocy BFSG. Mechanizm skarg (e-mail kontaktowy lub formularz) musi działać, nie być szczątkowy. Skargi dotyczące dostępności muszą być potwierdzane i rozpatrywane w rozsądnym czasie.
Dlaczego headless WordPress nie jest automatycznie dostępny
Build headless WordPress z frontem Astro lub Next.js nie dziedziczy dostępności po pochodzeniu WordPress. Framework front-endowy odpowiada za renderowane HTML, model interakcji z klawiaturą, zarządzanie fokusem i semantykę ARIA. Wybór odpowiedniego frameworka pomaga (zarówno Astro, jak i Next.js mają silne społeczności dostępności), ale praca musi zostać wykonana świadomie.
Według naszego Tech Radaru Q3 2026, Astro 5+ i Next.js 15 są oba w pierścieniu Adopt. Żaden nie jest automatycznie zgodny z WCAG 2.2. Audyt dostępności to oddzielny strumień pracy od wyboru frameworka.
Build headless kupuje jedną rzecz: kontrolę per-trasę nad renderowanym HTML, co czyni łatki dostępności wdrażalnymi i przewidywalnymi. Monolityczny build WordPressa pośredniczony przez ciężki kreator stron jest trudniejszy do naprawy, gdy kreator jest źródłem niedostępnego znacznika.
Częstotliwość audytów i narzędzia
Dwa audyty, dwie częstotliwości:
Automatyczny, każdy run CI. axe-core lub pa11y działające na reprezentatywnej próbie tras. Zatrzymuje build na każdym nowym naruszeniu. Wyłapuje około połowy problemów WCAG; nie wyłapuje połowy wymagającej oceny ludzkiej (jakość alt-textów, intencja porządku fokusu, intencja landmarków ARIA).
Manualny, rocznie plus przy istotnej zmianie. Wyszkolony tester dostępności prowadzący pełny audyt WCAG 2.2 AA z testami technologii wspomagających (czytnik ekranu, sterowanie głosem, tylko klawiatura). Wynikiem jest raport luk powiązany z konkretnymi kryteriami sukcesu.
Witryna prowadząca tylko audyt automatyczny nie jest zgodna z WCAG 2.2 AA. Witryna prowadząca tylko audyt manualny dryfuje pomiędzy rocznymi przeglądami. Oba są konieczne.
Gdzie to się wpisuje
Ten filar zakotwicza się w klastrze usługi headless WordPress jako wymiar zgodności. W kwestii wyboru frameworka zob. matryca decyzyjna Next.js vs Astro. W kwestii ryzyk migracji SEO (niektóre wzorce dostępności wpływają też na SEO, zwłaszcza hierarchia nagłówków i tekst linków) zob. listę wzorców SEO. W kwestii zgodności z NIS2 i DORA, które często pojawiają się w tych samych kryteriach zakupowych, zob. dedykowany artykuł NIS2 i DORA na WordPressie.
