Testowanie dostępności

Testowanie dostępności to bardzo szeroki temat. A równocześnie niezwykle ważny – takie testy pozwalają się bowiem upewnić, że z naszej strony może skorzystać jak najszersza grupa osób. Dlatego testy dostępności powinny być integralną częścią każdego procesu wytwarzania oprogramowania.

Niemniej wydaje się, że nie są… A przynajmniej nie przykłada się do nich dostatecznej wagi. W badaniu WebAIM Million w 2023 roku wykryto, że 96,3% z miliona najpopularniejszych stron WWW jest niezgodnych ze standardarem WCAG 2! A przecież ten standard zawiera jedynie zalecenia pozwalające na zapewnienie minimalnego poziomu dostępności. Dodatkowo testy zostały przeprowadzone przy pomocy automatycznego narzędzia (WAVE), a te znane są z tego, że wykrywają jedynie mniejszość ze wszystkich błędów dostępności. Mówiąc krótko: jest źle i niekoniecznie widać szansę na poprawę w najbliższej przyszłości.

Co jest o tyle zaskakujące, że W3C dołożyło sporych starań, aby zdefiniować dokładne wytyczne testowania stron internetowych. Udostępnia też dokładną metodykę takich badań, na której eksperci dostępności opierają swoje procesy testowania. Instytucje rządowe wdrażają też procesy, które mają na celu zrobienie z dostępności podstawowej funkcjonalności. W myśl takich procesów żadna część aplikacji nie jest gotowa, jeśli nie jest dostępna. Coraz głośniej się też mówi właśnie o tym, że zgodność ze standardem WCAG to dopiero początek i że “prawdziwa dostępność” to jednak coś o wiele głębszego. I że trzeba tutaj wejść na poziom dobrych praktyk i dialogu z osobami użytkowniczymi, żeby faktycznie odpowiadać na ich potrzeby, a nie na nasze wyobrażenia o ich potrzebach. I mimo tego niesamowitego przesunięcia w sposobie myślenia o dostępności i coraz częstszego pojawiania się kultury dostępności, jest źle…

Sporą część z problemów rozwiązać mogłoby właśnie testowanie dostępności. Osobiście wyróżniłbym trzy podstawowe rodzaje testów dostępności:

W typowej aplikacji internetowej rozkład tych testów zapewne będzie przypominał standardowy rozkład testów: najwięcej będzie testów automatycznych, potem manualnych, a najmniej – z osobami użytkowniczymi. Jest to w sumie dość logiczne, bo automatyczne testy są najmniej kosztowne i można je często zrobić minimalnym nakładem kosztów. Najtrudniej zorganizować z kolei testy z osobami użytkowniczymi, stąd jest ich najmniej i są przeznaczone na specjalne okazje. Mimo to ważność testów jest odwrotnie proporcjonalna do częstotliwości ich występowania.

Piramida ważności testów dostępności: najważniejsze są testy z osobami użytkowniczymi, następnie manualne, a na samym dole – automatyczne.

Testy automatyczne, choć najtańsze, wykrywają najmniej błędów. Testy manualne – zwłaszcza przeprowadzane przez profesjonalnego audytora – pozwalają wykryć zdecydowanie więcej błędów. Ale i tak osoba użytkownicza jest w stanie wykryć ich najwięcej i wskazać często te obszary, o jakich w ogóle dotąd nie pomyśleliśmy.

Testy automatyczne

Testy automatyczne dostępności często sprowadzają się do odpalenia jakiegoś narzędzia, które sprawdzi stronę pod względem wycinka wytycznych WCAG, a następnie wygeneruje raport, pokazujący, gdzie zostały popełnione błędy. Na ten moment najpopularniejszym tego typu rozwiązaniem jest axe, który występuje zarówno w darmowej, jak i płatnej wersji. Jest on używany w wielu innych produktach do testowania dostępności, takich jak choćby Lighthouse, wbudowany w przeglądarkę Chrome.

