Civic tech e prestazioni digitali — come i portali per la disoccupazione falliscono i richiedenti disabili

I portali statali per l’assicurazione contro la disoccupazione, i siti per la domanda di SNAP, gli strumenti per l’idoneità Medicaid e lo sportello SSDI della SSA stessa sono i servizi essenziali rivolti al pubblico della rete di sicurezza sociale americana. Sono anche alcune delle superfici con le peggiori prestazioni di accessibilità sul web pubblico. È stato condotto un audit dei principali portali per le prestazioni gestiti dai dieci stati USA più popolosi — California, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, North Carolina e Michigan — insieme allo strato federale di autenticazione (Login.gov) e ai sistemi rivolti ai richiedenti della SSA su SSA.gov, confrontandoli con WCAG 2.1 Livello AA e la norma finale DOJ Titolo II del 24 aprile 2024 che vincola giuridicamente i governi statali e locali allo stesso standard. Nelle dodici superfici sottoposte ad audit sono state registrate circa 217 distinte violazioni di WCAG 2.1 AA, una media di circa 18 per portale, con solo uno dei dodici che ha superato tutti e quattro i criteri soglia. Questo dossier nomina i portali, li classifica e conclude con le implicazioni della norma DOJ per i peggiori.

01. Metodologia e criteri soglia

L’audit si è svolto dal 7 marzo al 12 maggio 2026. Due auditor hanno percorso il percorso canonico del richiedente su ciascuno dei dodici portali partendo da una sessione a freddo — nessun cookie precedente, nessuna estensione helper installata, nessun autofill. Il percorso era: arrivare alla landing page, registrare un nuovo account, autenticarsi, presentare una domanda iniziale di prestazioni di disoccupazione (o, per le superfici SSA e SNAP-Medicaid, il flusso equivalente di prima richiesta), arrivare al punto di invio, quindi certificare la settimana successiva o caricare un documento di supporto.

Ogni superficie è stata valutata rispetto ai criteri di successo WCAG 2.1 Livello AA utilizzando axe-DevTools Pro 4.10 più un walk-through manuale con NVDA 2024.4 su Windows 11 e VoiceOver su macOS 14.7. I flussi mobile sono stati ri-testati su iOS 18.2 con VoiceOver e su Android 15 con TalkBack. Ogni PDF servito durante il percorso è stato estratto e analizzato separatamente con PAC 2024 e il controllo di accessibilità di Acrobat Pro DC.

Sono stati poi applicati quattro criteri soglia binari — più grossolani dell’intera scala WCAG, ma i criteri di cui si preoccupa davvero un richiedente disabile in attività: operabile da tastiera (un utente che usa solo la tastiera può arrivare a presentare la domanda?), recupero dagli errori con screen reader (quando qualcosa va storto, lo screen reader annuncia cosa e dove?), estensione del timeout di sessione (il meccanismo di avviso ed estensione è raggiungibile e azionabile tramite tecnologia assistiva?), e upload di file accessibile (l’esito positivo o negativo dell’upload viene annunciato in modo programmatico?). Una superficie supera l’audit solo se soddisfa tutti e quattro i criteri.

02. La classifica portale per portale

La classifica delle dodici superfici in base al loro punteggio di accessibilità normalizzato — la quota di pagine nel percorso che hanno superato axe a WCAG 2.1 AA, ponderata dal superamento o meno dei quattro criteri — ha prodotto la tabella seguente. Login.gov si trova in cima perché è stato progettato come primitiva di autenticazione con l’accessibilità come priorità fin dalla sua nascita e il team ri-testa ad ogni rilascio. Le superfici per i richiedenti di SSA.gov si trovano al secondo posto perché l’Office of Accessible Systems and Technology della SSA gestisce un programma di monitoraggio continuo. Dal terzo posto in poi il divario verso il fondo è netto.

Login.gov mostra la forma di un portale per le prestazioni accessibile. Florida CONNECT mostra la forma di uno che non può essere compilato senza l’aiuto di una persona vedente.

03. Le trappole CAPTCHA

