Automatyczny skaner dostępności potrafi w kilka sekund znaleźć błędy, których ręczne wyszukiwanie na dużej stronie zajęłoby wiele godzin. Wykryje problemy z kontrastem, formularzami, strukturą HTML, ARIA, linkami czy tekstami alternatywnymi. Nie jest jednak w stanie odpowiedzieć na najważniejsze pytanie: czy z tej strony rzeczywiście może swobodnie korzystać osoba z niepełnosprawnością.
Dotyczy to również naszego skanera DockAccess. Zbudowaliśmy go po to, żeby automatyzować te testy, które da się wiarygodnie wykonać programowo. Nie udajemy jednak, że wynik automatycznego audytu oznacza zgodność strony z WCAG. Część barier można znaleźć dopiero wtedy, gdy człowiek przejdzie stronę klawiaturą, użyje czytnika ekranu i sprawdzi działanie rzeczywistych procesów, takich jak formularz kontaktowy czy zakup produktu.
Co potrafi automatyczny skaner dostępności?
Automatyzacja sprawdza przede wszystkim elementy strony, które można ocenić według jednoznacznych reguł zapisanych w kodzie lub wynikających z właściwości elementów widocznych w przeglądarce.
Może wykrywać między innymi problemy z kontrastem tekstu, brakujące lub nieprawidłowe atrybuty, pola formularzy bez odpowiednich etykiet, puste linki, część problemów z ARIA, strukturą dokumentu oraz tekstami alternatywnymi.
Przy dużym serwisie jest to ogromna oszczędność czasu. Jeżeli ten sam błąd występuje na kilkuset kartach produktów, automat może znaleźć cały wzorzec bez ręcznego otwierania każdej strony.
Dlatego skan automatyczny powinien być jednym z pierwszych etapów pracy nad dostępnością.
Nie powinien być jednak etapem ostatnim.
Brak błędów w skanerze nie oznacza zgodności z WCAG
To ograniczenie nie dotyczy konkretnego producenta narzędzia. Wynika z samej natury WCAG.
W3C wskazuje, że narzędzia do oceny dostępności mogą szybko identyfikować potencjalne problemy, ale nie są w stanie automatycznie sprawdzić wszystkich aspektów dostępności. Do części testów potrzebna jest ocena człowieka.
Dobrym przykładem jest tekst alternatywny obrazu.
Skaner może sprawdzić, czy obraz posiada atrybut alt. Może również wykryć niektóre oczywiście podejrzane wartości.
Nie wie jednak, czy opis:
alt="IMG_2043"
przekazuje użytkownikowi jakąkolwiek przydatną informację.
Jeszcze trudniej jest ocenić, czy konkretny obraz w ogóle powinien być opisany. Zdjęcie produktu, wykres i dekoracyjna ilustracja pełnią zupełnie inne role, mimo że technicznie wszystkie są elementami <img>.
Automat widzi strukturę. Człowiek rozumie kontekst.
DockAccess też nie zastępuje audytu manualnego
W DockAccess rozwijamy własny skaner dostępności, który pozwala automatycznie analizować strony pod kątem wielu typowych problemów WCAG.
Można uruchomić audyt strony, sprawdzić wykryte błędy, analizować elementy bezpośrednio w przeglądarce i wykorzystać rozszerzenie dla Chrome lub Firefox podczas pracy nad serwisem.
Automatyczny audyt jest szczególnie przydatny do wyszukiwania błędów technicznych i powtarzalnych. Pozwala szybko znaleźć miejsca wymagające uwagi i ponownie sprawdzić stronę po wprowadzeniu poprawek.
DockAccess nie stwierdzi jednak automatycznie, że strona jest zgodna z WCAG. Nie powinno tego obiecywać żadne narzędzie wykonujące wyłącznie testy automatyczne.
Czy stronę da się obsłużyć klawiaturą?
Jednym z najprostszych testów manualnych jest odłożenie myszy i przejście strony za pomocą klawiatury.
Używając klawisza Tab, powinieneś być w stanie dotrzeć do wszystkich elementów interaktywnych, a aktualnie aktywny element powinien pozostawać widoczny.
Skaner może znaleźć część technicznych problemów związanych z obsługą klawiatury, ale nie przejdzie całej ścieżki w taki sposób jak użytkownik.
Problem może pojawić się dopiero po otwarciu menu, wyborze wariantu produktu, uruchomieniu modala albo przejściu do kolejnego kroku formularza.
Może się też okazać, że kolejność przechodzenia pomiędzy elementami jest technicznie możliwa, ale zupełnie nie odpowiada temu, co użytkownik widzi na ekranie.
Focus może istnieć i jednocześnie być bezużyteczny
Strona może posiadać poprawnie zdefiniowany focus, a mimo to użytkownik nie będzie wiedział, gdzie aktualnie się znajduje.
Wystarczy, że obramowanie jest prawie niewidoczne na danym tle albo aktywny element zostanie zasłonięty przez przyklejony nagłówek, pasek cookies lub okno czatu.
To szczególnie ważne w kontekście WCAG 2.2, które wprowadziło kryterium 2.4.11 Focus Not Obscured (Minimum) na poziomie AA.
Takie zachowanie zależy od aktualnej pozycji strony, wielkości ekranu, otwartych elementów i sposobu interakcji użytkownika. Automatyczna analiza może pomóc w części przypadków, ale rzeczywiste zachowanie interfejsu nadal wymaga sprawdzenia podczas korzystania ze strony.
Czy komunikat błędu rzeczywiście pomaga użytkownikowi?
Automat może wykryć pole formularza bez etykiety albo określone problemy z powiązaniem komunikatu błędu z polem.
Znacznie trudniej automatycznie ocenić, czy cały proces jest zrozumiały.
Wyobraź sobie formularz rejestracji. Po jego wysłaniu jedno z pól otrzymuje czerwoną ramkę. Dla części użytkowników jest oczywiste, gdzie wystąpił błąd.
Osoba korzystająca z czytnika ekranu może jednak nie otrzymać żadnej informacji.
Nawet jeśli komunikat zostanie odczytany, pozostaje pytanie, czy mówi użytkownikowi, co powinien poprawić i czy po błędzie można łatwo wrócić do właściwego pola.
To trzeba sprawdzić podczas rzeczywistej interakcji z formularzem.
Czy własne komponenty działają z technologiami asystującymi?
Nowoczesne strony coraz rzadziej składają się wyłącznie ze standardowych linków, pól i przycisków.
Sklepy wykorzystują własne selektory wariantów, filtry, autocomplete, slidery, kalendarze dostaw, rozwijane menu, popupy i konfiguratory produktów.
Komponent może wyglądać i działać idealnie przy użyciu myszy, ale być bardzo trudny albo niemożliwy do obsłużenia klawiaturą.
Może też zmieniać swój stan bez przekazania tej informacji do czytnika ekranu.
Automatyczny skaner może znaleźć część błędów w implementacji ARIA lub strukturze komponentu. Nie zastąpi jednak sprawdzenia, czy cały komponent da się faktycznie obsłużyć od początku do końca.
Najważniejsze są całe procesy, a nie pojedyncze podstrony
Automatyczne skanowanie bardzo dobrze działa na poziomie strony i pojedynczych elementów. Użytkownik korzysta jednak z całych procesów.
W sklepie internetowym dostępność karty produktu niewiele daje, jeżeli nie można wybrać wariantu albo przejść przez checkout.
Podobnie formularz kontaktowy może wyglądać poprawnie podczas pierwszego skanowania, a bariera pojawi się dopiero po jego błędnym wysłaniu.
Dlatego podczas audytu manualnego warto przejść najważniejsze ścieżki biznesowe, między innymi:
- wyszukanie produktu lub usługi,
- korzystanie z menu i filtrów,
- wybór wariantu produktu,
- dodanie produktu do koszyka,
- przejście całego checkoutu,
- rejestrację i logowanie,
- wypełnienie i wysłanie formularza,
- obsługę błędów i komunikatów.
Dopiero taki test pokazuje, czy użytkownik jest w stanie osiągnąć cel, dla którego wszedł na stronę.
Automatyczny skaner nadal jest bardzo potrzebny
Ograniczenia automatyzacji nie oznaczają, że skanery dostępności są mało przydatne.
Wręcz przeciwnie. Ręczne wyszukiwanie problemów, które komputer może znaleźć w kilka sekund, jest nieefektywne.
Dobry proces zaczyna się od automatycznego skanowania. Pozwala ono znaleźć dużą grupę technicznych i powtarzalnych błędów oraz uporządkować pracę nad serwisem.
Dopiero później warto poświęcić czas specjalisty na elementy, których automat nie potrafi wiarygodnie ocenić.
Tak właśnie podchodzimy do tego w DockAccess: automat robi to, w czym automat jest dobry, a testy wymagające zrozumienia kontekstu pozostają po stronie człowieka.
Co możesz sprawdzić samodzielnie w kilkanaście minut?
Po wykonaniu automatycznego skanu możesz zrobić kilka prostych testów bez specjalistycznego oprogramowania.
- Odłóż mysz. Spróbuj przejść klawiaturą przez menu, formularz i najważniejszy proces na stronie.
- Obserwuj focus. Na każdym etapie powinno być jasne, który element jest aktywny i nie powinien być zasłonięty przez inne części interfejsu.
- Powiększ stronę. Sprawdź, czy po zwiększeniu tekstu i przy wąskim widoku nadal można korzystać z treści i funkcji.
- Wywołaj błędy formularza. Zostaw wymagane pola puste albo wpisz nieprawidłowe dane i sprawdź, czy komunikaty rzeczywiście pomagają poprawić formularz.
- Sprawdź elementy dynamiczne. Otwórz menu, modal, filtr, kalendarz albo konfigurator i spróbuj obsłużyć go bez myszy.
- Przejdź najważniejszy proces do końca. W sklepie będzie to najczęściej droga od produktu do finalizacji zamówienia.
Już taki test często pokazuje bariery, których nie będzie w raporcie automatycznym.
Skan, audyt manualny i widżet rozwiązują różne problemy
Warto również rozdzielić trzy pojęcia, które często pojawiają się razem przy dostępności cyfrowej.
Skan automatyczny analizuje stronę i znajduje problemy, które można wykryć programowo.
Audyt manualny sprawdza zachowanie strony podczas rzeczywistego korzystania z niej, w tym obsługę klawiaturą i technologiami asystującymi.
Widżet dostępności daje użytkownikowi dodatkowe możliwości dostosowania sposobu wyświetlania lub korzystania ze strony.
Widżet nie naprawi jednak błędnej struktury HTML, niedostępnego formularza czy komponentu, którego nie da się obsłużyć klawiaturą. Nie zastępuje więc ani poprawnie przygotowanej strony, ani jej audytu.
Najlepszy audyt łączy automat z człowiekiem
Nie trzeba wybierać między automatycznym skanerem a audytem manualnym. Oba rozwiązania odpowiadają na inne pytania.
Skaner szybko znajduje problemy, które da się jednoznacznie wykryć w kodzie i interfejsie. Człowiek sprawdza później kontekst, zachowanie strony i całe procesy.
W3C w swoich materiałach dotyczących oceny dostępności również wskazuje, że żadne narzędzie samo nie może określić, czy strona spełnia standardy dostępności. Do takiej oceny potrzebna jest wiedza i ocena człowieka.
Dlatego w DockAccess nie traktujemy wyniku skanera jako certyfikatu zgodności z WCAG. Jest punktem wyjścia do znalezienia i naprawienia możliwie dużej liczby problemów automatycznie, a tam, gdzie kończą się możliwości narzędzia, zaczyna się audyt manualny.
Możesz zacząć od bezpłatnego skanu w DockAccess albo skorzystać z naszego darmowego rozszerzenia dla Chrome i Firefox. Jeśli potrzebujesz pełniejszej weryfikacji, możemy również przeprowadzić audyt dostępności obejmujący testy manualne.
