Civic Tech und digitale Sozialleistungen — wie Arbeitslosenportale Menschen mit Behinderungen scheitern

Die staatlichen Portale für Arbeitslosenversicherung, SNAP-Antragsseiten, Medicaid-Berechtigungstools und das SSDI-Frontend der SSA sind die öffentlich zugänglichen wesentlichen Dienste des amerikanischen sozialen Sicherheitsnetzes. Sie gehören zugleich zu den am schlechtesten abschneidenden Oberflächen für Barrierefreiheit im öffentlichen Web. Auditiert wurden die primären Leistungsportale der zehn bevölkerungsreichsten US-Bundesstaaten — Kalifornien, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, North Carolina und Michigan — sowie die föderale Authentifizierungsschicht (Login.gov) und die für Antragsteller zugänglichen Systeme der SSA auf SSA.gov, bewertet gegen WCAG 2.1 Level AA und die DOJ-Titel-II-Abschlussregel vom 24. April 2024, die staatliche und lokale Behörden rechtlich an denselben Standard bindet. Über die zwölf auditierten Oberflächen hinweg wurden ca. 217 verschiedene WCAG-2.1-AA-Verstöße protokolliert, im Durchschnitt ca. 18 pro Portal, wobei nur eine der zwölf alle vier Tor-Kriterien bestand. Dieses Dossier benennt die Portale, reiht sie ein und schließt mit den Konsequenzen der DOJ-Regel für die schlechtesten Performer.

01. Methodik und Audit-Tore

Das Audit lief vom 7. März bis 12. Mai 2026. Zwei Prüfer absolvierten die kanonische Antragstellerreise auf jedem der zwölf Portale von einer kalten Sitzung aus — keine vorherigen Cookies, keine installierten Hilfs-Extensions, kein Autofill. Die Reise umfasste: Ankunft auf der Einstiegsseite, Registrierung eines neuen Kontos, Authentifizierung, Einreichung eines Erstantrags auf Arbeitslosenleistungen (oder bei SSA- und SNAP-Medicaid-Oberflächen das entsprechende Erstantragsverfahren), Erreichen des Einreichungspunkts, anschließend Bestätigung einer folgenden Woche oder Upload eines unterstützenden Dokuments.

Jede Oberfläche wurde gegen die WCAG-2.1-Level-AA-Erfolgskriterien bewertet, unter Verwendung von axe-DevTools Pro 4.10 sowie einer manuellen Begehung mit NVDA 2024.4 auf Windows 11 und VoiceOver auf macOS 14.7. Mobile Abläufe wurden auf iOS 18.2 mit VoiceOver und auf Android 15 mit TalkBack nachgetestet. Jedes im Ablauf vorgelegte PDF wurde separat extrahiert und mit PAC 2024 sowie der Barrierefreiheitsprüfung von Acrobat Pro DC analysiert.

Anschließend wurden vier binäre „Tor“-Kriterien angewendet — gröber als die vollständige WCAG-Skala, aber die Kriterien, auf die es einem arbeitenden Menschen mit Behinderung tatsächlich ankommt: Tastaturbedienbarkeit (kann ein reiner Tastaturnutzer einen eingereichten Antrag erreichen?), Screenreader-Fehlerbehebung (wenn etwas fehlschlägt, teilt der Screenreader was und wo mit?), Sitzungs-Timeout-Verlängerung (ist der Warn-und-Verlängerungsmechanismus über assistive Technologie erreichbar und bedienbar?), und zugänglicher Datei-Upload (wird Erfolg oder Misserfolg beim Upload programmatisch angekündigt?). Eine Oberfläche besteht das Audit nur dann, wenn sie alle vier Tore passiert.

02. Das Portal-für-Portal-Ranking

