Automatyczny skan WCAG to początek, nie koniec audytu

Najczęstsze nieporozumienie, z jakim spotykam się przy dostępności, brzmi: „puściliśmy skaner, wyszło zero błędów, więc jesteśmy zgodni z WCAG”. To tak, jakby po przejściu lintera ogłosić, że aplikacja nie ma bugów.

Co automat sprawdza dobrze

Skanery takie jak axe-core są szybkie, powtarzalne i bezlitosne dla błędów, które da się opisać regułą. Wyłapią między innymi:

• brakujący atrybut alt przy obrazie,
• pola formularza bez etykiety,
• zbyt niski kontrast tekstu względem tła,
• niepoprawne użycie atrybutów ARIA,
• brak atrybutu lang na dokumencie.

To ważne błędy i warto je wyłapywać automatycznie, najlepiej w CI, przy każdej zmianie.

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('strona główna nie ma wykrywalnych naruszeń WCAG', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

Czego automat nie sprawdzi

Automat wie, że obraz ma alt. Nie wie, czy alt="obrazek" cokolwiek mówi. Wie, że przycisk ma nazwę. Nie wie, czy po jego kliknięciu fokus nie ucieka na początek strony. Kilka kryteriów, przy których zawsze potrzebuję człowieka:

• Kolejność fokusu i pułapki klawiaturowe w modalach, menu i niestandardowych komponentach.
• Sens tekstów alternatywnych, nagłówków i linków. Pięć linków „Czytaj więcej” obok siebie przejdzie przez skaner bez słowa.
• Fokus niezasłonięty (2.4.11, nowość w WCAG 2.2): przyklejony nagłówek potrafi zakryć element, na którym właśnie jesteś.
• Reflow przy 320 px i powiększenie do 200%. Automat nie zobaczy, że tekst nachodzi na siebie.
• Zrozumiałość komunikatów błędów. „Nieprawidłowa wartość” to komunikat, ale nie pomoc.

Jak wygląda mój proces

Audyt dzielę na sześć kroków. Automat jest pierwszym z nich, nie jedynym.

1. Skan automatyczny jako triage: szybko pokazuje skalę i powtarzalne błędy w szablonach.
2. Przejście klawiaturą przez kluczowe ścieżki: nawigacja, formularz, zakup, logowanie.
3. Czytnik ekranu: NVDA z Firefoxem na Windows, VoiceOver z Safari na macOS i iOS.
4. Powiększenie i reflow: 200%, 400%, szerokość 320 px, orientacja pozioma.
5. Przegląd treści: teksty alternatywne, struktura nagłówków, opisy linków, napisy do wideo.
6. Raport: każde zgłoszenie z kryterium WCAG, krokami do odtworzenia, wpływem na użytkownika i propozycją poprawki.

Gdzie automat zostaje na stałe

Nie chodzi o to, żeby z automatów rezygnować. Po audycie i poprawkach test w CI pilnuje, żeby te same błędy nie wróciły przy kolejnym wdrożeniu. Ręczny audyt powtarzam przy większych zmianach w interfejsie, a nie przy każdej zmianie w kodzie.

Ten sam podział stosujemy w DockAccess: automatyczne skanowanie i monitoring działają ciągle, a audyt ekspercki uzupełnia to, czego automat nie zobaczy.

Od czego zacząć jutro

Jeśli masz pół godziny, odłóż mysz i spróbuj przejść klawiaturą przez najważniejszą ścieżkę na swojej stronie. Zanotuj każde miejsce, w którym nie wiesz, gdzie jest fokus, albo nie możesz czegoś uruchomić. To będzie lepszy początek audytu niż najlepszy raport z automatu.