Ewaluacja dostępności cyfrowej

Ewaluacja dostępności cyfrowej (audyt dostępności) to proces oceny, na ile strona internetowa, aplikacja mobilna lub dokument spełniają uznane standardy dostępności (np. WCAG). Celem takiej oceny jest zidentyfikowanie barier, które mogą utrudniać korzystanie z produktu cyfrowego osobom z różnymi niepełnosprawnościami, oraz wskazanie sposobów poprawy tych elementów. Proces ewaluacji zwykle obejmuje kombinację testów automatycznych i manualnych, przeglądu wizualnego interfejsu, analizy kodu źródłowego oraz – jeśli to możliwe – testów z użyciem technologii asystujących (np. czytników ekranu) lub nawet z udziałem użytkowników z niepełnosprawnościami. Poniżej opisujemy, jak taki audyt przebiega w odniesieniu do różnych rodzajów produktów cyfrowych.

Audyt dostępności stron internetowych

Audyt strony internetowej rozpoczyna się zwykle od przeglądu automatycznego – za pomocą specjalistycznych narzędzi skanujących kod strony pod kątem typowych problemów. Narzędzia te potrafią szybko wykryć wiele oczywistych błędów, takich jak brak atrybutów ALT przy obrazkach, niska kontrastowość tekstu, nieprawidłowa struktura nagłówków czy błędy w składni HTML. Przykładowo, skanery pokroju axe DevTools czy WAVE zaznaczają wykryte problemy bezpośrednio na widoku strony, opisując ich naturę[9]. Warto jednak pamiętać, że automaty sprawdzające nie wykryją wszystkiego – testy automatyczne obejmują tylko wybrane aspekty dostępności. Potrafią np. stwierdzić, czy obraz ma dodany tekst alternatywny w kodzie, ale nie ocenią, czy ten opis jest adekwatny do zawartości grafiki[10]. Dlatego po wstępnym skanowaniu należy przeprowadzić ręczną weryfikację strony.

Podczas manualnego audytu ekspert ds. dostępności sprawdza kluczowe elementy interfejsu i interakcji na stronie, m.in.:

Obrazy i multimedia – czy wszystkie istotne grafiki mają opis alternatywny (atrybut alt), a multimedia (wideo, audio) są opatrzone napisami lub transkrypcją.
Struktura treści – czy nagłówki są używane zgodnie z hierarchią (H1, H2 itd.), listy i tabele są odpowiednio zdefiniowane, a układ strony jest spójny i czytelny semantycznie.
Nawigacja i klawiatura – czy całą stronę można obsłużyć za pomocą klawiatury (każdy interaktywny element jest dostępny fokusem, np. przez klawisz Tab), czy kolejność przemieszczania się fokusu jest logiczna i zgodna z wizualnym układem oraz czy fokus jest dobrze widoczny[11]. To szczególnie ważne dla osób niemogących korzystać z myszy.
Formularze i interakcje – czy pola formularzy są poprawnie oznaczone etykietami (label), czy użytkownik jest informowany o błędach walidacji w zrozumiały sposób, czy elementy interaktywne (przyciski, linki) mają jednoznaczne opisy.
Kolory i kontrast – czy tekst posiada wystarczający kontrast względem tła (zgodnie z wymogami WCAG), czy informacje nie są przekazywane wyłącznie za pomocą koloru (co byłoby niedostępne dla osób niewidomych czy daltonistów).

Audytor analizuje także kod strony pod kątem poprawności standardu (np. HTML5, ARIA) – bo dostępność często wiąże się z właściwą semantyką kodu. Podczas oceny weryfikuje się np., czy strukturę nagłówków odzwierciedla kod HTML, czy pola formularzy mają odpowiednie atrybuty (name, role, aria-label itp.), oraz czy skrypty nie zaburzają działania technologii asystujących. Wykonuje się również testy technologii wspomagających: typowo audytor uruchamia stronę przy pomocy czytnika ekranu (np. NVDA lub JAWS w środowisku Windows) i przechodzi kluczowe elementy serwisu, nasłuchując czy komunikaty głosowe są sensowne. Taka symulacja doświadczenia osoby niewidomej ujawnia problemy, których gołym okiem nie widać – np. niewidoczne, a nieopisane elementy interfejsu, nieprzekazywanie informacji o otwarciu nowego okna, złe oznaczenia przycisków ikonowych itp.

Raport z audytu strony zawiera następnie opis wszystkich zidentyfikowanych niezgodności wraz z odniesieniem do konkretnych wymagań standardu dostępności (np. danego punktu WCAG) potwierdzających, że dana sytuacja stanowi błąd dostępności[12]. Do każdego problemu powinny być dodane rekomendacje naprawy, czyli wskazówki jak go usunąć (np. dodanie opisu do obrazka, zwiększenie kontrastu tekstu, poprawa kolejności fokusu w menu itp.). Specjalista określa też znaczenie każdego błędu – czyli na ile wpływa on na możliwość korzystania ze strony (priorytet wysoki, średni, niski) – aby ułatwić zleceniodawcy ustalenie kolejności wdrażania poprawek.

Audyt dostępności aplikacji mobilnych

Proces ewaluacji aplikacji mobilnej pod kątem dostępności przebiega podobnie, choć uwzględnia specyfikę urządzeń mobilnych i systemów operacyjnych (Android, iOS). Na początku można użyć automatycznych skanerów dostępności dla aplikacji. Przykładem jest Google Accessibility Scanner dla Androida – aplikacja od Google, która analizuje interfejs uruchomionej aplikacji i wykrywa typowe problemy na podstawie zrzutów ekranu[13]. Wskazuje ona m.in. elementy o zbyt niskim kontraście między tekstem a tłem, zbyt małe przyciski i kontrolki dotykowe, brak etykiet tekstowych przy ikonach czy nieczytelne podpisy linków[14]. Podobnie Accessibility Insights for Android (narzędzie od Microsoft) pozwala automatycznie sprawdzić aplikację pod kątem brakujących opisów elementów, błędów kontrastu czy minimalnego rozmiaru pól dotykowych[15]. Dla ekosystemu iOS odpowiednikiem jest Accessibility Inspector od Apple, dostępny w Xcode – umożliwia on m.in. badanie kontrastu i symulowanie działania aplikacji z punktu widzenia dostępności[16]. Automatyczne testy aplikacji mają jednak ograniczony zakres – np. nie obejmują pełnej analizy procesów w aplikacji ani nie odpowiedzą wprost, czy aplikacja spełnia wszystkie wymagania prawne dostępności[17]. W przypadku iOS dodatkowym wyzwaniem bywa brak dostępu do skompilowanego kodu (aplikacje na iPhone są szyfrowane), co utrudnia pełne skanowanie automatyczne[18].

