Civic tech en digitale uitkeringen — hoe werkloosheidsportalen mensen met een beperking in de steek laten

Staatswerkloosheidsverzekeringssystemen, SNAP-aanvraagsites, Medicaid-geschiktheidstools en het SSDI-loket van de Social Security Administration zijn de publieke toegangspoorten tot het Amerikaanse vangnet. Ze zijn tegelijkertijd een van de slechtst presterende toegankelijkheidsoppervlakken op het publieke web. We auditeerden de voornaamste uitkeringsportalen van de tien meest bevolkte Amerikaanse staten — Californië, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, North Carolina en Michigan — samen met de federale authenticatielaag (Login.gov) en de SSA-aanvraagsystemen op SSA.gov, aan de hand van WCAG 2.1 Level AA en de DOJ Title II-eindregel van 24 april 2024, die staat en lokaal bestuur juridisch aan dezelfde norm bindt. Over de twaalf geauditeerde oppervlakken werden ca. 217 afzonderlijke WCAG 2.1 AA-tekortkomingen vastgesteld, gemiddeld ca. 18 per portaal, en slechts één van de twaalf slaagde voor al onze vier gatecriteria. Dit dossier noemt de portalen bij naam, rangschikt ze en sluit af met wat de DOJ-regel betekent voor de slechtst presterende portalen.

01. Methodologie en auditgates

De audit liep van 7 maart tot 12 mei 2026. Twee auditors doorliepen het canonieke aanvraagtraject op elk van de twaalf portalen vanuit een koude sessie — geen eerdere cookies, geen hulpextensies geïnstalleerd, geen automatisch invullen. Het traject was: aankomen op de startpagina, een nieuw account registreren, authenticeren, een initiële aanvraag voor werkloosheidsuitkering indienen (of, voor SSA- en SNAP-Medicaid-systemen, de equivalente eerste aanvraagflow), tot het punt van indiening komen, vervolgens een volgende week certificeren of een ondersteunend document uploaden.

Elk oppervlak werd getoetst aan de WCAG 2.1 Level AA-succescriteria met axe-DevTools Pro 4.10 plus een handmatige doorloop met NVDA 2024.4 op Windows 11 en VoiceOver op macOS 14.7. Mobiele flows werden opnieuw getest op iOS 18.2 met VoiceOver en op Android 15 met TalkBack. Elke PDF die in het traject werd aangeboden, werd apart geëxtraheerd en geanalyseerd met PAC 2024 en de toegankelijkheidscheck van Acrobat Pro DC.

Vervolgens pasten we vier binaire “gate”-criteria toe — grover dan de volledige WCAG-ladder, maar de criteria waarop een werkende aanvrager met een beperking daadwerkelijk rekent: bedienbaar via toetsenbord (kan een toetsenbord-gebruiker een ingediende aanvraag bereiken?), schermlezerfoutherstel (als er iets misgaat, kondigt de schermlezer aan wat en waar?), sessietime-outverlenging (is het waarschuwings- en verlengingsmechanisme bereikbaar en bedienbaar via hulptechnologie?), en toegankelijke bestandsupload (wordt het slagen of falen van een upload programmatisch aangekondigd?). Een oppervlak slaagt de audit uitsluitend als het alle vier de gates doorstaat.

02. De rangschikking portaal voor portaal

Het rangschikken van de twaalf oppervlakken op basis van hun genormaliseerde toegankelijkheidsscore — het aandeel pagina’s in het traject dat axe op WCAG 2.1 AA doorstond, gewogen naar of de vier gates werden gehaald — leverde de onderstaande tabel op. Login.gov staat bovenaan omdat het vanaf de start is ontworpen als een toegankelijkheidsprioriteit en het team bij elke release opnieuw test. De aanvraagsystemen op SSA.gov staan tweede omdat het Office of Accessible Systems and Technology van de SSA een doorlopend monitoring-programma beheert. Vanaf de derde plek is de val naar de bodem steil.

Login.gov laat zien hoe een toegankelijk uitkeringsportaal eruitziet. Florida CONNECT laat zien hoe een portaal eruitziet dat niet kan worden ingediend zonder ziende hulp.

03. CAPTCHA-vallen

De CAPTCHA-gate is het meest zichtbare probleemoppervlak omdat het vroeg in het proces staat — doorgaans bij het registratie- of inlogformulier, soms opnieuw bij de initiële aanvraagindiening als fraudebeveiliging. Acht van de twaalf geauditeerde portalen tonen een afbeeldingsgebaseerde reCAPTCHA v2-uitdaging waarvan de audiofallback defect is (laadt geruisloos, geen afspeelbaar audiobestand) of de aanvrager naar een generieke 404 leidt. Twee van de acht blokkeren het volledige initiële aanvraagproces achter de CAPTCHA: het UI-portaal van de Texas Workforce Commission en Florida CONNECT. Een blinde aanvrager in die twee staten kan zonder ziende hulp geen aanvraag indienen via die interfaces. Men moet de staat bellen, waar de wachtrij oploopt tot meerdere uren.

