Civic tech og digitale ydelser — hvordan dagpengeportaler svigter ansøgere med handicap

Staternes portaler til dagpenge, SNAP-ansøgninger, Medicaid-tilskudsberettigelse og SSA’s eget SSDI-system er de offentligt tilgængelige, essentielle tjenester i det amerikanske sociale sikkerhedsnet. De er også nogle af de dårligst præsterende tilgængeligheds­flader på det offentlige internet. Vi gennemgik de primære ydelsesportaler drevet af de ti mest folkerige amerikanske stater — Californien, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, North Carolina og Michigan — samt det føderale autentificerings­lag (Login.gov) og SSA’s ansøgerrettede systemer på SSA.gov, mod WCAG 2.1 niveau AA og DOJ Title II-slutreglen af 24. april 2024, som juridisk forpligter stats- og lokalmyndigheder til den samme standard. På tværs af de tolv gennemgåede flader registrerede vi ca. 217 unikke WCAG 2.1 AA-fejl, et gennemsnit på ca. 18 pr. portal, og kun én af de tolv bestod alle fire af vores gatekriterier. Dette dossier nævner portalerne ved navn, rangordner dem og slutter med, hvad DOJ-reglen betyder for de dårligste.

01. Metode og auditgates

Auditen løb fra 7. marts til 12. maj 2026. To auditorer gennemgik den kanoniske ansøgerrejse på hver af de tolv portaler fra en kold session — ingen tidligere cookies, ingen hjælpeudvidelser installeret, ingen autofyld. Rejsen var: ankomst til landingssiden, oprettelse af ny konto, autentificering, indgivelse af første dagpengekrav (eller, for SSA og SNAP-Medicaid-flader, den tilsvarende første-ansøgningsforløb), nå frem til indsendelse, derefter certificering af en efterfølgende uge eller upload af et støttedokument.

Hver flade blev evalueret mod WCAG 2.1 niveau AA-succeskriterier ved hjælp af axe-DevTools Pro 4.10 samt en manuel gennemgang med NVDA 2024.4 på Windows 11 og VoiceOver på macOS 14.7. Mobile forløb blev gentestet på iOS 18.2 med VoiceOver og på Android 15 med TalkBack. Alle PDF-filer, der optrådte i rejsen, blev udtrukket og analyseret separat med PAC 2024 og Acrobat Pro DC’s tilgængelighedstjek.

Vi anvendte derefter fire binære “gate”-kriterier — grovere end den fulde WCAG-stige, men de kriterier en arbejdende person med handicap faktisk bekymrer sig om: tastaturoperérbar (kan en bruger, der kun bruger tastatur, nå frem til en indsendt ansøgning?), skærmlæser-fejlgendannelse (når noget fejler, annoncerer skærmlæseren hvad og hvor?), sessionsforlængelse (er advarsel-og-forlæng-mekanismen tilgængelig og operérbar via hjælpeteknologi?), og tilgængeligt filupload (annonceres upload-succes eller -fejl programmatisk?). En flade består kun auditen, hvis den overstår alle fire gates.

02. Portal-for-portal-rangordningen

Rangordning af de tolv flader efter deres normaliserede tilgængelighedsscore — andelen af sider i rejsen, der bestod axe ved WCAG 2.1 AA, vægtet ud fra om de fire gates blev bestået — gav tabellen nedenfor. Login.gov ligger øverst, fordi det var designet som en tilgængeligheds­første autentificeringsprimitiv fra starten, og teamet genafprøver ved hvert release. SSA.gov’s ansøgerflader ligger på andenpladsen, fordi SSA’s Office of Accessible Systems and Technology driver et program for løbende overvågning. Fra tredjepladsen og ned er faldet til bunden stejlt.

Login.gov viser formen på en tilgængelig ydelsesportal. Florida CONNECT viser formen på én, der ikke kan udfyldes uden seende hjælp.

03. CAPTCHA-fælder

CAPTCHA-gaten er den mest synlige fejlflade, fordi den sidder tidligt i forløbet — normalt på registrerings- eller loginformularen, og somme tider igen ved indgivelse af den første ansøgning som svindelforebyggelse. Otte af de tolv auditerede portaler serverer en billede-only reCAPTCHA v2-udfordring, hvis lydfallback enten er defekt (indlæses lydløst, ingen lyd) eller sender ansøgeren til en generisk 404. To af de otte låser hele den indledende ansøgningsproces bag CAPTCHA’en: Texas Workforce Commissions UI-portal og Florida CONNECT. En blind ansøger i de to stater, der arbejder uden seende hjælp, kan ikke indgive et krav via disse grænseflader. De er nødt til at ringe til staten, hvor ventetiden er adskillige timer.