Z tego względu kluczowa jest ręczna ewaluacja mobilnej aplikacji przez eksperta. Obejmuje ona sprawdzenie, czy aplikacja jest poprawnie obsługiwana za pomocą systemowych czytników ekranu – VoiceOver na iOS oraz TalkBack na Androidzie. Audytor uruchamia aplikację z włączonym czytnikiem i nawigując po elementach (gestami na ekranie lub podłączoną klawiaturą), nasłuchuje komunikatów. Sprawdza, czy wszystkie przyciski, ikony i pola są opisane w sposób zrozumiały (np. przycisk z ikoną lupy powinien być odczytywany jako „Szukaj”, nie „przycisk bez etykiety”), czy fokus przeskakuje w logicznej kolejności między elementami oraz czy nie ma tzw. „pułapek klawiatury” (elementów, z których nie da się wyjść za pomocą nawigacji klawiszowej)[19]. Weryfikowane są również inne aspekty dostępności mobilnej, takie jak: reakcja aplikacji na zmianę rozmiaru tekstu w ustawieniach systemowych (czy interfejs skaluje się i pozostaje czytelny dla osób słabowidzących), działanie trybu wysokiego kontrastu lub odwróconych kolorów, poprawność komunikatów VoiceOver/TalkBack podczas wydarzeń (np. przy przejściu do nowego ekranu).

Specyficznym obszarem oceny jest gesty i nawigacja dotykowa – audytor sprawdza, czy aplikacja nie wymaga do obsługi skomplikowanych gestów dotykowych (np. przeciągania dwoma palcami jednocześnie), które mogą być trudne dla osób o ograniczonej sprawności rąk. Jeśli takie gesty istnieją, powinny mieć alternatywę prostszą do wykonania[20]. Kontrolowane jest również, czy obszar dotykowy przycisków i linków jest wystarczająco duży (wg WCAG 2.2 co najmniej ~24×24 px dla celów dotykowych), by osoby o ograniczonej precyzji ruchów mogły w nie trafić[20].

Końcowym efektem audytu aplikacji mobilnej jest raport analogiczny do raportu ze strony WWW – zawiera on listę znalezionych problemów dostępności (np. niedziałające poprawnie elementy dla VoiceOver, nieopisane ikony, słaby kontrast w określonych widokach itp.) wraz z zaleceniami zmian w kodzie aplikacji lub w projekcie interfejsu. Warto zaznaczyć, że w przypadku aplikacji mobilnych czasem trudniej jest automatycznie testować całość (ze względu na środowisko natywne), więc ręczna ocena przez eksperta ma tu szczególne znaczenie[17].

Audyt dostępności dokumentów cyfrowych (PDF)

Trzecim istotnym obszarem ewaluacji jest dostępność dokumentów cyfrowych, zwłaszcza formatów takich jak PDF, DOC/DOCX (Word), PPT (PowerPoint) czy innych plików udostępnianych do pobrania. Dokumenty (raporty, formularze, e-booki, skany) również podlegają wymaganiom dostępności – szczególnie jeśli są publikowane przez podmioty publiczne online, muszą być dostępne cyfrowo na równi ze stronami[5]. Audyt dokumentów polega na sprawdzeniu, czy ich zawartość i struktura są przygotowane zgodnie z wytycznymi dostępności.

W przypadku plików edytowalnych (Word, PowerPoint) warto zacząć od wbudowanych narzędzi sprawdzających. Pakiet Microsoft Office posiada funkcję Accessibility Checker (w polskiej wersji: Sprawdź dostępność), dostępną np. na karcie Recenzja. Po uruchomieniu przeprowadza ona analizę dokumentu i wskazuje typowe uchybienia: brakujące opisy obrazów, nieprawidłową strukturę nagłówków, zbyt mały rozmiar czcionki czy tekst o zbyt niskim kontraście[21]. Podobnie program Adobe Acrobat Pro oferuje narzędzie Acrobat Accessibility Checker, które skanuje plik PDF pod kątem zgodności ze standardami WCAG oraz PDF/UA (międzynarodowy standard dostępności PDF)[22]. Wynik takiego skanu to raport listujący wykryte problemy wraz z podpowiedziami. Dodatkowo istnieją dedykowane aplikacje, jak PDF Accessibility Checker (PAC) – bezpłatne narzędzie, które jednym kliknięciem sprawdza plik PDF w odniesieniu do wielu kryteriów standardu PDF/UA i wytycznych WCAG[23]. PAC jest szeroko stosowanym przez specjalistów narzędziem do weryfikacji technicznej PDF i automatycznie wychwytuje większość problemów, m.in. brak tagów struktury, nieopisane obrazy czy nieosadzone czcionki.

Analiza automatyczna to jednak nie wszystko. Równie ważne jest manualne sprawdzenie dokumentu, zwłaszcza pod kątem poprawności przekazu treści dla użytkownika korzystającego z technologii wspomagającej. Kilka kluczowych aspektów, na które należy zwrócić uwagę, to[24][25]:

Struktura nagłówków i spis treści – czy dokument ma zdefiniowane tytuły i nagłówki sekcji, odpowiednio oznaczone stylami (Heading 1, Heading 2 itd.), co umożliwia nawigację po dokumencie. Hierarchia nagłówków powinna być logiczna i spójna, aby np. osoba niewidoma mogła szybciej “przeglądać” dokument skacząc między nagłówkami.
Opisy alternatywne obrazów – wszystkie grafiki, wykresy, zdjęcia muszą mieć tekst alternatywny (tzw. alt text) opisujący ich zawartość lub funkcję. Czytnik ekranu odczyta taki opis, pozwalając zrozumieć niewidomemu użytkownikowi, co przedstawia obraz[26].
Tabele danych – tabele powinny być zbudowane w prosty, uporządkowany sposób. Należy sprawdzić, czy mają prawidłowo oznaczone nagłówki kolumn/wierszy (tytuły kolumn zaznaczone jako nagłówki tabeli). Unika się bardzo złożonych, zagnieżdżonych tabel, ponieważ mogą sprawiać trudności w odczycie maszynowym[25].
Linki i odnośniki – ich tekst powinien być zrozumiały poza kontekstem. Zamiast ogólnych sformułowań typu „kliknij tutaj”, zaleca się linki opisowe, np. „Pobierz formularz w PDF”. Użytkownik korzystający z czytnika często przegląda spis linków w dokumencie – opisowe linki pozwalają mu od razu zorientować się, dokąd prowadzą[27].
Czytelność tekstu – dokument powinien być czytelny wizualnie: odpowiednia wielkość i krój czcionki, odstępy między liniami, dobre kontrasty kolorystyczne tekstu w stosunku do tła[28]. Należy unikać drobnych, ozdobnych fontów i dbać, by np. tekst na kolorowym tle miał kontrast co najmniej 4.5:1 (dla normalnego tekstu, wg WCAG).

