Dlaczego automatyczne testy dostępności pomijają połowę problemów

Niewygodna prawda o automatycznym testowaniu dostępności

Automatyczne testowanie dostępności to jeden z najlepszych nawyków, jakie może wypracować zespół webowy. Wykrywa brakujące etykiety formularzy, tekst o niskim kontraście, nieprawidłowe ARIA, zduplikowane ID, puste przyciski i inne defekty, które nigdy nie powinny trafić na produkcję.

Jest też regularnie źle rozumiane.

Pozytywny wynik automatycznego raportu dostępności nie oznacza, że strona jest dostępna. Oznacza, że narzędzie nie znalazło podzbioru problemów, które potrafi wykryć. Ten podzbiór jest wartościowy, ale ograniczony. Wiele błędów dostępności zależy od znaczenia, kolejności, intencji, kontekstu i interakcji człowieka. Oprogramowanie może sprawdzić znaczniki. Nie potrafi jednak niezawodnie zrozumieć, czy doświadczenie działa dla osoby korzystającej z czytnika ekranu, klawiatury, powiększenia, sterowania głosem, napisów lub wsparcia poznawczego.

Dlatego stwierdzenie, że automatyczne testy pomijają około połowy problemów, nie jest cyniczne. Jest łagodne. Niektóre kategorie problemów bardzo dobrze poddają się automatyzacji. Inne prawie wcale.

Praktyczna odpowiedź nie polega na porzuceniu automatycznych narzędzi. Chodzi o umieszczenie ich we właściwym miejscu: wcześnie, często i jako części szerszego procesu testowania.

W czym automatyczne testy są dobre

Automatyczne narzędzia świetnie znajdują deterministyczne błędy. Jeśli regułę da się wyrazić jako warunek czytelny dla maszyny, skaner zwykle może sprawdzić ją szybko i konsekwentnie.

Typowe przykłady to:

• Obrazy z brakującymi atrybutami alt
• Pola formularzy bez powiązanych etykiet
• Przyciski bez dostępnych nazw
• Tekst, który nie spełnia progów kontrastu
• Nieprawidłowe atrybuty lub role ARIA
• Poziomy nagłówków pomijane w podejrzany sposób
• Brakujące lub zduplikowane landmarks
• Linki z pustymi dostępnymi nazwami
• Tabele bez podstawowej struktury

Te kontrole warto automatyzować, ponieważ ludzie słabo radzą sobie z powtarzalną inspekcją. Nikt nie powinien ręcznie przeglądać każdej strony w poszukiwaniu brakujących etykiet, jeśli narzędzie może wykryć je w milisekundy.

Automatyczne kontrole ułatwiają też rozmowę o dostępności w procesach inżynierskich. Nieudany test w CI jest konkretny. Ostrzeżenie w pull request jest na czas. Linia trendu obejmująca szablony daje zespołowi coś do poprawy.

Problem zaczyna się wtedy, gdy zespoły traktują te kontrole jako dowód dostępności, a nie dowód podstawowej higieny.

Gdzie automatyzacja przestaje działać

Dostępność nie jest wyłącznie właściwością kodu. Jest właściwością użycia.

Narzędzie może powiedzieć, czy obraz ma tekst alternatywny. Zwykle nie potrafi powiedzieć, czy ten tekst alternatywny jest użyteczny. Obraz produktu może wymagać szczegółowego opisu na stronie produktu, żadnego opisu w dekoracyjnym hero i zupełnie innego opisu w artykule pomocy. Poprawna odpowiedź zależy od kontekstu. Dlatego zespoły potrzebują wskazówek redakcyjnych, takich jak pragmatyczne podejście do tekstu alternatywnego obrazów, a nie tylko reguły lintera.

Ten sam problem pojawia się wszędzie.

