EU Accessibility Act 2025 (EAA) – jakie zmiany musisz wprowadzić na stronie lub w aplikacji

Czym jest EU Accessibility Act (EAA) 2025?

To dyrektywa unijna, która została zatwierdzona już całkiem dawno temu, bo w 2019 roku. Mimo, że termin jej wejścia w życie jest bardzo blisko, mówi się o niej niewiele - a zmienia sporo.

Celem dyrektywy jest zwiększenie dostępności treści cyfrowych (stron, aplikacji, ale nawet treści audio, e-booków) dla osób z niepełnosprawnościami. Czyli o accessibility.

O jakich niepełnosprawnościach mowa?

[…] obejmując udogodnienia dla osób niewidomych i słabowidzących, niesłyszących i z ubytkami słuchu, z ograniczeniami ruchowymi, zaburzeniami mowy, nadwrażliwością na światło, a także złożonymi kombinacjami tych niepełnosprawności. Obejmują również pewne udogodnienia dla osób z trudnościami w uczeniu się i ograniczeniami poznawczymi; jednak nie odpowiadają na wszystkie potrzeby użytkowników z tymi niepełnosprawnościami.

- WCAG (w3.org)

Czym w ogóle jest accessibility?

Dla osób, którym te słowo niewiele lub nic nie mówi. W kontekście tego o czym piszę na moim blogu (programowania), chodzi o tworzenie aplikacji, które są dostępne dla całego przekroju społeczeństwa.

Tak jak infrastruktura miejska (bardzo powoli) adaptuje się do potrzeb osób poruszających się na wózkach, niewidomych, tak strony i aplikacje można robić w bardziej lub mniej przystępny dla nich sposób.

Więcej o teorii i technikach przeczytasz w artykułach z kategorii accessibility. Polecam szczególnie 11 niezbędnych kroków by aplikacja była dostępna

Czy EU Accessibility Act w ogóle mnie dotyczy?

Zgodnie z informacjami na stronie Komisji Europejskiej, ustawa European Accessibility Act (EAA) dotyczy produktów i usług cyfrowych, takich jak strony internetowe i aplikacje mobilne, ale przede wszystkim w kontekście określonych branż, np. e-commerce, bankowości czy platform audiowizualnych.

Przykładowe usługi dotknięte EAA

Strony internetowe i aplikacje mobilne firm – np. sklepy internetowe, bankowość online, aplikacje usługowe.

Platformy e-commerce – jak Allegro, Amazon czy inne strony sprzedające produkty.

Aplikacje płatności i bankowości – np. Revolut, aplikacje bankowe.

Systemy rezerwacji biletów – np. bilety na pociąg, autobus czy samolot.

Platformy usług publicznych – np. aplikacje do składania wniosków urzędowych.

Media i platformy audiowizualne – jak Netflix, YouTube, Spotify.

Aplikacje telekomunikacyjne – np. Messenger, WhatsApp, Skype.

Chodzi o aplikacje i strony dostępne publicznie.

Stawiam jednak na to, że wdrożenie tych wymogów do kolejnych branż jest tylko kwestią czasu - w końcu osoby niepełnosprawne zasługują na dostęp do tych samych treści co inni.

Czy wdrażanie accessibility jest trudne?

Lista jest długa, a każda niepełnosprawność wiąże się z innymi trudnościami. Na pierwszy rzut oka, sprawa wydaje się bardzo skomplikowana, czasochłonna, a co za tym idzie - droga do wprowadzenia.

Tak i nie.

Wytyczne, które opisują co nasza aplikacja powinna, a czego nie powinna robić by nazywać się “dostępną” (accessible) mają już wiele lat. Druga wersja powstała w 2008 roku, a jej rozszerzenie (2.1) w 2018 roku (z aktualizacjami w 2023 i 2024).

Co to dla nas oznacza? To, że jest na rynku wiele narzędzi (w tym darmowych), które pomagają nam sprawdzać nasze strony i aplikacje. Co więcej, same dobre praktyki pracy z HTML załatwiają lwią część roboty.

Nie jest to więc powód do paniki dla osób, które po prostu piszą czysty, zgodny z dokumentacją kod.

Jeżeli chcesz taki pisać to zapraszam do zapoznania się z moimi kursami stworzonymi we współpracy z wydawnictwem Helion, czytania bloga lub kontaktu bezpośredniego w celu wsparcia indywidualnego.

4 zasady dostępności WCAG

WCAG definiuje 4 głównych zasad dostępności. Są one zarówno precyzyjne (co do pożądanego efektu) jak i ogólne (nie mówią o konkretnych technologiach czy narzędziach by to osiągnąć). Zasady mówią, że treści muszą być:

Postrzegalne (Perceivable)
Operacyjne (Operable)
Zrozumiałe (Operable)
Solidne (Robust)

Spróbujmy to przełożyć na praktykę.

Przykład wyzwań związanych z accessibility

Pierwsza zasada...

mówi, że każdy użytkownik powinien mieć dostęp do tych samych treści. Wydaje się to być proste, ale jeżeli na Twojej stronie kluczowe informacje zawarte są w krótkim video, to:

