ADA Title II e Section 504: cosa devono correggere entro il 2027 i siti pubblici e sanitari

Dal 26 aprile 2027 ogni ente statale o locale degli Stati Uniti con una popolazione totale pari o superiore a 50.000 abitanti deve rendere i propri contenuti web e le proprie app mobili conformi alle WCAG 2.1 di livello AA. Riguarda contee, città, distretti scolastici, università pubbliche e aziende di trasporto pubblico. Dall'11 maggio 2027 lo stesso standard si applica a ogni destinatario di finanziamenti dell'HHS con quindici o più dipendenti: ospedali, cliniche, centri sanitari, e le agenzie statali, i servizi sociali e i college che l'HHS finanzia.

Entrambe le date dovevano arrivare un anno prima. Il Dipartimento di Giustizia (DOJ) e l'HHS le hanno spostate ciascuno con una interim final rule nella primavera del 2026, ed entrambi hanno detto che potrebbero proporre di alleggerire i contenuti. Nessuno dei due l'ha fatto. Oggi le date del 2027 sono quelle scritte nei regolamenti, e la prima è a circa 29 settimane.

Se vendete anche nell'UE, l'European Accessibility Act è un regime separato, trattato nel nostro articolo sull'EAA.

Le date

«Popolazione totale» è un termine definito. Per la maggior parte degli enti è il censimento decennale del Census Bureau; un distretto scolastico indipendente usa le Small Area Income and Poverty Estimates. Un'università statale o un'azienda di trasporto prende la popolazione complessiva dei governi a cui appartiene. Uno special district government ha la data del 2028 qualunque sia la sua dimensione.

Un ospedale di contea di solito è sia un ente pubblico sia un destinatario HHS. Verificate entrambe le date e lavorate su quella che arriva prima.

Cosa chiedono le norme

Le due norme sono formulate in modo quasi identico, e tre espressioni fanno gran parte del lavoro.

«Contenuti web e app mobili». I contenuti web sono definiti in senso ampio: testo, immagini, suoni, video, controlli, animazioni e «documenti elettronici convenzionali», cioè PDF, file di videoscrittura, presentazioni e fogli di calcolo. Le app mobili sono le app native che le persone scaricano su telefoni e tablet.

«Direttamente o tramite accordi contrattuali, di licenza o di altro tipo». L'obbligo segue il servizio, non il server. Un portale per i permessi gestito da un fornitore, una pagina di pagamento ospitata da un processore di pagamenti, una piattaforma didattica concessa in licenza a un distretto scolastico: tutto conta come vostro. Nella norma finale del 2024 il DOJ ha fatto l'esempio in modo diretto: un ente che rimanda a un sito di terzi per il pagamento di tariffe, multe per il parcheggio o tasse deve assicurarsi che quel sito sia conforme.

«Criteri di successo e requisiti di conformità di livello A e AA specificati nelle WCAG 2.1». La versione di giugno 2018, non la 2.2. Sviluppare secondo la 2.2 non fa danni, ma il requisito legale è la 2.1 AA.

Le vie d'uscita sono strette. La conformità non è richiesta quando comporterebbe un'alterazione sostanziale o oneri finanziari e amministrativi eccessivi, ma deve deciderlo il vertice dell'ente (o un suo delegato) dopo aver considerato tutte le risorse disponibili, mettendo le ragioni per iscritto e facendo comunque tutto ciò che resta al di qua dell'onere. Una «versione alternativa conforme» separata è ammessa solo quando l'accessibilità diretta è impossibile per motivi tecnici o giuridici. C'è anche una disposizione sull'impatto minimo, ma è una difesa da sostenere dopo un reclamo, non un obiettivo di progetto.

