Automatyczne narzędzia do testowania dostępności są szybkie, tanie i łatwe w użyciu. W ciągu kilku sekund potrafią wskazać brakujące teksty alternatywne, błędne etykiety formularzy, problemy z kontrastem albo nieprawidłową strukturę nagłówków. Wynik często przyjmuje formę raportu, liczby błędów lub punktowej oceny strony.
Taki rezultat może jednak tworzyć fałszywe poczucie bezpieczeństwa. Strona może otrzymać wysoki wynik i nadal zawierać bariery uniemożliwiające wykonanie podstawowych zadań. Automat analizuje kod według określonych reguł. Nie rozumie celu strony, znaczenia treści ani tego, czy użytkownik rzeczywiście może załatwić sprawę.
Dlatego automatyczny test jest dobrym narzędziem pomocniczym, ale nie zastępuje pełnego audytu WCAG.
Automat sprawdza tylko to, co potrafi jednoznacznie ocenić
Część wymagań dostępności można sprawdzić technicznie. Program może wykryć, że obraz nie ma tekstu alternatywnego, pole formularza nie posiada etykiety albo nagłówki zostały użyte w nieprawidłowej kolejności.
Inne wymagania wymagają jednak oceny znaczenia i kontekstu.
Narzędzie może potwierdzić, że obraz ma opis, ale nie oceni wiarygodnie, czy ten opis przekazuje właściwą informację. Tekst alternatywny „grafika” formalnie istnieje, lecz nie wyjaśnia użytkownikowi, co przedstawia obraz.
Podobnie automat może wykryć obecność etykiety pola, ale nie stwierdzi, czy nazwa jest zrozumiała. Pole oznaczone jako „Dane dodatkowe 2” może być technicznie opisane, a jednocześnie całkowicie niejasne dla użytkownika.
Automatyczne narzędzie rozpoznaje obecność elementu. Audytor ocenia jego jakość i funkcję.
Wysoki wynik punktowy nie oznacza zgodności z WCAG
Niektóre narzędzia przedstawiają dostępność jako wynik od 0 do 100 punktów. Taki sposób prezentacji jest wygodny, ale może być mylący.
Wynik zależy od reguł przyjętych przez twórców konkretnego narzędzia. Dwa programy mogą ocenić tę samą stronę inaczej. Jeden uwzględni określony problem, drugi go pominie albo nada mu inną wagę.
Ocena 95 punktów nie oznacza, że strona jest zgodna z WCAG w 95 procentach. Standard nie działa w ten sposób. Jedna poważna bariera może uniemożliwić korzystanie z usługi mimo wysokiego wyniku ogólnego.
Strona może mieć poprawne kolory, nagłówki i opisy obrazów, a jednocześnie niedostępny formularz służący do złożenia wniosku. Z perspektywy użytkownika ten jeden problem może mieć większe znaczenie niż kilkadziesiąt poprawnych elementów.
Punktacja może pomagać w obserwowaniu zmian, ale nie powinna być traktowana jako dowód zgodności.
Automat nie sprawdzi, czy stronę da się obsłużyć klawiaturą
Jednym z podstawowych elementów audytu jest przejście przez stronę bez używania myszy.
Trzeba sprawdzić, czy każdy link, przycisk, formularz, menu i okno można obsłużyć za pomocą klawiatury. Fokus powinien być widoczny, kolejność przechodzenia logiczna, a użytkownik nie może zostać uwięziony w żadnym komponencie.
Automat może wykryć niektóre błędy techniczne, ale nie odtworzy w pełni rzeczywistego sposobu korzystania.
Nie oceni wiarygodnie, czy:
- menu rozwija się i zamyka w przewidywalny sposób,
- fokus trafia do otwartego okna,
- po zamknięciu wraca do właściwego miejsca,
- użytkownik nie przechodzi po elementach ukrytych pod warstwą,
- kolejność fokusu odpowiada układowi strony,
- aktywny element nie jest zasłonięty przez nagłówek lub pasek cookies.
Takie problemy ujawniają się dopiero podczas ręcznego testu.
Narzędzie nie rozumie procesu użytkownika
Strona internetowa nie jest zbiorem niezależnych podstron. Użytkownik wykonuje na niej zadania.
Może szukać informacji o naborze, pobierać dokument, wypełniać formularz, dodawać załącznik, wybierać termin, dokonywać płatności albo oczekiwać potwierdzenia wysłania danych.
Automatyczny skan zwykle analizuje pojedynczy widok lub fragment kodu. Nie sprawdza całego procesu od początku do końca.
Nie oceni, czy użytkownik:
- rozumie, od czego zacząć,
- wie, jakie dane będą potrzebne,
- może poprawić błąd bez utraty informacji,
- otrzymuje jasne potwierdzenie zakończenia,
- nie musi wielokrotnie wpisywać tych samych danych,
- może wrócić do wcześniejszego kroku,
- ma dostęp do pomocy w odpowiednim momencie.
Audyt musi obejmować rzeczywiste scenariusze korzystania. Dopiero wtedy można ustalić, czy strona nie tylko wygląda poprawnie, ale rzeczywiście pozwala ukończyć zadanie.
Automatyczny test nie oceni jakości treści
Dostępność cyfrowa zależy również od sposobu pisania.
Tekst może mieć prawidłowe nagłówki i kontrast, ale być niezrozumiały z powodu urzędowego języka, niejasnych skrótów, długich zdań i braku logicznej struktury.
Narzędzie nie oceni wiarygodnie, czy tytuł strony odpowiada treści, instrukcja formularza jest jednoznaczna, a komunikat błędu wyjaśnia sposób poprawy.
Może wykryć link opisany jako „kliknij tutaj”, ale nie zawsze rozpozna, że inny tekst również jest niejednoznaczny. Odnośnik „Więcej informacji” może być poprawny w jednym kontekście i całkowicie niejasny w innym.
Podobnie automat nie rozumie, czy nagłówek „Pozostałe” rzeczywiście pomaga porządkować treść ani czy nazwa przycisku odpowiada wykonywanej czynności.
Ocena treści wymaga znajomości kontekstu i potrzeb odbiorcy.
Tekst alternatywny wymaga decyzji człowieka
Automat może wykryć brak tekstu alternatywnego albo bardzo podejrzany opis. Nie potrafi jednak pewnie ustalić, jaką funkcję pełni obraz.
Zdjęcie może być informacyjne, dekoracyjne, pełnić funkcję linku albo przedstawiać dane. Każda z tych sytuacji wymaga innego podejścia.
Opis „spotkanie w sali konferencyjnej” może być wystarczający w jednym artykule, ale niewłaściwy w materiale, w którym istotne jest podpisanie konkretnej umowy przez wskazane osoby.
Wykres może mieć opis alternatywny, ale użytkownik nadal nie pozna danych ani najważniejszego wniosku.
Plakat może zostać opisany jako „grafika wydarzenia”, mimo że zawiera datę, miejsce i program niewystępujące w tekście strony.
Automat sprawdzi obecność opisu. Audytor musi ocenić, czy użytkownik otrzymuje równoważną informację.
Kontrast nie zawsze daje się ocenić automatycznie
Pomiar kontrastu tekstu względem jednolitego tła jest jednym z obszarów dobrze obsługiwanych przez narzędzia automatyczne. Problem zaczyna się przy bardziej złożonych projektach.
Tekst może znajdować się na zdjęciu, gradiencie, filmie albo ruchomym tle. Kontrast może być wystarczający w jednym fragmencie i niewystarczający w innym.
Program może nie rozpoznać poprawnie tekstu umieszczonego wewnątrz obrazu. Nie oceni także, czy napis pozostaje czytelny po zmianie zdjęcia w karuzeli.
Niektóre elementy zmieniają kolor po najechaniu, aktywacji lub przejściu fokusu. W stanie początkowym są poprawne, ale po interakcji kontrast znika.
Dlatego pomiar automatyczny powinien zostać uzupełniony ręcznym sprawdzeniem wszystkich stanów elementu i rzeczywistego tła.
Formularz może przejść skan i nadal być niedostępny
Formularze są szczególnie dobrym przykładem ograniczeń automatyzacji.
Narzędzie może potwierdzić, że pola mają etykiety, przycisk posiada nazwę, a formularz nie zawiera podstawowych błędów w kodzie.
Nie oznacza to jednak, że proces jest dostępny.
Trzeba ręcznie sprawdzić:
- czy etykiety są zrozumiałe,
- czy instrukcje pojawiają się przed wykonaniem czynności,
- czy pola obowiązkowe są jasno oznaczone,
- czy komunikaty błędów wskazują konkretny problem,
- czy użytkownik nie traci wpisanych danych,
- czy kalendarz działa bez myszy,
- czy załącznik można dodać bez przeciągania,
- czy formularz działa na telefonie,
- czy potwierdzenie wysłania jest jednoznaczne.
Automat może zauważyć brak etykiety. Nie oceni, czy użytkownik rozumie cały proces.
Test automatyczny nie zastąpi czytnika ekranu
Kod może wyglądać poprawnie w raporcie, ale zachowywać się inaczej w rzeczywistej technologii wspomagającej.
Czytnik ekranu pokazuje, jak strona jest odczytywana osobie niewidomej. Pozwala sprawdzić kolejność treści, nazwy przycisków, nagłówki, regiony strony, formularze, komunikaty dynamiczne i działanie elementów interaktywnych.
Automat może wskazać obecność atrybutów technicznych, ale nie potwierdzi w pełni, czy komunikat jest przekazywany w odpowiednim momencie ani czy komponent zachowuje się logicznie.
Przykładowo po dodaniu pliku na ekranie pojawia się informacja „Załącznik został dodany”. Jeśli czytnik ekranu jej nie ogłasza, użytkownik może nie wiedzieć, czy operacja się udała.
Podobnie rozwinięcie sekcji może być wizualnie oczywiste, ale technologia wspomagająca może nie otrzymać informacji o zmianie stanu.
Test z czytnikiem ekranu nie powinien być jedyną metodą badania, ale jest ważnym elementem audytu manualnego.
Automat nie oceni widoku mobilnego w rzeczywistych warunkach
Narzędzia mogą analizować stronę przy różnych szerokościach ekranu i wykrywać część problemów responsywnych. Nie odtwarzają jednak wszystkich warunków korzystania z telefonu.
Nie sprawdzą w pełni wpływu:
- klawiatury ekranowej,
- zwiększonego rozmiaru tekstu,
- orientacji poziomej,
- gestów powiększania,
- ustawień systemowych,
- obsługi dotykowej,
- małego obszaru widocznego po otwarciu komunikatów.
Strona może przejść skan, a jednocześnie ukrywać przycisk wysyłania pod klawiaturą, blokować obrót ekranu albo wymuszać poziome przewijanie.
Rzeczywiste urządzenie ujawnia problemy, których nie widać w samym kodzie.
Narzędzie nie oceni logicznej kolejności treści
Wielokolumnowy układ może wyglądać prawidłowo na ekranie, ale mieć przypadkową kolejność w kodzie.
Automat może wykryć niektóre problemy strukturalne, lecz nie zawsze ustali, czy kolejność odczytu odpowiada znaczeniu treści.
Na stronie wydarzenia przycisk zapisów może zostać odczytany przed informacją o terminie i warunkach udziału. W karcie usługi cena może pojawić się przed nazwą. W formularzu komunikat może zostać odczytany po elementach, których nie dotyczy.
Ocena logicznej kolejności wymaga przejścia przez stronę bez patrzenia na jej układ wizualny.
Automatyczny raport nie określi realnego priorytetu błędów
Narzędzie może podać liczbę problemów, ale nie zna znaczenia poszczególnych podstron i usług.
Brak opisu przy stu dekoracyjnych miniaturach może zostać przedstawiony jako poważniejszy problem liczbowy niż jeden niedostępny formularz składania wniosku.
Z perspektywy użytkownika jest odwrotnie. Jedna bariera blokująca usługę może mieć znacznie większe znaczenie niż wiele drobnych usterek.
Priorytet powinien uwzględniać:
- wpływ na możliwość wykonania zadania,
- znaczenie prawne treści,
- liczbę użytkowników,
- częstotliwość występowania,
- ryzyko powrotu błędu,
- możliwość zastosowania rozwiązania alternatywnego.
Automat zlicza błędy. Audytor ocenia ich rzeczywiste konsekwencje.
Skan jednej podstrony nie opisuje całego serwisu
Serwis może zawierać tysiące podstron, wiele szablonów, dokumenty, formularze i systemy zewnętrzne.
Przeskanowanie strony głównej nie mówi nic o dostępności BIP, formularza rezerwacji, wyszukiwarki, archiwum, wyników naboru ani dokumentów PDF.
Nawet skanowanie całej domeny nie gwarantuje pełnej oceny. Narzędzie może nie wejść do obszarów wymagających logowania, nie wykona procesu wieloetapowego i nie uruchomi wszystkich stanów dynamicznych.
Pełny audyt wymaga doboru reprezentatywnej próbki. Powinny znaleźć się w niej różne typy treści i funkcji, nie tylko najpopularniejsze adresy.
Próbka może obejmować:
- stronę główną,
- stronę informacyjną,
- listę aktualności,
- pojedynczy artykuł,
- wyszukiwarkę,
- formularz,
- dokument,
- tabelę,
- materiał wideo,
- usługę zewnętrzną,
- stronę błędu.
Dobór próbki jest decyzją analityczną, której automat sam nie podejmie prawidłowo.
Dokumenty wymagają osobnego badania
Automatyczny skaner strony internetowej nie oceni szczegółowo dostępności plików Word, PDF, Excel ani prezentacji.
Może wykryć, że na stronie znajduje się link do pliku, ale nie sprawdzi jego struktury.
Dokument może zawierać:
- brak nagłówków,
- nieprawidłową kolejność odczytu,
- skan bez warstwy tekstowej,
- nieopisane grafiki,
- źle oznaczone tabele,
- brak określonego języka,
- pola formularza bez nazw,
- linki bez opisowego tekstu.
Audyt serwisu publicznego powinien obejmować także reprezentatywną próbkę dokumentów. W przeciwnym razie wynik może pomijać jedną z najczęstszych barier występujących na stronach urzędowych.
Test automatyczny jest bardzo użyteczny w kontroli bieżącej
Ograniczenia narzędzi nie oznaczają, że należy z nich rezygnować.
Automatyczne testy są bardzo dobre do regularnej kontroli podstawowych błędów. Można uruchamiać je po aktualizacji strony, zmianie motywu, wdrożeniu nowego modułu albo publikacji większej liczby treści.
Pomagają szybko wykrywać powtarzalne problemy:
- brakujące opisy obrazów,
- nieprawidłowe etykiety,
- błędy w nagłówkach,
- problemy z kontrastem,
- puste linki,
- duplikaty identyfikatorów,
- nieprawidłowe atrybuty języka.
Mogą też wspierać redaktorów przed publikacją i programistów podczas tworzenia komponentów.
Największą wartość mają wtedy, gdy są częścią procesu kontroli, a nie jedynym dowodem zgodności.
Wyniki automatyczne trzeba interpretować
Raport może zawierać błędy, ostrzeżenia i elementy wymagające ręcznej oceny.
Nie każdy komunikat oznacza rzeczywistą niezgodność. Narzędzie może zaznaczyć element, którego nie potrafi jednoznacznie ocenić. Audytor musi sprawdzić kontekst i zdecydować, czy problem faktycznie występuje.
Możliwa jest również sytuacja odwrotna. Brak komunikatu nie oznacza, że element jest poprawny. Program mógł po prostu nie posiadać reguły pozwalającej na ocenę.
Dlatego raport powinien być analizowany, a nie tylko eksportowany i przekazywany jako wynik audytu.
Lista kilkuset komunikatów bez interpretacji nie pomaga zespołowi naprawczemu. Potrzebne są konkretne wskazania: gdzie występuje problem, jakie ma znaczenie, jak go odtworzyć i w jaki sposób należy go usunąć.
Audyt powinien kończyć się planem działania
Celem audytu nie jest samo policzenie błędów.
Dobry raport powinien pozwolić zespołowi technicznemu, redaktorom i kierownictwu podjąć działania. Każda istotna niezgodność powinna być opisana w sposób umożliwiający jej odtworzenie.
Raport powinien wskazywać:
- miejsce wystąpienia,
- wymaganie, którego dotyczy problem,
- sposób sprawdzenia,
- wpływ na użytkownika,
- przykład prawidłowego rozwiązania,
- priorytet naprawy.
Automatyczny raport zwykle nie zawiera pełnego kontekstu organizacyjnego. Nie rozróżnia, czy błąd wynika z motywu strony, działania wtyczki, treści redaktora czy systemu zewnętrznego.
Audyt manualny pozwala przypisać problem do właściwego obszaru i zaplanować naprawę.
Deklaracja zgodności nie może opierać się wyłącznie na skanerze
Podmiot publiczny powinien rzetelnie ocenić stan swojej strony przed określeniem poziomu zgodności w deklaracji dostępności.
Automatyczny test może dostarczyć części informacji, ale nie pozwala wiarygodnie potwierdzić pełnej lub częściowej zgodności całego serwisu.
Jeżeli deklaracja wskazuje pełną zgodność wyłącznie na podstawie wysokiego wyniku w popularnym narzędziu, może nie odpowiadać rzeczywistemu stanowi strony.
Ocena powinna obejmować testy automatyczne, manualne oraz analizę treści i dokumentów. Zakres badania musi odpowiadać wielkości i funkcjom serwisu.
Deklaracja nie jest certyfikatem wygenerowanym przez program. Jest publiczną informacją o rzeczywistym poziomie dostępności.
Najlepszy model łączy automatyzację i pracę człowieka
Automatyczne testy i audyt manualny nie są rozwiązaniami konkurencyjnymi. Pełnią różne funkcje.
Automat szybko przegląda dużą liczbę elementów i wykrywa powtarzalne błędy techniczne. Człowiek ocenia znaczenie, kontekst, procesy i rzeczywiste doświadczenie użytkownika.
Skuteczny audyt może rozpocząć się od skanowania. Wyniki pomagają wytypować obszary wymagające szczególnej uwagi. Następnie potrzebne są testy klawiaturą, czytnikiem ekranu, na urządzeniach mobilnych, przy powiększeniu oraz podczas wykonywania pełnych zadań.
Połączenie metod daje znacznie pełniejszy obraz niż każda z nich osobno.
Automatyczny test wykrywa błędy. Audyt ocenia dostępność
Najważniejsza różnica dotyczy celu badania.
Automatyczne narzędzie odpowiada na pytanie, czy w kodzie występują określone problemy możliwe do rozpoznania przez program.
Audyt odpowiada na znacznie szersze pytanie: czy użytkownik może odnaleźć informację, zrozumieć ją i wykonać potrzebną czynność.
Strona może nie zawierać błędów wykrywalnych automatycznie, a mimo to być niedostępna. Może również zawierać wiele drobnych ostrzeżeń, ale pozwalać na wykonanie kluczowych zadań. Dlatego wynik trzeba zawsze oceniać w kontekście.
Automatyczne skanowanie jest wartościowym elementem kontroli jakości. Nie powinno jednak służyć jako jedyny dowód zgodności, podstawa deklaracji ani zamiennik badania manualnego.
Dostępności nie można sprowadzić do liczby punktów. O jej jakości decyduje to, czy prawdziwy użytkownik może skorzystać z prawdziwej usługi.