Civic tech and digital benefits — how unemployment portals fail disabled claimants

State unemployment-insurance portals, SNAP application sites, Medicaid eligibility tools, and the SSA’s own SSDI front end are the public-facing essential services of the American social-safety net. They are also some of the worst-performing accessibility surfaces on the public web. We audited the primary benefits portals operated by the ten most populous US states — California, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, North Carolina, and Michigan — together with the federal authentication layer (Login.gov) and the SSA’s claimant-facing systems on SSA.gov, against WCAG 2.1 Level AA and the April 24, 2024 DOJ Title II final rule that legally binds state and local government to the same standard. Across the twelve surfaces audited we logged approx. 217 distinct WCAG 2.1 AA failures, an average of approx. 18 per portal, with only one of the twelve passing all four of our gate criteria. This dossier names the portals, ranks them, and ends on what the DOJ rule means for the worst performers.

01. Methodology and audit gates

The audit ran from March 7 to May 12, 2026. Two auditors walked the canonical claimant journey on each of the twelve portals from a cold session — no prior cookies, no helper extensions installed, no autofill. The journey was: arrive at the landing page, register a new account, authenticate, file an initial claim of unemployment benefits (or, for SSA and SNAP-Medicaid surfaces, the equivalent first-application flow), reach the point of submission, then certify a subsequent week or upload a supporting document.

Each surface was evaluated against the WCAG 2.1 Level AA success criteria using axe-DevTools Pro 4.10 plus a manual walk-through with NVDA 2024.4 on Windows 11 and VoiceOver on macOS 14.7. Mobile flows were re-tested on iOS 18.2 with VoiceOver and on Android 15 with TalkBack. Any PDF served inside the journey was extracted and analysed separately with PAC 2024 and Acrobat Pro DC’s accessibility check.

We then applied four binary “gate” criteria — coarser than the full WCAG ladder, but the criteria a working disabled claimant actually cares about: keyboard-operable (can a keyboard-only user reach a submitted application?), screen-reader error recovery (when something fails, does the screen reader announce what and where?), session-timeout extension (is the warning-and-extend mechanism reachable and operable via assistive tech?), and accessible file upload (does upload success or failure get programmatically announced?). A surface passes the audit only if it clears all four gates.

02. The portal-by-portal ranking

Ranking the twelve surfaces by their normalised accessibility score — the share of pages in the journey that passed axe at WCAG 2.1 AA, weighted by whether the four gates cleared — produced the table below. Login.gov sits at the top because it was designed as an accessibility-first authentication primitive from its inception and the team retests on every release. SSA.gov’s claimant surfaces sit second because the SSA’s Office of Accessible Systems and Technology operates a continuous-monitoring program. From third place down, the gap to the bottom is steep.

Login.gov shows the shape of an accessible benefits portal. Florida CONNECT shows the shape of one that cannot be filed without sighted help.

03. CAPTCHA traps

The CAPTCHA gate is the most visible failure surface because it sits early in the flow — usually on the registration or sign-in form, sometimes again on initial-claim submission as an anti-fraud measure. Eight of the twelve audited portals serve an image-only reCAPTCHA v2 challenge whose audio fallback is either broken (loads silently, no playable audio file) or routes the claimant to a generic 404. Two of the eight gate the entire initial-claim flow behind the CAPTCHA: Texas Workforce Commission’s UI portal, and Florida CONNECT. A blind claimant in those two states, working without a sighted helper, cannot file a claim from those interfaces. They have to phone the state, where the queue runs to multiple hours.

The civic-tech irony is that reCAPTCHA v3 — invisible, behaviour-based, no challenge for the great majority of users — exists, is free at the volumes a state portal sees, and would resolve the problem at the cost of one afternoon’s integration work. Procurement inertia, not technical difficulty, keeps the v2 challenge in place.

04. Session timeouts that don’t extend

Eleven of the twelve audited portals — every state unemployment surface and SSA’s iClaim — enforce a session timeout in the range of 10 to 20 minutes of inactivity. WCAG 2.2.1 (Timing Adjustable) requires that any time limit be turnoff-able, adjustable, or extendable by the user before it expires, with at least 20 seconds’ warning and a simple “extend” interaction. Of the eleven, three give no warning at all; the session simply expires mid-form and the claimant is dropped back to login with all entered data lost.

Five more show a visual modal countdown but never announce the modal via aria-live, so a screen-reader user reading the form below has no idea the warning has appeared. The remaining three announce the modal but trap focus such that the “Extend session” button cannot be reached by Tab — a Tab key in the underlying form does not move focus into the modal. The user knows the warning is there. The user cannot act on it.

05. PDF-only forms inside an HTML journey

