Co EAA i WCAG 2.1 znaczą dla stron na WordPressie
Od 28 czerwca 2025 roku europejski akt o dostępności (EAA, dyrektywa 2019/882) obowiązuje produkty i usługi wprowadzane po raz pierwszy na rynek UE. Dla strony internetowej czy aplikacji webowej oznacza to spełnienie wymagań WCAG 2.1 AA - standardu W3C, który definiuje, jak treść cyfrowa powinna być postrzegalna, funkcjonalna, zrozumiała i solidna. EAA nie wymienia samodzielnie kryteriów sukcesu WCAG; odwołuje się do europejskiej normy zharmonizowanej EN 301 549, która obecnie zawiera WCAG 2.1 na poziomie AA. WCAG 2.2 jest już bieżącą rekomendacją W3C, ale prawny próg, jaki musi spełnić większość polskich stron WordPress dzisiaj, to wciąż 2.1 AA - i dlatego warto zrozumieć ten standard na jego własnych warunkach, zanim przejdziemy dalej.
Ten artykuł jest punktem wejścia. Opisuje, kto realnie jest objęty przepisami, które wyłączenia się utrzymują a które nie, jak WCAG 2.1 AA wygląda na prawdziwym projekcie WordPress i dokąd pójść dalej. Zapoznaj się z usługami rozwoju WordPress w WPPoland, jeśli potrzebujesz zespołu, który buduje dostępne projekty, a nie tylko je audytuje.
Dwie liczby wyjaśniają, czemu to nie jest niszowy temat. Około 15% populacji UE żyje z jakąś formą niepełnosprawności, a znacznie większa część korzysta z dostępności sytuacyjnie: osoby starsze, ktoś z tymczasowym urazem, każdy używający małego ekranu w ostrym słońcu. Praca nad dostępnością pokrywa się też mocno z fundamentami SEO - semantyczna struktura, opisowy tekst alternatywny i czysty markup pomagają wyszukiwarkom oraz silnikom odpowiedzi AI tak samo, jak pomagają technologiom wspomagającym. Obydwa te wątki przewijają się przez resztę tego przewodnika.
Kluczowe terminy i kto jest objęty przepisami
Data wejścia w życie EAA jest ustalona, ale “objęty przepisami” nie jest prostą odpowiedzią tak/nie - zależy od kategorii produktu lub usługi, daty zawarcia umowy i typu obsługiwanego klienta. Tabela poniżej to praktyczne podsumowanie; prawne niuanse w przypadkach granicznych należą do prawnika, nie do wpisu na blogu.
| Termin | Co obejmuje | Niuans B2C vs B2B |
|---|---|---|
| 2025-06-28 | Wymogi dostępności EAA obowiązują produkty i usługi wprowadzane po raz pierwszy na rynek UE: e-commerce, bankowość konsumencka, e-booki, komunikacja elektroniczna, usługi dostępu do audiowizualnych mediów oraz interfejsy transportu pasażerskiego (załącznik I) | Kategoria e-commerce jest zdefiniowana wokół umowy z konsumentem (art. 3(30)); inne kategorie, takie jak bankowość i komunikacja elektroniczna, nie mają tego samego ograniczenia do konsumentów |
| 2025-06-28 do 2030-06-28 | Okres przejściowy: umowy o świadczenie usług zawarte przed 2025-06-28 mogą być kontynuowane na oryginalnych warunkach maksymalnie do tej daty | Obowiązuje niezależnie od typu klienta - decyduje data umowy, nie to, czy nabywcą jest konsument czy firma |
| Data wdrożenia + do 20 lat | Terminale samoobsługowe (bankomaty, biletomaty, kioski check-in) zainstalowane przed terminem mogą działać do końca okresu użytkowania, maksymalnie 20 lat | To głównie punkt sprzętowy dla fizycznych terminali; rzadko istotny dla czystego projektu WordPress, jeśli nie obsługuje kiosku w sklepie |
| Na bieżąco, w każdym roku finansowym | Ponowna ocena mikroprzedsiębiorstwa: jeśli liczba pracowników lub obrót usługodawcy przekroczy próg z art. 4(5), wyłączenie przestaje obowiązywać od tego roku finansowego | Dotyczy tylko usługodawców - obowiązki po stronie produktu nigdy nie były objęte tym wyłączeniem, niezależnie od rozmiaru firmy |
| Krajowe daty transpozycji | Większość państw członkowskich transponowała przepisy blisko daty unijnej - Polski Akt o Dostępności (ustawa z 26 kwietnia 2024 r.) wchodzi w życie tego samego dnia, 2025-06-28 - ale lokalne organy nadzoru, struktury kar i przepisy o deklaracji dostępności różnią się między krajami | Obowiązuje dla rynku, na który wprowadzany jest produkt lub usługa, nie dla kraju siedziby operatora |
Praktyczny odczyt: jeśli strona WordPress sprzedaje konsumentom w UE, obsługuje checkout WooCommerce albo świadczy usługę z jednej z kategorii załącznika I, termin już minął, a obowiązek jest aktywny teraz, nie czymś do zaplanowania “kiedyś”.
Wyłączenia i zakres dla mikroprzedsiębiorstw
To sekcja, która jest najczęściej źle odczytywana. “Jesteśmy mali, więc jesteśmy wyłączeni” to częste założenie i częściej jest błędne niż prawdziwe. Dyrektywa 2019/882 definiuje kilka wąskich wyjątków, nie ogólną przepustkę dla małych firm.
| Wyłączenie | Kto może z niego skorzystać | Warunki | Czego NIE obejmuje |
|---|---|---|---|
| Wyłączenie mikroprzedsiębiorstwa (art. 4(5)) | Przedsiębiorstwa poniżej 10 pracowników ORAZ roczny obrót lub suma bilansowa poniżej 2 mln EUR | Oba warunki muszą być spełnione jednocześnie; wyłączenie przepada od roku finansowego, w którym przekroczony zostaje którykolwiek z progów | Wyłącza jedynie usługi. Obowiązki producenta, importera czy dystrybutora produktów obowiązują niezależnie od wielkości przedsiębiorstwa |
| Nieproporcjonalne obciążenie (art. 14, załącznik VI) | Każdy podmiot gospodarczy, niezależnie od wielkości | Wymaga dokumentowanej oceny wobec kryteriów z załącznika VI, ważącej koszt względem korzyści dla użytkowników; musi być odnawiana co najmniej co pięć lat i udostępniana organom na żądanie | To nie ogólne zwolnienie - operator musi wciąż stosować każde wymaganie, które nie zostało wykazane jako nieproporcjonalne |
| Fundamentalna zmiana (art. 14) | Każdy podmiot gospodarczy, niezależnie od wielkości | Dotyczy tylko sytuacji, gdy spełnienie wymogu fundamentalnie zmieniłoby charakter produktu lub usługi | Rzadko dotyczy typowych funkcji WordPress (nawigacja, formularze, treść); bardziej istotne dla specjalizowanego sprzętu lub dedykowanego oprogramowania |
| Wcześniejsze umowy o usługi (art. 32) | Każdy rozmiar | Umowy o świadczenie usług zawarte przed 2025-06-28 mogą działać na oryginalnych warunkach maksymalnie do 2030-06-28 | Nie rozciąga się na nowe umowy podpisane po terminie, nawet z istniejącym klientem |
| Działające terminale samoobsługowe (art. 32) | Każdy rozmiar, zwykle operatorzy sprzętu | Terminale zainstalowane przed terminem mogą działać do końca okresu użytkowania, maksymalnie 20 lat | Nie dotyczy nowych terminali kupionych lub wdrożonych po terminie |
| Nagrania opublikowane przed 28 czerwca 2025 (art. 2(4)) | Każdy rozmiar | Media czasowe (audio/wideo) opublikowane przed terminem są retroaktywnie wyłączone z zakresu | Nowe nagrania opublikowane po terminie muszą spełniać wymagania od pierwszego dnia |
Realna decyzja o zakresie, rozpisana krok po kroku. Weźmy sklep WooCommerce z czterema pracownikami i obrotem znacznie poniżej 2 mln EUR, sprzedający bezpośrednio konsumentom. Na podstawie art. 4(5) jest to mikroprzedsiębiorstwo usługowe, więc obowiązki dostępności dla samej usługi zakupowej i checkoutu go nie obejmują. To wyłączenie przestaje działać w momencie, gdy sklep zatrudni piątego do dziesiątego pracownika i przekroczy dziesięć osób, albo obrót przekroczy 2 mln EUR - dyrektywa nie przewiduje żadnego okresu ochronnego, więc bezpieczniejszym założeniem planistycznym jest utrata wyłączenia od roku finansowego, w którym próg zostaje przekroczony, nie od jakiejś późniejszej daty odnowienia.
Teraz zmieniamy jeden fakt: ten sam czteroosobowy sklep działa jako dostawca hurtowy na podstawie negocjowanej umowy dla większej firmy, bez żadnego bezpośredniego checkoutu konsumenckiego. Dzieją się tu dwie odrębne rzeczy, nie jedna. Po pierwsze, kategoria e-commerce w EAA jest zdefiniowana wokół zawarcia umowy z konsumentem (art. 3(30), motyw 42) - kanał sprzedaży wyłącznie B2B może z tego powodu znajdować się poza tą kategorią, niezależnie od wyłączenia dla mikroprzedsiębiorstw. Po drugie, i to jest część, która najczęściej myli ludzi: bycie poza obowiązkiem e-commerce z EAA nie znaczy, że sklep jest wolny od wymagań dostępności w tej relacji. Jeśli większy nabywca sam podlega EAA, NIS2 lub klauzulom dostępności w zamówieniach publicznych, jego własny program zgodności może kontraktowo wymagać od dostawcy narzędzi zgodnych z WCAG, niezależnie od tego, czy dostawca jest mikroprzedsiębiorstwem, czy znajduje się poza kategorią e-commerce w prawie unijnym. Wyłączenie EAA chroni przed egzekwowaniem samej EAA; nie robi nic z klauzulą dostępności w umowie z klientem.
Praktycznie w Polsce oznacza to konkretną datę i konkretny organ: ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności produktów i usług (Polski Akt o Dostępności) weszła w życie 28 czerwca 2025 r., a nadzór nad rynkiem sprawuje Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych (PFRON) wraz z regulatorami sektorowymi. Ustawa przewiduje kary do 10% rocznego obrotu podmiotu gospodarczego za nieprzestrzeganie przepisów - znacznie wyżej niż stawki znane z niektórych innych transpozycji krajowych, co samo w sobie jest argumentem, żeby nie zakładać wyłączenia bez sprawdzenia liczb.
To jest ramowanie faktograficzne, nie porada prawna - jeśli konkretna klasyfikacja jest sporna albo matematyka przychodów jest bliska progu, potwierdź to z prawnikiem, zanim oprzesz się na wyłączeniu w publicznym oświadczeniu albo odpowiedzi przetargowej.
WCAG 2.1 AA w praktyce na WordPressie
WCAG 2.1 AA to nie lista do jednorazowego odhaczenia; to zestaw testowalnych kryteriów sukcesu, które na danej stronie, formularzu czy komponencie albo są spełnione, albo nie. Cztery obszary odpowiadają za większość realnej pracy na stronie WordPress.
Obsługa klawiaturą. Każdy interaktywny element - menu, rozwijana lista, modal, karuzela, przycisk dodaj do koszyka - musi być dostępny i obsługiwalny wyłącznie za pomocą Tab, Shift+Tab, Enter i klawiszy strzałek, z widocznym wskaźnikiem fokusu na każdym kroku. Tu page buildery i wtyczki do slajderów zawodzą najczęściej: slideshow, który przewija się tylko po najechaniu myszką, albo mega-menu, które otwiera się na hover, ale nigdy na fokus, cicho blokuje każdego, kto nie może użyć myszki. Poprawka rzadko wymaga przepisania kodu; zwykle wystarczy dodanie brakujących obsług zdarzeń klawiatury i widocznego stylu :focus z wystarczającym kontrastem.
Kontrast kolorów. WCAG 2.1 AA wymaga stosunku kontrastu co najmniej 4.5:1 dla normalnego tekstu i 3:1 dla dużego tekstu względem tła. Paleta marki zaprojektowana pod logo, nie pod treść, jest najczęstszym błędem: jasnoszary tekst na bieli, który elegancko wygląda w makiecie, ale nie przechodzi testu kontrastu dla osoby ze słabym wzrokiem. Błędy kontrastu są tanie w naprawie po wykryciu i kosztowne, jeśli zostaną, bo dotykają każdej strony dziedziczącej ustawienia typografii szablonu.
Formularze. Każde pole wymaga programowo powiązanej etykiety (<label for="id">, nie tylko tekstu placeholdera, który zanika po ustawieniu fokusu), każde pole wymagane musi zgłaszać, że jest wymagane, a każdy błąd walidacji musi być opisany tekstem w pobliżu pola, nie tylko czerwoną ramką. Formularze checkoutu i kontaktowe są tu obszarami najwyższego ryzyka, bo formularz, którego nie da się wypełnić przy użyciu czytnika ekranu, to utracona transakcja, a nie tylko brak zgodności.
Media. Wideo potrzebuje podpisów, audio potrzebuje transkrypcji, a każdy istotny obraz potrzebuje tekstu alternatywnego opisującego jego funkcję lub treść, nie powtarzającego nazwy pliku. Obrazy dekoracyjne (tła, przerywniki) powinny mieć puste alt="", żeby technologia wspomagająca pominęła je, zamiast ogłaszać zbędny szum. To jeden z obszarów, gdzie dyscyplina redakcyjna liczy się tak samo jak kod: programista może zbudować dostępny komponent obrazu, ale tylko wyszkolony redaktor treści utrzymuje zgodność każdego nowego uploadu.
Częste wzorce błędów na WordPressie, które widzimy w audytach
Kilka wzorców powtarza się w niemal każdym audycie WordPress, jaki przeprowadzamy, niezależnie od szablonu czy branży. Hierarchia nagłówków psuje się jako pierwsza: page buildery często emitują <h1> albo <h2> dla tekstu hero każdej sekcji, niezależnie od jej faktycznego miejsca w strukturze dokumentu, więc strona może mieć pięć tagów h1 i żadnego logicznego zagnieżdżenia h2/h3 pod nimi. Użytkownicy czytników ekranu nawigują po strukturze nagłówków; złamana struktura sprawia, że stronę dużo trudniej przeskanować, niż zauważy to widzący użytkownik.
Kontrolki wyłącznie z ikoną są dalej na liście - przycisk dodaj do koszyka albo szukaj wyrenderowany jako goła ikona bez widocznego tekstu i, często, bez aria-label, zostawia technologię wspomagającą bez niczego do zapowiedzenia. Automatycznie rotujące karuzele są bliskim trzecim wzorcem: brak kontrolki pauzy, brak nawigacji klawiaturą i treść zmieniająca się co cztery sekundy, niezależnie od tego, czy czytelnik skończył czytać obecny slajd.
Czwarty wzorzec jest cichszy, ale równie istotny: bannery zgody na cookies i modale newsletterowe, które łapią fokus klawiatury w pętlę. Użytkownik wchodzi tabem do modala i nigdy nie może wrócić tabem do treści strony, bo programista nigdy nie podłączył pułapki fokusu, która zwalnia się na Escape albo przy akcji zamknięcia. Jest niewidoczny w teście QA prowadzonym myszką i natychmiast oczywisty przy pierwszym teście wyłącznie klawiaturą.
Żaden z tych wzorców nie jest egzotycznym błędem. To bezpośredni, powtarzalny efekt popularnych wtyczek i szablonów używanych tak, jak większość stron je używa - i dlatego audyt znajduje tę samą garstkę wzorców w niezwiązanych ze sobą projektach. Artykuł o zestawie zgodności 2026 przechodzi przez listę błędów wtyczka po wtyczce - page buildery, szablony WooCommerce, wtyczki do slajderów, wtyczki formularzy - wraz z konkretnym kryterium WCAG, jakie każda z nich łamie, i konkretną poprawką dla każdego przypadku.
Ścieżka wdrożenia: audyt, poprawki, deklaracja, monitoring
Zmiana “musimy być zgodni” w dostarczony, obronny wynik przebiega tą samą czterostopniową ścieżką w każdym projekcie, który realizujemy.
Audyt. Zacznij od zakresowego przeglądu WCAG 2.1 AA na realnych ścieżkach klienta strony - strona główna, nawigacja, wyszukiwanie, formularze i każdy krytyczny dla przychodów krok checkoutu - nie tylko od automatycznego skanu strony głównej. Zautomatyzowane narzędzia (axe-core, Lighthouse, WAVE) wychwytują z grubsza połowę realnych problemów; resztę musi znaleźć człowiek z klawiaturą i czytnikiem ekranu.
Poprawki. Napraw w porządku, który chroni najpierw ścieżki o najwyższej wartości: pułapki klawiaturowe i nieopisane kontrolki checkoutu przed kosmetycznymi poprawkami kontrastu na linku w footerze. Jedna poprawka w komponencie współdzielonym - styl fokusu szablonu, markup etykiet wtyczki formularzy - często rozwiązuje dziesiątki powtarzających się wyników jednocześnie, dlatego poprawki powinny celować najpierw we współdzielone szablony, a potem w pojedyncze strony.
Opublikuj deklarację dostępności. Deklaracja stwierdzająca poziom zgodności, znane ograniczenia i działający kanał kontaktu dla zgłoszeń dotyczących dostępności jest obowiązkowa na podstawie kilku krajowych ustaw transponujących i dobrą praktyką wszędzie indziej. Daje też zespołom zamówień coś konkretnego do akt.
Monitoring. Dostępność rozmywa się w momencie, gdy nowa aktualizacja wtyczki, nowy szablon page buildera albo nowy redaktor treści dołącza bez szkolenia. Automatyczna kontrola w CI wychwytuje regresje przy każdym wdrożeniu; roczny ręczny retest wychwytuje to, czego automatyzacja nie widzi.
Po pełny zestaw prawny - dziewięć nowych kryteriów sukcesu WCAG 2.2, relację EAA-BFSG i szczegóły poprawek na poziomie wtyczek - przeczytaj zestaw zgodności 2026 dla WordPress. Jeśli chcesz zakresowego, pisemnego audytu, a nie samoobsługowej checklisty, audyt zgodności UE dla WordPress obejmuje dostępność wraz z ekspozycją na NIS2/DORA i AI Act w jednym zleceniu, z indywidualną wyceną na podstawie faktycznego zakresu strony.
Czemu dostępność pokrywa się z SEO i czytelnością dla AI
Większość technicznej pracy stojącej za WCAG 2.1 AA jest też, niezależnie, dobrym SEO i dobrą higieną dla silników odpowiedzi AI, dlatego budżety na dostępność łatwiej uzasadnić, niż mogłoby się wydawać na pierwszy rzut oka. Czysta, sekwencyjna hierarchia nagłówków to dokładnie to, czego roboty wyszukiwarek i podsumowujące modele językowe używają, żeby zrozumieć, o czym faktycznie jest strona; ta sama poprawka, która pomaga użytkownikowi czytnika ekranu nawigować po stronie, pomaga też systemowi AI wyciągnąć właściwą sekcję odpowiadając na zapytanie o niej. Opisowy tekst alternatywny działa podwójnie - jako sygnał dla wyszukiwania obrazów i jako zapasowy opis, który każdy system AI czytający markup strony może wykorzystać, kiedy sam obraz nie jest przetwarzany.
Semantyczny HTML - prawdziwe elementy <button> i <nav> zamiast stylizowanej zupy z <div>, właściwe powiązania <label> w formularzach - produkuje markup, który jest jednocześnie dostępny i łatwiejszy do wiarygodnego parsowania przez systemy automatyczne, niezależnie od tego, czy tym systemem jest czytnik ekranu, robot wyszukiwarki czy pipeline retrievalowy stojący za asystentem AI. Nic z tego nie jest przypadkiem: dostępność i czytelność dla maszyn zbiegają się w tym samym leżącym pod nimi wymaganiu, którym jest treść nosząca własną strukturę i znaczenie w markupie, a nie polegająca wyłącznie na stylizacji wizualnej. Traktowanie projektu poprawek WCAG wyłącznie jako kosztu prawnego przeocza fakt, że duża część pracy zwraca się w organicznej widoczności.
Co dalej
Gotowy przejść od oceny do działania? Skontaktuj się z nami, żeby ustalić zakres przeglądu dostępności dla Twojej strony WordPress, albo zacznij od zasobu, który odpowiada temu, gdzie akurat jesteś:
- Potrzebujesz głębszej mapy prawnej i technicznej, w tym WCAG 2.2 i BFSG? Przeczytaj artykuł o zestawie zgodności 2026.
- Potrzebujesz zakresowego, pisemnego audytu z backlogiem poprawek, który można przekazać programiście? Zobacz audyt zgodności UE dla WordPress.
- Potrzebujesz zespołu, który zbuduje poprawkę, a nie tylko ją zdiagnozuje? Sprawdź nasze usługi rozwoju WordPress.