Dla osoby głuchej lub niedosłyszącej musisz zadbać o “captions” czyli po prostu napisy
Dla osoby niewidomej same napisy mogłyby zostać co prawda odczytane, ale ta osoba zostanie pozbawiona kontekstu wynikającego z obrazu. Powinieneś przygotować tekst oddający sens i główny przekaz z wideo (lub audio)

Druga zasada...

odnosi się do interfejsów użytkownika, ich przystępności.

Dla osoby o ograniczonej ruchowości, musisz zadbać o to by treść widoczna np. w fikuśnej karuzeli, wizualnie zaawansowanej liście rozwijanej, była możliwa do odczytania w całości za pomocą różnych narzędzi. Upraszczając - nie tylko myszką, ale też klawiaturą czy przy wsparciu systemów asystujących (działajacych np. na podstawie poleceń głosowych)

Trzecia zasada...

mówi o byciu zrozumiałym. To wydaje się proste, nie? Przecież i tak robimy strony tak żeby były zrozumiałe. W praktyce nie jest to takie oczywiste.

Dla przykładu, jeżeli osoba niewidoma korzysta z naszej strony, to jej treść jest po prostu czytana. Często wyłapuje się kontekst na podstawie kolorów, obrazów, ikon. Częstym błędem jest dodawanie przycisku z ikoną “X”, bez opisania jej w odpowiedni sposób (np. “Zamknij okno”). Można to uzyskać między innymi za pomocą atrybutów ARIA.

Ostatnia zasada...

mówi o niezawodności.

Jeżeli nasza aplikacja zachowuje się nieprzewidywalnie, informacje zwrotne przychodzą z opóźnieniem przez co użytkownik przerywa operacje.
Kiedy przez błędy traci się postęp - na przykład gdy strona się odświeży lub zawiesi na ostatniej stronie długiego formularza (to doprowadza do szału również w pełni zdrowe osoby).

Jak bardzo musimy się postarać by spełnić wymogi Unii?

Ok, wracając do sedna sprawy - czekają nas zmiany w prawie. O accessibility można opowiadać godzinami, ale jeżeli chodzi o konkrety to nasza strona musi spełniać kryteria niezbędne do oceny “AA” według standardu WCAG 2.1 (a będąc precyzyjnym do ustawy EN 301 549, która z kolei wskazuje WCAG 2.1 na poziomie AA jako wyznacznik zgodności).

Wyróżniamy 3 poziomy dostępności. Zanim do nich przejdziemy, wyjaśnię tylko jak to działa. W dokumentacji znajdziemy długą listę "warunków" do spełnienia.

Wszystkie mają obok siebie oznaczenie A, AA lub AAA. Ten poziom jest "zaliczony" jeżeli Twoja strona/aplikacja spełnia wszystkie warunki w danej klasie.

A

W pierwszym mieszczą się bardzo podstawowe rzeczy jak na przykład

Oprócz kolorów, używamy też innych mechanizmów do informowania o roli elementu, akcji którą wywołuje (np. wspomniane atrybuty ARIA)
Jeżeli na stronie “leci jakaś muzyka” przez dłużej niż 3 sekundy, to są przyciski pozwalające ją wyłączyć lub zmienić jej głośność

AA

Druga (ta, która nas dotyczy) wymaga już nieco więcej, ale niektóre rzeczy nadal są dość proste:

Treści muszą mieć zachowany odpowiedni kontrast. Im większy tekst, tym ten kontrast może być mniejszy. Im mniejszy z kolei, tym kolor musi bardziej wyróżniać się względem tła.
Wideo i audio muszą mieć napisy
Strona lub aplikacja musi działać zarówno w orientacji poziomej jak i pionowej

AAA

Trzecia, "Złoty Graal" accessibility i znów - niektóre rzeczy są trywialne do zrobienia, jak na przykład:

Każda sekcja ma nagłówek, który ją opisuje - na przykład za pomocą tagów H1-H6. Oczywiście chodzi tutaj o stworzenie poprawnego “drzewa” strony, a nie używania ich losowo lub tylko dla nadania określonego stylu (użyję H5 bo jest mniejszy od H4). Pisałem o tym sporo w artykule o najważniejszych tagach semantycznych.
Elementy, z którymi można wejść w interakcje mają rozmiar przynajmniej 44x44 pikseli.
…ale też trudniejsze (czasem niewykonalne w określonych branżach) jak na przykład pisanie treści, które są zrozumiałe dla osób z wykształceniem nie wyższym odpowiednik ostatnich klas szkoły podstawowej (plus-minus)

Czy jest prosty sposób na sprawdzenie mojej aplikacji?

Znowu - tak i nie. Jest świetne narzędzie Axe od firmy Deque, która swoją drogą wydała przewodnik po EAA. Możesz je zainstalować jako rozszerzenie w Chrome i nie tylko dostaniesz raport z problemami, ale nawet zaznaczy Ci miejsca, w których występują.

Do kiedy jest czas?

Masz czas na wdrożenie zmian do 28 lipca 2025 roku. Niezależnie od tego czy Twoja aplikacja zalicza się do takich, które tego wymagają czy nie, osobiście polecam zainteresowanie się tematem.

Accessibility to nie tylko spełnianie wymogów, ale też poszerzanie grupy odbiorców Twoich usług i produktów. Zwiększa to też reputację Twojej marki.

Napisz do mnie jeżeli potrzebujesz wsparcia w ocenie swojej strony lub aplikacji.

Tagi: