Badanie dostępności strony: kontrola automatyczna a ręczna
· 5 min czytania
Kontrole automatyczne szybko i niezawodnie wykrywają błędy techniczne, takie jak brak tekstów alternatywnych, zbyt niski kontrast czy pola formularza bez etykiet. Czy jednak stronę da się naprawdę obsłużyć klawiaturą i czytnikiem ekranu, mogą ocenić tylko ludzie. Najlepsza strategia to połączenie: automatycznie – regularnie i na całej stronie, ręcznie – celowo dla najważniejszych procesów.
Jak działają kontrole automatyczne
Test automatyczny ładuje stronę w przeglądarce i stosuje reguły do kodu. Popularną otwartą biblioteką do takich testów jest axe-core; w wersji 4.11 zawiera ponad 100 reguł, z czego około dwie trzecie odnosi się do kryteriów WCAG na poziomach A i AA. Typowe reguły to:
- Czy każdy obraz ma atrybut
alt? - Czy każde pole formularza ma przypisaną etykietę?
- Czy tekst ma wystarczający kontrast względem tła?
- Czy każdy przycisk ma dostępną nazwę?
- Czy podano język strony?
- Czy atrybuty ARIA są poprawne?
Takie reguły da się sprawdzić jednoznacznie: atrybut jest albo go nie ma, kontrast jest powyżej 4,5:1 albo poniżej.
Co kontrole automatyczne robią dobrze
- Zasięg. Setki stron w krótkim czasie, bez zmęczenia.
- Powtarzalność. Ta sama kontrola co tydzień, z porównywalnymi wynikami.
- Wczesne wykrywanie. Nowe błędy po aktualizacji widać od razu.
- Koszt. W przeliczeniu na stronę znacznie taniej niż jakakolwiek kontrola ręczna.
- Dowód. Historia wyników pokazuje, że stale pracują Państwo nad dostępnością.
Gdzie kontrole automatyczne napotykają granice
Testy automatyczne obejmują tylko część możliwych barier; jak dużą, badania oceniają różnie (test GOV.UK, badanie Deque). Typowe luki:
| Pytanie | Dlaczego automat nie może na nie odpowiedzieć |
|---|---|
| Czy tekst alternatywny sensownie opisuje obraz? | „IMG_4711.jpg” formalnie jest tekstem alternatywnym – ale bezużytecznym. |
| Czy kolejność przechodzenia klawiszem Tab jest logiczna? | Automat widzi kod, a nie drogę przez stronę. |
| Czy fokus jest zawsze widoczny w trakcie procesu? | Zależy od stanów, animacji, nakładek. |
| Czy zamówienie da się w całości złożyć klawiaturą? | Wymaga prawdziwej interakcji w kilku krokach. |
| Czy komunikaty o błędach są zrozumiałe? | To kwestia języka, nie składni. |
| Czy czytnik ekranu ogłasza „Dodano do koszyka”? | Wymaga testu z technologią wspomagającą. |
| Czy baner cookie nie zasłania przycisku z fokusem? | Zależy od układu i rozmiaru ekranu. |
Do tego dochodzą fałszywe alarmy w przypadkach granicznych, np. przy tekście na zdjęciach lub gradientach, gdzie kontrast trudno obliczyć.
Dlatego obowiązuje zasada: kontrola automatyczna nie jest pełnym audytem. Kto obiecuje coś innego, obiecuje za dużo.
Jak wygląda kontrola ręczna
Kontrola ręczna przebiega według kryteriów sukcesu WCAG i wykorzystuje prawdziwe technologie wspomagające:
- Klawiatura: obsługa strony wyłącznie klawiszami Tab, Shift+Tab, Enter, spacją, strzałkami i Escape.
- Fokus: czy zawsze widać, gdzie się jest? Czy fokus nie jest zasłaniany przez przyklejone nagłówki lub banery?
- Powiększenie i dopasowanie: powiększenie 200%, wąski ekran, brak przewijania w poziomie.
- Czytnik ekranu: przejście głównego procesu z NVDA w systemie Windows lub VoiceOver na Macu i iPhonie.
- Treść: ocena merytoryczna tekstów alternatywnych, tekstów linków, nagłówków i komunikatów o błędach.
- Multimedia: napisy, audiodeskrypcja, sterowanie filmami i sliderami.
Jako metoda uporządkowanej kontroli sprawdza się metodologia oceny WCAG-EM opracowana przez W3C. Pełny audyt przypisuje wszystkie wyniki do kryteriów sukcesu i w zależności od zakresu trwa dni, a nie minuty.
Przykład z codzienności sklepu
Weźmy pole „Kod rabatowy” w kasie. Kontrola automatyczna zgłasza: pole nie ma przypisanej etykiety, tylko tekst zastępczy (placeholder). To wyraźny, technicznie wykrywalny błąd – szybko znaleziony, szybko poprawiony. Czy jednak komunikat „Nieprawidłowy kod” po wysłaniu zostanie odczytany przez czytnik ekranu i czy fokus trafi potem w sensowne miejsce, pokaże dopiero test ręczny. Obie kontrole się uzupełniają: automat znajduje błąd na wszystkich stronach, człowiek sprawdza proces.
Porównanie w skrócie
| Automatycznie | Ręcznie | |
|---|---|---|
| Szybkość | minuty dla wielu stron | od godzin do dni |
| Pokrycie kryteriów | część kryteriów | wszystkie kryteria |
| Powtarzanie | dowolnie często, np. co tydzień | doraźnie |
| Ocenia jakość treści | nie | tak |
| Testuje rzeczywiste procesy | w ograniczonym zakresie | tak |
| Koszt na stronę | niski | wyższy |
Rozsądne połączenie dla sklepów internetowych
- Automatycznie i regularnie. Co tydzień sprawdzać wszystkie ważne typy stron. Dzięki temu błędy wykrywalne technicznie pozostają pod kontrolą, a nowe widać od razu.
- Ręcznie dla kluczowych procesów. Wyszukiwanie, wybór produktu, koszyk, kasa, rejestracja – po każdej większej aktualizacji i co najmniej raz w roku.
- Ręcznie dla nowych komponentów. Nowy filtr, nowa wtyczka kasy czy nowy baner cookie zasługują na krótki test klawiaturą i czytnikiem ekranu przed wdrożeniem.
- Uwzględniać opinie. Zgłoszenia klientów o barierach są cenniejsze niż jakakolwiek reguła.
Listę kryteriów z informacją, co da się wykryć automatycznie, a co nie, znajdą Państwo w naszej liście kontrolnej WCAG 2.2.
Dlaczego nakładki nie są trzecią opcją
Czasem widżet oferowany jest jako „rozwiązanie automatyczne”. Nakładka (overlay) niczego jednak nie sprawdza ani nie poprawia w kodzie; kładzie tylko warstwę na wierzch. W 2025 r. amerykańska Federalna Komisja Handlu (FTC) wyegzekwowała od znanego dostawcy zapłatę miliona dolarów amerykańskich i zakaz niektórych twierdzeń reklamowych. Więcej w artykule Nakładki to nie rozwiązanie.
Co to oznacza dla Państwa obowiązków
Dla sklepów objętych niemiecką ustawą BFSG: wymagania dotyczą rzeczywistej dostępności, a nie konkretnej metody badania. Regularna kontrola automatyczna jest dobrym, udokumentowanym elementem. Do informacji o dostępności według § 14 BFSG potrzebny jest dodatkowo opis Państwa usługi – tego żaden skaner nie dostarczy. Ramy prawne wyjaśnia przewodnik po BFSG.
Jak sprawdzamy
Sprawdzamy automatycznie według WCAG 2.2 AA za pomocą axe-core w prawdziwej przeglądarce, objaśniamy każdy wynik kartą reguły i pokazujemy zmiany z tygodnia na tydzień. W każdym raporcie jest informacja: automatyczna kontrola, nie pełny audyt, nie porada prawna. Jak to wygląda w szczegółach, opisujemy na stronie Jak to działa. Proszę wypróbować na jednej stronie swojego sklepu.