De civic-tech-ironie is dat reCAPTCHA v3 — onzichtbaar, gedragsgebaseerd, geen uitdaging voor de grote meerderheid van gebruikers — bestaat, gratis is op de volumes die een staatsportaal bezoekt, en het probleem zou oplossen met een namiddags integratiewerk. Aanbestedingstraagheid, niet technische moeilijkheidsgraad, houdt de v2-uitdaging op zijn plaats.

04. Sessietime-outs die niet verlengbaar zijn

Elf van de twaalf geauditeerde portalen — elk staatswerkloosheidsoppervlak en SSA’s iClaim — handhaven een sessietime-out van 10 tot 20 minuten inactiviteit. WCAG 2.2.1 (Aanpasbare timing) vereist dat elke tijdslimiet door de gebruiker kan worden uitgeschakeld, aangepast of verlengd voordat deze verloopt, met minstens 20 seconden waarschuwing en een eenvoudige “verleng”-interactie. Van de elf geven er drie geen enkele waarschuwing; de sessie verloopt gewoon midden in een formulier en de aanvrager wordt teruggestuurd naar het inlogscherm met verlies van alle ingevoerde gegevens.

Vijf meer tonen een visueel modaal afteltimer maar kondigen het modaal venster nooit aan via aria-live, zodat een schermlezersgebruiker die het formulier eronder leest geen idee heeft dat de waarschuwing is verschenen. De resterende drie kondigen het modaal wel aan maar vangen de focus zodanig dat de knop “Sessie verlengen” niet bereikbaar is via Tab — een Tab-toets in het onderliggende formulier verplaatst de focus niet naar het modaal venster. De gebruiker weet dat de waarschuwing er is. De gebruiker kan er niet op reageren.

05. PDF-formulieren binnen een HTML-traject

Negen van de tien staatswerkloosheidsportalen sturen de aanvrager op enig moment in het traject door naar een PDF. De meest voorkomende zijn het bezwaarformulier, de deelweekcertificering, het werkzoeklogboek en de attestatie voor toeslaguitkeringen afhankelijken. Van de aangeboden PDF’s heeft minder dan de helft een getagde PDF-structuurboom. De rest zijn gescande afbeeldingen van papieren formulieren — soms het originele getypte sjabloon uit de jaren negentig, gekopieerd en opnieuw gekopieerd — zonder enige tekstlaag.

Een gescande PDF als verplicht formulier is geen randacces-tekortkoming. Het is een categorische uitsluiting. De schermlezer meldt een leeg document. OCR-hulpmiddelen falen omdat het formulier velden bevat die de OCR-laag niet kan reconstrueren. De aanvrager heeft twee opties: afdrukken, met de hand invullen, inscannen en e-mailen; of de instantie bellen. Beide opties veronderstellen een printer-scanner en ziende hulp. Veel aanvragers met een beperking hebben geen van beide.

06. Bestandsuploads zonder feedback voor schermlezers

Tien van de twaalf portalen vereisen ergens in het traject een bestandsupload — een ontslagbrief, een identiteitsdocument, een medische verklaring, een SNAP-Medicaid-geschiktheidsdocument. Het patroon dat de audit consequent doet falen is: het bestandsinvoerelement is een native HTML-invoer verpakt in een aangepast gestylede knop “Bestand kiezen” die de toetsenbordgebeurtenis opslokt en nooit de geselecteerde bestandsnaam aankondigt, nooit de uploadvoortgang aankondigt, nooit het slagen aankondigt en (het ergst) nooit het falen aankondigt. De gebruiker selecteert een bestand. Er gebeurt iets. Er wordt niets aangekondigd. De gebruiker gaat verder zonder te weten of de upload slaagde — en ontdekt drie dagen later dat de aanvraag is afgewezen wegens ontbrekende documentatie.

De goedkoopste oplossing in het gehele dossier bevindt zich hier. Een enkele visueel verborgen live-region naast het bestandsinvoerveld, beleefd, bijgewerkt bij selectie en voltooiing met de bestandsnaam en een status in één woord, kost een uur front-end werk en lost het volledige faalpatroon op. We zagen dit correct geïmplementeerd op precies één van de twaalf oppervlakken.

07. Foutmeldingen zonder aria-live

