AI zaczyna generować nie tylko treść, ale cały interfejs. Co wtedy z dostępnością?

Przez ostatnie dwa lata rozmowa o sztucznej inteligencji i dostępności cyfrowej koncentrowała się głównie na tym, co AI może zrobić dla użytkownika. Generowanie opisów alternatywnych, rozpoznawanie obrazu, streszczanie trudnych treści, pomoc w obsłudze niedostępnego interfejsu czy coraz bardziej zaawansowane funkcje czytników ekranu były naturalnym punktem zainteresowania. Sam pisałem już o tym, jak AI zaczyna pomagać użytkownikowi obchodzić bariery pozostawione przez twórców stron i aplikacji. Tymczasem zaczyna się coś, co może być dla dostępności znacznie większym wyzwaniem: sztuczna inteligencja przestaje tylko pracować wewnątrz interfejsu, a zaczyna ten interfejs tworzyć.

W3C coraz wyraźniej traktuje ten problem jako jeden z obszarów wymagających pracy badawczej i standaryzacyjnej. Research Questions Task Force rozwija projekt dotyczący dostępności machine learning i generatywnej AI, a równolegle w ramach prac nad stykiem Webu i sztucznej inteligencji pojawia się temat Generative UI, czyli interfejsów tworzonych lub przekształcanych dynamicznie przez modele i agentów AI. We wrześniu 2026 roku właśnie generatywnym interfejsom poświęcono seminarium W3C, podczas którego dostępność została postawiona obok interoperacyjności, prywatności, bezpieczeństwa, wydajności i testowania jako jeden z problemów wymagających rozwiązania.

To jeszcze nie jest nowy standard WCAG ani gotowy zestaw wymagań, według którego jutro będziemy wykonywać audyty. Prace Research Questions Task Force nadal mają charakter badawczy, a przygotowywany dokument jest rozwijanym projektem. Sam fakt, że w 2026 roku temat wraca na kolejnych spotkaniach grupy, jest jednak znaczący. Dyskusja przestaje dotyczyć wyłącznie tego, czy generatywna AI jest użyteczna dla osób z niepełnosprawnościami, i zaczyna obejmować znacznie trudniejsze pytanie: co stanie się z dostępnością, kiedy interfejs przestanie być czymś stałym?

Interfejs, który powstaje dopiero dla konkretnego użytkownika

Dotychczas podczas audytu dostępności mieliśmy do czynienia z czymś stosunkowo przewidywalnym. Otwieramy stronę, przechodzimy przez konkretny proces, sprawdzamy strukturę, semantykę, kolejność fokusu, formularze, komunikaty błędów i zachowanie elementów interaktywnych. Strona może oczywiście reagować na działania użytkownika, ładować nowe dane czy zmieniać część widoku, ale istnieje określony produkt, który można badać według powtarzalnego scenariusza.

Generative UI może tę sytuację mocno skomplikować. System AI może na podstawie intencji użytkownika zbudować formularz, wybrać zestaw kontrolek, skrócić proces, zmienić kolejność informacji albo stworzyć zupełnie inną ścieżkę wykonania tego samego zadania. Dwóch użytkowników może więc przyjść po tę samą usługę i dostać nieco inne interfejsy, bo model uzna, że taki sposób prezentacji lepiej odpowiada ich sytuacji.

Na poziomie użyteczności brzmi to bardzo atrakcyjnie. Zamiast przekopywać się przez skomplikowany portal, użytkownik może powiedzieć, co chce załatwić, a system przygotuje mu właściwą ścieżkę. W dostępności pojawia się jednak problem, którego nie da się rozwiązać stwierdzeniem, że „AI zrobi prostszy ekran”. Jeżeli interfejs powstaje dynamicznie, trzeba mieć pewność, że niezależnie od tego, jaką wersję wygeneruje model, zachowane zostaną poprawna semantyka, kolejność, nazwy kontrolek, relacje między elementami, obsługa klawiaturą i komunikacja z technologiami asystującymi.

Nie wystarczy więc sprawdzić jednej wersji i uznać produktu za dostępny.

Co właściwie mielibyśmy audytować?

To jest dla mnie najciekawsza konsekwencja całej zmiany. Klasyczny audyt bada konkretny produkt lub jego reprezentatywny zakres. Jeżeli jednak model może wygenerować dziesiątki wariantów tego samego procesu, zaczynamy badać nie tylko gotowy interfejs, ale również reguły jego tworzenia.

