Czy stosowanie ARIA jest obowiązkiem prawnym?

W środowisku deweloperskim i prawnym często pojawia się pytanie: czy standard WAI-ARIA (Accessible Rich Internet Applications) jest obowiązkowy? Odpowiedź nie jest jednowymiarowa. WAI-ARIA nie jest samodzielnym wymogiem prawnym wymienionym wprost w ustawach czy dyrektywach unijnych, ale w praktyce stanowi kluczowy aspekt wypełnienia wymogów prawnych dotyczących dostępności.

Prawo (zarówno w Polsce, jak i w UE) nie nakazuje wprost stosowania atrybutów ARIA na każdej stronie internetowej. Nakazuje natomiast spełnienie określonych kryteriów dostępności (zgodnych z WCAG 2.1 na poziomie AA oraz normą EN 301 549). Te kryteria w przypadku nowoczesnych, dynamicznych aplikacji internetowych często nie mogą być zrealizowane bez użycia ARIA.

W Unii Europejskiej od 2016 roku obowiązuje Dyrektywa (UE) 2016/2102 w sprawie dostępności stron internetowych i aplikacji mobilnych podmiotów sektora publicznego. Dyrektywa ta nakłada na wszystkie podmioty publiczne obowiązek zapewnienia dostępności ich serwisów internetowych i aplikacji mobilnych dla osób z niepełnosprawnościami:. W Polsce wdrożono ją poprzez Ustawę z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Ustawa ta definiuje dostępność cyfrową jako zgodność z wymaganiami WCAG 2.1 na poziomie AA, wyszczególnionymi w tabeli załączonej do ustawy.

Innymi słowy, polskie prawo wymaga, aby strony internetowe i aplikacje mobilne sektorów publicznych spełniały kryteria sukcesu WCAG 2.1 (co najmniej poziom AA). Jest to zgodne z normą europejską EN 301 549 w wersji 2.1.2, którą Komisja Europejska uznała za tzw. normę zharmonizowaną dla tej dyrektywy. W efekcie, od 2020 roku wszystkie instytucje publiczne (m.in. urzędy administracji rządowej i samorządowej, szkoły publiczne, szpitale, a nawet określone organizacje pozarządowe realizujące zadania publiczne) a od czerwca 2025 także firmy prywatne muszą dostosować swoje serwisy do wytycznych WCAG 2.1, zapewniając ich postrzegalność, funkcjonalność, zrozumiałość i kompatybilność.

Podobne wymogi nakłada Europejski Akt o Dostępności o którym piszemy w osobnym artykule. Europejski Akt o Dostępności, czyli Dyrektywa (UE) 2019/882 z 17 kwietnia 2019 r. wprowadza obowiązkowe wymagania dostępności dla wybranych produktów i usług na rynku – również w sektorze prywatnym. European Accessibility Act (EAA) ma na celu ujednolicenie wymagań dostępności w całej UE i usunięcie barier w dostępie do produktów i usług dla osób z niepełnosprawnościami. Od dnia 28 czerwca 2025 r. wszystkie firmy oferujące produkty i usługi objęte zakresem EAA muszą spełniać określone wymagania dostępności cyfrowej. Dotyczy to m.in. takich usług jak sklepy internetowe (e-commerce), bankowość elektroniczna, e-booki, usługi transportu pasażerskiego (np. bilety online) oraz aplikacje i strony związane z audiowizualnymi usługami medialnymi. Dyrektywa wprost nakłada obowiązek, aby serwisy e-commerce oraz inne wymienione usługi były dostępne dla osób z niepełnosprawnościami. Co ważne, EAA obejmuje nie tylko firmy z siedzibą w UE, ale także np. przedsiębiorstwa spoza UE (USA itp.), jeśli kierują swoje usługi do konsumentów w Unii. Przewidziano nieliczne wyjątki – np. mikroprzedsiębiorstwa świadczące usługi (jak lokalny transport) mogą być zwolnione z niektórych wymogów. Ogólnie jednak od 2025 r. wiele serwisów i aplikacji sektora prywatnego (w wymienionych branżach) będzie prawnie zobowiązanych do zgodności z kryteriami dostępności.

Standardy WCAG 2.1, EN 301 549 a rola ARIA

