Deklaracja dostępności dla WordPress: szablon + mapowanie na EN 301 549

#Deklaracja dostępności dla WordPress: szablon + mapowanie na EN 301 549

Deklaracja dostępności to odrębny dokument prawny, różny od audytu WCAG. Można przejść każdy automatyczny skan na stronie WordPress i wciąż nie być zgodnym z Polskim Aktem o Dostępności ani EAA, bo obie regulacje wymagają samej deklaracji: opublikowanego statusu zgodności, normy, względem której testowano, listy znanych ograniczeń i działającego mechanizmu zgłoszeń, z którego może skorzystać odwiedzający, żeby złożyć skargę. Ten artykuł jest elementem wspierającym zestawu zgodności WCAG 2.2, BFSG i EAA, skupionym konkretnie na dokumencie deklaracji i tym, jak jego sekcje mapują się na EN 301 549 - europejską normę, którą faktycznie cytują zespoły zamówień.

#Co musisz opublikować, w skrócie

• Dedykowaną stronę linkowaną z footera, nie paragraf w polityce prywatności.
• Status zgodności: pełna, częściowa z nazwanymi wyjątkami, albo niezgodna.
• Normę, względem której testowano: w praktyce WCAG 2.2 AA, zreferencjonowaną wobec EN 301 549 dla odbiorców zamówieniowych.
• Listę znanych ograniczeń z, jeśli możliwe, datą naprawy.
• Kontakt do zgłoszeń, który faktycznie trafia do monitorowanej skrzynki, plus ścieżkę egzekucji lub eskalacji.
• Datę przygotowania i rytm przeglądu, bo “przetestowaliśmy to raz w 2023” to nie aktualna deklaracja.

Nic z tego nie zastępuje audytu technicznego. To dokumentuje jego wynik. Jeśli nie przeprowadziłeś jeszcze audytu WCAG 2.2 AA, deklaracja albo zawyży zgodność, albo będzie wyglądać jak placeholder - a obydwa te wyniki przyciągają więcej uwagi niż brak deklaracji w ogóle.

#Kiedy deklaracja dostępności jest obowiązkowa w UE

Trzy nakładające się podstawy prawne stawiają deklarację dostępności na liście obowiązków operatora WordPress, i nie wszystkie dotyczą tej samej grupy odbiorców.

Dyrektywa (UE) 2016/2102, dyrektywa o dostępności stron internetowych, wymaga od podmiotów sektora publicznego opublikowania i regularnego aktualizowania deklaracji dostępności dla każdej strony i aplikacji mobilnej, jaką prowadzą. W Polsce transponuje ją ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych - obowiązki dla stron internetowych od 23 września 2020 r., dla aplikacji mobilnych od 23 czerwca 2021 r. Ta ustawa jest wcześniejsza od EAA i obejmuje sektor publiczny niezależnie od tego, co dalej opisano: strona miejska WordPress, blog uniwersytetu publicznego, portal prasowy agencji rządowej są objęte przepisami niezależnie od poniższego.

Europejski akt o dostępności (dyrektywa 2019/882), obowiązujący od 2025-06-28, rozciąga porównywalne obowiązki na operatorów prywatnych świadczących konkretne kategorie produktów i usług: e-commerce, usługi bankowe, transport, e-booki i inne wymienione w załączniku I dyrektywy. W Polsce transponuje ją Polski Akt o Dostępności (ustawa z 26 kwietnia 2024 r.), z nadzorem PFRON i regulatorów sektorowych oraz karami do 10% rocznego obrotu podmiotu gospodarczego.

Krajowe transpozycje wypełniają szczegóły operacyjne. Poza wspomnianymi ustawami, ustawa z 19 lipca 2019 r. o zapewnianiu dostępności osobom ze szczególnymi potrzebami nakłada na podmioty publiczne dodatkowe obowiązki dostępności architektonicznej, informacyjno-komunikacyjnej i cyfrowej. W praktyce oznacza to, że opublikowana deklaracja jest najprostszym sposobem wykazania, że proces zgłaszania i rozpatrywania skarg istnieje, zanim jakakolwiek skarga faktycznie wpłynie.

Wyłączenia, które warto znać przed napisaniem czegokolwiek: mikroprzedsiębiorstwa (poniżej 10 pracowników, roczny obrót lub suma bilansowa poniżej 2 mln EUR) są wyłączone z kilku obowiązków usługowych EAA, choć to wyłączenie jest węższe dla producentów produktów. Podmioty publiczne nie mają żadnego wyłączenia wielkościowego na podstawie dyrektywy 2016/2102. Roszczenia o nieproporcjonalne obciążenie istnieją w obu reżimach, ale wymagają dokumentowanej oceny, nie przypisu mówiącego “nie dotyczy”.

Artykuł-pillar o WCAG 2.2, BFSG i europejskim akcie o dostępności obejmuje pełny zestaw zgodności, wraz z rytmem audytu, który produkuje status zgodności dokumentowany w tej deklaracji.

#EN 301 549 vs WCAG 2.2 AA: o co faktycznie pyta zamówienie publiczne

WCAG 2.2 AA to standard, względem którego testuje Twój zespół developerski. EN 301 549 to standard, który cytuje urzędnik zamówień, dokument przetargowy albo audyt sektora publicznego, bo to zharmonizowana europejska norma dla dostępności ICT szeroko, nie tylko treści internetowej.

Wersja obecnie obowiązująca to EN 301 549 V3.2.1, opublikowana w marcu 2021 roku i zacytowana w Dzienniku Urzędowym UE na podstawie dyrektywy 2016/2102 poprzez decyzję wykonawczą Komisji (UE) 2021/1339. Jej rozdział poświęcony web, rozdział 9, zawiera przez odwołanie kryteria sukcesu WCAG 2.1 na poziomie A i AA. Rewizja obejmująca WCAG 2.2 jest w opracowaniu w ramach wspólnej grupy technicznej ETSI/CEN/CENELEC, z publikacją oczekiwaną w 2026 roku na podstawie mandatu standaryzacyjnego Komisji Europejskiej M/587, ale to jeszcze nie jest wersja zacytowana w Dzienniku Urzędowym.

To tworzy praktyczną rozbieżność, którą dokumenty zamówieniowe rzadko rozwiązują jasno: prawnie referencyjnym poziomem bazowym jest WCAG 2.1 AA, podczas gdy aktualny cel najlepszej praktyki, i to, do czego faktycznie buduje większość agencji (w tym nasza), to WCAG 2.2 AA. Ponieważ 2.2 jest ścisłym supersetem 2.1 z dziewięcioma dodatkowymi kryteriami sukcesu, testowanie i dokumentowanie względem 2.2 AA satysfakcjonuje też bazowy poziom 2.1 AA, do którego obecnie odwołuje się EN 301 549. Nie ma ryzyka niezgodności wersji przy budowaniu do nowszego standardu; ryzyko działa w drugą stronę - jeśli budujesz tylko do 2.1, a rewizja EN 301 549 opublikuje się w środku kontraktu.

Poza rozdziałem poświęconym web, EN 301 549 ma jedenaście innych rozdziałów. Trzy, które mają znaczenie dla typowego wdrożenia WordPress poza samą treścią internetową:

• Rozdział 10, dokumenty niewebowe. Pliki PDF, arkusze kalkulacyjne i prezentacje publikowane przez stronę (cenniki, raporty roczne, dokumenty przetargowe) potrzebują właściwego tagowania, porządku odczytu i dostępnych tabel, niezależnie od tego, jak dostępna jest sama otaczająca strona.
• Rozdział 11, oprogramowanie. Istotny, gdy sam panel administracyjny WordPress jest oceniany jako produkt, na przykład zespół redakcyjny sektora publicznego używający edytora blokowego jako narzędzia autorskiego, albo dedykowana wtyczka udostępniająca interfejs formularza użytkownikom końcowym.
• Rozdział 12, dokumentacja i usługi wsparcia. Strony pomocy, przewodniki wdrożeniowe i kanały wsparcia linkowane ze strony mają spełniać ten sam próg dostępności, co główna treść, a samo wsparcie musi być dostępne przez więcej niż jeden kanał.

