Jak stworzyć program testowania dostępności webowej oparty na rolach

Program testowania dostępności powinien działać jak część systemu dostarczania zmian, a nie jak końcowy audyt zamawiany u jednej osoby. Zanim praca się rozpocznie, zespół określa objęte nią ścieżki, komponenty i treści, dobiera wymagane metody oraz wskazuje wykonawcę, osobę akceptującą wynik i właściciela ponownego testu. Dzięki temu do przeglądu wydania trafiają nie tylko raporty ze skanera, lecz także dowody użycia klawiatury, oceny znaczenia treści, przeformatowania i — tam, gdzie to potrzebne — działania technologii wspomagających.

Kiedy testowanie dostępności staje się programem, a nie końcowym audytem?

Testowanie staje się programem, gdy różne rodzaje dowodów powstają na właściwych etapach pracy, a odpowiedzialność za ich zaakceptowanie pozostaje jednoznaczna. W3C zaleca ocenę dostępności wcześnie i przez cały okres tworzenia lub przebudowy, ponieważ wtedy problemy łatwiej korygować. Publiczna macierz Section508.gov pokazuje jeden z możliwych sposobów rozdzielenia działań między produkt, projekt, rozwój, QA, treści, specjalistów i nadzór. Jest inspiracją operacyjną, nie uniwersalnym wymogiem dla polskich firm.

• Automatyczne wykrywanie odpowiada, które programowo sprawdzalne warunki narzędzie potrafiło znaleźć w określonym zakresie.
• Ręczna kontrola zgodności ocenia zachowanie, strukturę i znaczenie wymagające interpretacji przez przygotowaną osobę.
• Test technologii wspomagającej sprawdza zgodność wybranej konfiguracji podczas reprezentatywnego zadania i jego stanów.
• Badanie z osobami z niepełnosprawnościami ujawnia bariery użyteczności oraz potrzeby, których sama kontrola standardu może nie pokazać.

Żaden z tych dowodów nie zastępuje pozostałych. W3C podkreśla, że samo narzędzie nie ustala zgodności serwisu ze standardami i potrzebna jest kompetentna ocena człowieka. Projektanci nadal odpowiadają za decyzje projektowe, autorzy za sens treści, a programiści za implementację i kontrole lokalne. Lider dostępności utrzymuje politykę, metody, szkolenia oraz pomaga rozstrzygać trudne przypadki, zamiast wykonywać każdy test osobiście i stawać się wąskim gardłem.

Jak dopasować głębokość testów do wydawanej zmiany?

Głębokość testów powinna rosnąć wraz z zakresem interakcji, ponownym wykorzystaniem rozwiązania, nowością, znaczeniem ścieżki i możliwym wpływem na użytkowników. Najpierw trzeba zinwentaryzować zmieniane widoki, komponenty, szablony, dokumenty, media, kontrolki, stany oraz obsługiwane technologie. Dopiero potem dobiera się metody. Jest to praktyczna drabina planowania, a nie oficjalny standard ryzyka, stała punktacja ani podstawa do uznania nietestowanej części serwisu za zgodną.

• Zmiana wyłącznie treściowa wymaga ludzkiej oceny treści i odpowiednich kontroli automatycznych; przy zmianie struktury, mediów, dokumentów, kontrolek lub znaczenia zadania dochodzą właściwe testy klawiatury, powiększenia albo technologii wspomagających.
• Zmiana wizualna lub układu wymaga przeglądu projektu, automatyzacji i kontroli powiększenia lub przeformatowania; gdy dotyka interakcji, obejmuje również fokus i obsługę klawiaturą.
• Zmiana komponentu lub interakcji otrzymuje kryteria akceptacji przed implementacją, kontrole programisty, niezależne testy QA odpowiednich stanów i regresję, jeżeli rozwiązanie jest używane ponownie.
• Nowy szablon, krytyczna ścieżka lub duże wydanie korzysta ze wszystkich właściwych warstw, reprezentatywnych zadań, przeszkolonych testerów technologii wspomagających, próbkowanej oceny zgodności i odpowiednio wczesnych badań z użytkownikami.