Zarówno dyrektywa, jak i Europejski Akt o Dostępności bazują na międzynarodowych standardach technicznych dotyczących dostępności treści cyfrowych. W praktyce kluczowe znaczenie mają Wytyczne WCAG 2.1 (Web Content Accessibility Guidelines) opublikowane przez W3C oraz europejska norma EN 301 549. Norma EN 301 549 (zatytułowana Accessibility requirements for ICT products and services) czerpie w dużej mierze z WCAG 2.1 i zawiera konkretne wymagania techniczne dla dostępności stron WWW, dokumentów elektronicznych i oprogramowania. Wersja EN 301 549 v2.1.2 została uznana za zharmonizowaną z dyrektywą, dając tzw. domniemanie zgodności – tzn. spełnienie jej kryteriów oznacza spełnienie wymogów prawnych dyrektywy. Najnowsza wersja również opiera się na WCAG 2.1 i uwzględnia dodatkowe wymagania, m.in. dla aplikacji mobilnych. W kontekście ARIA najważniejsza jest zasada Kompatybilność (Robust) – wymagająca, by zawartość była prawidłowo interpretowana przez różne przeglądarki i technologie asystujące (np. czytniki ekranu). W WCAG 2.1 istnieją kryteria sukcesu (np. 4.1.2 „Name, Role, Value”) obligujące twórców do zapewnienia, że wszystkie interaktywne elementy interfejsu mają właściwie zdefiniowane programistycznie nazwy, role i stany.

WAI-ARIA (Accessible Rich Internet Applications) to standard W3C uzupełniający HTML, który właśnie definiuje dodatkowe role, stany i atrybuty dla dynamicznych, bogatych aplikacji internetowych. Jak wskazuje nazwa, ARIA powstała po to, by podnieść dostępność zaawansowanych aplikacji webowych. Pozwala deweloperom oznaczać elementy interfejsu użytkownika (np. przyciski, okna dialogowe, menu tworzone w JavaScript) tak, aby były one rozpoznawalne i obsługiwalne przez technologie wspomagające. W ten sposób ARIA wspiera spełnienie kryteriów WCAG z kategorii „Robust” – zapewnia kompatybilność niestandardowych komponentów z czytnikami ekranu i innymi narzędziami. W samych dokumentach WCAG 2.1 czy EN 301 549 nazwa “ARIA” może nie pojawiać się wprost, ale jest ona de facto nieodłączną częścią technik spełniania tych wytycznych. Przykładowo, aby spełnić wymóg 4.1.2 WCAG (poprawne określenie nazw, ról, wartości elementów interfejsu), często trzeba zastosować odpowiednie role i atrybuty ARIA dla elementów tworzonych dynamicznie w aplikacji. Również inne zalecenia (np. dostarczanie informacji o zmianach na stronie w sposób dostępny) realizuje się przy użyciu ARIA (atrybuty typu aria-live, aria-label itp.). Standard ARIA jest zatem przywoływany pośrednio – poprzez wymóg zgodności z normami WCAG/EN 301 549, które to normy zalecają użycie ARIA tam, gdzie zwykłe HTML5 nie wystarcza do zapewnienia dostępności.

ARIA – wymóg prawny czy rekomendacja?

WAI-ARIA nie jest samodzielnym wymogiem prawnym wymienionym w ustawach czy dyrektywach unijnych, ale w praktyce stanowi kluczowy aspekt wypełnienia wymogów prawnych dotyczących dostępności. Prawo (zarówno w Polsce, jak i w UE) nie nakazuje wprost stosowania ARIA każdej stronie internetowej – nakazuje natomiast spełnienie określonych kryteriów dostępności (WCAG 2.1/EN 301 549), a te kryteria często nie mogą być zrealizowane bez użycia ARIA w przypadku nowoczesnych, dynamicznych aplikacji.

Można więc powiedzieć, że ARIA jest wymogiem pośrednim tzn. jest technicznym standardem rekomendowanym przez W3C i uznanym za najlepszą praktykę, który de facto „staje się obowiązkowy” wszędzie tam, gdzie potrzebne jest zapewnienie dostępności dynamicznych elementów. W sektorze publicznym brak wdrożenia rozwiązań opartych o ARIA (gdy są one konieczne do spełnienia WCAG) będzie naruszeniem przepisów o dostępności cyfrowej. W sektorze prywatnym, od czerwca 2025 roku podobna sytuacja ma miejsce w branżach objętych Europejskim Aktem o Dostępności – strony np. e-commerce muszą być już dostosowane do WCAG 2.1, a więc zapewne korzystać z ARIA przy interaktywnych elementach stron i aplikacji mobilnych. Reasumując, standard ARIA sam w sobie jest rekomendacją techniczną, lecz ze względu na powiązanie z prawnie wymaganymi standardami dostępności, jego stosowanie stało się praktycznie koniecznością, aby spełnić obowiązujące wymogi prawne.