Jak już zostało wspomniane, tego typu testowanie wykrywa tylko część błędów dostępności. Zwykle dotyczy to tych zaleceń standardu WCAG, które da się obiektywnie zmierzyć, jak np. współczynnik kontrastu czy kolejność nagłówków na stronie. W innych przypadkach takie narzędzie albo nie jest w stanie w ogóle wykryć błędu, albo co najwyżej może próbować zgadnąć, czy jakaś sytuacja jest błędem (np. kilka akapitów pod sobą, których treść zaczyna się od kolejnych cyfr, prawdopodobnie powinno być listą). Zatem tak naprawdę automatyczne testy dostępności są w stanie sprawdzić jedynie, czy strona jest zgodna ze standardem WCAG.

Co nie znaczy równocześnie, że tego typu testy nie są wartościowe! Z uwagi na to, jak łatwo można je zaimplementować, są doskonałą pierwszą linią obrony przed najprostszymi do sprawdzenia (i też jednymi z najczęstszych popełnianych) błędami dostępności. Nie wymagają też żadnej specjalistycznej wiedzy z zakresu dostępności. Wystarczy odpalić narzędzie, a następnie poprawić błędy zgodnie z wytycznymi z wygenerowanego raportu. Idealne do szybkiego wykrywania problemów na etapie developmentu. Powstało nawet pojęcie Continuous Accessibility (Nieustanna Dostępność), które opisuje praktyki polegające na dodaniu sprawdzania dostępności do systemów CI. Dzięki temu żadna regresja dostępności nie przemknie niepostrzeżenie w kodzie.

Testy manualne

Testy manualne to drugi typ testów dostępności. W przeciwieństwie do automatycznych te już wymagają zarówno więcej pracy ze strony osoby testującej, jak i posiadania przez nią pewnej wiedzy o dostępności. Takie testy może przeprowadzić zarówno sama osoba webdeveloperska, jak i profesjonalna osoba audytująca dostępność.

I choć “profesjonalna osoba audytująca dostępność” brzmi dość przerażająco, warto zauważyć, że część manualnych testów dostępności przeprowadzić można dość prostymi metodami. Chyba najprostszą z nich jest… przejechanie po stronie przy pomocy klawisza Tab. Choć sposób ten wydaje się wręcz śmiesznie prosty, to jest też zadziwiająco skuteczny. Niemal zawsze okazuje się bowiem, że albo jakiś element ma niewidoczny wskaźnik focusu, albo do jakiegoś przycisku lub linku w ogóle nie da się dostać przy pomocy samej klawiatury. Częstym problemem jest też nielogiczna kolejność otrzymywania focusu przez elementy na stronie, np. nawigacja, która focusuje się od końca, albo nagły przeskok w regiony stopki strony.

Ale ostatecznie i tak wypadałoby też sprawdzić, jak strona zachowuje się przy wykorzystaniu technologii asystującej. Najpopularniejszą są bez wątpienia czytniki ekranowe (w tym te na urządzeniach mobilnych). Ale przecież nie jedyną. Są też m.in. programy do sterowania głosem, do powiększania ekranu, itd. Co prawda nie da się przetestować wszystkich możliwych technologii asystujących, ale często warto wyjść poza “strefę komfortu”, jaką są czytniki ekranowe. A przynajmniej – mieć świadomość tego, że poza nimi istnieje cały przedziwny świat, więc wypada się nad nim choć chwilę zastanowić. Tutaj może nam pomóc testowanie z personami, które są świetnym punktem wyjścia dla takich rozważań.

Jeśli jednak nie mamy pewności, czy na pewno dobrze testujemy dostępność, zawsze zostaje owa mityczna “profesjonalna osoba audytująca dostępność”. W końcu to jej praca, więc się na tym zna! Warto więc zlecić jej zbadanie wszystkich zakamarków aplikacji w celu znalezienia błędów dostępności. A z kolei jako osoba audytująca dostępność warto pamiętać, że bycie dostępnym to niekoniecznie to samo, co zgodność ze standardem WCAG.

Testy z osobami użytkowniczymi