Il criterio CAPTCHA è la superficie di violazione più visibile perché si trova all’inizio del flusso — di solito sul modulo di registrazione o di accesso, a volte di nuovo sull’invio della domanda iniziale come misura antifrode. Otto dei dodici portali sottoposti ad audit presentano un CAPTCHA reCAPTCHA v2 solo immagini il cui fallback audio è rotto (si carica silenziosamente, nessun file audio riproducibile) o rimanda il richiedente a un generico 404. Due degli otto pongono l’intero flusso di presentazione della domanda iniziale dietro il CAPTCHA: il portale UI della Texas Workforce Commission e Florida CONNECT. Un richiedente non vedente in quei due stati, che lavora senza l’aiuto di una persona vedente, non può presentare la domanda da quelle interfacce. Deve telefonare allo stato, dove la coda raggiunge diverse ore.

L’ironia del civic tech è che reCAPTCHA v3 — invisibile, basato sul comportamento, nessuna sfida per la grande maggioranza degli utenti — esiste, è gratuito ai volumi che vede un portale statale, e risolverebbe il problema al costo di un pomeriggio di lavoro di integrazione. L’inerzia degli appalti, non la difficoltà tecnica, mantiene la sfida v2.

04. Timeout di sessione che non si estendono

Undici dei dodici portali sottoposti ad audit — ogni superficie statale per la disoccupazione e iClaim della SSA — applicano un timeout di sessione nell’intervallo da 10 a 20 minuti di inattività. WCAG 2.2.1 (Regolazione del tempo) richiede che qualsiasi limite di tempo sia disattivabile, regolabile o estendibile dall’utente prima della scadenza, con almeno 20 secondi di preavviso e una semplice interazione di «estendi». Degli undici, tre non danno nessun avviso; la sessione scade semplicemente durante la compilazione e il richiedente viene riportato al login con tutti i dati inseriti persi.

Altri cinque mostrano un modal visivo con conto alla rovescia ma non annunciano mai il modal tramite aria-live, così un utente screen reader che legge il modulo sottostante non sa che l’avviso è apparso. I restanti tre annunciano il modal ma intrappolano il focus in modo tale che il pulsante «Estendi sessione» non possa essere raggiunto tramite Tab — un tasto Tab nel modulo sottostante non sposta il focus nel modal. L’utente sa che l’avviso c’è. L’utente non può agire su di esso.

05. Moduli solo PDF in un percorso HTML

Nove dei dieci portali statali per la disoccupazione indirizzano il richiedente, ad un certo punto del percorso, verso un PDF. I casi più comuni sono il modulo di appello, la certificazione per settimana parziale, il registro delle ricerche di lavoro e l’attestazione dell’indennità per i familiari a carico. Dei PDF serviti, meno della metà porta una struttura ad albero di tag PDF. Il resto sono immagini scansionate di moduli cartacei — a volte il modello dattilografato originale degli anni ‘90, fotocopiato e ri-fotocopiato — senza alcun livello di testo.

Un PDF a immagini scansionate servito come modulo obbligatorio non è un difetto di accessibilità ai margini. È un’esclusione categorica. Lo screen reader segnala un documento vuoto. Gli helper OCR falliscono perché il modulo ha campi che il livello OCR non riesce a ricostruire. Il richiedente ha due opzioni: stampare, compilare a mano, scansionare di nuovo e inviare via email; oppure telefonare all’agenzia. Entrambe le opzioni presuppongono una stampante-scanner e l’aiuto di una persona vedente. Molti richiedenti disabili non ne hanno nessuna delle due.

06. Upload di file senza feedback per lo screen reader

Dieci dei dodici portali richiedono, da qualche parte nel percorso, un upload di file — una notifica di separazione, un documento d’identità, una certificazione medica, un documento di idoneità SNAP-Medicaid. Lo schema che fallisce l’audit, sistematicamente, è: l’elemento di input file è un input HTML nativo avvolto in un pulsante «Scegli file» stilizzato personalizzato che assorbe l’evento da tastiera e non annuncia mai il nome del file selezionato, non annuncia mai l’avanzamento dell’upload, non annuncia mai il successo e (peggio) non annuncia mai il fallimento. L’utente seleziona un file. Qualcosa succede. Niente viene annunciato. L’utente va avanti, senza sapere se l’upload sia riuscito — e scopre, tre giorni dopo, che la domanda è stata rifiutata per documentazione mancante.

La correzione più economica dell’intero dossier si trova qui. Una singola regione live visivamente nascosta accanto all’input file, polite, aggiornata alla selezione e al completamento con il nome del file e uno stato in una parola, costa un’ora di lavoro front-end e risolve l’intero schema di violazione. È stata vista implementata correttamente su esattamente una delle dodici superfici.

07. Messaggi di errore senza aria-live