Die Rangordnung der zwölf Oberflächen nach ihrem normalisierten Barrierefreiheits-Score — dem Anteil der Seiten in der Reise, die axe auf WCAG-2.1-AA-Niveau bestanden haben, gewichtet danach, ob die vier Tore passiert wurden — ergab die folgende Tabelle. Login.gov steht an der Spitze, weil es von Beginn an als barrierefreiheitsorientiertes Authentifizierungsprimitiv konzipiert wurde und das Team bei jedem Release erneut testet. Die für Antragsteller zugänglichen Oberflächen von SSA.gov stehen an zweiter Stelle, weil das Office of Accessible Systems and Technology der SSA ein kontinuierliches Monitoring-Programm betreibt. Ab dem dritten Platz ist der Abstand zum Ende steil.

Login.gov zeigt, wie ein zugängliches Leistungsportal aussieht. Florida CONNECT zeigt, wie eines aussieht, das ohne Sehunterstützung nicht ausgefüllt werden kann.

03. CAPTCHA-Fallen

Das CAPTCHA-Tor ist die sichtbarste Fehleroberfläche, weil es früh im Ablauf sitzt — üblicherweise im Registrierungs- oder Anmeldeformular, manchmal erneut bei der Erstantragsstellung als Anti-Betrugsmaßnahme. Acht der zwölf auditierten Portale bieten eine Nur-Bild-reCAPTCHA-v2-Herausforderung, deren Audio-Fallback entweder defekt ist (lädt geräuschlos, keine abspielbare Audiodatei) oder den Antragsteller auf einen generischen 404-Fehler weiterleitet. Zwei der acht sperren den gesamten Erstantragsablauf hinter dem CAPTCHA: das UI-Portal der Texas Workforce Commission und Florida CONNECT. Ein blinder Antragsteller in diesen zwei Bundesstaaten, der ohne Sehunterstützung arbeitet, kann von diesen Oberflächen aus keinen Antrag stellen. Er muss die staatliche Behörde anrufen, wo die Warteschlangen mehrere Stunden betragen.

Die Civic-Tech-Ironie liegt darin, dass reCAPTCHA v3 — unsichtbar, verhaltensbasiert, ohne Herausforderung für die große Mehrheit der Nutzer — existiert, bei den Volumen eines staatlichen Portals kostenlos ist und das Problem mit einem halben Tag Integrationsarbeit lösen würde. Beschaffungsträgheit, nicht technische Schwierigkeit, hält die v2-Herausforderung aufrecht.

04. Sitzungs-Timeouts, die nicht verlängern

Elf der zwölf auditierten Portale — jedes staatliche Arbeitslosenportal und SSA’s iClaim — setzen einen Sitzungs-Timeout im Bereich von 10 bis 20 Minuten Inaktivität durch. WCAG 2.2.1 (Timing Adjustable) verlangt, dass jede Zeitbegrenzung vom Nutzer vor Ablauf ausschaltbar, anpassbar oder verlängerbar ist, mit mindestens 20 Sekunden Vorwarnung und einer einfachen „Verlängern“-Interaktion. Von den elf geben drei überhaupt keine Warnung; die Sitzung läuft mitten im Formular ab und der Antragsteller wird zurück zur Anmeldung geleitet, alle eingegebenen Daten verloren.

Fünf weitere zeigen einen visuellen Modal-Countdown, kündigen das Modal jedoch nie über aria-live an, sodass ein Screenreader-Nutzer, der das darunterliegende Formular liest, keine Ahnung hat, dass die Warnung erschienen ist. Die verbleibenden drei kündigen das Modal an, sperren den Fokus aber so, dass die Schaltfläche „Sitzung verlängern“ per Tab nicht erreichbar ist — ein Tab im darunterliegenden Formular verschiebt den Fokus nicht in das Modal. Der Nutzer weiß, dass die Warnung da ist. Der Nutzer kann nicht auf sie reagieren.

05. Nur-PDF-Formulare in einer HTML-Reise

Neun der zehn staatlichen Arbeitslosenportale leiten den Antragsteller an irgendeiner Stelle der Reise zu einem PDF. Die häufigsten Kandidaten sind das Widerspruchsformular, die Teilwochenbescheinigung, das Arbeitssuchprotokoll und die Unterhaltsbeihilfe-Bestätigung. Von den vorgelegten PDFs besitzen weniger als die Hälfte eine getaggte PDF-Strukturstruktur. Der Rest sind eingescannte Bilder von Papierformularen — manchmal das ursprüngliche mit Schreibmaschine erstellte Template aus den 1990er Jahren, mehrfach fotokopiert — ohne jegliche Textebene.

