Coraz więcej stron i aplikacji powstaje z pomocą asystentów AI, a zespoły coraz częściej zakładają, że model „wie”, jak napisać dostępny kod. Wrześniowe badanie firmy AudioEye pokazuje, że to założenie jest ryzykowne. Wyniki pasują do tego, co w marcu zasygnalizował raport WebAIM Million: internet po raz pierwszy od lat zrobił się mniej dostępny.
Eksperyment: 15 stron „zgodnych z WCAG 2.2 AA”
AudioEye dało pięciu narzędziom AI (od OpenAI, Anthropic, Google, xAI i Lovable) to samo zadanie. Każde miało zbudować trzy serwisy: informacyjny, sklep internetowy i stronę usług finansowych, wszystkie zgodne z WCAG 2.2 AA. Powstałe 15 stron zeskanowano i przetestowano m.in. pod kątem obsługi fokusu klawiatury, zachowania okien dialogowych, ogłaszania błędów w formularzach i odczytu przez czytnik ekranu.
Wyniki:
- 306 różnych problemów z dostępnością, które wystąpiły łącznie ponad 59 tys. razy. Jeden błąd w menu albo polu formularza powtarza się na każdej stronie, która używa tego komponentu.
- 91% problemów oceniono jako średnio lub bardzo poważne, czyli utrudniające albo uniemożliwiające wykonanie zadania.
- Strony z AI miały średnio 55 problemów na stronę. Typowa strona w indeksie AudioEye za 2026 rok ma ich 62.
Wniosek autorów: wyraźna prośba o dostępny kod niewiele zmieniła. Ich zdaniem modele uczyły się na niedostępnym internecie i taki sam kod powielają.
Luka zaufania
Druga część badania to ankieta wśród programistów i menedżerów. 81% deklaruje przekonanie, że kod wygenerowany przez AI na ich stronach spełnia standardy dostępności. Jednocześnie 73% zauważa, że problemów i skarg dotyczących dostępności przybyło od czasu wdrożenia AI. 46% otrzymało wezwanie przedsądowe lub pozew, a 71% z tej grupy przyznaje, że zakwestionowane strony powstały z użyciem narzędzi AI.
Przy czytaniu tych liczb warto pamiętać o kontekście. AudioEye sprzedaje własne rozwiązania do automatycznego wykrywania i naprawiania błędów, a ankieta dotyczy głównie realiów amerykańskich, gdzie pozwy o dostępność są powszechne. Kierunek wyników jest jednak spójny z niezależnymi danymi.
WebAIM: złożoność i vibe coding
W raporcie WebAIM Million 2026 średnia liczba wykrywalnych błędów na stronach głównych wzrosła o 10,1%, do 56,1. Strony mają coraz więcej elementów i coraz więcej kodu ARIA. Autorzy wprost łączą ten trend z rosnącą zależnością od zewnętrznych frameworków i z kodowaniem wspieranym przez AI. Podkreślają, że poprawa dostępności na dużą skalę wymaga lepszych praktyk i prostszych systemów.
Druga strona medalu: AI w rękach niewidomych programistów
Byłoby jednak uproszczeniem uznać AI wyłącznie za zagrożenie. Badacze z Microsoft Research opisali dwutygodniowe badanie z udziałem 16 niewidomych i słabowidzących programistów, którzy pracowali z GitHub Copilot w VS Code. Wszyscy uczestnicy, którzy wzięli udział w drugim etapie, ocenili, że asystent zwiększył ich wydajność. Część z nich po raz pierwszy mogła sensownie pracować nad interfejsami użytkownika, które wcześniej były dla nich bardzo trudne ze względu na wizualny charakter.
Badanie pokazało też problemy. Ręczne pisanie kodu zajmowało uczestnikom tylko około jednej czwartej czasu zadania. Najwięcej czasu pochłaniało przeglądanie odpowiedzi AI, a duże trudności sprawiało sprawdzanie, co dokładnie zmienił agent. Po dwóch tygodniach uczestnicy zaczęli częściej wybierać bezpieczniejszy tryb pytań zamiast w pełni autonomicznego trybu agenta, bo chcieli zachować kontrolę. Jeden z nich powiedział badaczom: „to ty masz używać AI, a nie AI ciebie”.
Wniosek jest ważny także dla twórców narzędzi deweloperskich. Same asystenty kodowania muszą być dostępne. Potrzebne są jasne komunikaty o stanie, możliwość śledzenia zmian bez wzroku i spójne skróty klawiszowe.
Jak korzystać z AI i nie produkować barier
1. Nie traktuj promptu jako gwarancji. Dopisek „zgodnie z WCAG 2.2 AA” w poleceniu nie zastępuje testów. Badanie AudioEye pokazuje, że różnica była niewielka.
2. Wbuduj testy w proces. Automatyczne testy dostępności przy każdym wdrożeniu wychwycą część problemów, zanim trafią na produkcję. Kluczowe ścieżki, takie jak logowanie, formularze i płatności, sprawdzaj dodatkowo ręcznie z klawiaturą i czytnikiem ekranu.
3. Niech AI składa interfejs z gotowych, sprawdzonych komponentów. Jeden dostępny komponent formularza w bibliotece jest więcej wart niż sto wygenerowanych od zera. Błędy w komponentach powielają się na tysiącach stron, ale poprawki też.
4. Przeglądaj kod pod kątem dostępności tak samo jak pod kątem bezpieczeństwa. Natywne elementy HTML zamiast div z obsługą kliknięcia, poprawne etykiety, zarządzanie fokusem w modalach. To punkty, które warto mieć w liście kontrolnej code review.
5. Szkól zespół, nie tylko model. Programista, który rozumie WCAG, szybko zauważy, że wygenerowany przycisk nie ma dostępnej nazwy. Bez tej wiedzy AI tylko przyspiesza produkcję błędów.
6. Wybierając narzędzia, sprawdź ich dostępność. W zespole może pracować osoba korzystająca z czytnika ekranu. Badanie Microsoft Research pokazuje, że od dostępności narzędzia zależy, czy AI będzie dla niej wsparciem, czy kolejną przeszkodą.