Zapytaj o wycenę

AKTUALNOŚCI

EN 301 549 v4.1.1: norma, która definiuje dostępność cyfrową w UE, właśnie dostała pierwszej dużej aktualizacji od pięciu lat

Autor: Natalia Madej

Przez ostatnie pięć lat EN 301 549 kojarzyła się z jedną datą: 2021, wersja 3.2.1, oparta na WCAG 2.1.

Przez ostatnie pięć lat EN 301 549 kojarzyła się z jedną datą: 2021, wersja 3.2.1, oparta na WCAG 2.1. Ten fundament, na którym opierały się specyfikacje przetargowe, raporty z audytów i deklaracje dostępności w całej Unii, właśnie się przesunął. 2 września 2026 r. ETSI opublikowało EN 301 549 v4.1.1 — pierwszą od 2021 roku merytoryczną rewizję normy, która operacjonalizuje wymagania dostępności z European Accessibility Act (EAA) i unijnej dyrektywy o dostępności stron internetowych (WAD).

To nie jest kosmetyczna aktualizacja numeru wersji. Zmienia się podstawa techniczna (WCAG 2.2 zamiast 2.1), zmienia się zakres (dokumenty i komunikacja w czasie rzeczywistym dostają nowe, wcześniej nieistniejące wymagania), a przede wszystkim zmienia się to, co będzie można uznać za dowód zgodności w postępowaniu przetargowym czy kontroli.

Dlaczego to jest zmiana, a nie aktualizacja kosmetyczna

EN 301 549 to norma techniczna opracowana wspólnie przez ETSI, CEN i CENELEC na zlecenie Komisji Europejskiej (mandat standaryzacyjny M/587). Jej rola jest specyficzna: to ona przekłada ogólne wymogi prawne EAA i WAD na konkretne, testowalne kryteria techniczne. Dopóki dana wersja normy nie zostanie zacytowana w Dzienniku Urzędowym UE, nie daje ona domniemania zgodności (presumption of conformity) z prawem — a to domniemanie jest głównym powodem, dla którego zamawiający i dostawcy w ogóle się nią posługują.

Najważniejsza merytoryczna zmiana w v4.1.1: norma przechodzi z WCAG 2.1 na WCAG 2.2 na poziomie AA. Ale — jak podkreślają komentatorzy branżowi — spełnienie WCAG 2.2 AA nie jest tożsame ze spełnieniem EN 301 549 v4.1.1. WCAG 2.2 AA to tylko baza dla klauzul dotyczących stron internetowych, aplikacji i dokumentów (klauzule 9, 10, 11); reszta normy — sprzęt, oprogramowanie, komunikacja w czasie rzeczywistym, wsparcie techniczne — ma własne, odrębne wymagania.

Sześć nowych kryteriów, które trzeba będzie testować

Wraz z przejściem na WCAG 2.2 do zakresu normy wchodzi sześć nowych kryteriów sukcesu, obowiązkowo dla stron WWW, aplikacji i dokumentów elektronicznych (to ważne — reguły dla dokumentów mają odzwierciedlać reguły dla stron internetowych):

  • 2.4.11 Focus Not Obscured (Minimum) (AA) — komponent, który ma fokus klawiatury, nie może być całkowicie zasłonięty przez inny element interfejsu.
  • 2.5.7 Dragging Movements (AA) — każda funkcja realizowana przez przeciąganie (drag) musi mieć alternatywę niewymagającą tego gestu.
  • 2.5.8 Target Size (Minimum) (AA) — cele klikalne powinny mieć co najmniej 24×24 piksele CSS (z wyjątkami).
  • 3.2.6 Consistent Help (A) — mechanizmy pomocy (kontakt, chat, FAQ) muszą występować w spójnej kolejności na kolejnych stronach.
  • 3.3.7 Redundant Entry (A) — dane podane wcześniej w tym samym procesie nie mogą być ponownie wymagane od użytkownika ręcznie.
  • 3.3.8 Accessible Authentication (Minimum) (AA) — testy logowania oparte wyłącznie na funkcjach poznawczych (np. zapamiętywanie hasła, rozwiązywanie zagadki) muszą mieć alternatywę.