La violazione più comune in tutte e dodici le superfici — presente in circa tre casi su quattro di errore provocato — era un errore di validazione inline reso come uno span rosso stilizzato accanto a un campo di input, senza regione aria-live, senza puntatore aria-describedby dall’input al testo dell’errore e senza spostamento programmatico del focus sull’errore. L’errore è visibile. L’errore non viene annunciato. L’utente screen reader invia, la pagina non si ricarica, l’utente non sa perché non è successo nulla, e l’utente invia di nuovo.

Lo schema si aggrava con la violazione del timeout di sessione: un richiedente disabile passa attraverso errori di validazione non annunciati alla velocità della rilettura umana, raggiunge il timeout di 15 minuti, perde il modulo e ricomincia da capo. La correzione è due righe per errore — una regione aria-live vicino a ogni fieldset, polite, in cui la routine di validazione scrive quando si attiva. Nessuna delle superfici sottoposte ad audit lo fa in modo coerente.

La parte più costosa del risanamento di questi portali non è l’ingegneria. È il contratto di appalto che deve essere riaperto.

08. Implicazioni applicative del DOJ Titolo II

La norma finale DOJ Titolo II del 24 aprile 2024 — codificata al 28 CFR Part 35, Subpart H — adotta WCAG 2.1 Livello AA come standard federale di accessibilità per i contenuti web e le app mobile dei governi statali e locali. I grandi enti pubblici (popolazioni di 50.000 o più) avevano una scadenza di conformità al 24 aprile 2026; gli enti più piccoli hanno tempo fino al 24 aprile 2027. Ogni stato in questo audit serve una popolazione ben al di sopra della soglia di 50.000. La scadenza di aprile 2026 è nel passato.

La norma prevede eccezioni — contenuti archiviati, documenti individualizzati, contenuti non pubblici protetti da password, contenuti di terze parti non pubblicati dall’ente — ma il percorso canonico della domanda di disoccupazione non rientra in nessuna di esse. Un modulo di domanda iniziale su un portale UI statale è attuale, rivolto al pubblico, fornito dall’ente e utilizzato dal pubblico. È esattamente all’interno della superficie regolata.

L’applicazione ai sensi del Titolo II procede attraverso indagini avviate dal DOJ (la Sezione dei diritti delle persone con disabilità della Civil Rights Division), reclami individuali depositati su civilrights.justice.gov, e contenzioso privato ai sensi dello stesso statuto. I rimedi contemplati dalla norma includono piani di conformità, accordi di monitoraggio, danni compensativi ai denuncianti identificati e — nel schema del decreto di consenso che il Dipartimento utilizza dall’accordo H&R Block del 2014 — calendari di risanamento a livello nazionale con obiettivi di conformità WCAG nominati. Per ulteriori informazioni su ciò che attira specificamente l’attenzione del DOJ, si veda il nostro articolo complementare sulla norma DOJ Titolo II, a due anni dall’emanazione.

09. Il percorso del richiedente disabile è la UX del civic tech nel caso peggiore — e il più importante da risolvere

La disoccupazione è per definizione un momento di pressione finanziaria acuta. Il richiedente non ha reddito, ha riserve finite e una finestra temporale fissa per presentare la domanda. Un non-richiedente abbandona un checkout e-commerce rotto e acquista altrove. Un richiedente disabile di assicurazione contro la disoccupazione non può farlo. Il servizio è obbligatorio, i tempi sono fissi, l’alternativa è la miseria.

Questo è ciò che rende un portale per le prestazioni la superficie di accessibilità più critica sul web pubblico. I dieci portali statali sottoposti ad audit sono, con due o tre eccezioni, attualmente non conformi alla norma federale entrata in vigore nell’aprile 2026. Erano anche, prima che quella norma esistesse, i fallimenti di accessibilità più significativi nel civic tech americano. La norma DOJ non ha reso importanti questi portali. Li ha resi giuridicamente perseguibili.

Ciò che cambia successivamente è l’applicazione, non la tecnologia. Le correzioni — aria-live sugli errori inline, un controllo estendi-sessione con focus raggiungibile, PDF con tag, uno stato di upload annunciato, un fallback CAPTCHA funzionante — sono individualmente piccole, ben documentate e all’interno del budget di manutenzione ordinaria di ogni agenzia dell’elenco. Ciò che è mancato è la pressione normativa, l’attenzione politica e il linguaggio del contratto di appalto per far avvenire il risanamento. La prima è ora presente.