EN 301 549 V4.1.1 – co zmienia nowa wersja europejskiego standardu dostępności?

Dostępność cyfrowa przestaje być postrzegana jako etap kontroli jakości realizowany tuż przed publikacją serwisu lub aplikacji. Staje się elementem zarządzania procesem projektowym, bezpieczeństwem usług cyfrowych oraz odpowiedzialnością organizacji za sposób, w jaki użytkownicy korzystają z technologii. Opublikowanie przez ETSI nowej wersji normy EN 301 549 V4.1.1 jest kolejnym krokiem w tym kierunku – nie zmienia fundamentalnych zasad dostępności, ale przesuwa akcent z technicznego spełnienia wymagań na rzeczywistą użyteczność rozwiązań cyfrowych.

Publikacja EN 301 549 V4.1.1 jest jedną z ważniejszych zmian w europejskim systemie standardów dostępności ICT ostatnich lat. Najłatwiej sprowadzić ją do hasła „WCAG 2.2 wchodzi do EN 301 549”, ale z perspektywy audytora byłoby to duże uproszczenie. Aktualizacja obejmuje nie tylko kryteria sukcesu stosowane do stron internetowych, dokumentów elektronicznych i oprogramowania. Zmienia również wymagania dotyczące komunikacji w czasie rzeczywistym, preferencji użytkownika oraz sposobu powiązania technicznych wymagań normy z europejskimi regulacjami.

Dla zespołów odpowiedzialnych za dostępność oznacza to coś więcej niż dopisanie kilku pozycji do arkusza audytowego. Trzeba ponownie przyjrzeć się architekturze produktów cyfrowych, elementom interfejsu, procesom uwierzytelniania, formularzom, systemom komunikacyjnym oraz sposobowi prowadzenia oceny zgodności. W niektórych obszarach zmienia się także sama logika testowania: coraz większe znaczenie ma zachowanie produktu w określonym scenariuszu użytkowym, a nie tylko statyczna ocena pojedynczego komponentu.

 

Jednocześnie WCAG 2.2 usuwa kryterium 4.1.1 Parsing. W EN 301 549 odpowiadające mu wymaganie jest oznaczone jako void. Ma to bezpośrednią konsekwencję dla metodyki audytowej: raportowanie niezgodności wyłącznie na podstawie dawnego SC 4.1.1 nie odpowiada już strukturze WCAG 2.2.

Problemy wpływające na programowe określenie nazwy, roli, wartości, stanu czy relacji komponentu nadal mogą prowadzić do naruszenia innych kryteriów, przede wszystkim 4.1.2 Name, Role, Value. Zmienia się zatem podstawa kwalifikowania błędu, a nie potrzeba zapewnienia poprawnej współpracy z technologiami asystującymi.

Fokus nie może być tylko obecny

Kryterium SC 2.4.11 Widoczność fokusu (minimalna) dobrze pokazuje różnicę między techniczną obsługą klawiatury a rzeczywistą dostępnością interakcji.

Typowy przypadek to serwis wykorzystujący sticky header, baner cookies, pływający widget czatu lub inny element pozycjonowany nad właściwą treścią. Użytkownik przechodzący klawiszem Tab może prawidłowo przenieść fokus na kolejny element, ale komponent zostaje całkowicie przykryty.

Z punktu widzenia struktury DOM i kolejności fokusu wszystko może działać prawidłowo. Z punktu widzenia użytkownika klawiatury orientacja w interfejsie zostaje jednak utracona.

To ważna wskazówka dla audytorów: test samej sekwencji Tab nie wystarcza. Trzeba obserwować zachowanie interfejsu w różnych stanach, także po wyświetleniu elementów nakładanych dynamicznie.

Przeciąganie elementów wymaga alternatywnej metody obsługi

Kryterium SC 2.5.7 Ruchy przeciągania dotyczy funkcji wymagających wykonania gestu przeciągania.

Przykładem może być:

• zmiana kolejności elementów metodą przeciągnij i upuść (drag and drop),
• przesuwanie elementu na osi,
• manipulowanie suwakiem,
• interakcja z mapą.

Jeżeli wykonanie funkcji wymaga przeciągania, należy zapewnić możliwość osiągnięcia tego samego rezultatu za pomocą operacji niewymagającej przeciągania. Chyba że sam ruch jest istotą funkcjonalności albo zastosowanie ma jeden z przewidzianych wyjątków.

To wymaganie jest szczególnie istotne dla osób z ograniczoną sprawnością motoryczną, dla których jednoczesne utrzymanie przycisku i kontrolowanie ruchu wskaźnika może być niemożliwe.

Klikalne elementy w odpowiednim rozmiarze