Ein eingescanntes Bild-PDF, das als Pflichtformular dient, ist kein marginaler Barrierefreiheitsmangel. Es ist ein kategorischer Ausschluss. Der Screenreader meldet ein leeres Dokument. OCR-Helfer scheitern, weil das Formular Felder hat, die die OCR-Schicht nicht rekonstruieren kann. Der Antragsteller hat zwei Optionen: ausdrucken, von Hand ausfüllen, einscannen und per E-Mail zurücksenden; oder die Behörde anrufen. Beide Optionen setzen einen Drucker-Scanner und Sehunterstützung voraus. Viele Menschen mit Behinderungen haben weder das eine noch das andere.

06. Datei-Uploads ohne Screenreader-Rückmeldung

Zehn der zwölf Portale verlangen irgendwo in der Reise einen Datei-Upload — eine Trennungsbenachrichtigung, ein Ausweisdokument, eine medizinische Bescheinigung, ein SNAP-Medicaid-Berechtigungsdokument. Das Muster, das das Audit konsequent scheitern lässt, ist: das Datei-Input-Element ist ein natives HTML-Input, das in eine benutzerdefiniert gestaltete „Datei auswählen“-Schaltfläche verpackt ist, die das Tastaturereignis schluckt und nie den ausgewählten Dateinamen ankündigt, nie den Upload-Fortschritt ankündigt, nie den Erfolg ankündigt, und (am schlimmsten) nie den Misserfolg ankündigt. Der Nutzer wählt eine Datei aus. Irgendetwas passiert. Nichts wird angekündigt. Der Nutzer macht weiter, ohne zu wissen, ob der Upload erfolgreich war — und entdeckt drei Tage später, dass der Antrag wegen fehlender Dokumentation abgelehnt wurde.

Die günstigste Lösung im gesamten Dossier liegt hier. Eine einzige visuell verborgene Live-Region neben dem Datei-Input, höflich, beim Auswählen und beim Abschluss mit dem Dateinamen und einem einwortigen Status aktualisiert, kostet eine Stunde Frontend-Arbeit und behebt das gesamte Fehlermuster. Auf genau einer der zwölf Oberflächen war es korrekt implementiert.

07. Fehlermeldungen ohne aria-live

Das häufigste Versagen über alle zwölf Oberflächen hinweg — bei etwa drei von vier ausgelösten Fehlerzuständen vorhanden — war eine Inline-Validierungsfehlermeldung, die als gestaltetes rotes Span neben einem Eingabefeld gerendert wurde, ohne aria-live-Bereich, ohne aria-describedby-Zeiger vom Input zum Fehlertext und ohne programmatische Verschiebung des Fokus zum Fehler. Der Fehler ist sichtbar. Der Fehler wird nicht angekündigt. Der Screenreader-Nutzer sendet ab, die Seite lädt nicht neu, der Nutzer weiß nicht, warum nichts passiert ist, und sendet erneut ab.

Das Muster potenziert sich mit dem Sitzungs-Timeout-Versagen: ein Mensch mit Behinderung als Antragsteller durchläuft nicht angekündigte Validierungsfehler mit der Geschwindigkeit menschlichen Wiederlesens, erreicht den 15-Minuten-Timeout, verliert das Formular und fängt von vorne an. Die Lösung sind zwei Zeilen pro Fehler — ein aria-live-Bereich nahe jedem Fieldset, höflich, in den die Validierungsroutine schreibt, wenn sie ausgelöst wird. Keine der auditierten Oberflächen tut dies konsequent.

Der teuerste Teil der Behebung dieser Portale ist nicht die technische Umsetzung. Es ist der Beschaffungsvertrag, der wieder aufgeklappt werden muss.

08. Konsequenzen für die DOJ-Titel-II-Durchsetzung

