Technologia obywatelska i świadczenia cyfrowe — jak portale zasiłkowe zawodzą wnioskodawców z niepełnosprawnościami

Stanowe portale ubezpieczenia na wypadek bezrobocia, strony do składania wniosków o SNAP, narzędzia do ustalania uprawnień do Medicaid oraz własny front-end SSDI Administracji Ubezpieczeń Społecznych to publiczne, istotne usługi amerykańskiej siatki bezpieczeństwa socjalnego. Są też jednymi z najgorzej radzących sobie z dostępnością powierzchni w publicznym internecie. Przeprowadzono audyt podstawowych portali świadczeń prowadzonych przez dziesięć najbardziej zaludnionych stanów USA — Kalifornię, Teksas, Florydę, Nowy Jork, Pensylwanię, Illinois, Ohio, Georgię, Karolinę Północną i Michigan — wraz z federalną warstwą uwierzytelniania (Login.gov) i systemami obsługi wnioskodawców SSA na SSA.gov, pod kątem WCAG 2.1 Level AA i ostatecznej reguły DOJ Tytuł II z 24 kwietnia 2024 roku, która prawnie wiąże rządy stanowe i lokalne tym samym standardem. Na dwunastu zbadanych powierzchniach odnotowano ok. 217 odrębnych błędów WCAG 2.1 AA, średnio ok. 18 na portal, przy czym tylko jeden z dwunastu spełnił wszystkie cztery nasze kryteria progowe. Niniejsze dossier wymienia portale z nazwy, klasyfikuje je i kończy omówieniem konsekwencji reguły DOJ dla najgorzej wypadających.

01. Metodologia i kryteria audytu

Audyt trwał od 7 marca do 12 maja 2026 roku. Dwóch audytorów przeszło kanoniczną ścieżkę wnioskodawcy na każdym z dwunastu portali od czystej sesji — bez poprzednich plików cookie, bez zainstalowanych rozszerzeń pomocniczych, bez autowypełniania. Ścieżka obejmowała: dotarcie do strony startowej, zarejestrowanie nowego konta, uwierzytelnienie, złożenie wstępnego wniosku o zasiłek dla bezrobotnych (lub, w przypadku SSA i powierzchni SNAP-Medicaid, równoważnego przepływu pierwszego wniosku), dotarcie do momentu przesłania, a następnie tygodniowe potwierdzenie lub przesłanie dokumentu uzupełniającego.

Każdą powierzchnię oceniano pod kątem kryteriów sukcesu WCAG 2.1 Level AA za pomocą axe-DevTools Pro 4.10 oraz ręcznego przejścia z NVDA 2024.4 na Windows 11 i VoiceOver na macOS 14.7. Przepływy mobilne były ponownie testowane na iOS 18.2 z VoiceOver i na Android 15 z TalkBack. Każdy plik PDF podany w trakcie ścieżki był wyodrębniany i analizowany oddzielnie za pomocą PAC 2024 i sprawdzenia dostępności Acrobat Pro DC.

Następnie zastosowano cztery binarne kryteria „progowe“ — bardziej zgrubne niż pełna drabinka WCAG, ale kryteria, na których faktycznie zależy pracującemu wnioskodawcy z niepełnosprawnością: obsługa klawiaturą (czy użytkownik korzystający wyłącznie z klawiatury może dotrzeć do złożonego wniosku?), naprawa błędów przez czytnik ekranu (gdy coś się nie powiedzie, czy czytnik ekranu ogłasza co i gdzie?), przedłużenie limitu czasu sesji (czy mechanizm ostrzeżenia i przedłużenia jest dostępny i operowalny przez technologię wspomagającą?) oraz dostępne przesyłanie plików (czy powodzenie lub niepowodzenie przesyłania jest ogłaszane programowo?). Powierzchnia przechodzi audyt tylko wtedy, gdy spełnia wszystkie cztery kryteria.

02. Ranking portali