Ponadto audytor sprawdza tzw. kolejność odczytu dokumentu PDF – czyli czy zdefiniowana struktura tagów odpowiada logicznemu porządkowi treści. Czytniki ekranu odczytują PDFy w oparciu o strukturę tagów: ważne jest, by elementy były w poprawnej kolejności (najpierw tytuł, potem akapity, podpisy grafik itp.). Weryfikowane jest także, czy język dokumentu został zadeklarowany (aby syntezator mowy dobrał właściwą wymowę) oraz czy wszystkie interaktywne elementy (np. pola formularza w PDF) mają etykiety tekstowe.

Efektem audytu dokumentów jest raport wyszczególniający znalezione problemy (np. „brak tagu nagłówka dla tytułu dokumentu”, „obraz na str. 5 bez tekstu alternatywnego”, „zbyt niski kontrast tekstu w tabeli na str. 10”) wraz z zaleceniami, jak je poprawić. Dobre praktyki dokumentowania wyników omawiamy w dalszej części raportu.

Normy i wytyczne w dostępności cyfrowej (WCAG, EN 301 549)

Procesy oceny dostępności opierają się na uznanych standardach i wytycznych, które precyzują wymagania techniczne i funkcjonalne dla dostępnych treści cyfrowych. Najważniejszym z nich są Wytyczne dla dostępności treści internetowych WCAG (ang. Web Content Accessibility Guidelines). Aktualnie obowiązującą wersją jest WCAG 2.1 z 2018 roku, a w 2023 roku opublikowano także nową wersję WCAG 2.2[29][30]. WCAG to dokument opracowany przez konsorcjum W3C, zawierający zestaw mierzalnych kryteriów sukcesu – czyli konkretnych wymagań, jakie musi spełnić strona, aplikacja czy dokument, by uznać je za dostępne. Kryteria te podzielone są na trzy poziomy zgodności: A (podstawowy), AA (średni) i AAA (najwyższy). Poziom A obejmuje absolutne minimum niezbędne do tego, by pewna grupa osób z niepełnosprawnościami w ogóle mogła korzystać z treści (np. obecność napisów do nagrań wideo). Poziom AA jest szeroko uznawany za bazowy standard dostępności – spełnienie wszystkich kryteriów na tym poziomie zapewnia większości użytkowników z niepełnosprawnościami możliwość względnie komfortowego korzystania z serwisu[31][32]. Poziom AAA to najwyższy standard (np. dodatkowe udogodnienia dla specyficznych grup), jednak wymogi AAA są bardzo rygorystyczne i nie zawsze możliwe do zastosowania w każdej treści, dlatego zazwyczaj nie są obowiązkowe. W praktyce przepisy prawne i instytucje rekomendujące dostępność zwykle wymagają zgodności na poziomie co najmniej AA.

WCAG opiera się na czterech nadrzędnych zasadach określających filary dostępności: Postrzegalność, Funkcjonalność (Operowalność), Zrozumiałość i Solidność[33]. W skrócie oznacza to, że treść powinna być prezentowana tak, aby użytkownik mógł ją zauważyć różnymi zmysłami (np. tekst musi być możliwy do odczytania wzrokiem lub odsłuchania przez syntezator mowy – zasada Postrzegalności). Interfejs musi być funkcjonalny niezależnie od sposobu obsługi – tzn. wszelkie akcje wykonamy zarówno myszą, klawiaturą, gestami dotykowymi czy asystentem głosowym (zasada Operowalności)[34]. Treść i nawigacja muszą być zrozumiałe – czyli intuicyjne, przewidywalne w działaniu, napisane klarownym językiem (zasada Zrozumiałości). Wreszcie, rozwiązania techniczne muszą być solidne (kompatybilne) – poprawnie działające z różnym oprogramowaniem użytkowników, np. przeglądarkami, technologiami asystującymi, urządzeniami mobilnymi itp. (zasada Solidności/Robustness)[35]. Wszelkie szczegółowe wymagania WCAG (łącznie kilkadziesiąt kryteriów) są pogrupowane właśnie według tych czterech zasad.

WCAG 2.1 vs WCAG 2.2: Nowa wersja 2.2 nie zastępuje poprzedniej, lecz ją uzupełnia. WCAG 2.2 dodaje 9 nowych kryteriów sukcesu, zaprojektowanych głównie z myślą o ulepszeniu dostępności dla osób z niepełnosprawnością wzroku, trudnościami poznawczymi oraz motorycznymi, a także dla użytkowników urządzeń dotykowych[36]. Przykładowo, w WCAG 2.2 pojawił się wymóg zapewnienia, by fokusem klawiatury nie dało się zgubić na ekranie – element z fokusem musi zawsze być widoczny (co najmniej w połowie) na ekranie[37]. Wprowadzono kryterium minimalnego rozmiaru celów dotykowych – interaktywne przyciski/ikonki nie powinny być zbyt małe, by można było łatwo w nie trafić palcem (co najmniej 24×24 px)[20]. Kolejnym przykładem jest wymóg dostępniejszego uwierzytelniania – procedury logowania nie mogą opierać się wyłącznie na pamięci użytkownika czy przepisywaniu skomplikowanych kodów (CAPTCHA), powinny oferować prostsze metody, jak np. logowanie biometryczne lub jednorazowe linki[38]. Pojawiło się też kryterium, by często wykorzystywane elementy pomocy/kontaktu na stronie były rozmieszczone spójnie w stałych miejscach (to ułatwia nawigację osobom z problemami poznawczymi)[39]. Wszystkie te nowe wymogi poszerzają dotychczasowe standardy i warto je uwzględniać, choć – co istotne – obecnie większość przepisów (np. w UE) nadal formalnie odwołuje się do WCAG 2.1[30].