De meest voorkomende tekortkoming over alle twaalf oppervlakken — aanwezig bij circa drie van de vier fouttoestanden die we veroorzaakten — was een inline validatiefout weergegeven als een gestylede rode span naast een invoerveld, zonder aria-live-region, zonder aria-describedby-verwijzing van het invoerveld naar de fouттекst en zonder programmatische focusverplaatsing naar de fout. De fout is zichtbaar. De fout wordt niet aangekondigd. De schermlezergebruiker dient in, de pagina herlaadt niet, de gebruiker weet niet waarom er niets is gebeurd, en de gebruiker dient opnieuw in.

Het patroon verergert door de sessietime-outtekortkoming: een aanvrager met een beperking doorloopt niet-aangekondigde validatiefouten op de snelheid van menselijk herlezen, raakt de time-out van 15 minuten, verliest het formulier en begint opnieuw. De oplossing zijn twee regels per fout — een aria-live-region nabij elk formulieronderdeel, beleefd, waartoe de validatieroutine schrijft wanneer deze wordt uitgevoerd. Geen van de door ons geauditeerde oppervlakken doet dit consequent.

Het duurste deel van het herstel van deze portalen is niet de techniek. Het is het aanbestedingscontract dat heropend moet worden.

08. Handhavingsimplicaties DOJ Title II

De DOJ Title II-eindregel van 24 april 2024 — gecodificeerd in 28 CFR Part 35, Subpart H — neemt WCAG 2.1 Level AA over als federale toegankelijkheidsnorm voor webinhoud en mobiele apps van staat en lokaal bestuur. Grote overheidsinstanties (bevolkingen van 50.000 of meer) hadden een nalevingsdeadline van 24 april 2026; kleinere instanties hebben tot 24 april 2027. Elke staat in deze audit bedient een bevolking die ruimschoots boven de drempel van 50.000 ligt. De april 2026-deadline is verstreken.

De regel kent uitzonderingen — gearchiveerde inhoud, geïndividualiseerde documenten, niet-openbare inhoud met wachtwoordbeveiliging, inhoud van derden die niet door de instantie is geplaatst — maar het canonieke werkloosheidsaanvraagtraject valt buiten geen van deze uitzonderingen. Een initieel aanvraagformulier op een staatswerkloosheidsportaal is actueel, publieksgericht, door de instantie aangeboden en door het publiek gebruikt. Het valt duidelijk binnen het gereguleerde oppervlak.

Handhaving op grond van Title II verloopt via DOJ-geïnitieerde onderzoeken (de Disability Rights Section van de Civil Rights Division), individuele klachten ingediend op civilrights.justice.gov, en particuliere rechtszaken op grond van dezelfde wet. De maatregelen die de regel voorziet omvatten nalevingsplannen, monitoringovereenkomsten, schadevergoeding aan aangewezen klagers, en — in het toestemmingsdecreetpatroon dat het ministerie heeft gebruikt sinds het H&R Block-akkoord van 2014 — landelijke hersteltermiijnen met benoemde WCAG-conformiteitsdoelen. Voor meer over wat specifiek DOJ-aandacht trekt, zie ons begeleidende stuk over de DOJ Title II-regel, twee jaar later.

09. Het aanvraagtraject voor mensen met een beperking is de meest kritieke civic-tech UX — en de belangrijkste om te herstellen

Werkloosheid is per definitie een moment van acute financiële druk. De aanvrager heeft geen inkomen, beperkte reserves en een vaste termijn om een aanvraag in te dienen. Een niet-aanvrager verlaat een defecte e-commerce-kassa en winkelt elders. Een aanvrager met een beperking van een werkloosheidsverzekering kan dat niet. De dienst is verplicht, de timing is vast, het alternatief is armoede.

Dat is wat een uitkeringsportaal het hoogst-inzet toegankelijkheidsoppervlak op het publieke web maakt. De tien staatsportalen die we auditeerden, zijn — op twee of drie uitzonderingen na — momenteel niet in overeenstemming met de federale regel die in april 2026 van kracht werd. Ze waren ook, voordat die regel bestond, de meest ingrijpende toegankelijkheidstekortkomingen in de Amerikaanse civic tech. De DOJ-regel heeft deze portalen niet belangrijk gemaakt. Hij heeft ze juridisch afdwingbaar gemaakt.

Wat hierna verandert is handhaving, niet technologie. De oplossingen — aria-live op inline fouten, een focusbaar besturingselement voor sessieverlenging, getagde PDF’s, een aangekondigde uploadstatus, een werkende CAPTCHA-fallback — zijn individueel klein, goed gedocumenteerd en binnen het routineonderhoudsbudget van elke instantie op de lijst. Wat ontbrak was de regulatoire druk, de politieke aandacht en de contracttaal voor aanbestedingen om herstel te realiseren. Het eerste is nu aanwezig.