Wpadki i wypadki #21: Europejski akt o dostępności

Egzystując choćby na obrzeżach dostępnościowego świata, nie da się nie natknąć na informacje o Europejskim akcie o dostępności (European Accessibility Act, EAA). Wypada więc i tutaj o nim wspomnieć słów kilka.

Tak szczerze to nie planowałem tego artykułu, ale ostatecznie doszedłem do wniosku, że coś wypadałoby w tym temacie powiedzieć. Dlatego od razu zaznaczę, że nie jestem prawnikiem. Zajmuję się dostępnością od strony technicznej, więc jeśli masz wątpliwości co do interpretacji samego EAA lub tego, czy to prawo Cię obowiązuje, polecam skonsultować się z prawnikiem.

Czym jest Europejski akt o dostępności?

Zacznijmy od podstawowej kwestii – czym tak naprawdę jest EAA? Jak sama nazwa sugeruje, jest to unijne prawo dotyczące dostępności. Jego głównym celem jest rozszerzenie obowiązku dostarczania dostępnych produktów i usług na prywatne przedsiębiorstwa. Artykuł 2 aktu wymienia dokładnie, kto jest zobowiązany zapewnić dostępność swoim produktom i usługom. Są to m.in.:

• systemy sprzętu komputerowego ogólnego przeznaczenia i systemy operacyjne do nich,
• niektóre rodzaje terminali samoobsługowych, np. bankomaty, biletomaty, terminale płatnicze,
• czytniki e-booków,
• usługi łączności elektronicznej,
• platformy oferujące treści audiowizualne, takie jak YouTube czy serwisy streamingowe,
• usługi cyfrowe związane z transportem, np. sprzedaż biletów autobusowych online,
• bankowość elektroniczna,
• e-commerce.

Przepisy nie obowiązują mikroprzedsiębiorców (firm zatrudniających do 10 osób i mających obrót roczny do 2 milionów euro).

Jak całkiem spora część unijnego prawa, dyrektywa ta jest następnie wdrażana w poszczególnych krajach w postaci ustaw. W Polsce mamy Polski Akt o Dostępności. W innych krajach również istnieją odpowiadające mu akty prawne. I choć wszystkie z nich są zgodne z EAA, to jednak istnieją pewne subtelne różnice, np. niektóre kraje mogą nakładać dodatkowe obowiązki.

Z EAA związane są dwa standardy:

1. EN 301 549 – standard określający dokładne techniczne wymagania dotyczące dostępności produktów cyfrowych,
2. EN 17161 – standard opisujący podejście Design for All (Projektowanie dla wszystkich).

Choć trzymanie się ich nie jest wymagane, to stanowi prawdopodobnie najlepszy sposób na spełnienie wymagań EAA. Co więcej, zarówno EAA, jak i EN 301 549 odnoszą się bezpośrednio do standardu WCAG. Innymi słowy: jeśli nasza strona jest zgodna z WCAG w wersji 2.1 lub wyższej, to prawdopodobnie jest też (w pełni lub częściowo) zgodna z wymogami narzucanymi przez EAA. Natomiast EN 17161 pomaga we wprowadzeniu w organizacji kultury dostępności.

No i równie istotna kwestia: zgodność jest wymagana od 28 czerwca 2025. Mówiąc inaczej: od tego dnia można dostać karę za brak dostępnej strony WWW.

Więcej o samym EAA można przeczytać m.in. na stronie TPGI oraz na blogu Martijna Holsa. Polski Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych (PFRON) również przygotował wytyczne dostępności.

Jak w prosty sposób zapewnić dostępność?

Podaję najprostszy sposób:

1. Przeprowadzenie dokładnego audytu dostępności.
2. Podzielenie błędów na krytyczne i te, które mogą poczekać.
3. Poprawienie błędów.
4. Upewnienie się, że kolejne błędy nie będą się pojawiać.

I tak, to jest najprostszy sposób na zapewnienie dostępności. Rozwiązania, które proponują prostsze sposoby, zahaczają już o magię i polecam podchodzić do nich z ostrożnością. W końcu magia nie jest prawdziwa.

Przyjrzyjmy się pokrótce każdemu punktowi z powyższej listy.

Przeprowadzenie dokładnego audytu dostępności

Istnieją dwie możliwości. Pierwszą jest zlecenie audytu osobie profesjonalnie zajmującej się audytami dostępności. Drugą jest próba przeprowadzenia takiego samemu. Tutaj z pomocą przychodzi W3C, które opracowało metodykę przeprowadzania audytów dostępnośći (WCAG-EM). Z metodyką połączone jest także narzędzie do generowania raportów z audytu. Jeśli nie ma się jeszcze opracowanej własnej metodyki audytu, to WCAG-EM jest bardzo dobrym punktem wyjścia.

Warto także wspomnieć o VPAT. To ogólnie uznawany format dokumentowania dostępności danego produktu. Może on (wraz z bardziej szczegółowym formatem ACR) posłużyć do stworzenia deklaracji dostępności.

