Automatyczny audyt dostępności potrafi w kilka chwil znaleźć wiele problemów na stronie. Nie oznacza to jednak, że strona, która przechodzi taki test bez błędów, jest dostępna.
Część problemów można wykryć automatycznie. Inne wymagają sprawdzenia strony przez człowieka, użycia klawiatury i przejścia przez rzeczywiste procesy, takie jak zakup produktu, logowanie czy wysłanie formularza.
Dlatego skuteczny audyt dostępności nie powinien sprowadzać się do uruchomienia skanera i wygenerowania raportu.
Co może wykryć automatyczny audyt dostępności?
Automatyczne narzędzia są bardzo przydatne, ponieważ potrafią szybko przeanalizować dużą liczbę elementów i podstron.
Mogą wykrywać między innymi problemy związane z:
- kontrastem tekstu i elementów interfejsu,
- brakującymi lub nieprawidłowymi etykietami formularzy,
- strukturą nagłówków,
- niektórymi problemami z atrybutami ARIA,
- brakującymi opisami alternatywnymi obrazów,
- strukturą dokumentu HTML,
- wybranymi błędami wpływającymi na obsługę strony przez technologie asystujące.
Do takiej analizy można wykorzystać różne rozwiązania: skanery działające online, narzędzia wbudowane w środowisko developerskie czy rozszerzenia przeglądarkowe. Jednym z nich jest DockAccess, który pozwala wykonywać automatyczne audyty stron. Udostępniamy również bezpłatne rozszerzenie dla Chrome i Firefox, które umożliwia sprawdzanie dostępności bezpośrednio podczas pracy ze stroną.
Narzędzia przeglądarkowe są szczególnie wygodne podczas developmentu i testów. Pozwalają szybko sprawdzić aktualnie otwartą stronę, przeanalizować wybrany fragment interfejsu, zweryfikować strukturę dokumentu czy znaleźć część problemów przed wysłaniem zmian na produkcję.
Dużą zaletą automatycznych testów jest powtarzalność. Ten sam zestaw reguł można uruchamiać regularnie i szybko wykrywać problemy wprowadzane wraz z kolejnymi zmianami na stronie.
Automatyczny audyt świetnie sprawdza się więc jako pierwsza warstwa kontroli dostępności.
Nie powinien być jednak ostatnią.
Dlaczego automatyczny test WCAG nie wystarczy?
Wyobraź sobie sklep internetowy.
Kontrast jest prawidłowy. Przyciski mają nazwy. Pola formularza posiadają etykiety. Obrazy mają teksty alternatywne. Automatyczny skaner nie znajduje poważnych błędów.
Użytkownik dodaje produkt do koszyka i przechodzi do wyboru dostawy. Otwiera się okno modalne.
I tutaj pojawia się problem.
Osoba korzystająca wyłącznie z klawiatury może wejść do okna, ale nie może z niego wyjść. Fokus zostaje uwięziony, a dokończenie zakupu staje się niemożliwe.
Kod poszczególnych elementów może wyglądać poprawnie, ale cały proces nie działa.
Właśnie takich problemów automat często nie jest w stanie właściwie ocenić.
W3C zwraca uwagę, że narzędzia automatyczne nie mogą sprawdzić wszystkich aspektów dostępności, a ich wyniki wymagają interpretacji. Brak błędów w automatycznym raporcie nie jest więc równoznaczny z pełną dostępnością strony.
Źródło: W3C – Selecting Web Accessibility Evaluation Tools
Co sprawdza audyt manualny WCAG?
Audyt manualny pozwala spojrzeć na stronę tak, jak korzysta z niej użytkownik.
Nie chodzi wtedy tylko o sprawdzenie pojedynczego przycisku czy pola formularza. Ważne jest wykonanie całego zadania.
W sklepie internetowym może to oznaczać:
wyszukanie produktu → wybór wariantu → dodanie do koszyka → wybór dostawy → płatność → potwierdzenie zamówienia.
W aplikacji SaaS:
logowanie → przejście do konkretnej funkcji → uzupełnienie formularza → obsługa błędu → zapisanie zmian.
Dzięki temu można znaleźć bariery, które pojawiają się dopiero podczas rzeczywistej interakcji ze stroną.
Dobry scenariusz testowy powinien być konkretny.
Zamiast:
Sprawdź koszyk.
lepiej określić:
Dodaj produkt do koszyka, zmień liczbę sztuk, wybierz sposób dostawy i popraw błędnie wpisany kod pocztowy, korzystając wyłącznie z klawiatury.
W drugim przypadku dokładnie wiadomo, co ma zostać sprawdzone i kiedy można uznać proces za działający.
Automatyczny audyt czy audyt manualny?
Najlepsze rezultaty daje połączenie obu metod.
Automat daje skalę. Człowiek daje kontekst.
Automatyczne testy mogą szybko przeskanować wiele podstron i wskazać powtarzalne problemy. Audytor może następnie skoncentrować się na elementach, których nie da się wiarygodnie ocenić programowo.
Nie ma więc potrzeby wybierania pomiędzy jednym a drugim.
Automatyczne testy są dobrym filtrem i sposobem na ciągłe monitorowanie. Testy manualne pozwalają odpowiedzieć na znacznie ważniejsze pytanie:
czy użytkownik rzeczywiście jest w stanie skorzystać ze strony i wykonać najważniejsze czynności?
Czy podczas audytu trzeba sprawdzać każdą podstronę?
Niekoniecznie.
Duży sklep może mieć dziesiątki tysięcy adresów URL, ale wiele z nich korzysta z tych samych szablonów i komponentów.
Zamiast testować setki niemal identycznych kart produktów, można dobrać reprezentatywne typy stron i procesów, na przykład:
- stronę główną,
- listing produktów,
- kartę produktu,
- wyniki wyszukiwania,
- koszyk,
- checkout,
- formularz kontaktowy,
- logowanie i rejestrację,
- konto użytkownika,
- bardziej nietypowe lub rozbudowane podstrony.
Kluczowy jest właściwy dobór próby.
Pięć podobnych artykułów dostarcza mniej informacji niż sprawdzenie jednego rozbudowanego formularza, którego użytkownik nie jest w stanie obsłużyć klawiaturą.
W3C opisuje sposób określania zakresu oraz reprezentatywnej próby stron w metodyce WCAG-EM.
Źródło: W3C – Website Accessibility Conformance Evaluation Methodology
Jak powinien wyglądać dobry raport z audytu WCAG?
Raport nie powinien być wyłącznie długą listą błędów.
Każdy istotny problem powinien odpowiadać przynajmniej na kilka pytań:
Gdzie występuje problem?
Konkretna strona, komponent lub proces.
Jak go odtworzyć?
Instrukcja pozwalająca programiście lub testerowi zobaczyć dokładnie ten sam problem.
Na kogo wpływa?
Informacja o tym, jak dana bariera utrudnia korzystanie ze strony.
Z czym jest związany?
Odpowiednie kryterium WCAG lub inny wymóg będący podstawą oceny.
Jak go naprawić i ponownie zweryfikować?
Programista powinien wiedzieć nie tylko, co jest nie tak, ale również jaki rezultat powinien osiągnąć.
Istotny jest również priorytet.
Problem blokujący złożenie zamówienia powinien być traktowany inaczej niż drobna niedogodność na mało istotnej podstronie.
Jeden błąd może oznaczać setki problemów
Warto również uważać na samą liczbę błędów w raporcie.
Jeżeli ten sam nieprawidłowy komponent znajduje się na 300 podstronach, niekoniecznie mamy 300 niezależnych problemów.
Możemy mieć jeden problem w komponencie użytym 300 razy.
Z punktu widzenia zespołu developerskiego ta różnica jest bardzo ważna. Poprawienie komponentu może automatycznie usunąć problem w całym serwisie.
Dobry audyt powinien pomagać podejmować takie decyzje, a nie sztucznie zwiększać liczbę pozycji w raporcie.
Co zrobić po otrzymaniu audytu?
Raport jest początkiem procesu, a nie jego końcem.
Najpierw warto podzielić problemy na te wymagające zmian w kodzie, treści lub projekcie interfejsu. Następnie określić priorytety i zacząć od barier blokujących najważniejsze procesy.
Po wdrożeniu poprawki należy ponownie wykonać scenariusz, który wcześniej ujawniał problem.
Jeżeli użytkownik nie mógł dokończyć zakupu za pomocą klawiatury, samo oznaczenie zadania jako „Done” nie wystarczy.
Trzeba ponownie przejść zakup klawiaturą.
Dopiero wtedy wiadomo, czy problem rzeczywiście został rozwiązany.
Jak zacząć sprawdzanie dostępności swojej strony?
Na początek nie musisz analizować całego serwisu.
Wypisz trzy najważniejsze rzeczy, które użytkownik powinien móc zrobić na Twojej stronie. Może to być zakup produktu, wysłanie formularza, założenie konta albo znalezienie konkretnej informacji.
Uruchom automatyczny audyt, aby znaleźć problemy możliwe do wykrycia programowo. Możesz wykorzystać do tego narzędzia takie jak DockAccess albo rozszerzenie do audytowania dostępności bezpośrednio w przeglądarce. Następnie przejdź najważniejsze procesy ręcznie, korzystając między innymi z samej klawiatury.
To już daje znacznie lepszy obraz dostępności niż sam wynik automatycznego skanera.
W Dock łączymy automatyczne testy z audytem manualnym i analizą najważniejszych procesów użytkownika. Na tej podstawie możemy przygotować zakres audytu, określić priorytety oraz pomóc we wdrożeniu i ponownym przetestowaniu poprawek.
