Sztuczna inteligencja potrafi wygenerować kod, napisać testy, znaleźć część błędów i zaproponować poprawki zgodne z WCAG. Coraz częściej pojawiają się też narzędzia, które obiecują automatyczny audyt dostępności strony lub aplikacji.
Brzmi wygodnie. Problem w tym, że dostępność cyfrowa nie polega wyłącznie na sprawdzeniu kodu HTML.
AI jest dobrym pomocnikiem, ale słabym sędzią. Nie rozumie użytkownika tak, jak rozumie go osoba, która zna WCAG, testuje interfejsy z klawiaturą i pracuje z technologiami asystującymi. Dlatego nawet najlepszy model językowy nie powinien zastępować ręcznego audytu dostępności.
Automatyczne narzędzia widzą tylko część problemów
Pierwsza rzecz, którą warto zapamiętać: większość automatycznych testów wykrywa tylko część błędów accessibility.
AI może sprawdzić, czy obraz ma atrybut alt, ale nie oceni pewnie, czy opis rzeczywiście przekazuje właściwą informację. Na stronie sklepu zdjęcie czerwonych butów sportowych może dostać opis:
Zdjęcie produktu.
Technicznie atrybut istnieje. Praktycznie użytkownik niewidomy nadal nie wie, jaki produkt ogląda.
Podobnie jest z linkami. Model może zaakceptować tekst „Dowiedz się więcej”, bo link działa i ma nazwę. Audytor zapyta: „Dowiedz się więcej o czym?”. Jeśli osoba korzystająca z czytnika ekranu otworzy listę linków i usłyszy kilka identycznych pozycji, formalna poprawność nie pomoże jej w nawigacji.
W3C przypomina, że narzędzia do oceny dostępności mogą przyspieszać pracę, ale nie są w stanie automatycznie sprawdzić wszystkich aspektów dostępności. Ich wyniki wymagają interpretacji człowieka.
Źródło: W3C WAI, Selecting Web Accessibility Evaluation Tools
AI nie rozumie kontekstu
To jedna z największych słabości obecnych modeli. AI analizuje wzorce, ale nie zna celu strony, intencji autora ani sytuacji użytkownika.
Ten sam element może być poprawny albo błędny w zależności od kontekstu. Obraz może wymagać szczegółowego opisu, krótkiej informacji albo pustego alta, jeśli jest dekoracyjny. Nagłówek może być logiczny w izolacji, ale burzyć strukturę całego widoku. Komunikat może brzmieć ładnie, ale nie pomagać użytkownikowi wykonać zadania.
Dostępność nie znosi zgadywania. To, co dla AI wygląda jak poprawny fragment interfejsu, w realnym procesie może stać się barierą.
Kolejność focusu to coś więcej niż możliwość kliknięcia
Automatyczne narzędzie może wykryć, że element da się zaznaczyć klawiaturą. To jednak dopiero początek.
W audycie trzeba sprawdzić, czy focus porusza się logicznie, czy odpowiada kolejności wizualnej, czy nie wpada w ukryte elementy i czy po zamknięciu modala wraca tam, skąd użytkownik rozpoczął akcję.
To szczególnie ważne w aplikacjach opartych na komponentach. Modal, dropdown, wieloetapowy formularz albo dynamiczna walidacja mogą wyglądać dobrze myszą, a jednocześnie być bardzo trudne dla osoby korzystającej wyłącznie z klawiatury.
AI może wskazać podejrzane miejsca w kodzie. Nie zastąpi jednak przejścia przez proces krok po kroku i sprawdzenia, czy użytkownik naprawdę wie, gdzie jest.
AI nie wie, jak zachowa się czytnik ekranu
Model językowy może znać dokumentację NVDA, VoiceOver, JAWS czy TalkBack. To nie znaczy, że potrafi wiarygodnie przewidzieć ich zachowanie w konkretnej aplikacji.
Ten sam fragment kodu może zostać odczytany inaczej w różnych kombinacjach systemu, przeglądarki i czytnika ekranu. Dodatkowo znaczenie ma tempo interakcji, tryb nawigacji, kolejność DOM i sposób aktualizacji widoku po stronie JavaScriptu.
Dlatego doświadczeni audytorzy testują realne scenariusze z prawdziwymi technologiami asystującymi. Bez tego łatwo uznać interfejs za dostępny tylko dlatego, że w kodzie nie widać oczywistego błędu.
ARIA nie zawsze oznacza dostępność
Jednym z najczęstszych problemów jest nadmierne zaufanie do ARIA. AI bardzo często proponuje dodanie kolejnych atrybutów: role, tabindex, aria-expanded, aria-hidden albo aria-label.
Problem polega na tym, że ARIA nie naprawia złego kodu. Może pomóc, gdy jest użyta świadomie, ale może też pogorszyć doświadczenie użytkownika.
W3C w ARIA Authoring Practices przypomina zasadę, że brak ARIA jest lepszy niż zła ARIA. Jeśli element ma role="button", musi naprawdę zachowywać się jak przycisk: obsługiwać klawiaturę, focus i oczekiwane interakcje. Sama rola tego nie zapewnia.
Źródło: W3C WAI, ARIA APG - Read Me First
AI potrafi sprawić, że kod wygląda bardziej profesjonalnie, ale niekoniecznie bardziej dostępnie.
AI nie oceni całego procesu użytkownika
Jednym z najczęściej pomijanych problemów jest analiza pełnej ścieżki użytkownika.
Wyobraźmy sobie wieloetapowy formularz, w którym użytkownik wypełnia dane i przechodzi do kolejnego kroku. Kod może być poprawny. Pola mogą mieć etykiety. Przyciski mogą działać z klawiatury. A mimo to osoba korzystająca z czytnika ekranu może nie wiedzieć, co właśnie się wydarzyło.
Po kliknięciu przycisku „Dalej” mogą pojawić się problemy:
- formularz zostaje na tej samej stronie, ale użytkownik nie dostaje informacji, że część pól zawiera błędy
- aplikacja nie komunikuje, że pierwszy etap został zakończony i rozpoczął się kolejny
- focus pozostaje w przypadkowym miejscu
- komunikat pojawia się tylko wizualnie i nie zostaje odczytany przez czytnik ekranu
Dla osoby widzącej zmiana na ekranie może być oczywista. Użytkownik niewidomy może natomiast odnieść wrażenie, że aplikacja przestała działać albo kliknięcie nie przyniosło żadnego efektu.
To właśnie tutaj potrzebna jest znajomość całego procesu, a nie tylko pojedynczego komponentu. AI zwykle analizuje fragment kodu. Rzetelny audyt sprawdza, czy użytkownik otrzymuje odpowiedni feedback po wykonaniu akcji i czy może bezpiecznie przejść do następnego kroku.
AI często halucynuje wymagania WCAG
Modele językowe potrafią przekonująco uzasadniać błędne odpowiedzi. Zdarza się, że przypisują problem do niewłaściwego kryterium sukcesu, cytują nieistniejące wymagania albo proponują rozwiązania sprzeczne z dokumentacją W3C.
To ryzykowne zwłaszcza dla osób, które dopiero uczą się dostępności. Odpowiedź może brzmieć ekspercko, ale nadal być błędna.
Dlatego każde zalecenie AI warto sprawdzać z oficjalnymi materiałami WCAG i testować w konkretnym interfejsie.
Gdzie AI naprawdę pomaga?
To nie jest argument przeciwko używaniu AI. W accessibility AI może być bardzo przydatne, jeśli traktujemy je jako wsparcie, a nie jako ostatnią instancję.
Może pomóc w:
- wyszukiwaniu podejrzanych fragmentów kodu
- porządkowaniu checklisty audytowej
- tłumaczeniu kryteriów WCAG na prostszy język
- przygotowaniu propozycji komunikatów błędów
- analizie semantyki komponentów
- redagowaniu raportu po audycie
Każda z tych rzeczy może oszczędzić czas. Żadna nie zwalnia z odpowiedzialności za ręczną weryfikację.
Podsumowanie
Sztuczna inteligencja zmienia sposób pracy także w obszarze dostępności cyfrowej. Potrafi przyspieszyć analizę kodu, wskazać potencjalne problemy i pomóc w przygotowaniu poprawek. Nadal jednak nie rozumie całego kontekstu użytkownika, nie przewidzi pewnie działania czytników ekranu i nie zastąpi testów klawiaturą.
Dostępność cyfrowa to nie tylko odhaczanie kolejnych punktów z listy WCAG. To przede wszystkim zrozumienie, jak z produktu korzystają osoby z różnymi potrzebami, ograniczeniami i technologiami asystującymi.
Najlepszy model pracy to nie „AI zamiast audytora”, tylko „audytor mądrze korzystający z AI”. Mniej ręcznego szukania oczywistych błędów, więcej czasu na analizę procesu, feedbacku, treści i realnego doświadczenia użytkownika.
Przykładów takich ograniczeń jest dużo więcej. W kolejnych publikacjach warto pokazywać konkretne sytuacje z audytów: miejsca, w których AI wskazywało błędne rozwiązania, pomijało istotne bariery albo uznawało aplikację za zgodną z WCAG, mimo że dla użytkowników technologii asystujących pozostawała trudna w obsłudze.