Den civic-tech-ironi er, at reCAPTCHA v3 — usynlig, adfærdsbaseret, ingen udfordring for langt størstedelen af brugerne — findes, er gratis i de mængder en statsportal håndterer, og ville løse problemet til prisen af en eftermiddags integrationsarbejde. Indkøbsinertia, ikke teknisk vanskelighed, holder v2-udfordringen på plads.

04. Sessionstimeouts der ikke forlænges

Elleve af de tolv auditerede portaler — alle statslige dagpengeflader og SSA’s iClaim — håndhæver en sessionstimeout i intervallet 10 til 20 minutters inaktivitet. WCAG 2.2.1 (Timing Adjustable) kræver, at enhver tidsbegrænsning kan slås fra, justeres eller forlænges af brugeren, inden den udløber, med mindst 20 sekunders advarsel og en simpel “forlæng”-interaktion. Af de elleve giver tre ingen advarsel overhovedet; sessionen udløber midt i formularen, og ansøgeren ryger tilbage til login med alle indtastede data tabt.

Fem andre viser en visuel modal-nedtælling, men annoncerer aldrig modalen via aria-live, så en skærmlæserbruger, der læser formularen nedenunder, ikke ved, at advarslen er dukket op. De resterende tre annoncerer modalen men fanger fokus således, at “Forlæng session”-knappen ikke kan nås med Tab — et Tab-tryk i den underliggende formular flytter ikke fokus ind i modalen. Brugeren ved, at advarslen er der. Brugeren kan ikke handle på den.

05. PDF-only formularer inde i en HTML-rejse

Ni af de ti statslige dagpengeportaler sender ansøgeren på et tidspunkt i rejsen videre til en PDF. De hyppigste synder er klageformularen, certificering for delvis uge, arbejdssøgningsloggen og erklæringen om forsørgerfradrag. Af de leverede PDF-filer har færre end halvdelen et tagget PDF-strukturtræ. Resten er scannede billeder af papirformularer — til tider den originale 1990’er-maskintekstskabelon, fotokopieret og genfotokopieret — uden tekstlag overhovedet.

En scannet billede-PDF serveret som en obligatorisk formular er ikke en marginal tilgængeligheds­defekt. Det er en kategorisk udelukkelse. Skærmlæseren rapporterer et tomt dokument. OCR-hjælpere fejler, fordi formularen har felter, som OCR-laget ikke kan rekonstruere. Ansøgeren har to muligheder: udskrive, udfylde i hånden, scanne tilbage og sende pr. e-mail; eller ringe til myndigheden. Begge muligheder forudsætter en printer-scanner og seende hjælp. Mange ansøgere med handicap har ingen af delene.

06. Filuploads uden skærmlæser-feedback

Ti af de tolv portaler kræver et sted i rejsen et filupload — en fratrædelsesmeddelelse, et identitetsdokument, en lægeerklæring, et SNAP-Medicaid-tilskudsberettigelsesdokument. Det mønster, der konsekvent fejler auditen, er: filindtastningselementet er et native HTML-input pakket ind i en brugerdefineret “Vælg fil”-knap, der sluger tastaturhændelsen og aldrig annoncerer det valgte filnavn, aldrig annoncerer uploadets fremgang, aldrig annoncerer succes, og (værst) aldrig annoncerer fejl. Brugeren vælger en fil. Noget sker. Intet annonceres. Brugeren fortsætter uden at vide, om uploadet lykkedes — og opdager tre dage senere, at kravet blev afvist for manglende dokumentation.

Den billigste rettelse i hele dossieret sidder her. En enkelt visuelt skjult live-region ved siden af filinputteret, polite, opdateret ved valg og ved afslutning med filnavnet og en ét-ords-status, koster en times front-end-arbejde og løser hele fejlmønsteret. Vi så det implementeret korrekt på præcis én af de tolv flader.

07. Fejlmeddelelser uden aria-live