Die DOJ-Titel-II-Abschlussregel vom 24. April 2024 — kodifiziert unter 28 CFR Part 35, Subpart H — übernimmt WCAG 2.1 Level AA als föderalen Barrierefreiheitsstandard für Webinhalte und mobile Apps staatlicher und lokaler Behörden. Große öffentliche Stellen (Bevölkerungen von 50.000 oder mehr) hatten eine Konformitätsfrist bis zum 24. April 2026; kleinere Stellen haben bis zum 24. April 2027. Jeder Bundesstaat in diesem Audit bedient eine Bevölkerung weit über dem 50.000-Schwellenwert. Die April-2026-Frist liegt in der Vergangenheit.

Die Regel enthält Ausnahmen — archivierte Inhalte, individualisierte Dokumente, passwortgeschützte nicht öffentliche Inhalte, Drittanbieterinhalte, die nicht von der Stelle selbst eingestellt wurden — aber die kanonische Arbeitslosenantragstellerreise fällt in keine davon. Ein Erstantragsformular auf einem staatlichen UI-Portal ist aktuell, öffentlich zugänglich, von der Stelle bereitgestellt und wird von der Öffentlichkeit genutzt. Es liegt eindeutig innerhalb der regulierten Oberfläche.

Die Durchsetzung nach Titel II erfolgt durch DOJ-initiierte Untersuchungen (die Abteilung für Behindertenrechte der Bürgerrechtsabteilung), individuelle Beschwerden, eingereicht unter civilrights.justice.gov, und private Klagen nach demselben Gesetz. Die von der Regel vorgesehenen Rechtsmittel umfassen Konformitätspläne, Monitoring-Vereinbarungen, Schadensersatz für identifizierte Beschwerdeführer und — im Consent-Decree-Muster, das das Ministerium seit dem H&R-Block-Abkommen von 2014 verwendet — landesweite Behebungszeitpläne mit benannten WCAG-Konformitätszielen. Mehr zu dem, was speziell DOJ-Aufmerksamkeit auslöst, bietet unser Begleitstück über die DOJ-Titel-II-Regel, zwei Jahre danach.

09. Die Reise des Antragstellers mit Behinderung ist die schlechteste Civic-Tech-UX — und die wichtigste zu lösende

Arbeitslosigkeit ist per Definition ein Moment akuten finanziellen Drucks. Der Antragsteller hat kein Einkommen, begrenzte Reserven und ein festes Zeitfenster, in dem er den Antrag stellen muss. Ein Nicht-Antragsteller verlässt einen defekten E-Commerce-Checkout und kauft woanders. Ein arbeitsloser Versicherungsantragsteller mit Behinderung kann das nicht. Die Leistung ist obligatorisch, das Timing ist fest, die Alternative ist Mittellosigkeit.

Genau das macht ein Leistungsportal zur Oberfläche mit den höchsten Einsätzen für Barrierefreiheit im öffentlichen Web. Die zehn staatlichen Portale, die auditiert wurden, sind — mit zwei oder drei Ausnahmen — derzeit nicht konform mit der Bundesregel, die im April 2026 in Kraft trat. Sie waren auch, bevor diese Regel existierte, die folgenreichsten Barrierefreiheitsversagen in der amerikanischen Civic Tech. Die DOJ-Regel hat diese Portale nicht wichtig gemacht. Sie hat sie rechtlich verfolgbar gemacht.

Was sich als nächstes ändert, ist die Durchsetzung, nicht die Technologie. Die Lösungen — aria-live bei Inline-Fehlern, ein fokussierbares Sitzung-verlängern-Steuerelement, getaggte PDFs, ein angekündigter Datei-Upload-Zustand, ein funktionierender CAPTCHA-Fallback — sind einzeln klein, gut dokumentiert und innerhalb des regulären Wartungsbudgets jeder Behörde auf der Liste. Was gefehlt hat, ist der regulatorische Druck, die politische Aufmerksamkeit und die Beschaffungsvertragssprache, um die Behebung in Gang zu setzen. Das erste ist nun vorhanden.