#Sekcje szablonu z gotowymi do skopiowania nagłówkami

Poniższy porządek sekcji to struktura, jaka pojawia się w większości europejskich deklaracji dostępności zbudowanych na frameworku EN 301 549 / EAA / krajowych transpozycji. Jest poglądowa: wypełnij ją faktycznymi wynikami audytu, nie tekstem placeholderowym, i zleć jej przegląd osobie odpowiedzialnej za zgodność w Twojej organizacji, zanim ją opublikujesz.

# Deklaracja dostępności dla [nazwa strony]

## Status zgodności
[Nazwa strony] jest [w pełni zgodna / częściowo zgodna / niezgodna]
z WCAG 2.2 na poziomie AA, oceniana względem wymagań referencjonowanych w
EN 301 549. [Wybierz jedno:]
- Pełna zgodność znaczy, że treść w pełni spełnia normę bez wyjątków.
- Częściowa zgodność znaczy, że pewne części treści nie spełniają w pełni
  normy, wymienione poniżej pod "znane ograniczenia".

## Obowiązująca norma
Ta deklaracja jest oparta na samoocenie / ocenie przeprowadzonej przez
[nazwa lub rola oceniającego] w dniu [data], względem:
- Web Content Accessibility Guidelines (WCAG) 2.2, poziom AA
- EN 301 549, [wersja], rozdział 9 (Web)
[Wymień rozdziały 10, 11, 12 tutaj tylko jeśli dokumenty niewebowe,
oprogramowanie lub usługi wsparcia były również oceniane.]

## Znane ograniczenia
Poniższa treść nie jest jeszcze w pełni dostępna:
- [Konkretne ograniczenie, np. "osadzony widget rezerwacji na /kontakt/
  nie może być obsługiwany wyłącznie klawiaturą"], dotyczące [którego
  kryterium sukcesu], docelowy termin naprawy: [data lub "w przeglądzie"].
- [Powtórz dla każdego znanego problemu. Nie podsumowuj kilku problemów
  jedną niejasną linią; wypisz je pojedynczo.]