Per dare un'idea delle dimensioni, l'analisi del DOJ del 2024 contava 109.893 siti web e 8.805 app mobili gestiti da 91.489 enti statali e locali, con 16,9 miliardi di dollari di costi di attuazione nei primi tre anni. La proroga di aprile 2026 cita una stima del costo totale su 10 anni di 24,7 miliardi di dollari. La normativa HHS del 2024 nel suo complesso riguarda circa 453.084 destinatari.

Cosa è escluso, e a quali condizioni

Entrambe le norme prevedono le stesse cinque eccezioni, e ognuna ha una condizione facile da non vedere.

1. Contenuti web archiviati, solo se valgono tutte e quattro le condizioni: creati prima della vostra data di conformità (o riproduzioni di supporti cartacei o fisici anteriori), conservati esclusivamente a fini di consultazione, ricerca o documentazione, non modificati dopo l'archiviazione e conservati in un'area dedicata chiaramente indicata come archivio. I vecchi verbali sparsi nelle pagine attive dei vari uffici non rientrano. Spostateli.
2. Documenti elettronici convenzionali preesistenti, pubblicati prima della vostra data, a meno che non vengano usati attualmente per richiedere un servizio, accedervi o parteciparvi. Il PDF della domanda di permesso del 2019 ancora collegato dalla pagina dei permessi non è escluso.
3. Contenuti pubblicati da terzi, a meno che non siano pubblicati in base a un accordo contrattuale, di licenza o di altro tipo con voi. I commenti del pubblico in un forum sono esclusi. Qualsiasi cosa pubblichi per voi un fornitore no.
4. Documenti individuali protetti: file su una persona specifica, sui suoi beni o sul suo account, protetti da password o altrimenti messi in sicurezza. Un avviso di pagamento delle tasse o il PDF di un referto di laboratorio. L'eccezione copre il documento. Il portale che lo circonda resta incluso.
5. Post sui social media pubblicati prima della vostra data.

Niente di tutto questo elimina l'obbligo generale. Entrambe le proroghe del 2026 dicono che gli obblighi del Title II e della Section 504 continuano indipendentemente dalle date di conformità. Un residente che chiede una copia accessibile di un documento escluso può comunque averne diritto.

Cosa significa in pratica l'adeguamento

Modelli e componenti del CMS

La maggior parte dei siti pubblici è fatta di pochi modelli e una dozzina di componenti ripetuti su migliaia di pagine. Correggete una volta intestazione, navigazione, ricerca, accordion, tabelle e moduli, e ogni pagina eredita la correzione. Controllate l'ordine dei titoli, i landmark, il focus visibile (2.4.7), il contrasto del testo di 4,5:1 (1.4.3), il contrasto di 3:1 per controlli e bordi dei campi (1.4.11), il reflow su schermi stretti (1.4.10) e il testo ridimensionato al 200 per cento (1.4.4). Se il tema è personalizzato o vecchio di anni, è qui che va la maggior parte del budget.

Moduli, pagamenti e permessi

I percorsi transazionali sono l'oggetto dei reclami. Ogni campo ha bisogno di un'etichetta esposta alle tecnologie assistive (3.3.2), di errori descritti in forma testuale (3.3.1), del completamento automatico sui campi dei dati personali (1.3.5), del pieno funzionamento da tastiera (2.1.1) e di limiti di tempo della sessione che l'utente possa disattivare, regolare o prolungare (2.2.1). Quest'ultimo è facile da dimenticare nei flussi di pagamento e di richiesta dei permessi, dove una sessione può scadere mentre un utente di screen reader è ancora alla seconda pagina. I widget personalizzati (selettori di data, ricerca degli indirizzi, caricamento di file) hanno bisogno di nome, ruolo e valore corretti (4.1.2). Anche il frame di pagamento incorporato del processore deve superare la verifica, quindi testate tutto il flusso, non solo la vostra metà.

Portali per i pazienti e prenotazioni

Tutto quanto sopra, più selettori degli appuntamenti, questionari di accettazione, messaggistica sicura e video di telemedicina. Messaggi come «appuntamento confermato» devono essere annunciati senza spostare il focus (4.1.3).