Den hyppigste fejl på tværs af alle tolv flader — til stede ved ca. tre ud af fire fejltilstande, vi udløste — var en inline valideringsfejl renderet som et stilet rødt span ved siden af et inputfelt, uden aria-live-region, uden aria-describedby-pointer fra inputtet til fejlteksten og uden programmatisk flytning af fokus til fejlen. Fejlen er synlig. Fejlen annonceres ikke. Skærmlæserbrugeren indsender, siden genindlæses ikke, brugeren ved ikke, hvorfor intet skete, og indsender igen.

Mønsteret forværres af sessionstimeout-fejlen: en ansøger med handicap kykler igennem uannoncerede valideringsfejl i tempoet for menneskelig gennemlæsning, rammer den 15-minutters-timeout, mister formularen og starter forfra. Rettelsen er to linjer pr. fejl — en aria-live-region nær hvert feltsæt, polite, som valideringsrutinen skriver i, når den trigges. Ingen af de flader, vi auditerede, gør dette konsekvent.

Den dyreste del af at udbedre disse portaler er ikke ingeniørarbejdet. Det er udbudskontrakten, der skal genåbnes.

08. DOJ Title II-håndhævelseskonsekvenser

DOJ Title II-slutreglen af 24. april 2024 — kodificeret ved 28 CFR Part 35, Subpart H — vedtager WCAG 2.1 niveau AA som den føderale tilgængelighedsstandard for statslig og lokal regerings webindhold og mobilapps. Store offentlige enheder (befolkninger på 50.000 eller derover) havde en overholdelsesfrist den 24. april 2026; mindre enheder har til den 24. april 2027. Alle stater i denne audit betjener befolkninger langt over 50.000-tærsklen. April 2026-fristen er passeret.

Reglen indeholder undtagelser — arkiveret indhold, individuelle dokumenter, adgangs­kode­beskyttet ikke-offentligt indhold, tredjepartsindhold ikke lagt op af enheden — men den kanoniske arbejdsløsheds­ansøgningsrejse falder ingen af dem ind under. En første-ansøgningsformular på en statslig UI-portal er aktuel, offentlig, leveret af enheden og brugt af offentligheden. Den ligger klart inden for den regulerede flade.

Håndhævelse under Title II forløber via DOJ-initierede undersøgelser (Civil Rights Divisions Disability Rights Section), individuelle klager indgivet på civilrights.justice.gov, og privat retssag under den samme lov. De retsmidler, reglen tænker sig, omfatter overholdelses­planer, overvågnings­aftaler, erstatning til identificerede klagere, og — i det samtykkekendelsesmønster, ministeriet har brugt siden 2014 H&R Block-aftalen — landsdækkende udbedringer­stimelines med navngivne WCAG-overensstemmelsesmål. For mere om, hvad der specifikt udløser DOJ’s opmærksomhed, se vores ledsagestykke om DOJ Title II-reglen, to år efter.

09. Ansøgerrejsen for en person med handicap er den mest kritiske civic-tech-UX — og den vigtigste at rette

Arbejdsløshed er per definition et øjeblik af akut økonomisk pres. Ansøgeren har ingen indkomst, begrænsede reserver og et fast vindue, hvori der skal indgives krav. En ikke-ansøger opgiver en defekt e-handels-checkout og handler et andet sted. En dagpengeansøger med handicap kan ikke. Tjenesten er obligatorisk, timingen er fast, alternativet er fattigdom.

Det er det, der gør en ydelsesportal til den højst indsatsbelagte tilgængeligheds­flade på det offentlige internet. De ti statsportaler, vi auditerede, er — med to eller tre undtagelser — i øjeblikket ud af overensstemmelse med den føderale regel, der trådte i kraft i april 2026. De var også, inden den regel eksisterede, de mest konsekvensfulde tilgængeligheds­fejl i amerikansk civic tech. DOJ-reglen gjorde ikke disse portaler vigtige. Den gjorde dem juridisk håndgribelige.

Det, der ændrer sig som næste skridt, er håndhævelse, ikke teknologi. Rettelserne — aria-live på inline-fejl, en fokuserbar forlæng-session-kontrol, taggede PDF-filer, en annonceret filuploadstatus, et fungerende CAPTCHA-fallback — er individuelt set små, veldokumenterede og inden for det rutinemæssige vedligeholdelses­budget for enhver myndighed på listen. Det, der har manglet, er det regulatoriske pres, den politiske opmærksomhed og udbudskontrakt­sproget til at få udbedringen til at ske. Det første er nu til stede.