Drugim ważnym standardem jest EN 301 549, czyli Europejska Norma określająca wymagania dostępności dla produktów i usług ICT (Information and Communication Technology). EN 301 549 została opracowana przez europejskie organizacje normalizacyjne (CEN/CENELEC i ETSI) i jest zharmonizowanym standardem używanym do oceny zgodności z unijnymi przepisami dotyczącymi dostępności cyfrowej[40]. W praktyce EN 301 549 integruje wytyczne WCAG z kilkoma dodatkowymi wymaganiami specyficznymi (np. dotyczącymi oprogramowania nienależącego do kategorii „treści internetowe” czy urządzeń hardware). Obecna wersja EN 301 549 (v3.2.1) w całości zaimplementowała WCAG 2.1 na poziomie AA jako podstawę wymagań dla stron internetowych, dokumentów elektronicznych i oprogramowania (np. aplikacji)[41]. Standard ten dzieli wymagania analogicznie jak WCAG: Rozdział 9 normy dotyczy stron internetowych, rozdział 10 dokumentów niewebowych, a rozdział 11 oprogramowania (w tym aplikacji mobilnych)[42] – we wszystkich tych kategoriach stosowane są te same kryteria dostępności, dostosowane do kontekstu (dokument vs aplikacja). EN 301 549 zachowuje także trzy poziomy zgodności (A, AA, AAA) i w ramach wymogów prawnych poziom AA jest wymagany jako obowiązkowy (np. dla sektorów publicznych)[43].

Norma EN 301 549 nabrała znaczenia wraz z wprowadzeniem przepisów unijnych: Dyrektywy UE 2016/2102 o dostępności stron internetowych i aplikacji mobilnych podmiotów publicznych (tzw. Dyrektywa Web Accessibility Directive, WAD) oraz European Accessibility Act (Dyrektywa 2019/882) dotyczącej dostępności szeregu usług i produktów sektora prywatnego. W przypadku pierwszej z nich, od 23 września 2020 wszystkie publiczne strony internetowe w UE muszą spełniać wymagania EN 301 549, a od 23 czerwca 2021 dotyczy to także aplikacji mobilnych sektora publicznego[44]. Każda instytucja publiczna musi również publikować deklarację dostępności, w której raportuje poziom zgodności swojego serwisu z EN 301 549, i aktualizować ją co najmniej raz na 3 lata[45]. Z kolei European Accessibility Act rozszerza obowiązek dostępności (od czerwca 2025) na wybrane branże komercyjne – m.in. usługi e-commerce, bankowość, e-booki, urządzenia telekomunikacyjne – i tam również przewiduje się stosowanie EN 301 549 jako miernika spełnienia wymogów[46]. W skrócie, EN 301 549 można traktować jako europejską wersję WCAG rozszerzoną o dodatkowe obszary (np. dostępność sprzętu, terminali płatniczych, dokumentów) – dla typowych treści cyfrowych (web, aplikacje, dokumenty) pokrywa się ona w dużej mierze z WCAG 2.1 AA[41].

Podsumowując, ewaluacja dostępności najczęściej oznacza sprawdzanie zgodności badanej strony/aplikacji/dokumentu z powyższymi wytycznymi: czy to bezpośrednio z WCAG 2.1/2.2, czy też z normą EN 301 549, która referuje te wytyczne[47]. Eksperci przygotowujący audyty często odnotowują przy każdym wykrytym problemie, który konkretnie punkt standardu został naruszony – dzięki temu wiadomo, jaki wymóg nie jest spełniony i dlaczego należy wprowadzić zmianę. Świadomość obowiązujących standardów jest ważna nie tylko dla audytorów, ale i dla twórców treści cyfrowych: stosowanie WCAG od początku procesu projektowania stron czy aplikacji pozwala uniknąć wielu błędów i docelowo tworzyć produkty przyjazne wszystkim użytkownikom.

Narzędzia do analizy dostępności cyfrowej

W procesie ewaluacji dostępności korzysta się z różnych narzędzi, które pomagają wykrywać problemy zarówno automatycznie, jak i podczas ręcznych testów. Poniżej przedstawiamy przegląd popularnych rozwiązań:

