Testowanie dostępności cyfrowej stron internetowych i aplikacji mobilnych
Dostępność cyfrowa oznacza tworzenie stron internetowych i aplikacji mobilnych w taki sposób, aby mogły z nich korzystać osoby o różnych potrzebach – m.in. osoby z niepełnosprawnościami wzroku, słuchu czy ruchu. W wielu krajach (w tym w Polsce) jest to nie tylko dobra praktyka, ale wręcz wymóg prawny w sektorze publicznym. Kluczowym standardem są Wytyczne WCAG (Web Content Accessibility Guidelines), które opisują zasady tworzenia dostępnych treści internetowych. W Europie dodatkowo obowiązuje norma EN 301 549, ściśle powiązana z WCAG, określająca wymagania dostępności dla szeroko pojętych technologii informacyjno-komunikacyjnych. Przestrzeganie tych standardów przekłada się nie tylko na zgodność z prawem, ale także na lepsze doświadczenie użytkowników i szerszy zasięg odbiorców. Zanim jednak wdrożymy zasady dostępności, musimy umieć je przetestować w praktyce – zarówno automatycznie, jak i manualnie.
Standardy dostępności: WCAG i EN 301 549
WCAG 2.1/2.2. Web Content Accessibility Guidelines to międzynarodowy zbiór wytycznych opracowany przez W3C, opisujący jak zapewnić dostępność treści w internecie. Opiera się on na czterech nadrzędnych zasadach: postrzegalności, funkcjonalności, zrozumiałości i solidności (kompatybilności) – czyli m.in. prezentowaniu treści w alternatywny sposób (tekst alternatywny dla grafik, napisy do wideo), zapewnieniu obsługi interfejsu za pomocą klawiatury, klarowności nawigacji i języka oraz zgodności z technologiami asystującymi[1][2]. WCAG występuje w różnych wersjach (obecnie 2.1, a najnowsza 2.2) i poziomach zgodności (A, AA, AAA). W praktyce przepisy prawne wymagają zwykle poziomu WCAG 2.1 AA.
EN 301 549. To europejska norma dostępności, która opiera się na WCAG 2.1, gwarantując pełną zgodność z tymi wytycznymi[3]. Implementacja EN 301 549 oznacza więc automatyczne spełnienie kluczowych wymogów WCAG[4]. Norma EN 301 549 ma jednak szerszy zakres – dotyczy nie tylko stron WWW, lecz także aplikacji mobilnych, dokumentów elektronicznych, oprogramowania, a nawet sprzętu ICT[5]. W Unii Europejskiej norma ta jest powiązana z dyrektywą o dostępności i w Polsce znajduje odzwierciedlenie w Ustawie o dostępności cyfrowej z 2019 r. dla podmiotów publicznych. W praktyce oznacza to, że strony i aplikacje publiczne muszą być zgodne z WCAG 2.1 AA, a zgodność ta jest poświadczana m.in. poprzez deklarację dostępności. Testowanie dostępności służy właśnie sprawdzeniu, czy spełniamy te kryteria WCAG/EN 301 549 i gdzie wymagane są poprawki.
Metody testowania dostępności
Istnieją różne podejścia do oceny dostępności cyfrowej. Dwa podstawowe to testy automatyczne (wykonywane za pomocą programów/validatorów) oraz testy manualne (wykonywane przez człowieka – samodzielnie lub w formie eksperckiego audytu). Każde z tych podejść ma swoje narzędzia, zalety i ograniczenia, dlatego często stosuje się je łącznie dla najlepszych rezultatów[6]. Poniżej przedstawiamy praktyczne techniki testowania dostępności zarówno dla stron internetowych, jak i aplikacji mobilnych, z podziałem na metody automatyczne i manualne.
Testy automatyczne (walidatory dostępności)
Testy automatyczne polegają na wykorzystaniu specjalnych programów lub usług, które skanują kod strony/aplikacji i wychwytują znane problemy dostępności. To najszybszy sposób na wstępne sprawdzenie serwisu – wyniki otrzymujemy niemal od razu, często z czytelnym zaznaczeniem błędnych elementów[7]. Narzędzia automatyczne mogą działać jako wtyczki do przeglądarki, usługi online lub samodzielne aplikacje, a nawet jako skanery całych serwisów. W zależności od narzędzia różny może być zakres analizy (pojedyncza podstrona vs. wiele stron), rodzaj testów (sprawdzenie jednego aspektu jak kontrast albo wielu aspektów jednocześnie) czy szczegółowość raportu[8]. Poniżej omawiamy narzędzia automatyczne dla stron WWW i aplikacji mobilnych oraz ich możliwości.
Automatyczne testowanie stron internetowych – narzędzia i techniki
Dostępnych jest wiele walidatorów i skanerów automatycznych do stron WWW. Popularnym przykładem jest WAVE – narzędzie dostępne jako serwis online oraz jako rozszerzenie do przeglądarki[9]. WAVE analizuje pojedynczą stronę i wizualnie oznacza wykryte błędy bezpośrednio na widoku strony. Pokazuje m.in. brak tekstu alternatywnego w obrazkach, linki lub przyciski bez etykiety, problemy z kontrastem tekstu wobec tła czy nieprawidłową hierarchię nagłówków[10]. Każdy wykryty problem jest opisany i sklasyfikowany (np. jako błąd krytyczny lub ostrzeżenie), a narzędzie często podpowiada poprawne rozwiązanie. Podobnie działa Accessibility Insights for Web od Microsoft – dostępny jako wtyczka do Chrome/Edge lub samodzielna aplikacja na Windows[11]. Oprócz sprawdzania kodu HTML, narzędzie to pozwala też m.in. śledzić kolejność poruszania się po stronie za pomocą klawiatury czy przetestować wyświetlanie strony w skali szarości (bez kolorów)[12]. Inne często używane skanery to np. AXE DevTools (silnik Axe jest też wbudowany w wiele narzędzi deweloperskich), ARC Toolkit (wtyczka do Chrome od TPGi) – pozwalający sprawdzić kontrast, strukturę nagłówków, unikalność identyfikatorów itp.[13][14], czy też walidatory kodu pokroju W3C HTML Validator i CSS Validator (przydatne do wykrycia błędów w semantyce HTML/CSS)[15][16]. Istnieją również komercyjne rozwiązania zdolne przetestować cały serwis jednocześnie – przykładowo program SortSite potrafi automatycznie przeskanować wiele podstron pod kątem setek różnych kryteriów WCAG (oraz np. błędnych linków czy SEO)[17][18]. Większość narzędzi generuje raport wskazujący miejsca w kodzie wymagające poprawy, co bardzo ułatwia pracę programistom. Co ważne, część walidatorów jest dostępna bezpłatnie, więc podstawową analizę można przeprowadzić nie ponosząc kosztów (WAVE, Axe, itp.), podczas gdy za bardziej rozbudowane skanery (np. z audytem wielu stron jednocześnie) często trzeba zapłacić abonament lub licencję.
Automatyczne testowanie aplikacji mobilnych – narzędzia i techniki
W przypadku aplikacji mobilnych automatyczne testowanie dostępności nie jest tak rozpowszechnione jak dla stron WWW[19], jednak istnieją narzędzia, które mogą pomóc wyłapać typowe problemy. Wyróżnia się tu dwa podejścia: narzędzia analizujące interfejs na podstawie zrzutów ekranu oraz narzędzia sprawdzające kod aplikacji (np. poprzez biblioteki testowe)[20]. Przykładem pierwszego typu jest Google Accessibility Scanner (na Androida) – po zainstalowaniu na urządzeniu umożliwia zrobienie zrzutu ekranu z działającej aplikacji i automatyczną analizę elementów UI. Scanner wykrywa m.in. zbyt niski kontrast tekstu w aplikacji, zbyt małe przyciski lub elementy dotykowe, brak etykiet tekstowych przy ikonach/przyciskach (np. same ikonki bez opisu), powtarzalne lub nieopisowe etykiety linków, a także potencjalne problemy z nawigacją (np. nachodzące na siebie elementy interfejsu utrudniające kliknięcie)[21][22]. Wyniki prezentowane są graficznie – na zrzucie ekranu zaznaczone zostają problematyczne elementy wraz z sugestią poprawy. Podobne możliwości oferuje Accessibility Insights for Android od Microsoft – narzędzie to działa na komputerze (łączy się z uruchomioną aplikacją Android) i automatycznie wskazuje elementy o za małym kontraście, brakujące opisy/etykiety czy nieodpowiednie wymiary przycisków[23][24]. Dodatkowo pozwala ręcznie prześledzić kolejność fokusu (nawigacji) po elementach interfejsu za pomocą klawiatury, wykrywając tzw. pułapki klawiaturowe, czyli miejsca, w których fokus może utknąć[25]. Na systemie iOS narzędziem oferującym automatyczną inspekcję jest Accessibility Inspector wbudowany w Xcode (Apple) – umożliwia on symulację działania aplikacji i sprawdzenie m.in. kontrastu tekstu względem tła zgodnie z wymogami WCAG[26][27]. Trzeba jednak zaznaczyć, że automatyczne testy aplikacji iOS na gotowych apkach są utrudnione – kod aplikacji iOS jest domyślnie szyfrowany, więc aby przeprowadzić dogłębną analizę, potrzebny jest dostęp do kodu źródłowego (np. poprzez wbudowanie bibliotek testujących podczas procesu deweloperskiego)[19][28]. Dla programistów mobile istnieją biblioteki do integracji testów dostępności w aplikacji, jak Google GTXiLib czy Espresso Accessibility Checks (Android) oraz GSCXScanner (iOS). Takie rozwiązania sprawdzają w trakcie działania aplikacji wybrane aspekty – np. obecność etykiet dla elementów, wielkość przycisków, poprawność kolejności nawigacji – i zwracają raport dla dewelopera[29][30]. Ogólnie automatyczne testy mobile są najbardziej przydatne dla twórców aplikacji w trakcie developmentu, pozwalając wykryć oczywiste uchybienia już na etapie kodowania interfejsu.
Zalety testów automatycznych
- Szybka diagnoza: Walidatory potrafią w kilka sekund lub minut przeanalizować stronę albo aplikację i wskazać listę błędów. Daje to natychmiastowy obraz stanu dostępności i może służyć jako wstępny audyt przed dalszymi działaniami[7]. Automatyczne skanery można też zintegrować z procesem wytwarzania oprogramowania (np. jako część testów ciągłej integracji), by na bieżąco wyłapywać regresje dostępności.
- Przystępność dla nietechnicznych osób: Narzędzia często prezentują wyniki w przyjaznej formie wizualnej – podkreślając elementy na stronie i objaśniając problem w opisach[10][31]. Dzięki temu nawet osoby bez specjalistycznej wiedzy (np. menadżerowie projektu, testerzy treści) mogą zrozumieć, co wymaga poprawy.
- Przegląd dużej skali: Tylko automatyczne skrypty są w stanie szybko przeskanować wiele stron naraz. Przy dużych serwisach (setki podstron) ręczna kontrola każdej z nich byłaby bardzo czasochłonna – tu z pomocą przychodzą narzędzia potrafiące sukcesywnie sprawdzić cały serwis pod kątem wybranych kryteriów. Np. komercyjne narzędzia jak SortSite czy axe Monitor mogą wygenerować raport zbiorczy dla całej witryny[18].
- Pomoc dla programistów w codziennej pracy: Automatyczne testery są użyteczne nie tylko dla audytorów, ale i dla samych developerów, projektantów czy testerów podczas tworzenia produktu[32][33]. Szybkie uruchomienie walidatora (np. wtyczki w przeglądarce) przed wypuszczeniem nowej funkcjonalności pozwala wychwycić typowe problemy (jak brak alt przy nowym obrazku czy przycisk bez etykiety) zanim trafi to do użytkowników.
Ograniczenia testów automatycznych
- Ograniczony zakres wykrywanych problemów: Automatyka jest w stanie zidentyfikować jedynie ok. 30–40% potencjalnych błędów dostępności[34]. Walidatory sprawdzają głównie te aspekty, które da się zaprogramować – np. obecność atrybutów, poprawność składni, kontrast kolorów wg wzoru. Tymczasem wiele wymogów WCAG ma charakter jakościowy i kontekstowy, czego maszynowo ocenić się nie da. Narzędzie może np. potwierdzić, że obrazek ma atrybut alt, ale nie oceni, czy opis jest właściwy do zawartości obrazka. Może też nie wykryć złej struktury nagłówków, jeśli technicznie znaczniki są poprawne, ale ich logiczna hierarchia nie ma sensu dla użytkownika. Z tego względu automatycznym wynikom zawsze należy się przyglądać krytycznie i weryfikować je innymi metodami[35].
- Brak analizy kontekstu i użyteczności: Narzędzia skupiają się na pojedynczych elementach i regułach, pomijając szerszy kontekst korzystania ze strony czy aplikacji[35]. Przykładowo walidator nie odtworzy całego scenariusza użytkownika (np. procesu zakupowego czy wypełniania formularza, gdzie liczy się kolejność kroków i zrozumiałość komunikatów). Nie odpowie też jednoznacznie na pytanie, czy serwis spełnia wszystkie wymagania prawne – może wykryć część niezgodności, ale nie potwierdzi pełnej zgodności z WCAG/EN 301 549[34][36]. Dlatego nawet przy braku ostrzeżeń w raporcie automatycznym, nie można automatycznie zakładać, że strona jest w 100% dostępna.
- Możliwe wyniki fałszywe lub mylące: Czasem zdarza się, że walidator zgłosi problem, który w rzeczywistości nie wpływa na dostępność – np. ostrzeże o elemencie HTML nietypowym dla danego standardu, mimo że nie zaburza on funkcjonalności dla użytkownika. Z drugiej strony, narzędzie może coś pominąć (fałszywie nie wykryć błędu). Z tego powodu raporty trzeba interpretować z rozwagą, a najlepszą praktyką jest traktowanie ich jako listy potencjalnych tematów do dalszej, manualnej analizy.
Testy manualne (ręczne) i audyt ekspercki
Testowanie manualne polega na zaangażowaniu człowieka – który, w przeciwieństwie do automatu, jest w stanie ocenić dostępność w sposób kontekstowy, „od strony użytkownika”. Może ono przybrać formę samodzielnych testów (np. autor treści czy tester sprawdza stronę według listy kontrolnej) albo pełnego audytu eksperckiego przeprowadzanego przez specjalistę ds. dostępności. W obu przypadkach chodzi o ręczne przejście przez kluczowe elementy interfejsu i funkcjonalności, porównanie ich z wytycznymi WCAG oraz sprawdzenie, jak strona/aplikacja działa z technologiami asystującymi. Poniżej opisujemy, jak wyglądają takie testy w praktyce dla stron WWW i aplikacji mobilnych.
Osoba testująca dostępność strony internetowej za pomocą komputera – w trakcie audytu manualnego kluczowe jest sprawdzenie, czy wszystkie elementy interfejsu są dostępne z klawiatury i czytelne dla czytników ekranu.
Ręczne testowanie stron internetowych – techniki i narzędzia
Przy testach manualnych stron bardzo pomocne jest przygotowanie sobie listy kontrolnej obejmującej wszystkie istotne kryteria WCAG. Lista ta powinna zawierać pytania/sprawdzenia dotyczące m.in.: tekstów alternatywnych dla obrazków, prawidłowej struktury nagłówków (H1, H2 itd.), nawigacji za pomocą samej klawiatury, widoczności fokusu na elementach interaktywnych, odpowiedniego kontrastu tekstu, poprawnych podpisów i etykiet przy polach formularzy, dostępności multimediów (napisy do filmów, audiodeskrypcje) oraz ogólnej czytelności języka. Audyt dostępności zwykle realizuje właśnie taki przekrojowy scenariusz, w którym tester sprawdza po kolei wymogi z listy na reprezentatywnych podstronach serwisu[37][38]. Na przykład: przechodzi całą nawigację serwisu używając tylko klawisza Tab i Enter, aby upewnić się, że można dotrzeć do każdego linku i kontrolki (oraz że fokus nie „utknie” nigdzie); odczytuje zawartość strony za pomocą czytnika ekranu (np. NVDA lub JAWS na Windows, VoiceOver na macOS) sprawdzając, czy wszystkie elementy mają sensowne opisy i są prezentowane w logicznej kolejności; powiększa skalę wyświetlania tekstu do 200% aby sprawdzić responsywność i czytelność dla osób słabowidzących; próbuje obsłużyć serwis przy wyłączonej obsłudze CSS lub z własnymi stylami użytkownika (co ujawnia, czy struktura strony w HTML jest poprawna semantycznie). Niekiedy wykorzystuje się też specjalistyczne programy wspomagające testy manualne, takie jak:
– Czytniki ekranu – wspomniane NVDA (darmowy) czy JAWS (komercyjny) symulują doświadczenie osoby niewidomej, czytając na głos treść strony. Tester musi poznać skróty klawiaturowe i nawigację czytnika, by skutecznie przechodzić przez elementy strony (nagłówki, linki, formularze) i identyfikować ewentualne bariery. Typowe problemy wychwytywane tą metodą to brakujące lub nieprecyzyjne opisy (np. przyciski typu „Więcej” bez kontekstu), niewłaściwa kolejność odczytu elementów, nieopisane grafiki czy ikony, itp.
– Narzędzia do analizy kontrastu i kolorów – choć wiele walidatorów automatycznych zgłasza problemy z kontrastem, tester może też sam zweryfikować kontrast przy pomocy aplikacji takich jak Colour Contrast Analyser (CCA)[39][40]. Wystarczy pipetą wskazać kolor tekstu i tła, a narzędzie pokaże stosunek kontrastu i oceni go względem wymogu (np. minimalny 4.5:1 dla tekstu zwykłego). Manualnie warto też sprawdzić czy informacje nie są przekazywane wyłącznie kolorem (np. same kolorowe oznaczenia błędu bez dodatkowego komunikatu tekstowego).
– Walidatory kodu (HTML/CSS) – uruchamiane ręcznie (np. W3C Validator) pozwalają znaleźć błędy składni, brak zamknięcia znaczników, duplikaty ID itp., co pośrednio wpływa na dostępność. Poprawny kod to często warunek prawidłowego działania technologii asystujących[16].
– Programy powiększające i symulatory daltonizmu – np. narzędzia typu ZoomText (powiększanie zawartości ekranu z jednoczesnym odczytem), przeglądarki często mają też wbudowane opcje powiększenia/trybu wysokiego kontrastu. Tester może również użyć filtrów symulujących różne daltonizmy, aby sprawdzić, czy ważne treści nie są rozróżniane wyłącznie barwą.
Wykonując ręczne testy według listy kontrolnej, osoba testująca sukcesywnie zaznacza, które kryteria są spełnione, a które nie. Taka samodzielna ocena może wykryć wiele oczywistych problemów (tzw. basic accessibility check) i nie wymaga głębokiej specjalistycznej wiedzy – stanowi świetny punkt wyjścia do poprawy dostępności[38][41]. Jednak pełne potwierdzenie zgodności z WCAG/EN 301 549 wymaga zwykle dużego doświadczenia. Profesjonalny audyt ekspercki idzie o krok dalej: specjalista jest w stanie zbadać nie tylko „czy” dany element ma np. tekst alternatywny, ale ocenić jakość tego tekstu, spójność całego serwisu, dostępność bardziej zaawansowanych funkcjonalności (np. interaktywne mapy, aplikacje SPA) oraz przedstawić szczegółowe rekomendacje. Audytor korzysta przy tym z kombinacji własnej wiedzy, ręcznych testów i nieraz też narzędzi automatycznych (dla wsparcia), aby stworzyć kompleksowy raport.
Ręczne testowanie aplikacji mobilnych – techniki i narzędzia
Manualne sprawdzanie dostępności aplikacji mobilnej przebiega nieco inaczej ze względu na interfejs dotykowy i platformę, ale cel pozostaje ten sam. Podstawowym krokiem jest wykorzystanie wbudowanych technologii asystujących na smartfonach:
– Na systemie Android należy włączyć usługę TalkBack, a na iOS – VoiceOver. Są to czytniki ekranu odczytujące na głos elementy, na które wskazuje użytkownik, oraz zmieniające sposób nawigacji gestami. Tester uruchamia aplikację z włączonym czytnikiem i próbuje wykonać typowe czynności (np. przejście przez menu, wypełnienie formularza) posługując się wyłącznie gestami dostępnymi dla TalkBack/VoiceOver (przesuwanie palcem w lewo/prawo – następny/poprzedni element, dwukrotne tapnięcie – aktywacja, itp.). Pozwala to sprawdzić, czy wszystkie przyciski i pola mają poprawne etykiety dla czytnika, czy fokus logicznie przeskakuje przez elementy ekranu oraz czy nie pojawiają się tzw. pułapki focusa (np. focus utknie na jakimś elemencie i nie można przejść dalej).
– Testuje się również nawigację klawiaturą w aplikacji mobilnej – chociaż użytkownicy smartfonów rzadko podłączają fizyczne klawiatury, to systemy mobilne traktują czytnik ekranu jak nawigację klawiaturową (np. kolejność elementów dla TalkBack odpowiada kolejności Tab/Focus). Można więc też podłączyć klawiaturę lub użyć funkcji przełączników dostępności (switch control), aby przechodzić między elementami i upewnić się, że np. kolejność przejść jest zgodna z oczekiwaną logiką.
– Niezwykle ważne jest sprawdzenie skalowalności interfejsu: na Androidzie i iOS użytkownik może zwiększyć rozmiar tekstu w ustawieniach systemowych (tzw. Text Size / Dynamic Type). Tester symuluje maksymalne powiększenie czcionek i obserwuje, czy interfejs aplikacji nadal jest czytelny – czy teksty się mieszczą, nie nachodzą na inne elementy, przyciski nie zlewają się itp. Aplikacja powinna obsługiwać skalowanie co najmniej 200% bez utraty funkcjonalności (wymóg postrzegalności).
– Kolejnym krokiem jest weryfikacja kontrastów i kolorów w aplikacji mobilnej. Tutaj również można posłużyć się wzrokiem (czy jasnoszary tekst na białym tle nie jest zbyt blady?) albo narzędziami desktopowymi – np. zrobić zrzuty ekranu z telefonu i sprawdzić kolory pipetą w narzędziu typu CCA. Warto także włączyć tryb wysokiego kontrastu lub odcieni szarości, jeśli system oferuje, aby zobaczyć, czy aplikacja jest czytelna dla osób słabowidzących lub daltoników.
– Ostatnim, ale istotnym testem, jest przejście przez cały proces użytkownika w aplikacji (tzw. end-to-end), np. jeśli aplikacja służy do zamawiania usługi – spróbować wykonać to zamówienie posługując się tylko gestami i dostępnymi ułatwieniami. To ujawnia problemy nie tylko na poziomie pojedynczych ekranów, ale też w logice przepływu (np. czy po zatwierdzeniu formularza pojawia się czytelne potwierdzenie w formie tekstowej, czy komunikaty błędów są zrozumiałe i ogłaszane przez czytnik ekranu, itp.).
Takie kompleksowe testy manualne aplikacji mobilnej są czasochłonne i wymagają dobrej znajomości zarówno wytycznych WCAG/EN, jak i obsługi funkcji dostępności w telefonie[42]. Często przeprowadza się je na różnych urządzeniach (np. smartphone vs tablet) i w różnych systemach, by pokryć wszystkie platformy. Rezultatem jest lista znalezionych barier wraz z oceną ich wpływu na użytkownika – od krytycznych (np. aplikacji nie da się obsłużyć bez wzroku, bo elementy nie są w ogóle odczytywane) po drobniejsze niedogodności.
Zalety testów manualnych (audytów)
- Pełna ocena rzeczywistej dostępności: Tylko ludzki tester jest w stanie kompleksowo ocenić, czy strona lub aplikacja spełnia wymagania dostępności. Ręczne badanie obejmuje wiele aspektów niedostępnych dla automatów – od jakości opisów tekstowych, przez intuicyjność nawigacji, po zgodność z założeniami UX dla różnych grup użytkowników[43]. Dobrze przeprowadzony audyt ekspercki pozwala zidentyfikować większość, jeśli nie wszystkie bariery, włączając te subtelne lub kontekstowe. To właśnie na podstawie takiego audytu można oficjalnie stwierdzić zgodność (lub brak zgodności) z kryteriami WCAG i wymaganiami ustawowymi.
- Uwzględnienie kontekstu i doświadczenia użytkownika: Tester manualny może faktycznie poczzuć, jak korzysta się z produktu – czego automat nie potrafi. Dzięki temu wychwyci problemy wpływające na wygodę użytkowania, niekoniecznie opisane wprost w WCAG. Na przykład zauważy, że choć formalnie wszystkie pola formularza mają etykiety, to instrukcje są niejasne albo po wysłaniu pojawia się komunikat niezrozumiały dla laika. Testy z użyciem technologii asystujących (czytników ekranu, nawigacji bez myszy) dają wgląd w potrzeby osób rzeczywiście z nich korzystających[44]. Takie podejście jest nieocenione dla projektantów – pozwala lepiej zrozumieć perspektywę użytkownika z niepełnosprawnością.
- Możliwość badania procesów end-to-end: Ręcznie można sprawdzić całe scenariusze użytkownika, a nie tylko wyizolowane elementy[45]. Dla przykładu: automatyczne testy mogą wykazać, czy każde pole formularza jest poprawnie oznaczone, ale tylko tester sprawdzi, czy użytkownik od początku do końca może samodzielnie wypełnić i wysłać formularz, rozumiejąc wszystkie kroki po drodze. Testy z udziałem ludzi pozwalają ocenić spójność doświadczenia (UX) i realną przyjazność aplikacji dla odbiorcy.
- Elastyczność i kreatywność w znajdowaniu błędów: Dobry audytor potrafi „kombinować” – np. sprawdzi stronę przy różnym powiększeniu tekstu, różnej szerokości okna, nietypowych ustawieniach przeglądarki, z urządzeń mobilnych i desktop. Takie spontaniczne działania często odkrywają problemy, o których istnieniu twórcy strony nie mieli pojęcia. Człowiek może też zweryfikować poprawki po ich wdrożeniu, dostarczając informacji zwrotnej, czy faktycznie rozwiązały problem – coś, czego statyczny raport nie zapewni.
Ograniczenia i wyzwania testów manualnych
- Czasochłonność i koszt: Ręczna weryfikacja dużej strony czy złożonej aplikacji wymaga wiele godzin pracy. Jeśli zlecimy pełny audyt ekspercki zewnętrznej firmie, koszt może być znaczny (dla rozbudowanych serwisów sięga nawet kilkunastu tysięcy złotych)[46]. Samodzielne testowanie też pochłania czas pracowników, który trzeba uwzględnić w projekcie. Z tego powodu często nie da się przetestować za jednym razem wszystkiego – trzeba wybierać kluczowe podstrony, a proste testy rozkładać w czasie.
- Wymagana wiedza i umiejętności: Skuteczne przeprowadzenie testów manualnych wymaga znajomości wytycznych WCAG oraz działania technologii asystujących. Osoba nietechniczna musi się najpierw nauczyć obsługi czytnika ekranu czy zasad nawigacji klawiaturą, zanim uzyska miarodajne wyniki[47]. Brak doświadczenia może skutkować pominięciem pewnych błędów albo błędną interpretacją – np. ktoś może nie zauważyć, że dany element jest nieosiągalny z klawiatury, bo nie wiedział, jak poprawnie używać fokusowania. Dlatego zaleca się, by przynajmniej końcową walidację przeprowadzał doświadczony audytor lub zespół, ewentualnie by szkolić personel w zakresie dostępności.
- Subiektywność i potrzeba interpretacji wyników: W przeciwieństwie do automatu, który daje zero-jedynkowe komunikaty, testy manualne generują sporo uznaniowych Część z nich może wynikać np. z ogólnej użyteczności, a nie stricte z dostępności – tester musi zdecydować, co kwalifikuje jako naruszenie WCAG, a co jest np. tylko sugestią ulepszenia. W przypadku testów z udziałem użytkowników z niepełnosprawnościami (które są formą manualnego badania) często pojawiają się uwagi indywidualne, nie zawsze odzwierciedlające obiektywną zgodność z kryteriami[48]. Wymaga to doświadczenia, aby oddzielić faktyczne błędy dostępności od innych problemów.
- Trudność w powtarzalnym stosowaniu: Ze względu na czas i zasoby, pełnych audytów manualnych nie da się wykonywać bardzo często. Zwykle są one przeprowadzane np. przed ważnym wdrożeniem lub okresowo (raz na rok/kwartał). Między tymi punktami w czasie mogą pojawiać się nowe problemy wraz z rozwojem serwisu. Dlatego samo ręczne testowanie, bez wsparcia automatyzacji na co dzień, może nie wychwycić regresji, które wkradną się po audycie.
Porównanie metod i rekomendacje
Automatyczne i manualne podejście nie wykluczają się, lecz uzupełniają. Praktyka pokazuje, że najlepsze rezultaty osiąga się, stosując metody mieszane[49]. Szybkie testy automatyczne sprawdzają podstawy i typowe błędy na bieżąco, a testy manualne dają pogłębioną ocenę i potwierdzają faktyczną zgodność z normami oraz użyteczność dla użytkowników. Poniżej podsumowanie, kiedy i jak warto stosować poszczególne metody:
- Wykorzystuj testy automatyczne na co dzień: Zaleca się, aby programiści i testerzy włączyli narzędzia automatyczne do swojego standardowego procesu. Na etapie developmentu każdej nowej funkcji warto uruchomić choćby wtyczkę WAVE czy Axe w przeglądarce, by natychmiast wyłapać oczywiste uchybienia (np. brak aria-label w nowym przycisku). Również przy każdej większej aktualizacji strony dobrze jest zrobić automatyczny skan całości – wiele takich narzędzi można uruchomić w trybie batch (partia) dla całej witryny. Dzięki temu łatwo utrzymasz podstawowy poziom zgodności i zapobiegniesz gromadzeniu się błędów.
- Przeprowadzaj regularne audyty manualne: Mimo ciągłego monitorowania automatycznego, co pewien czas należy wykonać pełniejszą kontrolę ręczną. Dla serwisów publicznych wymagane jest wręcz okresowe dokonywanie przeglądu dostępności i aktualizacja deklaracji dostępności. Najlepiej zlecić audyt ekspertowi (lub wewnętrznemu specjaliście) przynajmniej w kluczowych momentach – np. tuż przed premierą nowej strony lub dużej przebudowy, a następnie regularnie powtarzać takie audyty (np. raz do roku). W międzyczasie można realizować okrojone samodzielne testy wybranych elementów, by nie czekać z poprawkami dopiero na kolejny audyt.
- Łącz metody dla efektywności: Istnieją strategie hybrydowe – na przykład możesz zacząć od audytu eksperckiego, a potem regularnie robić testy automatyczne w ramach utrzymania[50]. Albo odwrotnie: najpierw samodzielnie poprawić oczywiste błędy wykryte automatycznie, a dopiero potem poprosić eksperta o ocenę bardziej subtelnych kwestii. Jeśli budżet jest ograniczony, można zlecić audyt tylko najbardziej złożonych lub reprezentatywnych podstron, a prostsze sekcje sprawdzić samemu według listy kontrolnej[49]. Taki podział pozwoli zoptymalizować koszty, nie obniżając jakości oceny.
- Testuj na różnych etapach projektu: Dostępność najlepiej uwzględniać od początku tworzenia produktu (zasada Accessibility by design). W fazie projektowania interfejsu pomocne będzie przejrzenie makiet pod kątem wytycznych (to również forma manualnego audytu – tzw. design review). Później, w trakcie developmentu, korzystaj z testów jednostkowych dostępności (jeśli masz takie w projekcie) oraz narzędzi deweloperskich z wbudowanymi checkerami. Przed wdrożeniem produkcyjnym wykonaj komplet testów manualnych z udziałem QA. Po wdrożeniu monitoruj stronę – są narzędzia które ciągle nasłuchują zmian na stronie i sygnalizują nowe problemy dostępności. Ciągłość jest kluczem, bo dostępność to proces, nie jednorazowe zadanie[51].
- Zasięgnij opinii użytkowników: Choć formalnie zgodność z WCAG ocenia się ekspercko, warto zaangażować osoby z niepełnosprawnościami do przetestowania naszego serwisu czy aplikacji (np. w formie badania użyteczności). Taki test z użytkownikami dostarcza unikalnych spostrzeżeń – pokazuje, jak realni ludzie korzystają z naszego produktu i gdzie napotykają trudności[52][45]. Ich uwagi mogą wskazać problemy, których ani automat, ani audytor mogli nie przewidzieć, bo dotyczą specyficznych sytuacji życiowych. Należy jednak pamiętać, że opinie użytkowników trzeba interpretować – nie każdy kłopot zgłoszony przez użytkownika oznacza naruszenie WCAG, czasem może chodzić o ogólną ergonomię[48]. Mimo to, łączenie testów eksperckich z feedbackiem od użytkowników daje najpełniejszy obraz dostępności i użyteczności naszego produktu.
Podsumowanie: Testowanie dostępności cyfrowej to złożony, wieloetapowy proces. Wymaga zarówno automatycznych narzędzi – by szybko i systematycznie wyłapać oczywiste błędy – jak i dogłębnej analizy manualnej – by ocenić zgodność z standardami WCAG/EN 301 549 i realne doświadczenie użytkownika. Stosując oba podejścia komplementarnie, możemy mieć pewność, że nasze strony internetowe i aplikacje mobilne będą przyjazne dla każdego odbiorcy, a przy tym spełnią wszystkie wymagane prawem kryteria dostępności. To inwestycja, która procentuje: zmniejsza wykluczenie cyfrowe, poprawia wizerunek, a często i jakość całego produktu. Najważniejsze, by dostępność traktować nie jako jednorazowy obowiązek, ale stały element cyklu życia strony czy aplikacji – od projektu, poprzez testy, po utrzymanie. Dzięki temu świat cyfrowy będzie coraz bardziej otwarty i dostępny dla wszystkich.
Źródła: Niniejszy raport bazuje na aktualnych wytycznych i artykułach dotyczących dostępności cyfrowej, m.in. materiałach W3C WAI oraz polskim poradniku gov.pl o dostępności. Powołane źródła zawierają szczegółowe opisy narzędzi i metod testowania, zgodnych z WCAG 2.1/2.2 oraz normą EN 301 549.
[1] [2] [3] [4] [5] [51] Dostępność strony internetowej – wymagania, standardy i praktyczne wdrożenia – Media Click
https://mediaclick.pl/dostepnosc-strony-internetowej-wymagania-standardy-i-praktyczne-wdrozenia/
[6] [7] [38] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [52] 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
[8] [9] [10] [11] [12] [13] [14] [15] [17] [18] [31] [32] [33] [34] [35] [36] [39] [40] Jak automatycznie testować dostępność cyfrową stron internetowych – Dostępność cyfrowa – Portal Gov.pl
[16] [37] Jak testować dostępność strony? Najważniejsze narzędzia i techniki weryfikacji WCAG 2.1
[19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] Jak automatycznie testować dostępność cyfrową aplikacji mobilnych – Dostępność cyfrowa – Portal Gov.pl