Skaner może potwierdzić, że każdy przycisk ma dostępną nazwę. Nie zawsze potrafi stwierdzić, czy ta nazwa ma sens. Strona z pięcioma przyciskami o nazwie Submit może przejść podstawową regułę, a nadal być uciążliwa dla użytkowników czytników ekranu. Modal może mieć właściwe atrybuty ARIA, ale nieprawidłowo uwięzić fokus. Niestandardowa lista rozwijana może wyglądać zgodnie ze standardem w statycznym markupu i zawieść w chwili, gdy ktoś spróbuje użyć jej klawiaturą.

Automatyzacja ma trudność z pytaniami takimi jak:

• Czy kolejność fokusu odpowiada kolejności wizualnej i logicznej?
• Czy każde zadanie można wykonać samą klawiaturą?
• Czy komunikaty błędów są konkretne, pojawiają się we właściwym czasie i są powiązane z polami?
• Czy strona nadal działa po zmianie rozmiaru tekstu lub powiększeniu?
• Czy kolejność czytania ma sens dla technologii wspomagających?
• Czy instrukcje są zrozumiałe bez polegania na kolorze lub położeniu?
• Czy napisy, transkrypcje i etykiety rzeczywiście przekazują treść?
• Czy komponent zachowuje się przewidywalnie w różnych stanach?

To nie są przypadki brzegowe. To sedno dostępności.

Fałszywy komfort wysokiego wyniku

Wyniki dostępności są kuszące, ponieważ sprowadzają złożony temat do liczby. Dashboard pokazuje 98. Raport pokazuje zielone znaczniki. Wydanie wydaje się bezpieczniejsze.

Ale wynik mierzy tylko to, co mierzy narzędzie.

To podobne do testowania wydajności. Raport Lighthouse może ujawnić ważne problemy, ale nie jest tym samym, co obserwowanie prawdziwego użytkownika, który zmaga się z wolnym checkoutem na telefonie ze średniej półki. Jeśli Twój zespół już korzysta z audytów wydajności, obowiązuje to samo podejście: czytaj raport uważnie, a potem priorytetyzuj ustalenia, które wpływają na prawdziwych użytkowników. Pisaliśmy o tym rozróżnieniu w jak czytać raport Lighthouse bez paniki.

Raporty dostępności wymagają tej samej powściągliwości. Czysty automatyczny skan to punkt wyjścia. Nie jest certyfikatem.

Ryzyko jest szczególnie duże, gdy zespoły uruchamiają skany tylko na statycznych stronach. Nowoczesne interfejsy są stanowe: menu się otwierają, panele wysuwają, toasty się pojawiają, komunikaty walidacji aktualizują, zakładki przełączają panele, filtry przepisują treść, a uwierzytelnianie zmienia wszystko. Wiele poważnych defektów dostępności żyje właśnie w tych interakcjach.

Jeśli Twój skaner widzi tylko początkowy DOM, nie widzi produktu.

Kategorie najczęściej pomijane

1. Zachowanie klawiatury i fokusu

Dostęp z klawiatury to jeden z najjaśniejszych przykładów tego, dlaczego automatyzacja jest niewystarczająca.

Narzędzie może wykryć, czy element może otrzymać fokus. Może wychwycić dodatnie wartości tabindex lub oczywiste pułapki fokusu. Nie potrafi jednak niezawodnie ocenić, czy sekwencja tabulacji jest spójna, czy fokus po akcji przenosi się we właściwe miejsce, ani czy zamknięty komponent zwraca fokus do wyzwalacza.

Potrzebujesz człowieka, który przejdzie przez rzeczywisty workflow za pomocą Tab, Shift+Tab, Enter, Space, Escape i klawiszy strzałek.

Jest to szczególnie ważne w przypadku niestandardowych kontrolek. Natywne elementy HTML dają lata zachowań dostępności za darmo. Odbudowywanie przycisków, pól wyboru, checkboxów, menu i dialogów za pomocą divów oznacza, że Twój zespół przejmuje teraz odpowiedzialność za to zachowanie. Jeśli przeglądasz interaktywne komponenty, zacznij od krótkiej checklisty dla dostępnych przycisków webowych i zastosuj tę samą dyscyplinę do każdej niestandardowej kontrolki.

