Raport z audytu opisuje problemy, ale sam ich nie usuwa. Nawet bardzo szczegółowa lista kryteriów WCAG może pozostać bez wpływu na serwis, jeżeli błędy nie zostaną przekształcone w zadania, przypisane do właścicieli i zweryfikowane po naprawie. Plan naprawczy jest pomostem między wynikiem badania a zarządzaniem pracą.
Nie zaczynaj od liczby naruszeń kryteriów
Jedno naruszenie może występować w tysiącach podstron, a kilka kryteriów może wynikać z jednego wadliwego komponentu. Dlatego proste liczenie błędów albo porządkowanie ich według numerów WCAG nie pokazuje rzeczywistego nakładu pracy. Trzeba znaleźć przyczyny wspólne: szablon nagłówka, moduł formularza, sposób generowania PDF, reguły redakcyjne, integrację biletową albo brak kontroli przed publikacją.
Pierwszy podział powinien wskazywać właściciela rozwiązania. Błędy szablonu trafiają do zespołu technicznego lub dostawcy. Problemy dokumentów — do ich autorów i redakcji. Niejasne komunikaty wymagają pracy merytorycznej. Zewnętrzny system może wymagać interwencji umownej, zmiany konfiguracji albo zastąpienia rozwiązania.
Priorytet wynika z wpływu, zasięgu i kontekstu
Najwyższy priorytet mają bariery blokujące wykonanie podstawowej czynności: złożenie wniosku, zakup biletu, odczytanie decyzji, znalezienie kontaktu albo obsługę formularza bez myszy. Następnie należy uwzględnić liczbę użytkowników i stron, częstotliwość występowania oraz możliwość zastosowania jednej poprawki globalnej.
Poziom kryterium WCAG jest ważny, ale nie powinien być jedynym wskaźnikiem. Niewidoczny fokus w całej nawigacji może mieć większy wpływ niż wiele lokalnych błędów w archiwalnych podstronach. Z kolei pojedynczy niedostępny dokument może mieć krytyczne znaczenie, jeżeli jest niezbędny do udziału w naborze kończącym się następnego dnia.
Dobre zadanie opisuje wynik i dowód
Zadanie „poprawić kontrast” jest zbyt ogólne. Powinno wskazać komponent, miejsca występowania, wymagany rezultat, kryterium akceptacji, właściciela, termin i środowisko testowe. Warto dołączyć przykład błędu, ale nie narzucać implementacji, jeżeli wykonawca może zaproponować lepsze rozwiązanie zgodne z architekturą systemu.
Każde zadanie musi przewidywać retest. Zrzut ekranu albo informacja programisty „naprawione” nie potwierdzają działania z klawiaturą, czytnikiem ekranu czy po powiększeniu. Retest powinien odtworzyć warunki audytu i objąć również miejsca korzystające z tego samego komponentu. Poprawka jednego błędu może spowodować regresję w innym obszarze.
Plan obejmuje działania techniczne i organizacyjne
Nie wszystkie problemy kończą się zmianą kodu. Jeżeli redaktorzy nadal publikują plakaty bez tekstu, potrzebują standardu i kontroli. Jeżeli wykonawca dostarcza niedostępne pliki, trzeba zmienić warunki zamówienia. Jeżeli nikt nie zna właściciela formularza, potrzebna jest mapa odpowiedzialności. Plan naprawczy powinien więc zawierać poprawki, zmiany procesu, szkolenia, decyzje zakupowe i przeglądy treści.
Warto podzielić plan na szybkie działania, poprawki wymagające prac rozwojowych oraz zmiany systemowe. Szybkie poprawki nie mogą jednak całkowicie wyprzeć trudniejszych problemów. Publiczny licznik „zamknęliśmy 80% zadań” może wyglądać dobrze, choć pozostałe 20% nadal blokuje kluczowe usługi.
Postęp musi zmieniać deklarację i praktykę utrzymania
Po zakończeniu partii napraw trzeba zaktualizować stan zasobów, dokumentację i — jeżeli zmienił się stan faktyczny — deklarację dostępności. Dobrą praktyką jest przegląd po kilku tygodniach lub po następnej aktualizacji systemu, aby sprawdzić trwałość rozwiązania.
Plan naprawczy nie jest jednorazowym arkuszem po audycie. Powinien stać się częścią backlogu produktu lub systemu utrzymania serwisu. Nowe funkcje, dokumenty i integracje muszą przechodzić kontrolę przed wdrożeniem, inaczej organizacja będzie stale odtwarzać tę samą listę błędów.
Źródła
- Jak zarządzać dostępnością cyfrową: https://www.gov.pl/web/dostepnosc-cyfrowa/jak-zarzadzac-dostepnoscia-cyfrowa
- Dobre praktyki dostępności cyfrowej: https://www.gov.pl/web/dostepnosc-cyfrowa/jakie-sa-dobre-praktyki-z-zakresu-dostepnosci-cyfrowej
- WCAG 2.2 — materiały pomocnicze: https://www.w3.org/WAI/WCAG22/quickref/