Przejdź do treści

AI we wsparciu audytu WCAG

Definicja

AI może wspierać audyt dostępności cyfrowej. Może:

  • porządkować wyniki testów automatycznych,
  • podpowiadać, których kryteriów WCAG dotyczy problem,
  • przygotowywać opisy błędów i rekomendacje,
  • przechodzić ścieżki na stronie.

Nie zastępuje jednak audytora. Wiele kryteriów WCAG wymaga ludzkiej oceny, na przykład:

W polskich podmiotach publicznych wymagania wynikają z ustawy o dostępności cyfrowej i normy EN 301 549, która odwołuje się do WCAG 2.1 na poziomie AA.

Co to w zasadzie jest?

  • Testy automatyczne wykrywają tylko część problemów. W teście brytyjskiego GDS z 2017 roku najlepsze narzędzie wykryło 41% z 143 celowo wprowadzonych barier, a wszystkie 10 narzędzi razem 71%.
  • AI może przyspieszyć pracę wokół testów:
    • opis problemów,
    • priorytety,
    • raport,
    • propozycje poprawek.
  • Model może pewnym tonem podać błędny numer kryterium albo uznać coś za zgodne bez podstaw.
  • Ocena zgodności i deklaracja dostępności to odpowiedzialność człowieka i podmiotu, nie narzędzia.

Praktyczne zastosowania (konkretne scenariusze)

Scenariusz 1: Porządkowanie wyników testów automatycznych

  • Cel: czytelny raport zamiast listy setek ostrzeżeń.
  • Wejście: eksport z narzędzia testującego.
  • Kroki: AI grupuje powtarzające się problemy → przypisuje kryteria WCAG → proponuje priorytety → audytor weryfikuje.
  • Rezultat: raport do pracy dla zespołu.
  • Zabezpieczenie: audytor sprawdza każde przypisanie kryterium.

Scenariusz 2: Opisy błędów dla programistów

  • Cel: zrozumiałe zgłoszenia do poprawy.
  • Wejście: opis problemu i fragment kodu.
  • Kroki: AI pisze zgłoszenie: co jest źle, kogo to blokuje, jak poprawić, jak sprawdzić.
  • Rezultat: szybsze poprawki.
  • Zabezpieczenie: propozycja kodu sprawdzona przez osobę znającą semantyczny HTML i ARIA.

Scenariusz 3: Wstępny przegląd treści

  • Cel: wyłapanie problemów, których narzędzia nie widzą.
  • Wejście: treść strony, lista tekstów alternatywnych, etykiety formularzy.
  • Kroki: AI wskazuje podejrzane miejsca: niejasne linki, alty typu „obraz1.jpg”, brak instrukcji w formularzu.
  • Rezultat: lista do weryfikacji przez audytora.
  • Zabezpieczenie: końcowa ocena z czytnikiem ekranu i klawiaturą.

Typowe błędy i pułapki

  • Raport z samych testów automatycznych przedstawiany jako audyt.
  • Pytanie modelu „czy ta strona jest zgodna z WCAG?” i przyjęcie odpowiedzi.
  • Brak testów z czytnikiem ekranu, klawiaturą i powiększeniem.
  • Rekomendacje „dodaj ARIA” tam, gdzie wystarczy poprawny HTML.
  • Nakładki „naprawiające dostępność” jako zamiennik poprawy kodu.

Ryzyka i jak je ograniczać

Ryzyko 1: Fałszywe poczucie zgodności

  • Ryzyko: organizacja uznaje stronę za dostępną na podstawie raportu AI.
  • Jak ograniczać: jasny opis metody w raporcie, testy manualne, ocena przez audytora.

Ryzyko 2: Błędne kryteria i rekomendacje

  • Ryzyko: zły numer kryterium, nieistniejące wymaganie, szkodliwa poprawka ARIA.
  • Jak ograniczać: sprawdzanie w dokumentach W3C („Understanding WCAG”), przegląd kodu.

Ryzyko 3: Pominięcie użytkowników

  • Ryzyko: formalna zgodność bez realnej użyteczności.
  • Jak ograniczać: testy z osobami z niepełnosprawnościami tam, gdzie to możliwe.

Checklista “zanim użyjesz”

  • Czy raport jasno mówi, co sprawdziło narzędzie, co AI, a co człowiek?
  • Czy każde przypisanie kryterium WCAG zostało zweryfikowane?
  • Czy wykonano testy klawiaturą, czytnikiem ekranu i przy powiększeniu?
  • Czy poprawki kodu przejrzała osoba znająca HTML i ARIA?
  • Kto podpisuje się pod wynikiem audytu?

Diagram

flowchart LR
    A[Testy automatyczne]
    B[AI porządkuje i opisuje]
    C[Testy manualne audytora]
    D[Ocena zgodności]
    E[Raport]
    A --> B --> C --> D --> E

Diagram pokazuje, że AI porządkuje wyniki testów automatycznych, ale ocena zgodności powstaje dopiero po testach manualnych audytora.

Dalsza lektura

Miejsce w mapie

Powiązane hasła