Jednocześnie z normy zniknęło stare kryterium 4.1.1 Parsing — oznaczono je jako „void” (nieobowiązujące), zgodnie z tym, co zrobiono już wcześniej w samym WCAG 2.2.

To nie tylko strony internetowe

Dwie zmiany łatwo przeoczyć, jeśli ktoś czyta EN 301 549 wyłącznie jako „normę dla WWW”:

Dokumenty elektroniczne (klauzula 10). Sześć nowych kryteriów WCAG 2.2 dotyczy również dokumentów — PDF-ów, plików Office — w takim samym zakresie jak stron. To istotne przypomnienie dla zespołów, które przygotowują dokumenty publikowane w BIP-ach czy na portalach instytucji: same tagi i poprawna kolejność odczytu (wciąż najczęstsza przyczyna niedostępności dokumentów i wciąż wymagająca priorytetowej uwagi) nie wystarczą — trzeba też ocenić np. rozmiar obszarów klikalnych w formularzach interaktywnych czy unikanie powtórnego wprowadzania tych samych danych.

Preferencje użytkownika. Wymóg respektowania ustawień użytkownika (kontrast, rozmiar tekstu, ograniczenie animacji) wcześniej dotyczył głównie oprogramowania. W v4.1.1 dostał własne, odrębne wymaganie także dla stron internetowych i dokumentów.

Komunikacja w czasie rzeczywistym. Klauzula 6.7 wprowadza model „Total Conversation” — łączne wsparcie dla głosu, tekstu czasu rzeczywistego (RTT) i wideo w produktach obsługujących połączenia, komunikatory, centra kontaktu i wideokonferencje. To obszar, w którym komentatorzy branżowi spodziewają się największego technicznego refaktoringu po stronie dostawców telekomunikacyjnych i contact-center.

Nowe załączniki: mapowanie wprost na prawo unijne

Norma zyskała dwa nowe aneksy, które wprost łączą jej klauzule z konkretnymi aktami prawnymi: Annex ZA mapuje wymagania na dyrektywę WAD (strony i aplikacje sektora publicznego), a Annex ZB — na European Accessibility Act. Dodano też klauzulę A.2 dotyczącą oceny zgodności z wymogami EAA. Dla audytorów oznacza to mniej zgadywania przy odpowiadaniu na pytanie „które dokładnie wymagania EN 301 549 odpowiadają temu przepisowi EAA/WAD, który mnie obowiązuje”.

Harmonogram: publikacja przez ETSI to nie to samo, co obowiązywanie

To najczęściej pomijany, a najważniejszy praktycznie szczegół. Publikacja normy przez ETSI i jej zacytowanie w Dzienniku Urzędowym UE (OJEU) to dwa odrębne wydarzenia, rozdzielone w czasie:

Harmonogram wdrażania EN 301 549 v4.1.1 i jej status prawny
EtapData (wg dostępnych informacji)Status
Publikacja EN 301 549 v4.1.1 przez ETSI2 września 2026Fakt dokonany
Przekazanie normy Komisji Europejskiejok. 7 września 2026Wstępne, planistyczne
Zacytowanie w Dzienniku Urzędowym UE (OJEU)ok. 30 listopada 2026Wstępne, deklarowane jako niewiążący harmonogram planistyczny
Norma cytowana obecnie dla dyrektywy WADwciąż v3.2.1 (2021)Obowiązuje do czasu cytowania v4.1.1

Do momentu zacytowania w OJEU to wciąż EN 301 549 v3.2.1 pozostaje normą dającą domniemanie zgodności z dyrektywą o dostępności stron internetowych. v4.1.1 zyska analogiczny status dopiero po formalnym powołaniu przez Komisję. Terminy transpozycji krajowej poszczególne państwa członkowskie ustalają samodzielnie, więc mogą się różnić między sobą.

Co to oznacza w praktyce — dla różnych sytuacji