## Przygotowanie tej deklaracji
Ta deklaracja została przygotowana [data] i ostatnio przeglądana [data].
Została przygotowana na podstawie [samooceny / audytu strony trzeciej],
obejmując [zakres: np. "publiczne strony pod example.com, z wyłączeniem
osadzonej treści strony trzeciej"].

## Kontakt i zgłaszanie uwag
Jeśli natrafisz na barierę dostępności na tej stronie, skontaktuj się z nami:
- E-mail: [monitorowany adres]
- [Opcjonalnie: telefon, URL formularza kontaktowego]
Staramy się odpowiedzieć w ciągu [X] dni roboczych.

## Procedura egzekucyjna
Jeśli nie jesteś zadowolony z naszej odpowiedzi, możesz eskalować do:
[Krajowy organ nadzoru lub rozstrzygania sporów, z adresem URL, właściwy dla
jurysdykcji, w której operator ma siedzibę lub prowadzi działalność.]

## Specyfikacja techniczna
Ta strona opiera się na następujących technologiach dla zgodności:
HTML, CSS, JavaScript, WAI-ARIA.

Dwie sekcje wymagają więcej uwagi, niż może dać generyczny szablon. Znane ograniczenia to sekcja, którą większość deklaracji robi źle, albo całkowicie ją pomijając (deklarując pełną zgodność, gdy automatyczny skan pokazuje błędy), albo pisząc ją tak niejasno, że nie dostarcza dowodu faktycznej oceny. Procedura egzekucyjna potrzebuje realnego adresu, nie “skontaktuj się z krajowym organem”, bo sens tej sekcji polega na tym, że niezadowolony odwiedzający może działać na jej podstawie bez dodatkowego researchu.

#Tabela mapowania: wymaganie EN 301 549 na działanie na WordPressie

Rozdział 4 EN 301 549 określa oświadczenia o funkcjonalnej wydajności (użycie bez wzroku, użycie z ograniczoną sprawnością manualną i podobne), używane, gdy konkretne kryterium sukcesu nie mapuje się czysto na nowatorski interfejs. Dla standardowego front-endu WordPress większość pracy mapowania odbywa się w rozdziałach 9, 10, 11 i 12.

Ta tabela jest szkieletem raportu zgodności w stylu VPAT, jeśli klient sektora publicznego o taki poprosi; każdy wiersz staje się pozycją ze statusem zaliczone, częściowo lub niezaliczone, po przeprowadzeniu audytu.

#Gdzie opublikować deklarację na WordPressie: footer, dedykowana strona, schema

Link w footerze, na każdej stronie. Najczęściej sprawdzanym sygnałem w przeglądzie egzekucyjnym jest, czy deklaracja jest dostępna z każdego miejsca na stronie bez wyszukiwania. Link w footerze, obok polityki prywatności i regulaminu, załatwia to bez dodatkowej pracy developerskiej. Jeśli footer Twojego szablonu jest zarządzany przez obszar widgetów albo globalny szablon części footera, dodaj link tam raz, nie na każdej podstronie.

Dedykowana strona, własny URL. Nie wtapiaj deklaracji w politykę prywatności czy regulamin. Dedykuj jej samodzielny adres URL, na przykład /deklaracja-dostepnosci/, ustawiony przez zwykłą stronę WordPress (albo wpis MDX, w tym stacku), żeby mogła być przeglądana i wersjonowana niezależnie od innej treści prawnej.

Dane strukturalne, opcjonalne, ale przydatne w audytach zamówieniowych. Blok JSON-LD typu WebPage na stronie deklaracji, z dateModified pokrywającym się z datą ostatniego przeglądu, daje robotowi lub narzędziu checklisty zamówieniowej maszynowo odczytywalne potwierdzenie, że deklaracja istnieje i kiedy była ostatnio dotknięta. To nie zastępuje treści czytelnej dla człowieka; to niewielki dodatek, który usuwa niejasność, gdy ktoś przeprowadza automatyczny skan zgodności na Twojej domenie.

Rytm przeglądu, dokumentowany w samej deklaracji. Stwierdź, jak często deklaracja jest przeglądana (rocznie, albo po każdym większym redesignie) i trzymaj się tego rytmu. Deklaracja datowana trzy lata temu, z polem “ostatnio przeglądano”, którego nikt nie dotykał, jest jedną z pierwszych rzeczy, które audytor albo dział prawny konkurenta zgłosi.

#Proces zgłoszeń i skarg

Mechanizm zgłoszeń to część Polskiego Aktu o Dostępności i EAA, której nie zaspokoi sam audyt front-endu, bo to wymaganie procesowe, nie kodowe.

1. Przyjęcie zgłoszenia. Monitorowany adres e-mail albo formularz kontaktowy, odrębny od ogólnego supportu, żeby zgłoszenia dotyczące dostępności nie gubiły się w generycznej kolejce. Skieruj je do osoby odpowiedzialnej za zgodność, nie tylko do webmastera.
2. Potwierdzenie. Potwierdź otrzymanie w zadeklarowanym oknie czasowym (zwykle kilka dni roboczych). Potwierdzenie powinno przywołać zgłoszoną barierę, żeby odwiedzający wiedział, że została poprawnie zrozumiana.
3. Zbadanie. Odtwórz barierę, sprawdź ją względem właściwego kryterium sukcesu WCAG i zapisz wynik, niezależnie czy potwierdza znane ograniczenie już wymienione w deklaracji, czy odkrywa nowe.
4. Odpowiedź i plan naprawy. Powiedz odwiedzającemu, co znaleziono i, jeśli to prawdziwa bariera, kiedy zostanie naprawiona albo czemu nie może być (nieproporcjonalne obciążenie, treść strony trzeciej poza Twoją kontrolą i podobne, dokumentowane, nie tylko stwierdzone).
5. Ścieżka eskalacji. Jeśli odwiedzający nie jest zadowolony, skieruj go do właściwego organu nadzoru lub rozstrzygania sporów. W Polsce nadzór nad rynkiem w zakresie EAA sprawuje PFRON wraz z regulatorami sektorowymi, a nad sektorem publicznym minister właściwy do spraw informatyzacji; inne państwa członkowskie wyznaczają własne organy nadzoru rynku na podstawie EAA.
6. Rejestrowanie wewnętrzne. Prowadź rejestr każdej otrzymanej skargi i jej rozwiązania. Ten rejestr jest tym, co zmienia “mamy proces” z deklaracji w oświadczeniu w dowód podczas audytu albo postępowania egzekucyjnego.

Żaden z tych kroków nie wymaga nowego oprogramowania. Współdzielona skrzynka, prosty arkusz kalkulacyjny albo tag w systemie ticketowym i nazwany właściciel pokrywają wymaganie dla większości operatorów WordPress. Liczy się, że proces jest dokumentowany w deklaracji i faktycznie stosowany, gdy nadejdzie skarga, nie wymyślony retroaktywnie po fakcie.

#Jak to wpisuje się w audyt zgodności UE

Deklaracja dostępności jest jednym z kilku efektów w ramach szerszego audytu zgodności UE dla WordPress, który obejmuje też mapowanie NIS2/DORA dostawców i obowiązki oznaczania treści z AI Act, gdzie ma to znaczenie. Wewnątrz części dotyczącej dostępności tego audytu deklaracja jest tym elementem, który zmienia techniczny raport WCAG 2.2 AA w coś, na czym może działać osoba odpowiedzialna za zgodność, recenzent zamówień publicznych albo organ egzekucyjny, bez czytania surowego wyniku skanu.

Sekwencja, która produkuje obronną deklarację, w porządku, w jakim ją realizujemy:

1. Techniczny audyt WCAG 2.2 AA, automatyczny plus manualny, obejmujący reprezentatywną próbkę stron opisaną w zestawie zgodności WCAG/BFSG/EAA.
2. Lista braków przypisana do konkretnych kryteriów sukcesu, nie generyczne podsumowanie “znaleziono jakieś problemy”, bo sekcja znanych ograniczeń w deklaracji potrzebuje konkretnych, nazwanych pozycji.
3. Wersja robocza deklaracji wykorzystująca strukturę sekcji powyżej, wypełnioną faktycznym wynikiem audytu, nie placeholderowym roszczeniem zgodności.
4. Konfiguracja procesu zgłoszeń, podłączona do realnej skrzynki i nazwanego właściciela, testowana fałszywym zgłoszeniem przed publikacją.
5. Publikacja, linkowana z footera, na własnym URL, z datą przeglądu ustawioną na następny cykl.

Jeśli realizujesz to jako część szerszego projektu gotowości EAA/WCAG, przegląd europejskiego aktu o dostępności i WCAG jest punktem wejścia dla pytań o zakres (kto jest wyłączony, co znaczy “wprowadzony na rynek” dla umowy usługowej), a ten artykuł obejmuje konkretnie dokument deklaracji, gdy podstawowy audyt jest już zrobiony.

#Lektura z klastra

• Pillar: WCAG 2.2, BFSG i europejski akt o dostępności: zestaw zgodności 2026 dla WordPress
• Europejski akt o dostępności i WCAG 2.1: jak wdrożyć dostępność cyfrową
• Audyt zgodności UE dla WordPress: dostępność, NIS2/DORA, AI Act