Wyobraźmy sobie usługę publiczną, w której AI buduje użytkownikowi formularz na podstawie rozmowy. W jednym przypadku system przygotuje trzy pola, w innym sześć, a jeszcze innemu użytkownikowi najpierw zada serię pytań i dopiero później pokaże właściwe kontrolki. Audytor może sprawdzić kilkanaście scenariuszy i w każdym uzyskać poprawny wynik, ale nadal pozostaje pytanie, czy model nie wygeneruje jutro kombinacji, w której etykieta pola będzie niejasna, komunikat zostanie umieszczony poza logicznym kontekstem albo focus po zmianie widoku znajdzie się w przypadkowym miejscu.

To oznacza, że sama metodologia badania dostępności może w przyszłości wymagać rozszerzenia. Być może trzeba będzie oceniać nie tylko konkretne ekrany, ale również ograniczenia nałożone na generator interfejsu, zestaw dopuszczalnych komponentów, sposób walidacji wyniku i mechanizmy zabezpieczające przed utworzeniem struktury, która nie spełnia wymagań dostępności.

Dla twórców systemów jest tu zresztą bardzo praktyczna wskazówka. Jeżeli AI ma budować interfejs, znacznie bezpieczniej pozwolić mu komponować go z wcześniej przygotowanych i sprawdzonych dostępnych komponentów, niż pozwolić modelowi za każdym razem „wymyślać” cały interfejs od początku. Sztuczna inteligencja może zdecydować, którego elementu użyć, ale dostępność samego elementu powinna wynikać z dobrze zaprojektowanego systemu komponentów, a nie z tego, czy model akurat poprawnie wygeneruje HTML, ARIA i zachowanie JavaScript.

Dostępność to nie tylko poprawne ARIA

Można oczywiście wyobrazić sobie generator, który technicznie tworzy prawidłowy kod. Wszystkie pola mają etykiety, przyciski mają nazwy, struktura nagłówków się zgadza, focus porusza się logicznie i czytnik ekranu otrzymuje wszystkie potrzebne informacje. Nadal nie oznacza to jednak, że interfejs jest rzeczywiście dobry dla użytkownika.

Jeżeli AI przy każdym wejściu zmienia układ procesu, osoba korzystająca z serwisu nie może nauczyć się jego struktury. Jeśli funkcja, która wczoraj znajdowała się w jednym miejscu, jutro pojawi się gdzie indziej, rośnie obciążenie poznawcze. Dla części użytkowników możliwość adaptacji może być ogromnym ułatwieniem, ale dla innych przewidywalność jest właśnie jednym z warunków skutecznego korzystania z produktu.

Generatywny interfejs stawia więc twórców przed ciekawym konfliktem: personalizacja może poprawiać dostępność, a jednocześnie nadmierna zmienność może ją pogarszać. Nie każda osoba potrzebuje interfejsu „najlepiej dopasowanego przez AI”. Czasami bardziej potrzebuje tego, żeby ekran zachował się dokładnie tak jak ostatnio.

To jeden z powodów, dla których dostępności generatywnych interfejsów nie można sprowadzić do technicznego sprawdzenia kodu. Trzeba będzie badać również przewidywalność, spójność, możliwość powrotu do wcześniejszego stanu oraz to, czy użytkownik ma kontrolę nad tym, jak mocno system może zmieniać sposób interakcji.

Czy AI powinno wiedzieć, że użytkownik ma niepełnosprawność?

Personalizacja prowadzi do jeszcze trudniejszego pytania. Skoro system potrafi dostosować interfejs do konkretnej osoby, może pojawić się pokusa, żeby automatycznie tworzyć inną wersję dla użytkownika korzystającego z czytnika ekranu, inną dla osoby mającej problemy ze wzrokiem, a jeszcze inną dla osoby z trudnościami poznawczymi.

Technicznie jest to coraz bardziej możliwe. Organizacyjnie i etycznie robi się dużo bardziej skomplikowane.

System może przecież próbować wnioskować o potrzebach użytkownika z jego zachowania, urządzenia, ustawień systemowych albo wcześniejszych interakcji. W takim modelu bardzo łatwo przejść od dostępności do profilowania. Jeszcze gorzej, jeśli AI zacznie „pomagać” bez pytania i na podstawie własnego przypuszczenia uprości interfejs osobie, która wcale tego nie chciała.