2. Znaczące nazwy i opisy

Automatyczne narzędzia potrafią wykrywać brak. Znacznie gorzej radzą sobie z oceną jakości.

Link o nazwie Czytaj więcej może technicznie mieć dostępną nazwę. Przycisk oznaczony OK może być poprawny. Podpowiedź formularza może być obecna. Ale czy są znaczące w kontekście? Często nie.

Dostępne nazwy powinny mówić użytkownikom, co się stanie albo co dany element reprezentuje. To wymaga osądu. Wymaga też testowania z interfejsem, nie tylko z kodem.

3. Obsługa błędów

Formularze są pełne błędów dostępności, które skanery wykrywają tylko częściowo.

Narzędzie może oznaczyć pole bez etykiety. Może nie wychwycić, że komunikat walidacyjny pojawia się za późno, znika zbyt szybko, nie jest ogłaszany czytnikom ekranu albo mówi Nieprawidłowe dane, kiedy powinien mówić Hasło musi mieć co najmniej 12 znaków.

Dobra obsługa błędów to projektowanie interakcji. Wymaga ręcznego testowania i, najlepiej, testów z użytkownikami.

4. Adaptacja wizualna

WCAG zawiera wymagania dotyczące zmiany rozmiaru tekstu, reflow, kontrastu, odstępów i nieopierania się na pojedynczej wskazówce sensorycznej. Część z tego można sprawdzić automatycznie, ale prawdziwe pytanie brzmi, czy interfejs pozostaje użyteczny w zmienionych warunkach.

Spróbuj powiększenia 200%. Spróbuj zmiany rozmiaru tekstu w przeglądarce. Spróbuj trybu wysokiego kontrastu lub forced colors mode. Spróbuj wąskich szerokości viewportu. Spróbuj reduced motion. Wiele stron, które wyglądają dopracowanie przy ustawieniach domyślnych, szybko się psuje, gdy użytkownicy egzekwują swoje preferencje.

5. Jasność treści

Żadne automatyczne narzędzie dostępności nie potrafi w pełni ocenić, czy treść jest zrozumiała.

Może oznaczyć brakujące nagłówki lub niejasny tekst linku. Nie może wiedzieć, czy strona jasno wyjaśnia proces, czy etykiety odpowiadają oczekiwaniom użytkowników, ani czy gęsty tekst tworzy możliwe do uniknięcia obciążenie poznawcze.

Dostępność nie dotyczy tylko kompatybilności z technologiami wspomagającymi. Chodzi też o ograniczanie tarcia dla osób będących pod presją, używających nieznanego języka, zmagających się z ograniczeniami uwagi lub przechodzących przez złożone zadania.

Lepszy proces testowania

Zrównoważony proces dostępności ma warstwy.

Uruchamiaj automatyczne kontrole stale

Używaj automatycznych testów w development, pull requestach, podglądach komponentów i CI. Powinny być nudne, szybkie i nienegocjowalne. Nowe brakujące etykiety i nieprawidłowe ARIA nie powinny wymagać kwartalnego audytu, żeby je wykryć.

Traktuj te błędy jak błędy lintingu. Celem nie jest heroizm; celem jest zapobieganie regresjom.

Dodaj ręczne testowanie klawiaturą

Dla każdego istotnego przepływu użytkownika testuj bez myszy. Obejmuje to nawigację, wyszukiwanie, tworzenie konta, checkout, filtrowanie, modale, menu i wysyłanie formularzy.

Co najmniej zweryfikuj:

• Każdy element interaktywny jest osiągalny
• Fokus jest zawsze widoczny
• Kolejność fokusu jest logiczna
• Oczekiwane klawisze działają
• Escape zamyka nakładki, które można zamknąć
• Fokus jest zarządzany po otwarciu i zamknięciu komponentów
• Nie istnieje żadna pułapka klawiaturowa