Wymaganie SC 2.5.8 Minimalny rozmiar celu posługuje się wartością 24 × 24 piksele CSS, ale nie oznacza nakazu, aby każdy link lub przycisk miał dokładnie taki minimalny wymiar. Kryterium przewiduje wyjątki, m.in. związane z odpowiednim odstępem pomiędzy celami, równoważnym mechanizmem dostępnym na tej samej stronie, elementami znajdującymi się w tekście czy rozmiarem kontrolowanym przez agenta użytkownika (user agent).

Dlatego automatyczne zgłoszenie:

„element ma mniej niż 24 px”

nie jest jeszcze wystarczającą podstawą do stwierdzenia niezgodności.

Audytor musi przeanalizować geometrię celu interakcji, jego otoczenie oraz możliwość zastosowania wyjątków przewidzianych w kryterium.

Dostępne uwierzytelnianie – bezpieczeństwo nie powinno tworzyć barier poznawczych

Kryterium SC 3.3.8 Dostępne uwierzytelnianie (minimalne) wymaga szczególnej uwagi, ponieważ znajduje się na styku dostępności cyfrowej i cyberbezpieczeństwa.

Kryterium nie oznacza zakazu stosowania haseł ani uwierzytelniania wieloskładnikowego. Problemem jest sytuacja, w której proces wymaga od użytkownika wykonania zadania angażującego funkcje poznawcze – np. zapamiętania informacji, rozwiązania zadania lub ręcznego przepisania danych – bez udostępnienia odpowiedniego mechanizmu wspomagającego lub alternatywy.

Dlatego blokowanie:

• wklejania hasła,
• korzystania z menedżerów haseł,
• automatycznego uzupełniania danych,
• może stanowić problem z perspektywy dostępności procesu logowania.

Dla zespołów bezpieczeństwa jest to istotna zmiana perspektywy. Mechanizmy ochrony powinny ograniczać ryzyko, ale nie poprzez odbieranie użytkownikowi narzędzi, które wspierają go w pokonywaniu ograniczeń poznawczych.

Formularz należy audytować z uwzględnieniem całego procesu

Podobna zmiana podejścia widoczna jest w kryterium SC 3.3.7 Ponowne wprowadzanie informacji.

W wieloetapowym formularzu użytkownik może podać dane w pierwszym kroku, a następnie zostać poproszony o ponowne wpisanie tych samych informacji kilka ekranów dalej.

W tradycyjnym audycie każde pole może być technicznie dostępne:

• posiadać prawidłową etykietę,
• mieć programowo określoną nazwę,
• prezentować poprawny komunikat błędu,
• zachowywać właściwą kolejność fokusu.

Mimo tego cały proces może tworzyć niepotrzebną barierę.

Dlatego przy ocenie zgodności z WCAG 2.2 formularze należy analizować jako pełne ścieżki użytkownika, a nie wyłącznie jako zestaw niezależnych komponentów.

Audyt formularza zakupowego powinien zatem obejmować przejście całej ścieżki: od wprowadzenia danych, przez kolejne kroki procesu, po jego zakończenie. Dopiero wtedy można ocenić, czy informacje podane wcześniej są automatycznie uzupełniane lub możliwe do wybrania, zamiast ponownie wymagane.

Preferencje użytkownika – co zmienia EN 301 549 V4.1.1?

Jedna z istotniejszych zmian V4.1.1 wykracza poza kryteria WCAG.

Wymagania dotyczące user preferences zostały wyraźnie uwzględnione dla stron internetowych w klauzuli 9.7, dokumentów w 10.7 i oprogramowania w 11.7.

W praktyce chodzi o zdolność produktu do współpracy z preferencjami dostępności ustawionymi przez użytkownika na poziomie platformy lub środowiska. Mogą one dotyczyć m.in. rozmiaru tekstu, kolorystyki, kontrastu czy sposobu prezentacji interfejsu.

Ma to istotne konsekwencje dla designu systemów. Komponent może spełniać wymagania kontrastu w referencyjnym widoku przygotowanym przez projektanta, a jednocześnie zachowywać się nieprawidłowo po zastosowaniu ustawień użytkownika. Podobnie interfejs może być poprawny przy domyślnym rozmiarze tekstu, ale przestać być funkcjonalny po jego zwiększeniu.

Dlatego test dostępności nie powinien ograniczać się do stanu domyślnego komponentu. Trzeba również sprawdzić jego odporność na zmianę parametrów prezentacji.

Klauzula 6 – Real-Time Text i total conversation

Koncentracja wyłącznie na WCAG 2.2 prowadziłaby do pominięcia jednej z największych zmian strukturalnych V4.1.1 – przebudowy klauzuli 6.

Jej zakres dotyczy obecnie ICT wspierających dwukierunkową komunikację w czasie rzeczywistym, a nie wyłącznie komunikację głosową.

Szczególne znaczenie ma rozwinięcie wymagań dla Real-Time Text (RTT). RTT różni się od klasycznego komunikatora tym, że tekst jest transmitowany w trakcie jego wprowadzania, a nie dopiero po naciśnięciu przycisku „Wyślij”.

W określonych scenariuszach usługi zapewniające dwukierunkową komunikację głosową w czasie rzeczywistym muszą również wspierać RTT.

Norma obejmuje przy tym nie tylko samo udostępnienie tej funkcji. Klauzula 6.2 zawiera wymagania dotyczące m.in.:

• prezentacji RTT,
• responsywności,
• dodawania i usuwania wprowadzanego tekstu,
• szybkości przetwarzania,
• reprezentacji znaków,
• metod wprowadzania tekstu.

Drugim istotnym pojęciem jest total conversation, czyli komunikacja integrująca w ramach sesji trzy media: tekst w czasie rzeczywistym, głos oraz wideo.

Dla standardowego serwisu klauzula 6 może mieć ograniczone zastosowanie. Inaczej wygląda sytuacja w przypadku platform komunikacyjnych, systemów telekomunikacyjnych czy komunikacji alarmowej. Tam nie jest to zmiana poboczna, lecz jeden z podstawowych obszarów oceny.

Dokumenty elektroniczne też muszą być dostępne

Przejście na WCAG 2.2 nie dotyczy wyłącznie stron internetowych.

Klauzula 10 obejmująca dokumenty elektroniczne również została zaktualizowana. Oznacza to, że analiza gotowości organizacji do V4.1.1 powinna uwzględniać m.in. publikowane PDF-y i dokumenty biurowe.

Audyt po V4.1.1 – warto zmienić metodykę

Z perspektywy audytora najprostszą reakcją na publikację V4.1.1 byłoby dopisanie sześciu kryteriów do istniejącego arkusza WCAG 2.1. Taka aktualizacja jest potrzebna, ale niewystarczająca.

Nowe wymagania jeszcze mocniej pokazują ograniczenia audytu opartego wyłącznie na analizie pojedynczych ekranów i komponentów.

Przykładowo:

 

W praktyce rośnie więc znaczenie testowania scenariuszowego. Podkreślają to słowa Wojciecha Polara:

 

 

„EN 301 549 V4.1.1 pokazuje bardzo wyraźnie, że audyt dostępności nie może być tylko sumą wyników testu kilku komponentów. W sytuacji, gdy kryterium dotyczy ponownego podawania informacji, sposobu uwierzytelniania albo zachowania interfejsu po zmianie preferencji użytkownika, musimy analizować produkt jako system. To oznacza przechodzenie pełnych ścieżek użytkownika, badanie stanów dynamicznych i jeszcze większe rozumienie zależności pomiędzy warstwą interfejsu, platformą oraz technologiami asystującymi.”

 

 

Wojciech Polar – audytor dostępności cyfrowej, ekspert ds. transformacji cyfrowej

 

Ta zmiana ma również znaczenie dla raportowania. Raport zgodności powinien coraz wyraźniej odróżniać błąd konkretnego komponentu od problemu systemowego wynikającego np. z designu systemu, mechanizmu uwierzytelniania lub architektury całego procesu.

Norma EN 301 549 V4.1.1 jest opublikowana, ale czy obowiązuje?

EN 301 549 V4.1.1 została opublikowana jako nowa wersja europejskiej normy. Nie oznacza to jednak, że z chwilą publikacji automatycznie zastąpiła V3.2.1 jako podstawa domniemania zgodności pod kątem prawnym.

Sam fakt, że V4.1.1 zawiera Annex ZB mapujący wymagania EAA, nie jest równoznaczny z uzyskaniem przez normę statusu normy zharmonizowanej zapewniającej domniemanie zgodności.

To istotne również w polskich realiach. W przypadku podmiotów publicznych obowiązki wynikają z ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Sama publikacja V4.1.1 nie aktualizuje automatycznie krajowego katalogu wymagań do WCAG 2.2. Na to musimy jeszcze poczekać.

EN 301 549 V4.1.1 – podsumowanie

Najważniejszy wniosek z V4.1.1 nie brzmi: „do WCAG doszło sześć kryteriów A i AA”. To tylko najbardziej widoczna część zmiany. Nowa wersja normy wzmacnia podejście, w którym dostępność ocenia się na poziomie produktu, funkcjonalności i pełnego scenariusza użytkownika. Powinno to skłonić organizacje do sprawdzenia, czy obecny system zarządzania dostępnością rzeczywiście obejmuje cały cykl.

Największym błędem byłoby potraktowanie V4.1.1 wyłącznie jako przyszłego obowiązku formalnego. WCAG 2.2 można testować już dziś, a design, procesy uwierzytelniania czy formularze można poprawiać bez czekania na zmianę przepisów. W przypadku dużych systemów właśnie ten czas przygotowania może zdecydować o tym, czy przejście na nowy standard będzie kontrolowaną aktualizacją, czy kolejnym kosztownym projektem naprawczym.

 

Źródła:

https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf

https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en