ARIA jako „wymóg pośredni”

Można zdefiniować ARIA jako techniczny standard rekomendowany przez W3C, który de facto „staje się obowiązkowy” wszędzie tam, gdzie natywny HTML nie wystarcza do zapewnienia dostępności.

Sektor publiczny: Brak wdrożenia rozwiązań opartych o ARIA (gdy są one konieczne do spełnienia WCAG) jest naruszeniem Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych.
Sektor prywatny (E-commerce, bankowość): Od czerwca 2025 roku, w związku z Europejskim Aktem o Dostępności (EAA), podobne wymogi obejmą szeroki rynek usług komercyjnych. Sklepy internetowe czy aplikacje bankowe będą musiały być zgodne z WCAG 2.1, co wymusza stosowanie ARIA przy interaktywnych interfejsach.

Przykłady: Kiedy brak ARIA oznacza złamanie prawa?

Aby zrozumieć, dlaczego rekomendacja techniczna staje się wymogiem prawnym, warto przeanalizować konkretne elementy interfejsu. Poniżej przedstawiamy sytuacje, w których brak atrybutów ARIA prowadzi do niespełnienia kryteriów sukcesu WCAG, a tym samym – do naruszenia przepisów.

Przykład 1: Rozwijane menu (Hamburger menu)

Współczesne strony mobilne opierają się na przyciskach otwierających nawigację. Wizualnie zmiana jest oczywista – menu się wysuwa. Dla osoby niewidomej korzystającej z czytnika ekranu (Screen Reader), sam przycisk bez odpowiednich atrybutów jest tylko elementem, który można „kliknąć”.

Problem prawny (WCAG 4.1.2 Name, Role, Value): Jeśli użytkownik nie otrzymuje informacji zwrotnej, czy menu jest w danym momencie otwarte, czy zamknięte, system jest niedostępny.
Rozwiązanie ARIA: Zastosowanie atrybutu aria-expanded="true/false". Bez tego technicznego dodatku, strona nie spełnia kryterium 4.1.2, co czyni ją niezgodną z wymogami ustawy.

Przykład 2: Formularze i walidacja błędów w czasie rzeczywistym

Wyobraźmy sobie formularz rejestracji, który dynamicznie sprawdza poprawność wpisanego e-maila. Gdy użytkownik popełni błąd, na ekranie pojawia się czerwony komunikat „Niepoprawny format adresu”.

Problem prawny (WCAG 3.3.1 Identyfikacja błędu): Jeśli komunikat o błędzie pojawi się tylko wizualnie, osoba niewidoma o nim nie wie i próbuje wysłać formularz, co kończy się frustracją.
Rozwiązanie ARIA: Użycie regionów aria-live lub atrybutu aria-invalid="true" wraz z aria-describedby. Pozwala to czytnikowi ekranu natychmiast zaanonsować błąd. Brak tego mechanizmu w dynamicznych formularzach to prosta droga do audytu kończącego się wynikiem negatywnym.

Przykład 3: Zakładki (tabs)

Popularny element interfejsu, gdzie kliknięcie w nagłówek zmienia treść poniżej bez przeładowania strony. W czystym HTML to często tylko lista linków i divy.

Problem prawny (WCAG 1.3.1 Informacje i relacje): Bez odpowiedniej semantyki użytkownik technologii asystującej nie rozumie relacji między zakładką a jej zawartością, ani tego, która zakładka jest aktywna.
Rozwiązanie ARIA: Zastosowanie ról role="tablist", role="tab", role="tabpanel" oraz stanu aria-selected. Jest to jedyny sposób, aby ten konkretny wzorzec projektowy był zgodny z prawem (WCAG).

Podsumowanie

Reasumując, standard ARIA sam w sobie jest rekomendacją techniczną. Jednakże, ze względu na ścisłe powiązanie z prawnie wymaganymi standardami dostępności (WCAG), jego stosowanie stało się praktyczną koniecznością. Tworząc nowoczesne strony internetowe po 2024 roku, nie można spełnić obowiązujących wymogów prawnych bez znajomości i wdrożenia WAI-ARIA.