Praktyczne konsekwencje EN 301 549 v4.1.1 w różnych sytuacjach
SytuacjaOcenaCo zrobić
Trwający audyt WCAG 2.1 / EN 301 549 v3.2.1Nadal ważny formalnie do czasu cytowania v4.1.1Dokończyć zgodnie z obecną podstawą, ale odnotować w raporcie, wobec której wersji normy audyt został przeprowadzony
Specyfikacja przetargu pisana teraz na nową stronę/aplikacjęWymaga decyzji projektowej już dziśRozważyć uwzględnienie klauzul v4.1.1 i WCAG 2.2 AA jako celu, nawet przed formalnym cytowaniem w OJEU
Dokumenty PDF publikowane w BIPNowe kryteria dotyczą też dokumentówNie ograniczać się do starych testów tagowania — sprawdzić też nowe kryteria interakcyjne, jeśli dokument je zawiera
Systemy komunikacji głosowej / contact centerPotencjalnie duży zakres pracZaplanować ocenę wymagań Total Conversation (klauzula 6.7) z odpowiednim wyprzedzeniem
Stary raport z audytu przedstawiany jako dowód zgodności z v4.1.1Błąd metodologicznyNie przedstawiać audytów WCAG 2.1 jako dowodu spełnienia nowej wersji normy
Automatyczny skan (np. axe, WAVE) jako jedyny dowód zgodnościNiewystarczające, także wcześniejWymagać testów manualnych, oceny preferencji użytkownika i (gdzie dotyczy) komunikacji czasu rzeczywistego

Co zrobić już teraz — siedem kroków

  1. Oddziel bieżące obowiązki od stanu docelowego. To, co obowiązuje formalnie dziś (v3.2.1/WCAG 2.1), i to, do czego trzeba się przygotować (v4.1.1/WCAG 2.2), to dwa różne punkty odniesienia — warto je trzymać rozdzielnie w dokumentacji projektu.
  2. Zaktualizuj specyfikacje przetargowe już na etapie projektowania. Zamiast ogólnego odwołania do „WCAG 2.1″ warto zacząć odwoływać się do konkretnych klauzul v4.1.1 i sprecyzować oczekiwania co do testów, odpowiedzialności za naprawę błędów i formy raportowania zgodności.
  3. Zmapuj swoje produkty cyfrowe względem nowych klauzul. Osobno strony i aplikacje, osobno dokumenty, osobno — jeśli dotyczy — systemy komunikacji głosowej/wideo.
  4. Zażądaj od dostawców precyzji w audytach. Dostawca zewnętrzny powinien jasno wskazywać, którą edycję EN 301 549 i które klauzule faktycznie obejmuje jego raport z audytu.
  5. Zacznij od systemu projektowego (design system). To najbardziej efektywny punkt startowy — poprawki w komponentach współdzielonych (rozmiar celów, spójna pomoc, obsługa fokusu) propagują się automatycznie do wszystkich miejsc, gdzie komponent jest używany.
  6. Priorytetowo potraktuj dokumenty pod kątem podstaw, zanim zajmiesz się nowymi kryteriami. Jeśli tagowanie i kolejność odczytu wciąż szwankują, to one — a nie nowe kryteria WCAG 2.2 — są głównym źródłem niedostępności dokumentu.
  7. Przeszkol zespół w relacji WCAG ↔ EN 301 549 ↔ prawo. Wielu praktyków traktuje te trzy warstwy zamiennie, a nie są tożsame — spełnienie WCAG 2.2 AA to warunek konieczny, ale niewystarczający dla zgodności z pełnym zakresem normy.

Najważniejsza zasada

EN 301 549 v4.1.1 jest już faktem technicznym, ale jeszcze nie faktem prawnym w pełnym znaczeniu — dopóki nie zostanie zacytowana w Dzienniku Urzędowym UE, domniemanie zgodności wciąż wiąże się z wersją 3.2.1. To jednak nie powód, by czekać z rękami złożonymi: okno między publikacją a cytowaniem to właśnie czas, w którym można wdrożyć zmiany bez presji ostatniej chwili — w ramach zwykłego cyklu wydawniczego produktu, a nie awaryjnej korekty tuż przed kontrolą czy przetargiem.

Źródła

Przeczytaj również