WCAG 2.2, BFSG i Europejski akt o dostępności: stos zgodności WordPressa na 2026

#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.

Ten tekst uzupełnia opis usługi headless WordPress, bo dostępność zależy też od sposobu zbudowania frontu. Łączy się również z porównaniem headless vs monolit, gdzie część decyzji architektonicznych wpływa na SEO i dostępność.

#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:

1. Wygląd fokusu (AA, tylko poziom AA w 2.2)
2. Fokus nieprzysłonięty minimum (AA)
3. Fokus nieprzysłonięty rozszerzony (AAA)
4. Gesty przeciągania (AA)
5. Minimalny rozmiar celu (AA, 24 by 24 CSS pixels)
6. Spójna pomoc (A)
7. Powtórne wprowadzanie (A)
8. Dostępne uwierzytelnianie minimum (AA)
9. 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 przez aria-describedby, pola wymagane z aria-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 Q4 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.

#Najpierw triage: czy i gdzie obowiązek dotyczy organizacji

Nie zaczynaj od instalowania wtyczki z ikoną dostępności. Zacznij od krótkiej kwalifikacji zakresu, którą później można przekazać doradcy prawnemu do potwierdzenia. Zapisz, kto świadczy usługę, na jakich rynkach jest oferowana, czy odbiorcą jest konsument, jakie transakcje można zakończyć online oraz które podmioty w grupie odpowiadają za sklep, płatności i obsługę. Sam język strony, domena albo liczba podstron nie rozstrzygają zastosowania przepisów.

Dla WordPressa zakres techniczny powinien obejmować nie tylko stronę główną. Trzeba zinwentaryzować szablony produktu i kategorii, wyszukiwarkę, koszyk, checkout, konto klienta, uwierzytelnianie, formularze, pliki do pobrania, banery zgód oraz zewnętrzne elementy osadzone. Jeśli zakup przechodzi do operatora płatności albo systemu rezerwacji, granicę odpowiedzialności należy udokumentować, a przejście pomiędzy systemami przetestować. Użytkownik doświadcza jednej ścieżki, nawet gdy organizacja utrzymuje ją u kilku dostawców.

Triage powinien kończyć się tabelą decyzji, nie ogólnym stwierdzeniem „EAA nas dotyczy” albo „jesteśmy zwolnieni”. Dla każdej usługi zapisz rynek, typ odbiorcy, właściciela biznesowego, systemy składające się na ścieżkę, podstawę przyjętego zakresu i osobę zatwierdzającą interpretację. Jeżeli rozważane jest wyłączenie, zachowaj przesłanki i datę oceny. To zapis roboczy, a nie porada prawna ani gwarancja, że organ przyjmie tę samą interpretację.

#Pakiet dowodowy, który zostaje po audycie

Lista błędów z narzędzia automatycznego nie jest jeszcze dowodem należytego procesu. Użyteczny pakiet dowodowy łączy zakres, wyniki i decyzje w sposób, który pozwala powtórzyć test. Powinien zawierać:

• spis badanych adresów i stanów interfejsu wraz z datą, wersją wdrożenia, przeglądarką i rozmiarem widoku;
• macierz kryteriów WCAG 2.2 AA z wynikiem, dowodem, wpływem na użytkownika i właścicielem poprawki;
• zapis testów klawiaturą, powiększeniem i uzgodnionymi kombinacjami czytnika ekranu oraz przeglądarki;
• zrzuty ekranu, krótkie nagrania lub fragmenty DOM pokazujące problem i wynik ponownego testu;
• rejestr wyjątków, ograniczeń stron trzecich i zaakceptowanych ryzyk wraz z osobą decyzyjną i terminem przeglądu;
• wersję oświadczenia o dostępności oraz procedurę przyjmowania, klasyfikowania i zamykania zgłoszeń.

Każde ustalenie musi być odtwarzalne. Zamiast „menu nie działa z czytnikiem” raport powinien podać trasę, krok wejścia, użyte urządzenie, oczekiwane zachowanie, zachowanie faktyczne i kryterium sukcesu. Dzięki temu programista może poprawić defekt, tester potwierdzić rezultat, a właściciel produktu zrozumieć ryzyko bez oglądania całego audytu.

Dowody należy przechowywać razem z wydaniem, którego dotyczą. Po zmianie motywu, checkoutu lub systemu formularzy stare wyniki nie opisują nowej wersji. Nie warto też deklarować „pełnej zgodności” na podstawie próbki, jeśli część istotnych tras nie została sprawdzona. Precyzyjne określenie zakresu jest bardziej wiarygodne niż szeroka obietnica.

#Testy akceptacyjne i definicja zakończenia

