Audyt dostępności nie jest skanem strony ani zestawieniem procentowego wyniku. Jest badaniem wybranych stron, komponentów i procesów z użyciem kilku metod, zakończonym wnioskami możliwymi do wdrożenia. Jego wartość zależy od doboru próby, kompetencji badających, opisu wpływu na użytkowników i możliwości powtórzenia testu po naprawie.
Jak dobrać próbę
Badanie całego serwisu strona po stronie jest zwykle niepotrzebne i kosztowne, ale próba nie może ograniczać się do strony głównej. Powinna obejmować szablony, nawigację, wyszukiwarkę, strony usług, formularze, tabele, multimedia, dokumenty, komponenty interaktywne i systemy zewnętrzne. Należy uwzględnić strony popularne, krytyczne dla wykonania zadania oraz reprezentujące różne sposoby budowy.
Procesy bada się od początku do końca. W systemie biletowym dostępna lista wydarzeń nie ma znaczenia, jeżeli wybór miejsca, płatność lub pobranie biletu blokują użytkownika klawiatury. W formularzu trzeba sprawdzić wprowadzanie poprawnych i błędnych danych, walidację, powrót do pola i potwierdzenie.
Automaty i badanie manualne
Narzędzia automatyczne wykrywają problemy kodu możliwe do jednoznacznego zdefiniowania. Są szybkie, powtarzalne i przydatne w testach regresji. Nie oceniają jednak całego standardu. Nie potrafią ustalić, czy tekst alternatywny przekazuje właściwy sens, czy kolejność fokusu odpowiada zadaniu ani czy komunikat jest zrozumiały.
Badanie manualne obejmuje klawiaturę, powiększenie, zmianę układu, kontrast, strukturę, nazwy, role i stany komponentów oraz technologie asystujące. Samo naciskanie klawisza Tab nie jest pełnym testem klawiatury. Trzeba wykonać zadania, obsłużyć wszystkie elementy, obserwować fokus i sprawdzić brak pułapek.
Testy z użytkownikami uzupełniają audyt ekspercki. Pokazują rzeczywiste strategie i problemy, ale niewielka grupa nie potwierdza zgodności ze wszystkimi kryteriami. Dlatego nie należy przeciwstawiać obu metod.
Co powinien zawierać raport
Każdy problem potrzebuje identyfikatora, lokalizacji, opisu, sposobu odtworzenia, wpływu na użytkownika, powiązanego wymagania, zasięgu i rekomendowanego kierunku naprawy. Zrzut ekranu może pomóc, ale nie zastępuje instrukcji testu. Raport powinien rozróżniać błąd globalny, lokalny problem treści i ograniczenie systemu zewnętrznego.
Priorytet nie powinien wynikać wyłącznie z poziomu kryterium. Liczy się blokowanie zadania, liczba wystąpień, znaczenie usługi i możliwość globalnej naprawy. Audytor powinien wskazać zależności, lecz nie musi projektować całej implementacji bez znajomości architektury. Wykonawca naprawy odpowiada za rozwiązanie zgodne z systemem, a retest potwierdza efekt.
Audyt aplikacji i dokumentów
Aplikacja mobilna wymaga testów na rzeczywistych systemach, z czytnikami ekranu, skalowaniem tekstu, zmianą orientacji, gestami i klawiaturą ekranową. Dokumenty PDF wymagają analizy znaczników, kolejności, tabel, metadanych oraz odczytu. Są to odrębne kompetencje i nie powinny być automatycznie dopisywane do audytu strony bez odpowiedniego zakresu.
Retest i plan naprawczy
Retest odpowiada na pytanie, czy wskazany problem usunięto bez utworzenia nowych barier. Powinien korzystać z tej samej metodyki i obejmować wszystkie miejsca użycia komponentu. Częściowy retest potwierdza tylko wskazane poprawki, nie nową pełną zgodność całego serwisu.
Raport trzeba zamienić na zadania z właścicielami, terminami i kryteriami akceptacji. Błędy kodu, treści, dokumentów, umów i procesu wymagają innych działań. Bez tego nawet bardzo dobry audyt pozostaje dokumentem odłożonym na półkę.
Powiązane materiały: Dlaczego automatyczny test nie zastępuje audytu, Testy klawiaturą i Plan naprawczy po audycie.