Litera i duch
W Polsce serwisy podmiotów publicznych muszą spełniać wymagania Ustawy z 4 kwietnia 2019 roku o dostępności cyfrowej. Załącznik do ustawy to lista 49 kryteriów WCAG 2.1 na poziomie AA.
Ta lista jest potrzebna. Bez niej ocena dostępności opierałaby się na intuicji, a projektant, programista, redaktor i audytor nie mieliby wspólnego języka. Dzięki niej możemy sprawdzić, czy kontrast jest wystarczający albo czy pola formularza mają etykiety.
Ale każde kryterium ocenia się zero-jedynkowo, a lista nie przypisuje im wag. Kryteria WCAG — to litera. Duchem prawa jest to, żeby każda osoba — i korzystająca z ekranu, i ta, która korzysta z czytnika; i ta, która używa myszy, i ta, która posługuje się wyłącznie klawiaturą, i ta, która komunikuje się za pomocą interfejsu głosowego — mogła znaleźć to, czego potrzebuje i osiągnąć cel, na jakim jej zależy.
Sto dwadzieścia błędów albo tylko jeden
Automat testujący może zwrócić 120 odstępstw: kontrast na ozdobnym separatorze, brak tekstu alternatywnego przy dekoracyjnej grafice, powtórzony identyfikator w kodzie. Żadnego z nich użytkownik nie zauważy: nie żadnym stopniu nie utrudnią mu nawigacji.
Może się też zdarzyć, że znaleziony zostanie tylko jeden błąd, z enigmatycznym opisem — a w praktyce będzie się on sprawiał, że użytkownik korzystający z klawiatury nie będzie mógł zapoznać się z repertuarem albo listą produktów.
W deklaracji dostępności oba te przypadki wpadają do kategorii „serwis częściowo zgodny”, bo kryteria WCAG są ilościowym opisem jakościowego problemu.
Jak z tego wybrnąć? Zdając się na doświadczenie człowieka: badanie z udziałem osób z niepełnosprawnościami albo ocenę ekspercką kogoś, kto nada odstępstwom wagi i zamieni je w plan naprawy.
Dostępność jest procesem
Ustawa wymaga, żeby deklarację dostępności przeglądać i aktualizować co roku. Oto litera prawa: „zaktualizować dokument”.
Duch mówi coś ważniejszego: serwis żyje. Redakcja publikuje pliki PDF bez struktury. Ktoś umieszcza podkast bez transkrypcji. Zewnętrzny system biletowy zmienia formularz. Aktualizacja biblioteki psuje obsługę klawiaturą w menu. Każda z tych zmian może pogorszyć dostępność w warstwie, której redakcja po prostu nie dostrzega.
Po to właśnie są okresowe przeglądy — żeby przypominać, że dostępność cyfrowa wymaga stałej uwagi. Nie jest cechą produktu, ale nawykiem organizacyjnym: ktoś sprawdza dokument przed publikacją, ktoś pamięta o opisach alternatywnych, a ktoś testuje nawigację klawiaturą po aktualizacji.
Celem nie jest „bezbłędna strona WWW”, tylko organizacja, która zauważa bariery i wie, jak je usuwać.
Najważniejsze wnioski
- Standard WCAG tworzy techniczną i prawną podstawę dostępności cyfrowej. Bez niego trudno byłoby obiektywnie ocenić jakość serwisu.
- Sama liczba odstępstw od standardu nie opisuje jednak jakości serwisu. Znaczenie ma to, w jakim miejscu bariera występuje, kogo dotyczy i jaki proces blokuje.
- Badania z użytkownikami nie zastępują audytu zgodności. Audyt nie zastępuje badań z użytkownikami.
- Dostępność nie jest jednorazowym zadaniem — ale ciągłym procesem.
FAQ
Czy zgodność z WCAG oznacza, że serwis jest wygodny dla każdej osoby?
Nie. WCAG znacząco ogranicza liczbę barier, ale nie gwarantuje, że każdy użytkownik uzna produkt za prosty i wygodny. Na rzeczywiste doświadczenie wpływają także architektura informacji, język, złożoność procesów oraz indywidualne kompetencje użytkownika.
Czy audyt WCAG wystarczy do oceny dostępności?
Nie. Audyt WCAG mierzy zgodność z kryteriami WCAG, nie całe doświadczenie dostępności. To dwie bliskie, ale nie tożsame rzeczy.
Audyt wskazuje odstępstwa od standardu, lecz sama ich liczba nie mówi, jak dostępny jest serwis. Kilkadziesiąt drobnych uwag może mieć mniejsze znaczenie niż jedna bariera blokująca kluczowy proces. Dlatego wyniki audytu wymagają interpretacji: ustalenia, które problemy rzeczywiście utrudniają korzystanie z serwisu i które należy usunąć w pierwszej kolejności.
Dlaczego dostępność trzeba sprawdzać okresowo?
Nawet dobrze przygotowany serwis zmienia się po wdrożeniu. Nowy dokument, film, formularz zewnętrznego dostawcy albo aktualizacja kodu mogą stworzyć bariery, których wcześniej nie było. Okresowy przegląd służy więc nie tylko aktualizacji deklaracji, ale przede wszystkim wychwytywaniu problemów powstających podczas codziennego rozwoju serwisu.