Documenti

Il PDF accessibile più economico è quello che non create. Pubblicate in HTML ordini del giorno, avvisi e moduli dove potete. Per i PDF che devono restare: tag, un ordine di lettura corretto, veri campi modulo, la lingua del documento e alternative testuali per le immagini. Poi sistemate la parte produttiva (modelli Word con titoli veri, impostazioni di esportazione che mantengono i tag, un controllo prima di qualsiasi pubblicazione), altrimenti continuerete per sempre ad adeguare l'ordine del giorno della settimana dopo.

Video e riunioni

I video preregistrati richiedono sottotitoli (1.2.2) e audiodescrizione dove l'immagine trasmette significato (1.2.5). L'audio dal vivo nei contenuti multimediali sincronizzati richiede sottotitoli in tempo reale (1.2.4), il che per la maggior parte di città, contee e consigli scolastici significa la riunione pubblica trasmessa in streaming. Le vecchie registrazioni possono andare in archivio alle quattro condizioni indicate sopra.

App mobili

Le app native sono tenute agli stessi criteri tramite il livello di accessibilità della piattaforma: ogni controllo etichettato per VoiceOver e TalkBack, nessun blocco su un solo orientamento (1.3.4), un'alternativa con un semplice tocco ai gesti di scorrimento e pizzico (2.5.1).

Software pacchettizzato: il codice è del fornitore, l'obbligo è vostro

Se il vostro sito gira su un CMS per enti pubblici in hosting, i pagamenti passano dalla pagina ospitata di un processore e il portale per i pazienti è un modulo della vostra cartella clinica elettronica, la maggior parte delle correzioni al codice spetta ai fornitori. Il vostro lavoro è negli acquisti: chiedete a ogni fornitore un rapporto di conformità rispetto alle WCAG 2.1 AA, verificate le loro dichiarazioni sui vostri percorsi critici e mettete nel contratto o nel rinnovo un obbligo di conformità e una data entro cui correggere. I vostri contenuti (PDF, video, testi alternativi, le pagine scritte dal personale) restano compito vostro su qualsiasi piattaforma.

Questo articolo è più utile se gestite sistemi interni, datati o personalizzati: un portale per i permessi sviluppato in casa, un tema CMS pesantemente modificato, un'app la cui agenzia è passata ad altro, un modulo di accettazione innestato su un prodotto di un fornitore. Questi non li sistemerà nessun altro.

Perché un overlay non basta

La norma misura i vostri contenuti rispetto alle WCAG 2.1 AA. Un overlay è uno script che si appoggia sopra la pagina. Non può scrivere una descrizione sensata di un grafico, sottotitolare una riunione, aggiungere i tag a un PDF o modificare un'app nativa, e non arriva al dominio di terzi per il pagamento o la prenotazione verso cui vengono mandati i vostri utenti.

La FTC ha già esaminato la promessa di conformità immediata. A gennaio 2025 ha pubblicato una proposta di ordinanza consensuale con accessiBe, produttore dell'overlay accessWidget, dopo aver contestato che il prodotto non rendeva tutti i siti conformi alle WCAG. La proposta prevedeva un pagamento di 1.000.000 di dollari e l'obbligo di dichiarare che il prodotto non corregge le barriere sui domini di terzi che non lo utilizzano a loro volta.

Il rischio sulle date