Klasyfikacja dwunastu powierzchni według znormalizowanego wyniku dostępności — udział stron w ścieżce, które przeszły kontrolę axe przy WCAG 2.1 AA, ważony tym, czy spełniono cztery kryteria — przyniosła poniższą tabelę. Login.gov zajmuje pierwsze miejsce, ponieważ od początku był projektowany jako prymityw uwierzytelniania z priorytetem dostępności, a zespół ponownie testuje go przy każdym wydaniu. Powierzchnie wnioskodawców SSA.gov zajmują drugie miejsce, ponieważ Biuro Dostępnych Systemów i Technologii SSA prowadzi ciągły program monitorowania. Od trzeciego miejsca w dół przepaść do dołu jest stromy.

Login.gov pokazuje, jak wygląda dostępny portal świadczeń. Florida CONNECT pokazuje, jak wygląda portal, z którego nie można złożyć wniosku bez pomocy osoby widzącej.

03. Pułapki CAPTCHA

Kryterium CAPTCHA jest najbardziej widoczną powierzchnią błędu, ponieważ pojawia się wcześnie w przepływie — zazwyczaj w formularzu rejestracyjnym lub logowania, a czasem ponownie przy składaniu wstępnego wniosku jako środek antyfraudowy. Osiem z dwunastu audytowanych portali podaje wyzwanie reCAPTCHA v2 z samym obrazem, którego wariant audio jest albo zepsuty (ładuje się w ciszy, brak odtwarzalnego pliku audio), albo kieruje wnioskodawcę do ogólnego błędu 404. Dwa z ośmiu ustawia cały przepływ wstępnego wniosku za CAPTCHA: portal UI Texas Workforce Commission i Florida CONNECT. Niewidomy wnioskodawca w tych dwóch stanach, działający bez pomocy osoby widzącej, nie może złożyć wniosku przez te interfejsy. Musi zadzwonić do stanu, gdzie czas oczekiwania wynosi wiele godzin.

Ironia technologiczna polega na tym, że reCAPTCHA v3 — niewidoczna, oparta na zachowaniu, bez wyzwania dla zdecydowanej większości użytkowników — istnieje, jest bezpłatna przy wolumenach, jakie widzi portal stanowy, i rozwiązałaby problem kosztem jednego popołudnia pracy integracyjnej. Inercja zamówieniowa, a nie trudność techniczna, utrzymuje wyzwanie v2 na miejscu.

04. Limity czasu sesji bez możliwości przedłużenia

Jedenaście z dwunastu audytowanych portali — każdy stanowy portal zasiłkowy i iClaim SSA — wymusza limit czasu sesji w przedziale od 10 do 20 minut bezczynności. WCAG 2.2.1 (Timing Adjustable) wymaga, aby każde ograniczenie czasowe można było wyłączyć, dostosować lub przedłużyć przez użytkownika przed jego wygaśnięciem, z co najmniej 20-sekundowym ostrzeżeniem i prostą interakcją „przedłuż“. Spośród jedenastu, trzy w ogóle nie podają ostrzeżenia; sesja wygasa w połowie formularza i wnioskodawca jest przenoszony z powrotem do logowania z utratą wszystkich wprowadzonych danych.

Pięć kolejnych pokazuje wizualny modal odliczania, ale nigdy nie ogłasza modalu przez aria-live, więc użytkownik czytnika ekranu czytający formularz poniżej nie ma pojęcia, że ostrzeżenie się pojawiło. Pozostałe trzy ogłaszają modal, ale zarządzanie fokusem jest takie, że przycisk „Przedłuż sesję“ jest nieosiągalny przez Tab — klawisz Tab w leżącym poniżej formularzu nie przenosi fokusa do modalu. Użytkownik wie, że ostrzeżenie jest. Użytkownik nie może na nie zareagować.

05. Formularze wyłącznie w PDF wewnątrz ścieżki HTML