Testy z osobami użytkowniczymi to najlepszy sposób na znalezienie wszystkich błędów dostępności, które zdołały się prześlizgnąć przez dwa poprzednie filtry. W końcu to właśnie one będą używały aplikacji na co dzień i to właśnie im nic nie ma w tym przeszkadzać. Jeśli coś przeszkadza, to od nich najszybciej o tym usłyszymy. Tego typu testy pozwalają też zweryfikować nasze założenia, np. o tym, że osoby niewidome są ekspertami w używaniu czytników ekranowych. Warto pamiętać o tym, że jest wiele rodzajów niepełnosprawności i trzeba dobrze dobrać grupę osób testujących tak, aby pokryć jak najszersze spektrum przypadków. Zwłaszcza, że osoby niewidome niekonieczne mają takie same potrzeby jak np. osoby głuche i skupianie się tylko na jednym rodzaju niepełnosprawności może wykluczyć osoby z innym rodzajem niepełnosprawności. Dla osoby niewidomej filmik z wywiadem będzie całkowicie zrozumiały – w końcu wszystkie potrzebne informacje są przekazywane dźwiękowo. Ale dla osoby głuchej ten sam filmik będzie całkowicie niezrozumiały bez dodanych napisów.

Symulacje

Warto pochylić się nad jeszcze jednym wątkiem – czymś, co nazwałbym symulacjami. Nie są to testy jako takie, ale bardziej… eksperymenty? Osobom, które nie mają żadnych niepełnosprawności, często bardzo trudno zrozumieć sposób, w jaki osoby z niepełnosprawnościami używają Sieci i jakie są ich potrzeby. Dlatego czasami podejmują pewnego rodzaju wyzwania. Jednym z nich może być próba używania Sieci bez użycia jakiejś technologii lub urządzenia. Przykładami może być przeglądanie internetu bez włączonego CSS-a lub bez używania myszki. Często jednak symulacja jest bardziej złożona i np. obejmuje konkretny rodzaj niepełnosprawności – takiej jak ślepota barw. Tego typu symulacje przeprowadzane są najczęściej przy użyciu odpowiednich programów, np. filtrów, które zmieniają kolory na ekranie tak, aby wyglądały identycznie do tych widzianych przez osoby z daltonizmem. Czasami używa się również specjalnych urządzeń, które np. ograniczają ruchy palców, żeby symulować niepełnosprawności ruchowe.

Samo założenie tego typu symulacji jest jak najbardziej dobre: żeby być w stanie wczuć się w sytuację osób z niepełnosprawnościami, należy ją najpierw zrozumieć. Takie symulacje często nazywane są “treningiem empatii”. Niemniej nowsze badania wskazują, że często dają wręcz odwrotne rezultaty:

However, a recent study published by Michelle Nario-Redmond, Ph.D., professor of psychology, reveals that disability simulations often result in feelings of fear, apprehension and pity toward those with disabilities, proving Nario-Redmond’s thesis that disability simulations do more harm than good.

[Niemniej badania opublikowane niedawno przez dr Michelle Nario-Redmond, profesorkę psychologii, wykazały, że symulacje niepełnosprawności często powodują uczucia strachu, lęku oraz litości względem osób z niepełnosprawnościami, potwierdzając tezę Nario-Redmond, że symulacje takie powodują więcej szkody niż pożytku.]

Symulacje takie są krótkotrwałe, często trwają mniej niż dzień, co powoduje, że problem niepełnosprawności zostaje mocno spłycony. Osoba z niepełnosprawnością zostaje zredukowana do samej niepełnosprawności. A przecież osoby, które zmagają się z niepełnosprawnością od lat, przez ten czas często wykształciły skuteczne metody radzenia sobie z nią. Tego typu symulacja jednak nie daje wglądu do takich dostosowań i często sprawia mylne wrażenie, że osoby z niepełnosprawnością są niesamodzielne i nieporadne. Dlatego też Michelle Nario-Redmond zamiast symulacji proponuje kontakt z osobami z niepełnosprawnością w celu poznania stojących przed nimi wyzwań i zobaczenia, jak radzą sobie z otaczającym je środowiskiem, które często jest niedostępne.

Źródła

Dodatkowe materiały