Dostępny interfejs nie powinien wymagać od użytkownika ujawnienia niepełnosprawności. Jeżeli AI daje dodatkowe możliwości personalizacji, powinny one zwiększać kontrolę użytkownika, a nie odbierać mu decyzję o tym, jak chce korzystać z produktu. Warto pamiętać o tej granicy szczególnie teraz, zanim dynamiczne dostosowywanie interfejsów stanie się czymś powszechnym.

A jeśli model się pomyli?

W pracach Research Questions Task Force pojawia się jeszcze jeden wątek, który dobrze łączy się z wcześniejszymi tematami Labu: zawodność generatywnej AI. Grupa dyskutowała m.in. o halucynacjach, konieczności krytycznej oceny wyników i sytuacji, w której błędy systemu nie muszą być dla użytkownika oczywiste. W przypadku generowania opisów obrazu problem jest stosunkowo łatwy do pokazania: ten sam model może dla tego samego obrazu przygotować różniące się opisy, a użytkownik niewidomy nie zawsze ma niezależny sposób sprawdzenia, który z nich jest właściwy.

Przenieśmy teraz ten sam problem na interfejs. AI nie myli się już tylko w odpowiedzi tekstowej, ale może błędnie zbudować proces, pominąć istotną możliwość albo niewłaściwie zinterpretować intencję użytkownika. Jeżeli wygenerowany interfejs dotyczy zakupu biletu, konsekwencją będzie irytacja. Jeżeli dotyczy sprawy urzędowej, świadczenia, zdrowia albo innego procesu o większym znaczeniu, konsekwencje mogą być znacznie poważniejsze.

Dlatego generatywne UI nie może opierać się wyłącznie na założeniu, że skoro model przeciętnie generuje dobry interfejs, to rozwiązanie jest wystarczająco dostępne. W systemach używanych do realizacji istotnych zadań potrzebne będą ograniczenia, walidacja oraz możliwość przejścia na stabilny, przewidywalny interfejs, który nie zależy od poprawności pojedynczego wyniku modelu.

AI może stworzyć prostszą administrację. Ale równie dobrze może stworzyć nową barierę

Dla administracji publicznej ta technologia może być wyjątkowo ciekawa. Obecne serwisy często odzwierciedlają strukturę urzędu zamiast potrzeb mieszkańca. Użytkownik musi wiedzieć, do jakiej komórki należy sprawa, znaleźć odpowiednią usługę, przeczytać instrukcję i przejść przez formularz przygotowany według logiki organizacji.

Generatywny interfejs mógłby to odwrócić. Mieszkaniec opisuje, co chce zrobić, a system dobiera właściwą usługę i buduje potrzebną ścieżkę. Z perspektywy prostego języka, dostępności poznawczej czy osób, które mają trudność z poruszaniem się po rozbudowanych portalach, potencjał jest ogromny.

Tyle że ten sam mechanizm może stworzyć bardzo trudną do wykrycia barierę. Jeżeli tradycyjny formularz jest niedostępny, możemy go zbadać, znaleźć przyczynę i naprawić. Jeśli formularz jest generowany w locie i pojawia się tylko w określonej konfiguracji rozmowy z AI, samo wykrycie problemu może być trudniejsze. Administrator może nawet nie zobaczyć dokładnie tej wersji interfejsu, z którą spotkał się użytkownik.

Dlatego wraz z generatywnym UI rośnie znaczenie rejestrowania błędów, możliwości odtworzenia przebiegu interakcji i projektowania systemu tak, aby wygenerowany wynik nadal podlegał jasno określonym zasadom. Dostępność nie może być jedną z sugestii przekazywanych modelowi w promptach. Musi być właściwością całej architektury rozwiązania.

WCAG nie znika, ale sam sposób jego stosowania może się zmienić

Nie ma dziś podstaw, żeby twierdzić, że generatywne interfejsy wymagają porzucenia WCAG. Wiele podstawowych zasad pozostaje dokładnie takich samych: użytkownik musi mieć dostęp do informacji, interfejs musi być możliwy do obsługi, komunikaty i kontrolki muszą być zrozumiałe, a technologie asystujące muszą otrzymywać prawidłową strukturę i stan elementów.

