Prawdziwe pokrycie reguł WCAG przez narzędzia testowania dostępności

Jak zapewne część z Was zauważyła zaczęliśmy w naszych wystąpieniach i publikacjach bardziej naukowo podchodzić do badanych tematów. Ma to miejsce między innymi przy określaniu tego czy użycie pojedynczego lub całej grupy narzędzi jest opłacalne i przynosi wartość. Podobny zabieg wykonaliśmy i na potrzeby prezentacji „Automatyzacja testów dostępności” oraz tego artykułu, gdzie zweryfikowaliśmy pokrycie reguł WCAG.

Wartość narzędzia

Warte podkreślenia jest to, że wszystkie poddane przez nas analizie narzędzia uzyskały niezerowe pokrycie, a znalezione defekty są rzeczywiście problemami oprogramowania. Do zalet należy również fakt, że są to narzędzia automatycznej weryfikacji, czyli nie pisane pod konkretny projekt, ale dla większości istniejących stron internetowych.  Dodatkowo ich konfiguracja i pierwsze odpalenie to jest kwestia minut. Koszty ich wdrożenia i uruchomienia są niewielkie w relacji do uzyskanej efektywności. Są one w większości za darmo, a czas potrzebny na naukę obsługi jest bardzo krótki.

Biorąc pod uwagę wszystkie powyższe można bez wątpliwości powiedzieć, że ich wdrożenie w projekcie ma wartość. 

Liczenia pokrycia

Przyjrzymy się liczbom, które musimy wziąć pod uwagę, aby określić pokrycie:

• WCAG 2.1 to 78 kryteriów sukcesu. 
• wymagany polską Ustawą o Dostępności pokrycie to zapewnienie poprawności implementacji 20 kryteriów z poziomu A i 29 kryteriów poziomu AA (wszystkie za wyjątkiem reguły 1.2.4) co sumarycznie daje 49 kryteriów sukcesu do pokrycia.

Lista wszystkich reguł pokrycia znajduje się poniżej

*) problematyczna na tej liście jest reguła 4.1.1, która zawsze jest spełniona, ale to opiszemy w osobnej publikacji.

Przeglądając szereg publikacji popularnych w Internecie oraz odpytując LLMy możemy znaleźć informację, że narzędzia testowania dostępności osiągają od 25 do 30% pokrycia reguł WCAG. Postawiliśmy sobie za cel zweryfikowanie, czy te wartości są rzeczywiste, a także zbadanie, jak to się ma do pokrycia wszystkich reguł WCAG oraz tego, co jest wymagane Ustawą. 

Problem liczenia pokrycia

Podstawowym problemem w obliczaniu pokrycia jest to, że kryteria sukcesu nie stanowią atomowych weryfikatorów. W związku z tym nie da się więc (w znaczącej liczbie przypadków) zaprojektować jednego testu, aby zweryfikować jedno kryterium sukcesu. 

Przyglądając się pierwszemu z brzegu kryterium „1.1.1 Treść nietekstowa. Poziom A” widzimy tu dużą liczbę elementów, które muszą zostać sprawdzone, aby określić czy elementy nietekstowe są opisane przy pomocy dodatkowego testu. 

Dodatkowo wiadomo, że zapewnienie opisu tekstowego jest możliwe na wiele sposobów, np. przez zastosowanie aria-label lub atrybutu alt.

Zaglądając do dokumentacji narzędzia Wave, można stwierdzić, że sprawdzenie tego jednego kryterium sukcesu wymaga zastosowania więcej niż jednego testu. 

Publikacje pokazujące efektywność narzędzi

Wiele publikacji podsumowujących skuteczność narzędzi automatyzacji testów dostępności dość luźno podchodzi do wspomnianych powyżej ograniczeń. Jednym z chlubnych wyjątków jest pochodzące z 2020 roku porównanie wtyczek przeglądarkowych wspierających testowenie dostępności. 

Autorzy odrobili pracę domową i dla zbioru narzędzi przeanalizowali liczbę „checków” w poszczególnych narzędziach. Nie będziemy omawiać skuteczności poszczególnych narzędzi, a osoby tym zainteresowane odsyłamy do materiału źródłowego. 

Dodatkowo w publikacji znajdziemy informację o tym, ile reguł jest deklaratywnie pokrywanych przez poszczególne narzędzia. 

Na wykresie widzimy, że wszystkich reguł WCAG jest 78, a deklarowane pokrycia we wszystkich badanych narzędziach wynosi 62. Autorzy opracowania nie sprawdzili jednak, czy deklarowane pokrycie jest rzeczywiste i kompletne.

Badania własne

Przeprowadziliśmy własne badanie dla wybranych narzędzi porównując to, co jest w nich deklarowane, z tym, co rzeczywiście można automatycznie sprawdzić. Do badania wybraliśmy narzędzia popularne i często używane na polskim rynku badania dostępności.

Niestety, ponieważ kryteria sukcesu nie są atomowe, a liczba koniecznych „checków” nie jest możliwa do jednoznacznego określenia, końcowe wartości są jedynie przybliżone. Wyniki zebraliśmy w poniższej tabeli.

Kluczowym elementem badanych narzędzi są tzw. Errors, czyli rzeczywiste problemy wykrywane przez narzędzia. Z pewnym przybliżeniem można założyć, że Errors pojawiają się wtedy, gdy realnie występuje defekt dostępności. Niestety nie oznacza to pełnego pokrycia dla kryterium sukcesu. 

Analizując jedynie „Procent pokrycia całego WCAG przez Errors” dla danego narzędzia, widzimy już, że deklaracje twórców narzędzi wynoszą około 16-18%. Dopiero gdy przyjrzymy się pokryciu wymagań Ustawy, osiągamy deklarowane przez twórców narzędzi wartości w przedziale między 25, a 30% (kolumna „Procent pokrycia Ustawy przez Errors”).

Po przeanalizowaniu brakujących „checków” oraz przyznaniu im pewnych wag dodatkowych ustaliliśmy, że realnie uzyskujemy jedynie około poniżej 10% pokrycia WCAG przez narzędzia. Wynika to między innymi z zapisów WCAG, które nie mogą być jednoznacznie zweryfikowane przy pomocy testu. Przykładowo - w omawianym przez nas kryterium 1.1.1 narzędzie powinno dostarczyć wartościowy opis dla elementów nietekstowych w postaci sprawdzenia, czy nie brakuje tekstów alternatywnych (np. dla obrazów). Innym aspektem jest kwestia, czy udało się zapewnić adekwatny tekst alternatywny - narzędzie bez wsparcia prawdziwej lub sztucznej inteligencji nie sprawdzi, czy tekst alternatywny jest dokładny i użyteczny dla osób niewidomych.

Podsumowanie

Deklarowane przez twórców narzędzi pokrycie sięgające 30% nie jest w badanych narzędziach osiągane. Rzeczywista wartość pokrycia wynosi poniżej 10%. Nie zmienia to faktu, że koszty wdrożenia i uruchomienia narzędzi są tak pomijalnie małe, że każde użycie poprawnie działającego narzędzia przyniesie pozytywny zwrot z inwestycji (ROI).