axe DevTools – rodzina narzędzi (w tym wtyczka do przeglądarki Chrome, biblioteka JS) oparta na silniku axe-core. Axe skanuje strony pod kątem błędów dostępności i generuje raport z odnalezionymi problemami. Jest cenione za dokładność i to, że dostarcza programistom szczegółowych informacji, gdzie w kodzie występuje błąd i jak go naprawić. Wiele innych narzędzi (np. Microsoft Accessibility Insights) korzysta w tle z silnika axe. Wtyczka axe DevTools umożliwia szybki audyt strony bezpośrednio w przeglądarce – jednym kliknięciem można zaznaczyć na stronie elementy, które naruszają wytyczne (np. brakujący opis obrazka, zły kontrast tekstu itp.)[9].
WAVE (Web Accessibility Evaluation Tool) – darmowe narzędzie od WebAIM dostępne zarówno online, jak i jako rozszerzenie do przeglądarki. WAVE analizuje wskazaną stronę i nakłada na nią kolorowe oznaczenia: ikonki błędów, ostrzeżeń i elementów poprawnych, wraz z krótkimi opisami[48]. Dzięki temu można wizualnie zobaczyć, gdzie np. brakuje tekstu alternatywnego (WAVE zaznaczy to ikoną błędu przy obrazie) albo że nagłówki są zagnieżdżone niehierarchicznie. Narzędzie to jest bardzo przydatne dla testerów nietechnicznych – pozwala zrozumieć problemy bez zagłębiania się w kod. WAVE wykrywa też elementy wymagające manualnej weryfikacji (oznacza je innym kolorem), co przypomina, że automatyczna diagnoza nie jest w 100% kompletna.
Lighthouse – zintegrowane narzędzie audytowe Google (dostępne w Chrome DevTools oraz jako samodzielny produkt). Lighthouse potrafi przeprowadzić audyt strony pod kątem wydajności, SEO oraz dostępności. Generuje wynik procentowy (tzw. Accessibility score) oraz listę wykrytych problemów. Ocenia m.in. struktury ARIA, kontrast, obecność opisów dla kontrolerów formularzy, poprawność użycia znaczników itp. Lighthouse jest łatwo dostępny (w Chrome wystarczy otworzyć narzędzia deweloperskie i uruchomić audyt) i daje ogólny pogląd na stan dostępności strony. Należy jednak pamiętać, że wynik Lighthouse opiera się na automatycznych testach – wysoki wynik (np. 90%) nie gwarantuje pełnej dostępności, a niski wynik wskazuje tylko, że jest dużo oczywistych błędów.
Microsoft Accessibility Checker – jak wspomniano wcześniej, to wbudowana funkcja w programach Office (Word, PowerPoint, Excel) służąca do sprawdzania dostępności tworzonych dokumentów. W kontekście narzędzi warto podkreślić, że podobne mechanizmy istnieją również w innych edytorach – np. LibreOffice posiada swój Accessibility Checker, a narzędzia do publikacji treści w CMS-ach często mają wtyczki oceniające dostępność wpisów (np. podpowiadają dodanie alt textu do obrazka). Accessibility Checker Office znajduje typowe problemy w dokumentach, takie jak brak tekstów alternatywnych, używanie trudnych dla czytelnika czcionek, pominięte nagłówki itp., i wyświetla listę zaleceń jak je poprawić[21]. Jest to nieocenione podczas przygotowywania dostępnych plików przed publikacją.
Adobe Acrobat – pełna kontrola dostępu – w programie Acrobat Pro dostępne jest profesjonalne narzędzie do sprawdzania PDF (“Full Check” w panelu Accessibility). Działa podobnie do PAC: skanuje dokument PDF i raportuje zgodność z wieloma punktami standardów WCAG/PDF/UA[22]. Po uruchomieniu wskazuje, które elementy “zaliczyły” test (np. wykryto tagi struktury, poprawne nagłówki), a które nie (np. obraz bez alt, tabela bez oznaczonych nagłówków). Co więcej, Acrobat pozwala od razu edytować pewne elementy dostępności (dodawać alt texty, zaznaczać język dokumentu, porządkować kolejność tagów) oraz ponownie zweryfikować plik.
PAC (PDF Accessibility Checker) 2021/2024 – niezależne, darmowe narzędzie dedykowane plikom PDF, rozwijane przez branżę dostępności (firma Access for All i później axes4). PAC jest ceniony przez ekspertów, ponieważ sprawdza automatycznie większość wymogów PDF/UA i WCAG dla PDF i generuje przejrzysty raport[23]. Poza listą błędów, PAC udostępnia także podgląd struktury dokumentu oraz symulację odczytu przez czytnik ekranu (tzw. Preview), co ułatwia manualną inspekcję struktury logicznej dokumentu[49]. W raporcie PAC wskazuje zarówno błędy krytyczne (np. brak tagów w ogóle), jak i ostrzeżenia (np. podejrzanie długi alternatywny opis, który warto zweryfikować). Aktualnie dostępna jest wersja PAC 2024, zastępująca PAC 2021, lecz podstawowa funkcjonalność pozostaje podobna.
Inne narzędzia i dodatki: Ekosystem narzędzi dostępności jest bogaty. Wspomniany Accessibility Insights od Microsoftu istnieje nie tylko dla Androida, ale też jako wtyczka do Chrome (dla stron WWW). IBM udostępnia Equal Access Accessibility Checker – rozszerzenie przeglądarki wykonujące audyt stron (podobne do axe). Dla testerów przydatne bywają też proste narzędzia, np. Color Contrast Analyzer (sprawdza kontrast kolorów na ekranie względem WCAG) czy HeadingsMap (wylistowuje strukturę nagłówków na stronie). Wiele błędów można też wykryć używając walidatorów kodu (np. W3C Validator) – choć nie są one narzędziami dostępności per se, to błędy w kodzie HTML mogą przekładać się na problemy z dostępnością.

W praktyce, audytorzy łączą różne narzędzia, aby uzyskać pełny obraz sytuacji. Testy automatyczne dają szybkie rezultaty – wskazują miejsca oczywistych uchybień od standardów i pozwalają z grubsza oszacować stan dostępności serwisu[50]. Co więcej, wiele z tych narzędzi można wykorzystywać do monitorowania ciągłego – np. uruchamiać cyklicznie skany i porównywać wyniki w czasie, aby śledzić postępy lub wychwycić pogorszenie dostępności[51]. Jednak żadne narzędzie nie zastąpi oczu (i uszu) ludzkiego testera, dlatego kombinacja automatycznej analizy i ręcznego testowania jest najlepszą praktyką.

Metody identyfikacji problemów i obszarów do poprawy

Aby rzetelnie zidentyfikować problemy z dostępnością i ustalić obszary wymagające poprawy, nie wystarczy jedna metoda badawcza. Konieczne jest zastosowanie wielu komplementarnych podejść, ponieważ różne metody ujawniają różne klasy błędów. Poniżej omawiamy najważniejsze z nich:

Testy automatyczne – omówione wcześniej narzędzia (axe, WAVE, Lighthouse etc.) stanowią pierwszy krok. Automaty potrafią od razu wychwycić dziesiątki usterek technicznych i dać ogólny obraz dostępności. Ich zalety to szybkość i szeroki zasięg – można jednym kliknięciem przeskanować nawet setki podstron dużego serwisu[52][50]. Dzięki temu łatwo zorientować się, które obszary serwisu są potencjalnie najbardziej zaniedbane (np. jeśli narzędzie wskaże, że wszystkie podstrony bloga mają błędne opisy obrazków, to wiemy, gdzie będzie dużo pracy). Testy automatyczne są też przydatne do regularnego monitoringu – np. można zaplanować ich wykonywanie co miesiąc i śledzić, czy liczba błędów spada wraz z wprowadzaniem poprawek[51]. Z drugiej strony wady są takie, że automaty sprawdzają tylko to, co da się łatwo zmierzyć algorytmem – wiele aspektów pozostaje poza ich zakresem[53]. Nie powiedzą nam, czy dany opis obrazka faktycznie ma sens, czy tekst na stronie jest prosty do zrozumienia, czy kolejność logiczna treści nie myli użytkownika – do tego potrzebna jest ocena ludzka. Dlatego testy automatyczne powinny być zawsze uzupełniane innymi metodami i nigdy nie należy poprzestawać wyłącznie na nich[54].
Audyt ekspercki (badanie manualne) – to najdokładniejsza metoda, polegająca na tym, że specjalista ds. dostępności cyfrowej systematycznie sprawdza produkt punkt po punkcie według listy kontrolnej wymagań[55]. Taki audyt (opisany szczegółowo w poprzednich sekcjach dla stron, aplikacji, dokumentów) jest kompleksowy: obejmuje dziesiątki różnych kryteriów i pozwala stwierdzić z dużą pewnością, czy strona/aplikacja spełnia oficjalne wytyczne. Tylko w ramach pełnego badania eksperckiego można formalnie orzec zgodność serwisu z ustawą o dostępności cyfrowej lub standardem WCAG[56][57]. Zaletą audytu eksperckiego jest też to, że oprócz samej listy błędów zawiera on sugestie rozwiązań i rekomendacje – ekspert dzięki swojemu doświadczeniu podpowiada, jak naprawić znalezione problemy, a czasem wskazuje też dobre praktyki na przyszłość[58]. Wadą pozostaje wyższy koszt i czasochłonność – zatrudnienie profesjonalisty i oczekiwanie na raport może trwać od kilkunastu dni do nawet kilku tygodni, zwłaszcza dla dużych serwisów[59]. Mimo to, dla krytycznych projektów lub spełnienia wymogów prawnych, audyt ekspercki jest niezastąpiony.
Proste testy samodzielne – nie zawsze dysponujemy budżetem czy czasem na pełen audyt, zwłaszcza na początku działań. Wtedy warto sięgnąć po podstawowe testy dostępności, które można wykonać własnoręcznie bez specjalistycznej wiedzy[60]. Przykłady takich testów to: sprawdzenie na stronie poruszania się klawiszem Tab (czy można dotrzeć do wszystkich linków i formularzy i czy fokus jest widoczny), próba odczytania strony czytnikiem ekranu (dostępnym choćby wbudowanym w system – Narrator w Windows, VoiceOver w macOS), zmiana rozmiaru czcionki i sprawdzenie, czy interfejs się skaluje, ocena “na oko” czy kolory tekstu nie zlewają się z tłem, próba obsługi elementów interaktywnych bez użycia myszy itd. Takie czynności nie wymagają dużej wiedzy, a pozwalają wychwycić oczywiste bariery – np. jeśli samemu nie da się wypełnić formularza bez użycia myszy, to znaczy, że użytkownik niewidomy również nie będzie mógł[61][11]. Zaletą prostych testów jest ich niska bariera wejścia – każdy webdeveloper czy redaktor strony może od czegoś takiego zacząć, by małymi krokami poprawiać dostępność zanim uda się zorganizować większy audyt[62]. Oczywiście minusem jest ograniczony zakres i brak formalnej oceny zgodności – samodzielnie znajdziemy tylko podstawowe błędy i nie mamy pewności, czy serwis spełnia np. wszystkie kryteria WCAG (jednak taka samodzielna analiza to dobry sposób, by w ogóle poznać te wytyczne w praktyce)[63].
Listy kontrolne i listy sprawdzające – dobrą pomocą dla samodzielnych testerów są gotowe checklisty dostępności. Dostępne są one w internecie (często jako wyciąg z WCAG w prostszej formie pytań). Polski rząd udostępnia np. obszerną Listę kontrolną do samodzielnego badania dostępności, składającą się z ~100 punktów do sprawdzenia[64]. Pytania na takiej liście brzmią np.: „Czy po powiększeniu tekstu o 200% zawartość jest nadal czytelna bez przewijania poziomego?” albo „Czy wszystkie przyciski mają nazwy informujące o ich funkcji?”. Korzystanie z listy kontrolnej systematyzuje test i pomaga nie zapomnieć o żadnym obszarze. Oczywiście wymaga to czasu oraz pewnej rzetelności w wykonywaniu poleceń z listy, ale w zamian pozwala zbliżyć się do szczegółowości audytu eksperckiego bez specjalistycznych narzędzi.
Testy z udziałem użytkowników z niepełnosprawnościami – to metoda często pomijana, a niezwykle cenna. Polega na zaproszeniu do testów osób z grup docelowych, np. użytkownika niewidomego, słabowidzącego, głuchego, osoby z dysfunkcją ruchową rąk itd., i poproszeniu ich o wykonanie pewnych zadań w serwisie lub aplikacji (np. znalezienie informacji, złożenie wniosku, zakup produktu). Tego typu badanie użyteczności ukazuje realne doświadczenia i pozwala zebrać bezpośrednie opinie od osób, które na co dzień polegają na dostępności cyfrowej[65]. Zaletą jest również to, że użytkownicy testują całe procesy end-to-end, a nie tylko pojedyncze strony – np. sprawdzamy, czy osoba niewidoma samodzielnie zdoła od początku do końca wypełnić i wysłać formularz online, a nie tylko czy pojedyncze pola formularza mają etykiety[66]. Takiego holistycznego podejścia nie zapewni nawet najlepszy audyt ekspercki, który z konieczności skupia się na elementach interfejsu w oderwaniu od kontekstu użytkownika. Co więcej, udział osób z niepełnosprawnościami uświadamia zespołowi projektowemu prawdziwą wartość dostępności – widać wtedy wyraźnie, że dostępność to nie tylko spełnianie punktów ustawy czy norm, ale realny wpływ na życie tych osób, dający im niezależność w dostępie do usług[67].

Oczywiście testy z użytkownikami nie zastępują audytu według kryteriów – często uczestnicy nie są świadomi wszystkich wytycznych WCAG, więc ich brak uwag na jakiś temat nie oznacza, że wszystko jest zgodne ze standardem[68]. Ponadto zgłaszane przez nich problemy mogą dotyczyć ogólnej użyteczności (UX) serwisu, niekoniecznie kwestii dostępności (np. mogą powiedzieć „nie rozumiem tej ikony”, co może wynikać ze słabego designu, a nie łamania standardu). Dlatego wyniki takiego badania wymagają interpretacji eksperta, który oddzieli problemy stricte dostępności od innych uwag[69]. Mimo to, połączenie audytu eksperckiego z testami z udziałem użytkowników daje najpełniejszy obraz – zarówno pod kątem formalnej zgodności z kryteriami, jak i praktycznej wygody korzystania.

