Klasyczny audyt dostępności opiera się na prostym założeniu: istnieje konkretny produkt, który można zbadać według powtarzalnego scenariusza. Sztuczna inteligencja podważa to założenie na dwa sposoby. Po stronie użytkownika potrafi „naprawić” źle zbudowaną stronę. Po stronie twórcy może z kolei generować interfejs na bieżąco, inny dla każdej osoby. W obu przypadkach audytor musi zadać sobie nowe pytania.

AI, która omija błędy autora

Bartłomiej Wilk z Lab Dostępności zwraca uwagę na zapowiedzi Apple z 19 maja 2026 roku. VoiceOver ma generować dokładniejsze opisy obrazów, w tym zdjęć i zeskanowanych dokumentów. Sterowanie głosowe ma rozumieć język naturalny, np. polecenie „stuknij w fioletowy folder”. Apple pisze wprost, że ma to pomagać także wtedy, gdy elementy nie są prawidłowo oznaczone pod kątem dostępności.

Dla użytkownika to realna zmiana na lepsze. Autor stawia jednak ważne rozróżnienie. Jeśli aplikacja przekazuje poprawną nazwę kontrolki, to jest informacja wynikająca z projektu. Jeśli AI odtwarza znaczenie elementu z jego wyglądu i położenia, to jest interpretacja. Często trafna, ale nie ta sama rzecz.

Nie można też uznać produktu za dostępny dlatego, że część osób ma sprzęt zdolny do obejścia jego wad. Według Apple nowe sterowanie głosowe będzie działać tylko po angielsku, w USA, Kanadzie, Wielkiej Brytanii i Australii. Języka polskiego nie ma też na liście języków obsługiwanych przez Apple Intelligence. Producent sam przestrzega też, by nie polegać na nowych funkcjach VoiceOver i Lupy w sytuacjach wysokiego ryzyka ani do nawigacji. Gdyby AI miała usprawiedliwiać złe strony, odpowiedzialność za dostępność przeszłaby z twórcy usługi na użytkownika i jego telefon.

Podobne rozróżnienie stosuje W3C. Zasada „robust” w WCAG wymaga, by treść była niezawodnie interpretowana przez programy użytkownika, w tym technologie asystujące, a niestandardowe komponenty przekazywały nazwę, rolę i wartość. Nawet Google w dokumentacji koncepcji Natively Adaptive Interfaces zaleca semantyczny HTML i poprawne atrybuty WAI-ARIA.

Generative UI: co właściwie audytujemy?

Jeszcze trudniejsze pytania pojawiają się, gdy AI zaczyna budować sam interfejs. W drugim tekście Wilk opisuje prace grupy W3C Research Questions Task Force nad dostępnością uczenia maszynowego i generatywnej AI. Opisuje też seminarium W3C o Generative UI z września 2026 roku, na którym dostępność postawiono obok interoperacyjności, prywatności, bezpieczeństwa i testowania. Autor podkreśla, że to wciąż prace badawcze, a nie nowy standard.

Wyobraźmy sobie usługę publiczną, w której AI składa formularz na podstawie rozmowy. Jednej osobie pokaże trzy pola, drugiej sześć, a trzeciej najpierw zada serię pytań. Audytor może sprawdzić kilkanaście wariantów i każdy uznać za poprawny. Nadal nie wie jednak, czy model jutro nie wygeneruje wersji z niejasną etykietą albo fokusem w przypadkowym miejscu.

Stąd zasadnicza zmiana pytania audytowego. Zamiast „czy ten ekran jest dostępny?” trzeba pytać: „czy system jest zaprojektowany tak, by nie mógł wygenerować niedostępnego ekranu?”. W praktyce oznacza to ocenę reguł generatora, zestawu dozwolonych komponentów, walidacji wyniku i mechanizmów awaryjnych.

Wilk zwraca też uwagę na mniej oczywisty problem. Interfejs, który za każdym razem wygląda inaczej, utrudnia naukę jego obsługi. Dla części osób przewidywalność jest warunkiem samodzielności. Personalizacja może więc dostępność poprawiać i zarazem pogarszać. Do tego dochodzi kwestia etyczna: dostępny interfejs nie powinien wymagać ujawnienia niepełnosprawności, a AI nie powinna „upraszczać” ekranu bez pytania użytkownika.

Fundament się nie zmienia: WCAG-EM 2.0

W tym samym czasie W3C opublikowało 23 lipca 2026 roku WCAG-EM 2.0, czyli nową wersję oficjalnej metodyki oceny zgodności z WCAG 2. Pierwsza wersja dotyczyła stron internetowych. Druga obejmuje także aplikacje i inne produkty cyfrowe, np. kioski. Procedura ma pięć kroków: określenie zakresu, poznanie produktu, wybór reprezentatywnej próby, ocena próby i raport. W3C zaleca także udział użytkowników z niepełnosprawnościami.

Krok trzeci, czyli wybór próby, przy interfejsach generatywnych nabiera nowego znaczenia. Próbą przestaje być tylko zestaw ekranów. Staje się nią także zestaw scenariuszy, w których generator może się zachować inaczej.

Wnioski dla zespołów produktowych i audytorów

1. Nie licz na AI użytkownika. Strona lub aplikacja ma przekazywać poprawną strukturę, role, nazwy i stany. Inteligentna technologia asystująca to dodatkowa warstwa, a nie zamiennik.

2. Jeśli AI ma budować UI, niech składa je z gotowych klocków. Wilk radzi, by model wybierał spośród sprawdzonych, dostępnych komponentów, zamiast za każdym razem generować HTML, ARIA i JavaScript od zera.

3. Zapewnij stabilną alternatywę. W procesach o dużym znaczeniu, takich jak urzędowe, zdrowotne czy finansowe, użytkownik powinien móc przejść na przewidywalny, niegenerowany interfejs.

4. Rejestruj wygenerowane warianty. Bez możliwości odtworzenia tego, co zobaczył użytkownik, nie da się zdiagnozować zgłoszonej bariery.

5. Rozszerz zakres audytu. Przy systemach z AI oceniaj nie tylko ekrany, ale też ograniczenia generatora i scenariusze graniczne. Opieraj się na WCAG-EM 2.0 jako wspólnym języku.

6. W raporcie oddziel produkt od obejścia. Jeśli zadanie udało się wykonać tylko dzięki AI użytkownika, błąd nadal istnieje i powinien trafić do raportu.

Źródła