Podzielenie błędów na krytyczne i te, które mogą poczekać

Taki podział błędów pozwoli skupić się w pierwszej kolejności na tych najpoważniejszych, zostawiając te mniej poważne na później. Jednak warto pochylić się nad tym, czym są krytyczne błędy dostępności. Otóż są to takie, które uniemożliwiają korzystanie ze strony określonej grupie osób z niepełnosprawnościami. Przykładem takiego błędu może być przycisk „Kup teraz”, ktory w kodzie byłby obrazkiem bez atrybutu [alt]:

<img src="button.svg">

Taki przycisk byłby niemożliwy do obsłużenia przez osoby niewidome, korzystające z czytnika ekranowego. Nie dość, że zamiast etykiety „Kup teraz” usłyszałyby adres obrazka, to dodatkowo nie wiedziałyby, że ten obrazek jest przyciskiem, ani że można go kliknąć. Również osoby używające wyłącznie klawiatury miałyby problem z jego obsługą, bo nie da się przenieść do niego focusu. Tym samym tego typu przycisk wyklucza co najmniej dwie grupy osób – zatem należy to bezwzględnie poprawić i to najlepiej jak najszybciej.

Poprawienie błędów

W poprawianiu błędów bardzo pomocny jest standard WCAG. Jeśli przyjrzymy się dowolnemu kryterium sukcesu, np. 1.1.1. Treść nietekstowa, to zauważymy, że towarzyszą mu dwa linki: do dokładnego objaśnienia oraz do listy technik pozwalająćych spełnić to kryterium. Objaśnienie tłumaczy dokładnie, w jaki sposób sprawdzić zgodność z danym kryterium oraz czemu w ogóle zostało ono dodane do standardu. Natomiast lista technik zawiera proponowane rozwiązania problemu, np. dodanie atrybutu [alt]. Technik zazwyczaj jest na tyle dużo, że rozwiązują często nawet mocno skomplikowane sytuacje. Zatem jeśli zatniemy się przy naprawianiu jakiegoś błędu, warto zerknąć do samego standardu – istnieje spora szansa, że rozwiąże nasz problem!

Upewnienie się, że kolejne błędy nie będą się pojawiać

Mamy w końcu dostępną stronę – super! Tylko że strony się zmieniają. Zwykłe dodanie przycisku do dzielenia się stroną na nowej platformie społecznościowej może wystarczyć, żeby pojawił się błąd dostępności. I to z wielu różnych powodów: przycisk może mieć niepoprawną etykietę, może mieć zbyt niski kontrast, może niepoprawnie obsługiwać focus… Każda taka zmiana musi zostać sprawdzona pod kątem dostępności.

Takim absolutnym minimum powinny być testy automatyczne, najlepiej będące częścią procesów CI/CD. Jeśli coś wykryją, to znak, że w którymś miejscu pojawił się nam jakiś dostępnościowy babol. Takie testy jednak wykryją tylko część problemów. Część rzeczy musi zostać przetestowana ręcznie. A w idealnym świecie – również z osobami z niepełnosprawnościami. Niemniej podejrzewam, że w wielu przypadkach całość testów zostanie ograniczona do tych automatycznych. Być może od czasu do na produkt spojrzy firmowa osoba od dostępności. Ale takie rozwiązanie jest zwyczajnie nieoptymalne. Taka osoba musiałaby tak naprawdę testować każdą zmianę widoczną dla osób używających strony. Bo każda z nich mogłaby popsuć dostępność. A popsuta dostępność to potencjalne narażenie się na kary finansowe za niedostępność produktu. Innymi słowy: nasza osoba od dostępności staje się kluczowym elementem całego procesu aktualizacji strony WWW i bez jej zgody strona nie może trafić na produkcję. Więc byłoby miło, gdyby nasza osoba od dostępności nie wpadła pod autobus. O wiele bezpieczniej jest zainwestować w stworzenie faktycznej kultury dostępności. Dzięki temu wiedza o dostępności nie będzie ograniczona do jednej osoby, ale zostanie „rozłożona” na wszystkie techniczne osoby, biorące udział w tworzeniu strony internetowej. Tym sposobem absolutnie każdy będzie w stanie zidentyfikować potencjalne błędy dostępności i zaradzić im, zanim te trafią na produkcję.

To jest też dobry moment na zadanie sobie jednego, bardzo ważnego pytania: po co dbamy o dostępność? „Bo prawo tak każe” jest sensowną odpowiedzią. Ale dla mnie jest tak naprawdę wstępem do czegoś więcej. Kiedy się już egzystuje w kulturze dostępności, ona sama staje się naturalna. I dzięki temu przestaje być obowiązkiem, a staje się pełnoprawnym elementem procesu developmentu. Czymś tak zwyczajnym i codziennym, że nawet się tego nie dostrzega. Czego życzę każdej organizacji.