Zmienia się natomiast przedmiot badania. W tradycyjnym produkcie oceniamy to, co zaprojektował zespół. W systemie generatywnym część decyzji projektowych może zostać podjęta dopiero w chwili interakcji z konkretnym użytkownikiem. Audyt będzie więc musiał coraz częściej pytać nie tylko „czy ten ekran jest dostępny?”, ale również „czy system jest zaprojektowany tak, aby nie mógł wygenerować niedostępnego ekranu?”.

To pozornie niewielka różnica, ale w praktyce zmienia bardzo dużo. Badanie pojedynczego wyniku zaczyna przypominać testowanie próbki z systemu, który może zachować się inaczej za chwilę. Wtedy znaczenia nabierają reguły generowania, testy automatyczne, dostępność biblioteki komponentów, scenariusze graniczne i ręczne testowanie zachowania całego procesu z technologiami asystującymi.

W3C dopiero zaczyna tę rozmowę

Warto zachować tutaj proporcje. Nie mamy dziś „WCAG dla generatywnej AI”, a dokument przygotowywany przez Research Questions Task Force nie jest nowym standardem zgodności. W sierpniu grupa nadal porządkowała strukturę projektu i zakres problemów, a z zapisów spotkań wynika, że lista zagadnień jest szeroka i ciągle rozwijana. Pojawiają się w niej nie tylko generatywne modele, ale również AI agentowa, wyszukiwanie oparte na AI, technologie asystujące i konsekwencje sytuacji, w której model staje się pośrednikiem między użytkownikiem a właściwą stroną internetową.

Równolegle W3C coraz mocniej interesuje się relacją pomiędzy AI a samą platformą Web. Seminarium poświęcone Generative UI i WebSkill jest jednym z sygnałów, że pytania o dostępność nie będą rozwiązywane wyłącznie na poziomie rekomendacji dla użytkowników modeli. Jeżeli interfejsy naprawdę zaczną być dynamicznie generowane przez agentów, standardy sieciowe będą musiały uwzględnić ten model działania.

Dla osób zajmujących się dostępnością to dobry moment, żeby zacząć obserwować temat, zanim pojawi się gotowa lista wymagań. Kiedy standard zostaje opublikowany, wiele produktów jest już zaprojektowanych i wdrożonych. Znacznie lepiej zadawać pytania o semantykę, przewidywalność, kontrolę użytkownika i możliwość testowania wtedy, kiedy sposób budowania tych systemów dopiero się kształtuje.

Być może za kilka lat będziemy audytować nie interfejs, ale zdolność systemu do jego bezpiecznego tworzenia

To na razie hipoteza, ale moim zdaniem całkiem prawdopodobna. Jeżeli generatywne interfejsy rzeczywiście upowszechnią się, obecny model audytu będzie musiał się rozszerzyć. Nadal będziemy testowali konkretne widoki, formularze i komponenty, ale częścią badania może stać się również ocena mechanizmu, który je składa.

Trzeba będzie wiedzieć, jakie komponenty AI może wykorzystać, jakie ma ograniczenia, czy użytkownik może wymusić stabilną wersję interfejsu, co dzieje się po błędzie, jak system zachowuje focus, czy zmiany są komunikowane technologiom asystującym i czy kolejne wygenerowanie tej samej funkcji nie daje zupełnie innego doświadczenia. W takim świecie dostępność przestaje być wyłącznie właściwością gotowego ekranu, a staje się również właściwością systemu generującego ekrany.

I właśnie dlatego prace rozpoczęte wokół W3C są dla mnie znacznie ciekawsze niż kolejna informacja o tym, że AI potrafi wygenerować opis alternatywny. Tu nie chodzi już o wykorzystanie sztucznej inteligencji jako dodatkowego narzędzia dostępności. Chodzi o sytuację, w której AI zaczyna współdecydować o tym, jak w ogóle wygląda cyfrowe środowisko, z którego korzysta użytkownik.

Jeżeli pójdziemy w tę stronę bez uwzględnienia dostępności od początku, za kilka lat możemy odkryć bardzo znajomy problem: nowe technologie będą niezwykle zaawansowane, a część użytkowników znowu będzie próbowała znaleźć sposób, żeby się do nich dostać. Tym razem jednak naprawienie pojedynczego przycisku czy formularza może już nie wystarczyć.