Ten jeden nawyk wykrywa dużą klasę problemów, które automatyczne skany pomijają.

Testuj z co najmniej jednym czytnikiem ekranu

Nie musisz zostać ekspertem w używaniu czytników ekranu, żeby nauczyć się użytecznych rzeczy. Potrzebujesz jednak pokory. Testowanie z czytnikiem ekranu ma krzywą uczenia się, a początkujący mogą błędnie diagnozować problemy.

Mimo to podstawowe testowanie z VoiceOver, NVDA lub JAWS może ujawnić zepsute nazwy, mylącą kolejność czytania, nieogłaszane aktualizacje i problemy z landmarks, których skaner może nie wychwycić.

Połącz to z semantycznym HTML. Im więcej natywnych elementów używasz, tym mniej krucha staje się Twoja dostępność.

Przeglądaj treść i stany

Sprawdzaj stany puste, ładowania, błędu, wyłączone, komunikaty sukcesu i błędy uprawnień. Błędy dostępności często ukrywają się poza szczęśliwą ścieżką.

Przeglądaj też rzeczywiste słowa. Etykiety, nagłówki, instrukcje i komunikaty błędów są częścią interfejsu.

Uwzględnij użytkowników z niepełnosprawnościami, gdy stawka jest wysoka

W przypadku krytycznych przepływów ręczny ekspercki przegląd nie wystarczy. Testy z użytkownikami z niepełnosprawnościami znajdują problemy, których zespoły nie przewidują. Jest to szczególnie ważne dla usług publicznych, ochrony zdrowia, finansów, edukacji i każdego przepływu, w którym wykluczenie ma poważne konsekwencje.

Automatyczne testowanie się skaluje. Testowanie z ludźmi rozumie.

Jak odpowiedzialnie interpretować wyniki automatyczne

Nie pytaj: Czy przeszliśmy?

Zadawaj lepsze pytania:

• Jakie kategorie problemów to narzędzie potrafi wykryć?
• Które szablony i stany przeskanowało?
• Czy działało po interakcjach, czy tylko przy początkowym ładowaniu?
• Czy naruszenia są grupowane według przyczyny źródłowej, czy liczone wielokrotnie?
• Które błędy blokują użytkownikom wykonanie zadań?
• Co nadal wymaga ręcznego przeglądu?

Ta rama zmienia rozmowę. Automatyczne narzędzia stają się dowodem, nie autorytetem.

Pomaga to też zespołom unikać jałowej pracy. Naprawa jednego komponentu może usunąć setki powtarzających się naruszeń. Z kolei strona z tylko jednym zgłoszonym problemem może nadal zawierać poważną pułapkę klawiaturową. Liczby nie są wpływem.

Praktyczny standard: automatyzuj oczywiste, ręcznie testuj doświadczenie

Najlepsze zespoły od dostępności nie są przeciwko narzędziom. Są przeciwko fantazji.

Automatyzują to, co maszyny potrafią niezawodnie wykryć. Ręcznie testują to, co zależy od zachowania i znaczenia. Używają standardów takich jak WCAG jako wspólnej podstawy, nie jako substytutu korzystania z produktu.

Jeśli Twój obecny proces to tylko automatyczny skan przed wydaniem, ulepsz go w tej kolejności:

1. Dodaj automatyczne kontrole wcześniej w development.
2. Ręcznie przetestuj klawiaturą kluczowe przepływy.
3. Przejrzyj nazwy, etykiety, błędy i instrukcje.
4. Przetestuj typowe komponenty z czytnikiem ekranu.
5. W przypadku ścieżek wysokiego ryzyka włącz testy eksperckie i z użytkownikami.

To nie jest proces idealny. Jest realistyczny. I znajdzie znacznie więcej niż zielony wynik dostępności kiedykolwiek znajdzie.