Podobną zasadę różnicowania głębokości przedstawia Section508.gov, od kontroli automatycznych i punktowych po testy komponentowe oraz kompleksowe, osobno wskazując monitorowanie i badania z osobami z niepełnosprawnościami. Nie oznacza to, że niski poziom ryzyka pozwala pominąć każdy dowód. Gdy potrzebna jest szersza ocena zgodności, WCAG-EM prowadzi przez określenie celu i zakresu, rozpoznanie kluczowych widoków i funkcji, dobór reprezentatywnej próby, ocenę oraz raport.

Co wpisać do macierzy własności testów i kto przejmuje kolejne etapy?

Macierz powinna dla każdej warstwy określać wyzwalacz i zakres, najwcześniejszy użyteczny etap, odpowiedzialnego wykonawcę, osobę rozliczaną z akceptacji, wymagane kompetencje i środowisko, zachowywany dowód, regułę blokady oraz właściciela naprawy i ponownego testu. Takie pola odpowiadają elementom powtarzalnej metodyki wskazywanym w wytycznych Section508.gov: momentowi testu, wykonawcy, głębokości, kwalifikacjom, środowisku, metodzie i śledzeniu wyniku. Własna macierz organizacji powinna jednak odzwierciedlać jej realne role.

Projektant odpowiada za dostępne decyzje projektowe, redaktor za znaczenie komunikatów, programista za implementację, a QA za plan i niezależne wykonanie uzgodnionych kontroli. Badacz prowadzi etyczne badania z osobami z niepełnosprawnościami, specjalista dostępności utrzymuje metody i doradza przy trudnych ustaleniach, zaś upoważniony właściciel produktu lub wydania podejmuje decyzję o publikacji. W małym zespole jedna osoba może nosić kilka takich „czapek”, ale przy pracy wyższego ryzyka warto zachować przeszkolony lub niezależny przegląd.

Dostępność przestaje być cudzą kontrolą końcową, gdy każda zmiana ma nazwane dowody, odpowiedzialność i drogę ponownego testu.

Co powinny naprawdę sprawdzać podstawowe kontrole dostępności?

Każda podstawowa kontrola powinna sprawdzać wykonanie konkretnego zadania lub właściwość treści, a nie jedynie obecność technicznego elementu. Automatyzacja wykrywa powtarzalne warunki możliwe do zaprogramowania, lecz czysty raport nie rozstrzyga o zgodności. Ludzki przegląd ocenia, czy tytuły, nagłówki, etykiety, linki, instrukcje, błędy, napisy, transkrypcje i teksty alternatywne przekazują użyteczne znaczenie w danym kontekście. WCAG zawiera wymagania dotyczące takiego znaczenia, więc samo istnienie pola lub etykiety nie wystarcza.

• W kontroli klawiatury wykonaj reprezentatywne zadanie, uruchom każdą właściwą kontrolkę, prześledź oczekiwaną kolejność fokusu, sprawdź jego widoczność i brak całkowitego zasłonięcia, wejdź do złożonych komponentów i opuść je, obserwuj zmiany stanu oraz odzyskiwanie po błędach.
• W kontroli treści czytaj komunikaty w kolejności zadania i pytaj, czy nazwa, instrukcja, link lub błąd pozwala zrozumieć cel oraz następny krok bez wiedzy autora.
• Przy powiększeniu tekstu sprawdź właściwy przypadek do 200%, uwzględniając wyjątki kryterium, oraz obserwuj utratę treści, funkcji, fokusu i możliwość ukończenia zadania.
• Przy przeformatowaniu oddziel warunek szerokości 320 pikseli CSS bez przewijania poziomego od warunku wysokości 256 pikseli CSS bez przewijania pionowego, pamiętając o wyjątku dla układów wymagających dwóch wymiarów.

WCAG 2,2 wymaga obsługi funkcjonalności klawiaturą z określonym wyjątkiem dla wejścia zależnego od ścieżki ruchu oraz możliwości przeniesienia fokusu poza komponent. Na poziomie AA wskaźnik fokusu musi być widoczny, a treść utworzona przez autora nie może go całkowicie zasłonić. Podczas kontroli powiększenia i przeformatowania nie chodzi więc o podobieństwo piksel w piksel, lecz o zachowanie informacji, funkcjonalności i orientacji: brak zasłonięć, ukrytego fokusu, nieoczekiwanych zmian poza widokiem oraz niedozwolonego przewijania.

Kiedy dodać technologie wspomagające, badania z użytkownikami i ocenę zgodności?