Dziewięć z dziesięciu stanowych portali zasiłkowych kieruje wnioskodawcę w pewnym momencie ścieżki do pliku PDF. Najczęstszymi winowajcami są formularz odwoławczy, tygodniowe potwierdzenie dla niepełnego tygodnia, dziennik poszukiwania pracy i zaświadczenie o przyznaniu świadczenia dla dependentów. Spośród podawanych plików PDF mniej niż połowa ma oznakowane drzewo struktury PDF. Reszta to zeskanowane obrazy papierowych formularzy — czasem oryginalny maszynowo napisany szablon z lat 90., wielokrotnie kserokopiowany — bez żadnej warstwy tekstowej.

Zeskanowany obrazem PDF podany jako wymagany formularz nie jest defektem dostępności na marginesie. To kategoryczne wykluczenie. Czytnik ekranu zgłasza pusty dokument. Pomocniki OCR zawodzą, bo formularz ma pola, których warstwa OCR nie może zrekonstruować. Wnioskodawca ma dwie opcje: wydrukować, wypełnić ręcznie, zeskanować ponownie i wysłać e-mailem; lub zadzwonić do agencji. Obie opcje zakładają drukarkę-skaner i pomoc osoby widzącej. Wielu wnioskodawców z niepełnosprawnościami nie ma ani jednego, ani drugiego.

06. Przesyłanie plików bez informacji zwrotnej dla czytnika ekranu

Dziesięć z dwunastu portali wymaga gdzieś w ścieżce przesłania pliku — zawiadomienia o rozwiązaniu umowy, dokumentu tożsamości, zaświadczenia lekarskiego, dokumentu uprawniającego do SNAP-Medicaid. Wzorzec, który konsekwentnie nie przechodzi audytu, jest następujący: element file-input to natywny HTML input opakowany w niestandardowo stylizowany przycisk „Wybierz plik“, który pochłania zdarzenie klawiatury i nigdy nie ogłasza wybranej nazwy pliku, nigdy nie ogłasza postępu przesyłania, nigdy nie ogłasza sukcesu i (co najgorsze) nigdy nie ogłasza niepowodzenia. Użytkownik wybiera plik. Coś się dzieje. Nic nie jest ogłaszane. Użytkownik przechodzi dalej, nie wiedząc, czy przesyłanie się powiodło — i odkrywa trzy dni później, że wniosek został odrzucony z powodu brakującej dokumentacji.

Najtańsza naprawa w całym dossier tkwi właśnie tutaj. Jeden niewidoczny wizualnie region live obok pola file-input, polite, aktualizowany przy wyborze i po zakończeniu z nazwą pliku i jednowyrazowym statusem, kosztuje godzinę pracy front-endu i rozwiązuje cały wzorzec błędu. Widziano to prawidłowo zaimplementowane na dokładnie jednej z dwunastu powierzchni.

07. Komunikaty o błędach bez aria-live

Najczęstszy błąd na wszystkich dwunastu powierzchniach — obecny w ok. trzech czwartych stanów błędów, które wywołano — to wbudowany błąd walidacji renderowany jako stylizowany czerwony span obok pola wejściowego, bez regionu aria-live, bez wskaźnika aria-describedby z pola wejściowego do tekstu błędu i bez programowego przeniesienia fokusa do błędu. Błąd jest widoczny. Błąd nie jest ogłaszany. Użytkownik czytnika ekranu przesyła formularz, strona się nie przeładowuje, użytkownik nie wie dlaczego nic się nie stało i przesyła ponownie.

Wzorzec ten kumuluje się z błędem limitu czasu sesji: wnioskodawca z niepełnosprawnością przechodzi przez nieogłaszane błędy walidacji w tempie ludzkiego ponownego czytania, trafia na 15-minutowy timeout, traci formularz i zaczyna od nowa. Naprawa to dwie linie na błąd — region aria-live blisko każdego zestawu pól, polite, do którego rutyna walidacji zapisuje po wywołaniu. Żadna z audytowanych powierzchni nie robi tego konsekwentnie.

Najdroższą częścią naprawy tych portali nie jest inżynieria. To kontrakt zamówieniowy, który trzeba ponownie otworzyć.

