European Accessibility Act 2025 — co musi zmienić Twój sklep WooCommerce
EAA obowiązuje od 28 czerwca 2025. Co to znaczy dla polskiego sklepu WooCommerce? Jakie kary grożą, co trzeba zmienić technicznie i od kogo egzekwuje UOKiK.

28 czerwca 2025 zaczął obowiązywać European Accessibility Act (dyrektywa 2019/882). W Polsce wdrożono ją ustawą z 26 kwietnia 2024. Znaczna część właścicieli sklepów internetowych do dziś nie wie, że ich dotyczy. Tymczasem UOKiK i PFRON już dostały instrumenty kontrolne, a kary za niezgodność sięgają do 10× przeciętnego miesięcznego wynagrodzenia, czyli na koniec 2025 około 80 000 zł.
Poniżej — co konkretnie zmieniło się technicznie, kogo dotyczy, i co trzeba poprawić w typowym sklepie WooCommerce. Bez prawnego żargonu.
Kogo EAA faktycznie dotyczy
Obowiązek obejmuje „przedsiębiorców oferujących konsumentom produkty lub usługi w UE”, wyłączenia — mikroprzedsiębiorcy (< 10 pracowników i ≤ 2 mln € obrotu). W praktyce: jeśli prowadzisz sklep internetowy który nie jest jednoosobową działalnością i nie sprzedajesz tylko B2B — EAA cię dotyczy.
Konkretnie obejmuje:
- Sklepy internetowe e-commerce (WooCommerce, Shopify, PrestaShop — bez różnicy),
- Banki i usługi finansowe z obsługą online,
- Platformy rezerwacji transportu i noclegów,
- E-booki i audiobooki,
- Publiczne aplikacje mobilne.
Blog firmowy bez funkcji sprzedażowej — teoretycznie nie. Ale jeśli strona ma formularz kontaktowy / lead capture / call-to-action — de facto jest „usługą” i inspektor może zakwalifikować.
Standard techniczny = EN 301 549 = WCAG 2.1 poziom AA
Ustawa mówi ogólnikowo o dostępności. Konkret jest w normie EN 301 549, która odwołuje się do WCAG 2.1 na poziomie AA. Nie AAA — AA. To jest średni rygor.
Oznacza to 50 wymogów technicznych. Najczęściej naruszane w sklepach WooCommerce:
1. Kontrast tekstu i tła
WCAG 1.4.3 — minimum 4.5:1 dla tekstu zwykłego, 3:1 dla dużego tekstu. Sprawdzasz narzędziem WebAIM Contrast Checker albo zakładką DevTools Chrome → Lighthouse Accessibility.
Typowe problemy: szare placeholdery w formularzach (#999 na białym = 2.8:1 → fail), delikatne „metadata” pod produktami (kategoria, oceny), przycisk „Dodaj do koszyka” w sezonowej kolorystyce nie spełniający kontrastu.
Fix: tailwind utility text-neutral-700 zamiast text-neutral-400, audit motywu przez Lighthouse.
2. Klawiatura — wszystkie akcje osiągalne bez myszy
WCAG 2.1.1 + 2.4.3. Cała nawigacja, dodanie do koszyka, checkout, filtry produktów — muszą działać Tab / Shift+Tab / Enter / spacja. Focus ring musi być widoczny.
Typowe problemy w WooCommerce:
- Custom dropdown „wybierz rozmiar” bez
role="combobox"i obsługi klawiatury. - Modal „Szybki podgląd” bez focus trap.
- Hamburger menu na mobile z pułapką na Tab (focus ucieka poza menu).
Fix: Gutenberg szablony blokowe domyślnie OK. Starsze motywy ThemeForest zwykle fail — wymaga refactoru.
3. Tekst alternatywny obrazów
WCAG 1.1.1. Każdy obraz produktu, każda grafika dekoracyjna — poprawny alt albo alt="" jeśli dekoracyjny.
W WooCommerce problem: import masowy z CSV zostawia puste altty. Wtyczka WP-CLI:
wp media list --fields=ID,title --format=count
wp db query "SELECT COUNT(*) FROM wp_postmeta WHERE meta_key='_wp_attachment_image_alt' AND meta_value='';"Jeśli liczba atachmentów bez altu > 0 — masz problem.
4. Formularze z prawidłowymi etykietami
WCAG 1.3.1 + 3.3.2. Każde <input> powiązane z <label for="..."> lub aria-label. Placeholder nie wystarcza — znika po wpisaniu.
Contact Form 7 domyślnie ma labelki, ale jeśli ktoś edytował szablon i zostawił tylko placeholder — fail. WPForms i Fluent Forms — domyślnie OK.
5. Błędy walidacji czytelne przez screen reader
Po wysłaniu formularza z błędami, komunikat musi być zanonsowany przez czytnik ekranu. Techniczne: aria-live="polite" na kontenerze z errorami, aria-invalid="true" + aria-describedby="error-id" na polach.
6. Strona „Deklaracja dostępności”
Wymóg administracyjny. Publiczny URL (np. /dostepnosc/) z:
- Datą sporządzenia deklaracji,
- Kontaktem do osoby odpowiedzialnej za dostępność,
- Informacją o częściowej zgodności (jeśli dotyczy),
- Linkiem do raportu.
W Polsce szablon publikuje PFRON. Sklepy WooCommerce zwykle tego nie mają — pierwszy punkt do szybkiego uzupełnienia.
Mobilność, zoom, timeout
- Zoom do 200% bez łamania layoutu — WCAG 1.4.4. Responsywny sklep zwykle to spełnia, ale fixed-width modalki często fail.
- Timeout koszyka/sesji — musi być możliwość przedłużenia. Domyślny WooCommerce cart session 48h — OK. Checkout timeout 24h — OK. Niestandardowe timery (np. „promocja wygasa za 10 minut”) muszą być rozszerzalne.
- Bez migających treści — WCAG 2.3.1. Odpuszczamy stare gify reklamowe na stronie głównej.
Co robić krok po kroku (checklist agencji)
- Audyt Lighthouse Accessibility na home + PDP + koszyku + checkoucie. Baseline.
- Audyt WAVE (wave.webaim.org) — uzupełnia Lighthouse o manual checks.
- Test klawiaturą — 15 minut ręcznej nawigacji Tab-em po sklepie od strony głównej do zakończonego checkoutu.
- Test screen readerem — NVDA (darmowy, Windows) albo VoiceOver (macOS). Otwierasz sklep, dodajesz produkt, próbujesz kupić. Wszystkie informacje muszą być dostępne audio.
- Fix krytycznych failów — kontrast, labelki, focus ring, alt tags.
- Deklaracja dostępności opublikowana pod
/dostepnosc/. - Testy okresowe — raz na kwartał audyt Lighthouse + oznakowanie w deklaracji.
Pułapki, o których się nie pisze
- „Nakładka accessibility” (typu UserWay, AccessiBe) — nie wystarczy. Sądy w USA (ADA) już odrzucały argument „mamy nakładkę” — rzeczywista dostępność musi być na poziomie DOM, nie overlay’em JavaScript.
- Certyfikaty accessibility — w UE nie ma oficjalnego. Deklaracja własna jest wystarczająca. Ale musi być prawdziwa — inspektor może to zweryfikować technicznie.
- Third-party embedy (YouTube, mapy, chat) — odpowiadasz za nie. Embed Calendly bez obsługa klawiatury = twoja odpowiedzialność.
Co grozi
Kara może wynosić do 10× przeciętnego miesięcznego wynagrodzenia za każde stwierdzone naruszenie. W praktyce — inspektor zwykle daje pisemne wezwanie do usunięcia + termin 30 dni. Kara dopiero po bezskutecznym wezwaniu.
Dodatkowo: poszkodowany użytkownik może żądać rekompensaty cywilnoprawnie. W Niemczech są już pierwsze wyroki (500–2000 €) za brak dostępności sklepu.
Realna wycena wdrożenia
Dla przeciętnego sklepu WooCommerce z motywem ThemeForest i 500 produktami:
| Prace | Godziny | Koszt netto |
|---|---|---|
| Audyt wejściowy (Lighthouse + manual) | 4-6 h | 800-1200 zł |
| Fix kontrastu i labelek formularzy | 6-10 h | 1200-2000 zł |
| Refactor nawigacja klawiaturąigation (modale, menu) | 8-16 h | 1600-3200 zł |
| Alt tags na 500 produktach (half automated) | 3-5 h | 600-1000 zł |
| Deklaracja dostępności + procedura | 2 h | 400 zł |
| Test regression po zmianach | 3 h | 600 zł |
Razem: 5 000 – 8 000 zł za średni sklep. Blok themes + modern theme: 2 000 – 3 500 zł.
Jeśli masz sklep WooCommerce i nie wiesz czy spełniasz EAA — zacznij od 10-minutowego Lighthouse Accessibility audit. Jeśli score < 90 na PDP albo checkoutcie, masz pracę do zrobienia. Darmowy audyt Devance obejmuje m.in. sprawdzenie EAA/WCAG jako jeden z modułów.

Doświadczony WordPress Developer z ponad 14-letnim stażem w tworzeniu zaawansowanych stron i sklepów internetowych. Specjalizuje się w WordPressie, dedykowanych wtyczkach i motywach.
Więcej o autorze