Metody mieszane i ciągły cykl usprawnień – w realnych projektach często stosuje się kombinację powyższych metod. Można np. zlecić ekspertowi audyt kluczowych, najbardziej złożonych podstron aplikacji, a jednocześnie samodzielnie przetestować te prostsze, mniej krytyczne[70]. Można też rozpocząć od jednorazowego pełnego audytu, a następnie regularnie (np. co kwartał) przeprowadzać doraźne testy automatyczne i proste testy, by monitorować postępy i upewniać się, że nowe treści nie wprowadzają regresji[71]. Ważne jest, by nie poprzestawać na jednorazowym badaniu. Dostępność to proces ciągły – stan serwisu może się zmienić, gdy tylko ktoś doda nowy nieprzystosowany element (artykuł, wtyczkę, film)[72]. Dlatego kluczowe jest wpisanie dostępności w cykl życia projektu: każda nowa funkcjonalność powinna być projektowana z myślą o dostępności, a po wdrożeniu testowana choćby podstawowymi metodami. Takie podejście zapewni, że liczba problemów będzie z czasem maleć, a nie rosnąć.

Podsumowując, identyfikacja problemów dostępności wymaga różnorodnych metod i spojrzenia z wielu stron. Automatyzacja da nam szybko listę oczywistych błędów, audyt ekspercki wskaże wszystkie niezgodności ze standardami, a testy z prawdziwymi użytkownikami pokażą, jak serwis sprawdza się w praktyce. Kombinacja tych podejść pozwala nie tylko znaleźć problemy, ale też ustalić priorytety napraw (bo np. opinie użytkowników wskażą, które bariery najbardziej frustrują, a audyt wskaże, które wymagania formalne są niespełnione). Uzbrojeni w taką wiedzę, możemy przejść do etapu wdrażania poprawek.

Dokumentowanie wyników i monitorowanie postępów

Prawidłowe udokumentowanie wyników audytu jest kluczowe, aby zespół odpowiedzialny za serwis mógł efektywnie wprowadzić wymagane poprawki. Dobrze przygotowany raport z ewaluacji dostępności powinien być czytelny zarówno dla developerów, jak i dla menedżerów czy decydentów. Zaleca się, by raport zawierał m.in.[73]:

Informacje wstępne o audycie – co było badane (np. lista podstron, wersja aplikacji), kiedy przeprowadzono audyt i kto go wykonał, a także jakich narzędzi i metod użyto. Pozwala to zrozumieć zakres i kontekst badania.
Ogólna ocena dostępności – podsumowanie wyników w formie opisowej i/lub liczbowej. Może to być np. stwierdzenie poziomu zgodności (czy serwis spełnia kryteria w stopniu pełnym, częściowym, czy jest niezgodny) albo ocena procentowa/punktowa. Często audytor wskazuje, czy strona spełnia minimalne wymogi prawne (np. WCAG 2.1 AA) czy nie[74]. Taka syntetyczna ocena jest przydatna dla decydentów i do celów porównawczych (np. po wprowadzeniu poprawek można łatwo zobaczyć poprawę oceny).
Szczegółowa lista wykrytych problemów – zasadnicza część raportu. Każdy znaleziony błąd dostępności powinien być opisany: na czym polega problem (np. „Przycisk ‘Wyślij’ nie jest osiągalny z klawiatury”), dlaczego jest to problem (np. odniesienie do konkretnych wytycznych: „naruszenie WCAG 2.1 sukces kryterium 2.1.1 – brak obsługi przez klawiaturę”[12]) oraz lokalizacja (np. „formularz kontaktowy na stronie /kontakt”). Raport może grupować błędy kategoriami lub według stron, aby był bardziej przejrzysty. Ważne, by opisy były zrozumiałe także dla osób nietechnicznych – np. oprócz komunikatu „Błąd: brak atrybutu alt w znaczniku <img>” warto dodać „Obrazek nie ma opisu dla czytnika ekranu”.
Rekomendacje poprawy – dla każdego problemu audytor powinien zaproponować sposób naprawy. Czasem jest to oczywiste (np. „dodać opis alt opisujący grafikę”), czasem wymaga decyzji projektowej (np. „zaprojektować od nowa komponent menu, aby był dostępny z klawiatury – sugerowane rozwiązanie: …”). Dobre rekomendacje zawierają wskazówki implementacyjne, a nieraz fragment przykładowego kodu lub link do dokumentacji (np. do specyfikacji ARIA). Dzięki temu programiści dokładnie wiedzą, co zrobić, a cały zespół uczy się na przyszłość.
Priorytety i wagi problemów – nie wszystkie błędy są równie poważne; raport powinien wskazywać znaczenie każdego problemu[75]. Często stosuje się kategorie typu: krytyczny (uniemożliwia korzystanie osobom z danym ograniczeniem, np. brak kluczowej funkcji poza myszą), poważny, umiarkowany, drobny. Audytor może też zasugerować kolejność napraw – np. najpierw usunąć bariery blokujące dostęp głównych funkcjonalności, a na końcu zająć się drobnymi ułatwieniami. Taka informacja pomaga w planowaniu prac i alokacji zasobów.
Wyniki testów użytkowników (opcjonalnie) – jeśli przeprowadzano odrębne testy z udziałem osób z niepełnosprawnościami, raport może zawierać streszczenie ich uwag i obserwacji. Często dodaje się case study: np. „Użytkownik niewidomy próbował zarejestrować się w serwisie i utknął na kroku 3 – nie usłyszał komunikatu o błędzie formularza”. Tego typu informacje obrazują praktyczne skutki wykrytych błędów i wzmacniają argumentację, dlaczego należy je poprawić.

Ważnym elementem jest też dokumentacja metodyki audytu – czyli opis przyjętego podejścia, np. według jakiej listy kontrolnej pracowano, jak wybrano próbkę stron do badania, czy audyt obejmował również pliki multimedialne itp. Taka sekcja zwiększa wiarygodność raportu i ułatwia jego późniejsze wykorzystanie (np. przy kolejnym audycie inny audytor może powtórzyć te same założenia dla porównywalności wyników).