08. Konsekwencje egzekwowania DOJ Tytuł II

Ostateczna reguła DOJ Tytuł II z 24 kwietnia 2024 roku — skodyfikowana w 28 CFR Part 35, Subpart H — przyjmuje WCAG 2.1 Level AA jako federalny standard dostępności dla treści webowych i aplikacji mobilnych rządów stanowych i lokalnych. Duże podmioty publiczne (populacje powyżej 50 000 osób) miały termin zgodności 24 kwietnia 2026 roku; mniejsze podmioty mają czas do 24 kwietnia 2027 roku. Każdy stan w tym audycie obsługuje populację znacznie przekraczającą próg 50 000 osób. Termin z kwietnia 2026 roku jest już za nami.

Reguła przewiduje wyjątki — treści archiwalne, indywidualne dokumenty, treści chronione hasłem nieudostępniane publicznie, treści stron trzecich nieumieszczane przez podmiot — ale kanoniczna ścieżka wniosku o zasiłek dla bezrobotnych nie mieści się w żadnym z nich. Formularz wstępnego wniosku na stanowym portalu zasiłkowym jest aktualny, publicznie dostępny, udostępniany przez podmiot i używany przez ogół. Wchodzi wprost w zakres regulowanej powierzchni.

Egzekwowanie na podstawie Tytułu II odbywa się przez dochodzenia wszczęte przez DOJ (Sekcja ds. Praw Osób z Niepełnosprawnościami Wydziału Praw Obywatelskich), indywidualne skargi składane na civilrights.justice.gov oraz prywatne postępowania sądowe na podstawie tej samej ustawy. Środki przewidziane przez regułę obejmują plany zgodności, umowy monitoringowe, odszkodowania dla zidentyfikowanych skarżących oraz — w schemacie ugody stosowanym przez Departament od czasu ugody z H&R Block z 2014 roku — ogólnokrajowe harmonogramy naprawy z nazwanymi celami zgodności WCAG. Więcej na temat tego, co konkretnie przyciąga uwagę DOJ, można znaleźć w naszym artykule towarzyszącym o regule DOJ Tytuł II dwa lata później.

09. Ścieżka wnioskodawcy z niepełnosprawnością to najgorszy przypadek UX technologii obywatelskiej — i najważniejszy do naprawienia

Bezrobocie jest z definicji momentem ostrego stresu finansowego. Wnioskodawca nie ma dochodu, ma skończone rezerwy i stałe okno czasowe, w którym musi złożyć wniosek. Użytkownik bez niepełnosprawności porzuca zepsuty koszyk e-commerce i robi zakupy gdzie indziej. Wnioskodawca ubezpieczenia na wypadek bezrobocia z niepełnosprawnością nie może. Usługa jest obowiązkowa, termin jest stały, alternatywą jest nędza.

To właśnie sprawia, że portal świadczeń jest powierzchnią dostępności o najwyższej stawce w publicznym internecie. Dziesięć stanowych portali objętych audytem — z dwoma lub trzema wyjątkami — jest obecnie niezgodnych z federalną regułą, która weszła w życie w kwietniu 2026 roku. Były też, zanim ta reguła istniała, najbardziej brzemiennymi w skutki błędami dostępności w amerykańskiej technologii obywatelskiej. Reguła DOJ nie uczyniła tych portali ważnymi. Uczyniła je prawnie skarżalnymi.

To, co zmienia się dalej, to egzekwowanie, nie technologia. Naprawy — aria-live przy wbudowanych błędach, fokusowalny element sterowania przedłużeniem sesji, oznakowane pliki PDF, ogłaszany stan przesyłania pliku, działający wariant alternatywny CAPTCHA — są indywidualnie małe, dobrze udokumentowane i mieszczą się w rutynowym budżecie konserwacyjnym każdej agencji z listy. Brakowało nacisku regulacyjnego, uwagi politycznej i języka kontraktu zamówieniowego, które sprawiłyby, że naprawa stałaby się faktem. Pierwszy z tych elementów jest teraz obecny.