• Sia il DOJ sia l'HHS hanno scritto che durante la proroga «valuteranno l'emanazione di una NPRM» sui contenuti. La voce dell'agenda normativa del DOJ dice che si sta valutando se le disposizioni «possano essere rese meno onerose», con la data della proposta «da definire».
• Entrambi hanno anche scritto che, se non viene emanata alcuna NPRM del genere e nient'altro indica un ulteriore rinvio, ciascun dipartimento «prevede pienamente di applicare il regolamento alla nuova scadenza».
• Il 21 maggio 2026 la National Federation of the Blind ha fatto causa davanti al tribunale distrettuale del Maryland (National Federation of the Blind v. Department of Justice, 1:26-cv-02007), contestando entrambe le proroghe. A inizio ottobre 2026 non c'è ancora una decisione.
• Una proposta di norma da sola non cambia nulla. Una norma finale o una interim final rule sì, e il 2026 ha mostrato quanto tardi possa arrivare: la proroga del DOJ è entrata in vigore il 20 aprile 2026, quattro giorni prima della data che spostava.

Quindi il rischio va in entrambe le direzioni: una proposta potrebbe alleggerire la norma, e la causa sostiene che la data non avrebbe mai dovuto spostarsi. Contare su una tregua è una scommessa. Se il DOJ o l'HHS pubblicano un ulteriore rinvio, ripianificate prima di spendere altro.

Un piano che vale la pena seguire comunque vada

Una parte di questo lavoro ripaga in qualsiasi scenario, perché il Title II e la Section 504 impongono già la parità di accesso. Fatelo comunque:

• Correggete modelli e componenti.
• Fate funzionare da tastiera e con uno screen reader, dall'inizio alla fine, i principali percorsi transazionali (pagare, fare domanda, registrarsi, prenotare, accedere).
• Smettete di produrre nuovi PDF non accessibili.
• Mettete le WCAG 2.1 AA in ogni contratto e rinnovo.
• Sottotitolate le riunioni pubbliche.

Se viene pubblicato un rinvio, rimandate: l'adeguamento massivo di vecchi documenti usati di rado. Un archivio fatto bene di solito costa comunque meno.

A ritroso dal 26 aprile 2027 (i destinatari HHS hanno tempo fino all'11 maggio 2027):

1. Da ottobre a metà novembre 2026: inventario. Ogni dominio, app, sistema di fornitori e archivio di documenti. Ordinate i documenti in base al fatto che qualcuno li usi ancora per ottenere un servizio. Decidete cosa archiviare o eliminare.
2. Da metà novembre a gennaio: modelli, componenti e principali percorsi transazionali. Inviate subito ai fornitori la vostra richiesta di conformità. I cicli contrattuali sono più lenti del codice.
3. Gennaio e febbraio: documenti in uso, moduli, sottotitoli e correzioni alle app. Inviate gli aggiornamenti delle app entro fine febbraio, per lasciare margine alla revisione degli store.
4. Marzo: test. Prima solo tastiera, poi NVDA o JAWS su Windows, VoiceOver su iOS e macOS, TalkBack su Android, sui veri percorsi critici. Uno scanner non può dirvi se un testo alternativo significa qualcosa.
5. Aprile: congelamento e protezione. Aggiungete controlli automatici alla build e al flusso di pubblicazione, così il prossimo ordine del giorno e il prossimo rilascio non disfano il lavoro. Dove una dichiarazione di onere eccessivo si applica davvero, fatela firmare per iscritto prima della data, non dopo un reclamo.

Sui costi, la proroga dell'HHS cita rapporti della National League of Cities con preventivi una tantum per l'adeguamento di PDF e siti web da 10.000 a 20.000 dollari, e fino a 70.000 dollari all'anno, per città di dimensioni non indicate.

Dove trovare aiuto

Correggiamo l'accessibilità nel codice: modelli, librerie di componenti, moduli, portali e app mobili, con controlli nella build perché la correzione regga. Niente overlay, e niente rapporti di sola verifica. L'approccio è descritto nella pagina del nostro servizio di adeguamento all'accessibilità, e il versante UE è nel nostro articolo sull'European Accessibility Act.

Siamo ingegneri, non avvocati: quale data si applichi e se una dichiarazione di onere eccessivo regga sono domande per i vostri legali. Se avete un portale su misura e una data da rispettare, scrivete a office@c9group.dev.