Po dostarczeniu raportu bardzo istotne jest monitorowanie postępów we wdrażaniu zaleceń. Sam audyt to dopiero początek drogi – prawdziwą korzyść osiągniemy dopiero eliminując wskazane bariery. Zaleca się, aby organizacja przygotowała na podstawie raportu plan działań naprawczych: listę zadań do wykonania, przypisane osoby odpowiedzialne i oszacowany czas realizacji. Dobre praktyki to np. włączenie tych zadań do istniejącego backlogu developerskiego (jeśli serwis jest rozwijany w metodyce agile) lub stworzenie osobnego projektu naprawczego. Ważne jest ustalenie priorytetów zgodnie z zaleceniami audytora – tak by najpierw naprawić rzeczy najbardziej wpływające na użytkowników i zgodność z prawem.

Monitorowanie postępów polega na śledzeniu, jak kolejne problemy są rozwiązywane i czy nie pojawiają się nowe. Można tu wykorzystać narzędzia automatyczne: np. po każdej większej aktualizacji strony uruchomić ponownie skan (axe, Lighthouse) i porównać wyniki z poprzednimi. Jeżeli firma posiada środowiska testowe, warto włączyć testy dostępności do cyklu QA (Quality Assurance) – np. każdy nowy moduł przed wdrożeniem poddajemy krótkiej weryfikacji czy działa z klawiaturą i czy teksty mają odpowiedni kontrast. Można też wyznaczyć koordynatora dostępności w zespole, który będzie odpowiadał za pilnowanie tych kwestii i raportowanie stanu dostępności kierownictwu.

Zgodnie z zasadą „co się mierzy, to się poprawia”, organizacje często ustalają metryki dostępności – np. % spełnionych kryteriów WCAG, liczba otwartych problemów dostępności w backlogu, średni wynik Lighthouse itp. Regularne raportowanie tych metryk (np. co kwartał) pozwala zobaczyć trend. Jeśli wskaźniki nie poprawiają się w czasie, to sygnał, że trzeba zwiększyć wysiłki (np. dodatkowe szkolenia zespołu, audyt uzupełniający, konsultacje eksperckie).

Należy pamiętać, że dostępność to stan dynamiczny. Raport z audytu pokazuje sytuację na moment badania, ale już kilka miesięcy później serwis może ulec zmianom. Wystarczy, że na dostępnej dotąd stronie pojawi się niedostępny załącznik PDF czy nowa, nieprzystosowana funkcja, a ogólny stan dostępności się pogorszy[72]. Dlatego zalecamy, by dostępność cyfrowa była procesem ciągłym – po pierwszej rundzie poprawek powinny następować kolejne testy i udoskonalenia. Dobrym nawykiem jest włączenie punktów kontrolnych do cyklicznych przeglądów projektu (np. accessibility review co sprint lub przed każdym wydaniem wersji).

Dokumentowanie postępów można realizować poprzez aktualizację wspomnianej deklaracji dostępności (dla sektora publicznego jest to wymóg – musi ona odzwierciedlać aktualny stan zgodności serwisu). Interno, zespół może prowadzić rejestr zmian dotyczących dostępności: np. w release notes nowej wersji oprogramowania wypunktować, jakie usprawnienia dostępności dodano. To nie tylko pomaga utrzymać kurs, ale też buduje pozytywną kulturę w organizacji – pokazuje, że dostępność jest traktowana poważnie i stale poprawiana.

Na zakończenie warto podkreślić: najważniejsze jest, co zrobimy z wynikami audytu. Samo przeprowadzenie badań i stworzenie raportu nie zapewni dostępności, jeśli rekomendacje pozostaną na papierze. Należy zadbać, by wyniki audytu przełożyły się na konkretne działania – poprawki w kodzie, zmiany w procedurach dodawania treści, dodatkowe szkolenia dla redaktorów. Trzeba też zagwarantować, że nie spoczniemy na laurach po jednej rundzie usprawnień. Dostępność cyfrowa to element jakości produktu, o który trzeba dbać tak samo jak o bezpieczeństwo czy wydajność – regularnie, konsekwentnie i z zaangażowaniem całego zespołu. Tylko wtedy osiągniemy trwałą poprawę i zapewnimy wszystkim użytkownikom równy dostęp do naszych cyfrowych zasobów[76][77].

[1] [2] [9] [11] [30] [31] [33] [34] [35] [48] [61] Testowanie dostępności cyfrowej aplikacji

https://techblog.ing.pl/blog/testowanie-dostepnosci-cyfrowej-aplikacji

[3] [4] [6] [7] Czym jest dostępność cyfrowa i dlaczego jest ważna?

https://nofluffjobs.com/pl/log/praca-w-it/dostepnosc-cyfrowa-co-to-jest/

[5] [21] [22] [24] [25] [26] [27] [28] Jak sprawdzić dostępność cyfrową dokumentu? – AT ONCE

https://atonce.pl/jak-sprawdzic-dostepnosc-cyfrowa-dokumentu/

[8] [20] [29] [32] [36] [37] [38] [39] Wytyczne dostępności cyfrowej stron internetowych czyli WCAG 2.2: co warto wiedzieć? | Mayko

https://mayko.pl/blog/wytyczne-dostepnosci-cyfrowej-stron-internetowych/

[10] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [74] [76] [77] Jakie są sposoby wyszukiwania błędów i badania dostępności cyfrowej – Dostępność cyfrowa – Portal Gov.pl

https://www.gov.pl/web/dostepnosc-cyfrowa/sposoby-wyszukiwania-bledow-i-badania-dostepnosci-cyfrowej

[12] [47] [73] [75] Czym jest audyt ekspercki dostępności cyfrowej i jak go zorganizować – Dostępność cyfrowa – Portal Gov.pl

https://www.gov.pl/web/dostepnosc-cyfrowa/czym-jest-audyt-ekspercki-dostepnosci-cyfrowej-i-jak-go-zorganizowac

[13] [14] [15] [16] [17] [18] [19] Jak automatycznie testować dostępność cyfrową aplikacji mobilnych – Dostępność cyfrowa – Portal Gov.pl

https://www.gov.pl/web/dostepnosc-cyfrowa/jak-automatycznie-testowac-dostepnosc-cyfrowa-aplikacji-mobilnych

[23] [49] PDF Accessibility Checker – PAC

https://pac.pdf-accessibility.org/en

[40] [41] [42] [43] [44] [45] [46] EN 301 549: European standard for digital accessibility | Deque

https://www.deque.com/en-301-549-compliance/