AI jest świetne w robieniu wrażenia, że rozumie interfejs. Patrzy na kod, streszcza problem, proponuje poprawkę, czasem nawet pisze sensowny aria-label. I właśnie dlatego łatwo dać się nabrać.
Bo dostępność nie polega na tym, żeby interfejs wyglądał poprawnie w raporcie. Chodzi o to, czy ktoś naprawdę może z niego skorzystać: bez myszy, z czytnikiem ekranu, w powiększeniu, w stresie, z treścią, która ma sens.
AI może dziś pomagać w A11y. Ale jeśli pytanie brzmi: czy może samodzielnie dobrze zająć się dostępnością produktu? Na dzień dzisiejszy odpowiedź brzmi: nie.
Dostępność to nie checklista, tylko zachowanie produktu
Największy problem z automatyzacją dostępności polega na tym, że wiele rzeczy wygląda poprawnie, dopóki nikt ich nie użyje.
Przycisk może mieć nazwę dostępną, ale ta nazwa może być bez sensu. Modal może mieć role="dialog", ale focus może uciekać w tło. Formularz może mieć etykiety, ale komunikat błędu może nie mówić, co użytkownik ma zrobić dalej.
W3C pisze wprost, że narzędzia do oceny dostępności pomagają szybko wykrywać potencjalne problemy, ale nie są w stanie automatycznie sprawdzić wszystkich aspektów. Potrzebny jest osąd człowieka, a wyniki narzędzi mogą być fałszywe albo mylące.
Źródło: W3C WAI, Selecting Web Accessibility Evaluation Tools
AI wpada dokładnie w tę samą pułapkę, tylko w ładniejszym opakowaniu. Zamiast czerwonego błędu pokazuje pewnie brzmiące zdanie.
AI nie widzi intencji
Dostępność jest bardzo mocno zależna od intencji. Ten sam obraz może potrzebować opisu produktu w sklepie, informacji medycznej w artykule albo pustego alta, jeśli jest tylko dekoracją.
AI może zgadnąć. Czasem trafi. Ale często nie wie, po co obraz istnieje, jaką decyzję ma wspierać i co użytkownik musi z niego wynieść. A dostępność nie znosi zgadywania.
Podobnie jest z linkami, nagłówkami i instrukcjami. AI może napisać poprawny językowo tekst, ale niekoniecznie tekst użyteczny. A w A11y "ładnie brzmi" to za mało.
ARIA jest obietnicą, nie dekoracją
Jednym z najbardziej ryzykownych miejsc dla AI jest ARIA.
W3C w ARIA Authoring Practices przypomina zasadę: "No ARIA is better than Bad ARIA". Rola ARIA jest obietnicą. Jeśli element ma role="button", musi też zachowywać się jak przycisk: obsługiwać klawiaturę, focus i oczekiwane interakcje. Sama rola nie daje tego za darmo.
Źródło: W3C WAI, ARIA APG - Read Me First
AI potrafi dodać ARIA tam, gdzie wystarczyłby zwykły HTML. Potrafi też poprawić ostrzeżenie z narzędzia w sposób pozorny: dodać atrybut, zamknąć błąd i zostawić użytkownika z gorszym doświadczeniem niż wcześniej.
To jest szczególnie niebezpieczne, bo zła semantyka nie zawsze psuje widok. Dla osoby widzącej strona wygląda tak samo. Dla czytnika ekranu może mówić coś zupełnie innego.
Automatyczne testy łapią wzorce, nie całą rzeczywistość
Automatyczne narzędzia są potrzebne. Dobrze łapią brak etykiety, niski kontrast, brak nazwy dostępnej czy niepoprawne relacje w formularzu.
Ale dostępność ma też warstwę, której nie da się sprowadzić do jednego selektora CSS albo jednej reguły.
Czy kolejność focusu jest logiczna? Czy użytkownik rozumie, co się stało po wysłaniu formularza? Czy komponent działa w Safari z VoiceOver i w Chrome z NVDA? Czy po powiększeniu do 400 procent nadal da się kupić produkt?
WCAG 2.2 obejmuje szeroki zakres zaleceń dla treści internetowych i dotyczy różnych rodzajów niepełnosprawności oraz urządzeń. Kryteria sukcesu są testowalne, ale ich wdrożenie wymaga interpretacji w konkretnym produkcie.
Źródło: W3C, Web Content Accessibility Guidelines 2.2
Sama znajomość listy kryteriów nie wystarcza. Trzeba rozumieć produkt.
Badania pokazują potencjał i granicę
To nie jest tekst przeciwko AI. Badanie nad narzędziem FixAlly pokazało, że rozwiązania oparte na LLM mogą proponować poprawki do problemów accessibility w aplikacjach mobilnych. Autorzy opisali 77 procent skuteczności w generowaniu prawdopodobnych sugestii. Ale "prawdopodobnych" jest tu kluczowe. To nadal sugestie, nie gwarancja dostępności.
Źródło: arXiv, Automated Code Fix Suggestions for Accessibility Issues in Mobile Apps
To bardzo uczciwy kierunek: AI jako asystent, nie jako ostatnia instancja.
Najtrudniejsze są rzeczy ludzkie
Najbardziej wymagające problemy dostępności często nie są spektakularne technicznie. Użytkownik nie wie, gdzie jest po zamknięciu modala. Instrukcja formularza jest zrozumiała dla zespołu, ale nie dla klienta. Tekst alternatywny opisuje zdjęcie, ale nie funkcję obrazu. Komponent działa myszą, ale klawiaturą wymaga pamiętania dziwnej sekwencji.
AI może takie rzeczy nazwać, jeśli ktoś dobrze je opisze. Rzadziej sama je odkryje, bo one wychodzą z użycia, nie z samego patrzenia na plik.
Dlatego W3C zachęca do włączania użytkowników z niepełnosprawnościami w ocenę dostępności. Taka ewaluacja ujawnia problemy, których sama zgodność ze standardem może nie pokazać.
Źródło: W3C WAI, Involving Users in Evaluating Web Accessibility
Gdzie AI pomaga?
Najrozsądniejsze miejsce dla AI w A11y jest dziś praktyczne:
- szybkie wyszukiwanie podejrzanych fragmentów kodu
- tłumaczenie kryteriów WCAG na zadania
- propozycje tekstów alternatywnych
- analiza komponentów pod kątem semantyki
- porządkowanie raportów z audytu
- testy regresji dla znanych problemów
To jest realna wartość. AI może skrócić drogę od problemu do hipotezy rozwiązania. Potem ktoś musi sprawdzić, czy ta hipoteza działa w przeglądarce, z technologią asystującą i w konkretnym przepływie.
Wniosek
AI nie przegrywa z dostępnością dlatego, że jest "głupie". Przegrywa dlatego, że dostępność jest osadzona w kontekście: technicznym, projektowym, językowym i ludzkim.
Dobry audyt A11y wymaga czytania DOM-u, rozumienia WCAG, znajomości HTML i ARIA, testów klawiaturą, pracy z czytnikami ekranu oraz oceny treści.
AI może być świetnym drugim monitorem. Może podpowiadać, przyspieszać, prowokować do sprawdzenia miejsc, które łatwo pominąć. Ale nie powinno podpisywać się pod dostępnością produktu.
Na dziś najlepszy model to nie "AI zamiast specjalisty". To specjalista, który umie używać AI bez oddawania mu odpowiedzialności: mniej ręcznej pracy, więcej mądrego sprawdzania, ale nadal z człowiekiem po stronie decyzji.