Compliance

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.

DDawid Penkala
11 min czytania
Osoba korzystająca z czytnika ekranu — dostępność cyfrowa

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)

  1. Audyt Lighthouse Accessibility na home + PDP + koszyku + checkoucie. Baseline.
  2. Audyt WAVE (wave.webaim.org) — uzupełnia Lighthouse o manual checks.
  3. Test klawiaturą — 15 minut ręcznej nawigacji Tab-em po sklepie od strony głównej do zakończonego checkoutu.
  4. Test screen readerem — NVDA (darmowy, Windows) albo VoiceOver (macOS). Otwierasz sklep, dodajesz produkt, próbujesz kupić. Wszystkie informacje muszą być dostępne audio.
  5. Fix krytycznych failów — kontrast, labelki, focus ring, alt tags.
  6. Deklaracja dostępności opublikowana pod /dostepnosc/.
  7. 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:

PraceGodzinyKoszt netto
Audyt wejściowy (Lighthouse + manual)4-6 h800-1200 zł
Fix kontrastu i labelek formularzy6-10 h1200-2000 zł
Refactor nawigacja klawiaturąigation (modale, menu)8-16 h1600-3200 zł
Alt tags na 500 produktach (half automated)3-5 h600-1000 zł
Deklaracja dostępności + procedura2 h400 zł
Test regression po zmianach3 h600 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.

Tagi:EAAdostępnośćWCAGWooCommercecomplianceRODOEN 301 549
Dawid Penkala
Dawid Penkala

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