Przed poprawkami uzgodnij warunki odbioru. Dobra definicja zakończenia mówi, które szablony i scenariusze muszą przejść test, jak traktowane są problemy zewnętrznych dostawców oraz kto może zaakceptować ryzyko rezydualne. Dla sklepu WooCommerce scenariusze powinny obejmować co najmniej znalezienie produktu, wybór wariantu, zmianę ilości, obsługę błędów, płatność, potwierdzenie zamówienia i dostęp do konta bez myszy.

Automatyczny skan uruchom po poprawce i na reprezentatywnym zestawie tras, ale nie ustawiaj jako kryterium jedynie wyniku punktowego Lighthouse. Odbiór manualny powinien sprawdzić kolejność fokusu, widoczność fokusu, komunikaty dynamiczne, obsługę błędów, powiększenie i reflow, znaczenie etykiet oraz czy zadanie da się ukończyć. Krytyczne ścieżki testuje się od początku do końca, ponieważ poprawny pojedynczy komponent może zawieść w kontekście modala, sticky headera albo walidacji formularza.

Ustalenie można zamknąć dopiero po ponownym teście na wersji przeznaczonej do wydania. Sam commit, deklaracja autora wtyczki lub zniknięcie błędu ze skanera nie wystarcza. W raporcie końcowym warto rozdzielić: naprawione i potwierdzone, pozostające z planem, zależne od dostawcy oraz poza uzgodnionym zakresem.

#Kolejność napraw, która ogranicza koszt regresji

Najpierw napraw problemy blokujące wykonanie zadania: brak obsługi klawiatury, pułapki fokusu, niedostępne uwierzytelnianie, niewidoczne lub nieogłaszane błędy oraz elementy, których nie można aktywować. Następnie popraw wzorce wspólne w motywie i komponentach, na przykład nawigację, modal, formularz, kartę produktu i komunikaty statusu. Jedna poprawka systemowa może usunąć ten sam defekt na setkach adresów.

Dopiero później przechodź do błędów pojedynczych treści i dokumentów. Równolegle zatrzymaj źródło nowych problemów: dodaj testy komponentów, zasady dla redakcji i kontrolę przed publikacją. Instalowanie warstwy nakładkowej nie zastępuje naprawy kodu, treści ani procesu. Może zmienić prezentację, lecz nie usuwa podstawowej przyczyny i może wprowadzić kolejne konflikty z technologiami wspomagającymi.

Wydawaj poprawki małymi partiami. Zmiana semantyki, JavaScriptu i CSS w jednym dużym wdrożeniu utrudnia ustalenie, co wywołało regresję. Po każdej partii wykonaj szybki test scenariuszy krytycznych, a przed zamknięciem programu pełny retest uzgodnionej próbki.

#Dostępność jako stały element zarządzania

Zgodność nie jest jednorazowym projektem. Właściciel produktu powinien odpowiadać za backlog i terminy, zespół techniczny za komponenty oraz testy regresji, redakcja za obrazy, nagłówki, linki i multimedia, a obsługa klienta za dostępny kanał zgłoszeń. Dostawca motywu lub wtyczki może pomóc, ale nie przejmuje odpowiedzialności organizacji za decyzję o publikacji.

Raz w miesiącu warto przejrzeć nowe szablony, zgłoszenia użytkowników i otwarte wyjątki. Przy każdym większym wydaniu trzeba ponowić testy ścieżek krytycznych. Pełniejszy przegląd wykonuje się według ustalonej kadencji oraz po zmianie checkoutu, motywu, logowania czy kluczowego dostawcy. Oświadczenie o dostępności aktualizuje się wtedy, gdy zmienia się stan serwisu, a nie tylko w rocznicę jego publikacji.

Jeśli potrzebujesz zakresu możliwego do wyceny, wyślij pisemny brief zawierający adres serwisu, rynki, model sprzedaży, aktywny motyw i najważniejsze wtyczki, krytyczne ścieżki, znane bariery oraz planowaną datę wydania. Na tej podstawie audyt dostępności WordPress WCAG może zostać podzielony na kwalifikację zakresu, badanie, plan napraw i retest. Wynikiem jest udokumentowany stan oraz lista działań, nie obietnica prawnego bezpieczeństwa ani automatyczna gwarancja zgodności.

#Powiązane tematy

Ten artykuł należy do działu o zgodności WordPressa z wymaganiami UE i uzupełnia opis usługi headless WordPress. Przy wyborze technologii zob. matrycę decyzyjną Next.js vs Astro. Przy ryzykach migracji SEO i architektury informacji zob. porównanie headless vs monolit. W sprawie NIS2 i DORA, które często pojawiają się w tych samych kryteriach zakupowych, zob. artykuł NIS2 i DORA na WordPressie.