Dodatkowe metody należy włączać do reprezentatywnych i bardziej ryzykownych zmian wtedy, gdy ich wyniki mogą jeszcze wpłynąć na projekt. Przeszkolony tester czytnika ekranu lub innej technologii wspomagającej sprawdza zadania, stany i kompatybilność wybranej konfiguracji. Nie symuluje w ten sposób doświadczenia wszystkich niewidomych osób ani nie potwierdza pełnej zgodności. GOV.UK zaleca takie testowanie w toku rozwoju, zwłaszcza po istotnych funkcjach i większych zmianach, z użyciem reprezentatywnych zadań.

• Dobierz aktualne połączenia systemu, przeglądarki i technologii z danych o odbiorcach, technologii produktu, deklarowanego wsparcia i znanego ryzyka, zamiast kopiować uniwersalną listę.
• Zapisz zadanie, wpływ na użytkownika, oczekiwane zachowanie, system, przeglądarkę, technologię i wersję, materiał dowodowy, właściciela naprawy oraz wynik ponownego testu.
• W badaniu z osobami z niepełnosprawnościami usuń wcześniej istotne oczywiste bariery, lecz zapraszaj uczestników już do prototypów, jeżeli ich informacja może zmienić kierunek rozwiązania.

Badania z osobami z niepełnosprawnościami mogą ujawnić problemy użyteczności, których nie pokazuje sama ocena zgodności, ale nie zastępują oceny standardu. W3C opisuje zarówno nieformalną informację o prototypie, jak i formalne badania zadaniowe dopasowane do etapu projektu oraz przestrzega przed uogólnianiem doświadczenia jednej osoby na całą grupę. Szersza ocena zgodności powinna natomiast określić cel i zakres, rozpoznać kluczowe widoki i funkcje, dobrać reprezentatywne pokrycie, przeprowadzić ocenę i udokumentować ograniczenia. Nawet najwyższy poziom WCAG nie odpowiada na potrzeby każdej osoby.

Jak dowody powinny sterować wydaniem i doskonaleniem programu?

Wydanie powinno zależeć od kompletu dowodów wymaganych dla danej klasy zmiany, a nie od jednego globalnego wyniku. Właściwe kontrole muszą być zakończone, ustalenia uznane za blokujące — naprawione i ponownie sprawdzone, a zapis powinien wskazywać zakres, metodę, środowisko, rezultat, właściciela, decyzję i status retestu. QA i specjaliści dostarczają niezależnych dowodów, twórcy naprawiają swoje rozwiązania, natomiast upoważniony właściciel produktu lub wydania podejmuje i dokumentuje decyzję o akceptacji.

Jeżeli polityka organizacji dopuszcza wyjątek, jego zapis powinien zawierać upoważnionego właściciela, uzasadnienie, dotkniętych użytkowników, środek ograniczający skutki, termin wygaśnięcia i działanie następcze. Wyjątek nie zmienia wyniku testu i nie ustanawia zgodności. Po publikacji zgłoszone bariery oraz powtarzające się defekty warto powiązać z macierzą, testami regresyjnymi, szkoleniami, szablonami i przyszłymi klasami zmian. Taka pętla odpowiada zaleceniu W3C, by nie ograniczać oceny dostępności do jednego etapu końcowego.

1. Wybierz jedną krytyczną ścieżkę i opisz wymagane warstwy testów.
2. Nazwij właścicieli ról i zapewnij im potrzebne szkolenie.
3. Dodaj szablony dowodów oraz właściwą automatyzację.
4. Skalibruj reguły blokady na rzeczywistych ustaleniach.
5. Przeglądaj powtarzalne typy defektów i ich przyczyny.
6. Rozszerzaj pokrycie dopiero po domknięciu pierwszej ścieżki.

Najlepszym początkiem jest kompletna ścieżka dowodowa dla jednego ważnego zadania, a nie szeroka macierz wypełniona niejasnymi deklaracjami. Gdy zespół nie potrafi ocenić złożonych interakcji, zachowania technologii wspomagających, reprezentatywności próby lub spornego ustalenia, powinien skorzystać z przeszkolonego ewaluatora dostępności. Badania z osobami z niepełnosprawnościami warto powierzyć doświadczonemu badaczowi użytkowników. Interpretacje obowiązków prawnych i deklaracje zgodności dla konkretnej jurysdykcji wymagają natomiast porady odpowiednio wykwalifikowanego prawnika.