Nine of the ten state unemployment portals route the claimant, at some point in the journey, to a PDF. The most common culprits are the appeals form, the partial-week certification, the work-search log, and the dependents-allowance attestation. Of the PDFs served, fewer than half carry a tagged-PDF structure tree. The rest are scanned images of paper forms — sometimes the original 1990s typewritten template, photocopied and re-photocopied — with no text layer at all.

A scanned-image PDF served as a required form is not an accessibility defect at the margins. It is a categorical exclusion. The screen reader reports an empty document. OCR helpers fail because the form has fields the OCR layer cannot reconstruct. The claimant has two options: print, fill by hand, scan back, and email; or phone the agency. Both options assume a printer-scanner and sighted help. Many disabled claimants have neither.

06. File uploads with no screen-reader feedback

Ten of the twelve portals require, somewhere in the journey, a file upload — a separation notice, an ID document, a medical certification, a SNAP-Medicaid eligibility document. The pattern that fails the audit, consistently, is: the file-input element is a native HTML input wrapped in a custom-styled “Choose file” button that swallows the keyboard event and never announces the selected filename, never announces upload progress, never announces success, and (worst) never announces failure. The user selects a file. Something happens. Nothing is announced. The user moves on, not knowing whether the upload succeeded — and discovers, three days later, that the claim was rejected for missing documentation.

The cheapest fix in the entire dossier sits here. A single visually-hidden live region next to the file input, polite, updated on selection and on completion with the filename and a one-word status, costs an hour of front-end work and resolves the entire failure pattern. We saw it implemented correctly on exactly one of the twelve surfaces.

07. Error messages with no aria-live

The most common failure across all twelve surfaces — present at roughly three out of four error states we triggered — was an inline validation error rendered as a styled red span beside an input field, with no aria-live region, no aria-describedby pointer from the input to the error text, and no programmatic move of focus to the error. The error is visible. The error is not announced. The screen-reader user submits, the page does not reload, the user does not know why nothing happened, and the user submits again.

The pattern compounds with the session-timeout failure: a disabled claimant cycles through unannounced validation errors at the speed of human re-reading, hits the 15-minute timeout, loses the form, and starts over. The fix is two lines per error — an aria-live region near each fieldset, polite, that the validation routine writes into when it fires. None of the surfaces we audited do this consistently.

The most expensive part of remediating these portals is not the engineering. It is the procurement contract that has to be reopened.

08. DOJ Title II enforcement implications

The April 24, 2024 DOJ Title II final rule — codified at 28 CFR Part 35, Subpart H — adopts WCAG 2.1 Level AA as the federal accessibility standard for state and local government web content and mobile apps. Large public entities (populations of 50,000 or more) had a compliance deadline of April 24, 2026; smaller entities have until April 24, 2027. Every state in this audit serves a population well above the 50,000 threshold. The April 2026 deadline is in the past.

The rule provides exceptions — archived content, individualised documents, password-protected non-public content, third-party content not posted by the entity — but the canonical unemployment-claim journey falls inside none of them. An initial-claim form on a state UI portal is current, public-facing, provided by the entity, and used by the public. It is squarely inside the regulated surface.

Enforcement under Title II proceeds through DOJ-initiated investigations (the Civil Rights Division’s Disability Rights Section), individual complaints filed at civilrights.justice.gov, and private litigation under the same statute. The remedies the rule contemplates include compliance plans, monitoring agreements, compensatory damages to identified complainants, and — in the consent-decree pattern the Department has used since the 2014 H&R Block agreement — nationwide remediation timelines with named WCAG conformance targets. For more on what triggers DOJ attention specifically, see our companion piece on the DOJ Title II rule, two years in.

09. The disabled-claimant journey is the worst-case civic-tech UX — and the most important to fix

Unemployment is by definition a moment of acute financial pressure. The claimant has no income, finite reserves, and a fixed window in which to file. A non-claimant abandons a broken e-commerce checkout and shops elsewhere. A disabled unemployment-insurance claimant cannot. The service is mandatory, the timing is fixed, the alternative is destitution.

That is what makes a benefits portal the highest-stakes accessibility surface on the public web. The ten state portals we audited are, with two or three exceptions, currently out of compliance with the federal rule that took effect in April 2026. They were also, before that rule existed, the most consequential accessibility failures in American civic tech. The DOJ rule did not make these portals important. It made them legally cognisable.

What changes next is enforcement, not technology. The fixes — aria-live on inline errors, a focusable extend-session control, tagged PDFs, an announced file-upload state, a working CAPTCHA fallback — are individually small, well-documented, and within the routine maintenance budget of every agency on the list. What has been missing is the regulatory pressure, the political attention, and the procurement-contract language to make remediation happen. The first is now present.