EAA: 6 motivi per cui un sito conforme sulla carta non passa l'audit

Il divario nei controlli sull'EAA è la distanza tra un prodotto che sulla carta rispetta l'European Accessibility Act (una dichiarazione pubblicata, un punteggio Lighthouse verde, un widget overlay nel footer) e un prodotto che una persona con disabilità riesce davvero a usare per completare un acquisto, aprire un conto o cambiare una prenotazione. Audit, segnalazioni e cause in tribunale misurano la seconda cosa. Le carte sono la metà economica del lavoro, ed è quella che si fa per prima.

L'Act si applica dal 28 giugno 2025 a un elenco preciso di prodotti e servizi per i consumatori, tra cui e-commerce, servizi bancari al consumo, e-book, comunicazioni elettroniche e trasporto passeggeri (Direttiva (UE) 2019/882). Nel primo anno i controlli sono passati soprattutto da diffide, ingiunzioni e termini per mettersi in regola, più che da multe. È proprio la fase in cui il divario emerge: un ispettore o chi presenta una segnalazione prova il servizio con la tastiera o con uno screen reader, e la dichiarazione sul sito smette di contare.

Che aspetto ha un prodotto conforme solo sulla carta?

Lo schema si riconosce subito. Il footer rimanda a una dichiarazione di accessibilità che afferma la piena conformità alle WCAG 2.1 AA. Non c'è una data di valutazione, né un elenco di problemi noti. Il sito marketing prende 100 nell'audit di accessibilità di Lighthouse. Un overlay offre un pulsante per il contrasto e un cursore per la dimensione del testo. Poi qualcuno attraversa il checkout con il tasto Tab e il focus sparisce dentro un selettore di date, oppure lo screen reader legge il pulsante di pagamento come "pulsante", senza nome.

Nessuno di questi segnali è una frode in sé. Ognuno misura qualcosa di più ristretto di quello che chiede la legge. I sei errori che seguono sono i punti in cui il campo si restringe.

Sei motivi per cui un prodotto conforme sulla carta non passa l'audit

1. Il punteggio automatico viene preso per l'audit

I controlli automatici leggono il markup. Non sanno dire se il testo alternativo descrive l'immagine, se l'ordine del focus segue quello visivo, o se un messaggio di errore arriva a chi usa uno screen reader nel momento in cui compare. Quando il Government Digital Service britannico ha provato 13 strumenti su una pagina di test costruita con 142 barriere volute, il migliore ne ha trovate il 40 per cento (blog accessibilità del GDS). Un 100 su Lighthouse vuol dire che la pagina, nello stato in cui è stata provata, non ha nessuno degli errori che Lighthouse cerca. Sul resto non dice niente.

2. La dichiarazione è un modello copiato, non una valutazione

L'Allegato V della Direttiva chiede a chi fornisce un servizio di spiegare come il servizio soddisfa i requisiti di accessibilità, nelle condizioni generali o in un documento equivalente, descrivendone progettazione e funzionamento per quanto serve alla valutazione (Direttiva (UE) 2019/882, Allegato V). Un paragrafo copiato che dichiara la piena conformità non fa nulla di tutto questo. Una dichiarazione senza data e senza problemi noti fa pensare che nessuno abbia valutato il prodotto. Una dichiarazione che indica lo standard, data e metodo dell'ultima verifica, i difetti noti e quando verrà corretto ciascuno descrive un prodotto sotto controllo, anche prima che sia del tutto conforme.

3. Si installa un overlay come rimedio

Un overlay aggiunge un widget sopra la pagina. Le barriere stanno nella pagina sotto: campi senza etichetta, div usati come pulsanti, finestre di dialogo da cui il focus scappa. Nel gennaio 2025 la Federal Trade Commission statunitense ha imposto ad accessiBe di pagare un milione di dollari per aver sostenuto che il suo widget rendeva qualsiasi sito conforme alle WCAG, e ha rilevato che lo strumento non era riuscito a rendere conformi elementi di base come menu, titoli, tabelle e immagini (comunicato FTC). È un provvedimento americano di tutela dei consumatori, non una decisione sull'EAA. Risponde comunque alla domanda pratica: uno script appoggiato sopra non ripara il markup che l'auditor controlla.

4. I componenti passano da soli e falliscono insieme

È la versione design system del problema. Ogni componente della libreria supera i propri controlli: il pulsante ha un nome, il campo ha un'etichetta, la finestra di dialogo ha un ruolo. Il difetto compare quando li si mette insieme. Una finestra si apre da un menu e, quando si chiude, il focus torna in cima alla pagina. Un form mostra errori in linea che si vedono ma non vengono mai annunciati. Una combobox funziona con il mouse e intrappola la tastiera dentro un pannello di filtri. Le story dei componenti li provano uno alla volta. Gli audit provano i compiti dell'utente, e un compito attraversa più componenti. Di come una libreria si allontana dalle proprie regole abbiamo scritto in component drift: come un design system si degrada.

5. Si verificano le pagine, non i percorsi

Una dichiarazione di conformità spesso si basa su un campione di template: home, scheda prodotto, articolo. I compiti che interessano all'EAA stanno altrove: registrazione, verifica dell'identità, carrello, pagamento, modifica della prenotazione, area personale. Nelle cause francesi avviate nel novembre 2025 dalle associazioni apiDV e Droit Pluriel contro quattro grandi catene della distribuzione alimentare, il bersaglio era il servizio di spesa online, cioè il sito e l'app con cui una persona cieca o ipovedente fa la spesa (Intérêt à Agir). Nel 2026 un tribunale francese ha dato a Carrefour sei mesi per rendere accessibili sito e app, con una penale per ogni giorno di ritardo (LSA).

6. I sei errori più comuni restano nei token

Il WebAIM Million 2026 ha trovato errori WCAG rilevabili sul 95,9 per cento del milione di home page più visitate, contro il 94,8 per cento del 2025. Il testo a basso contrasto compariva sull'83,9 per cento. Sei tipi di errore (basso contrasto, testo alternativo mancante, etichette dei form mancanti, link vuoti, pulsanti vuoti, lingua del documento non dichiarata) valevano il 96 per cento di tutto ciò che è stato rilevato, e sono gli stessi sei da sette anni (WebAIM Million 2026). Il basso contrasto raramente è un bug di pagina. È un token: un grigio scelto per il testo su uno sfondo colorato e poi riusato su centinaia di schermate. Correggerlo pagina per pagina vuol dire correggerlo centinaia di volte e dimenticarne qualcuna.

Quanto costa questo divario nel 2026?

Le sanzioni le fissa ogni Stato, quindi il rischio dipende da dove si vende il prodotto. I massimali vanno da circa 5.000 euro in Estonia a circa un milione di euro in Spagna (tabella per paese di WebYes), e diversi Stati aggiungono penali giornaliere o il potere di ritirare un servizio. A un anno dall'entrata in vigore, i resoconti pubblicati parlano di diffide, ingiunzioni e termini per correggere, più che di multe riscosse (rapporto di Disability World sul primo anno).

Le cause mostrano anche che l'ambito di applicazione è ancora in discussione. Nel maggio 2026 il tribunale di Lille ha riconosciuto che il sito di Auchan E-Commerce non era conforme e ha comunque respinto il ricorso, leggendo la legge francese come un'esenzione per una controllata sotto i 250 milioni di euro di fatturato. Le associazioni hanno fatto appello, sostenendo che questa lettura contraddice la Direttiva (Faire Face). Se una società rientri o no nell'ambito è una domanda da fare a un avvocato. Se il suo checkout funzioni con la tastiera è una domanda a cui un team di prodotto risponde in una settimana.

Per il team il costo vero è il tempo. Un'ingiunzione con sei mesi di termine concentra in un solo ciclo di rilascio il lavoro che un design system avrebbe distribuito su un anno, e lo fa cadere sui percorsi che portano ricavi.

Come si chiude il divario su un prodotto già online?

1. Elencare i compiti, non le pagine. Scrivere i cinque-dieci compiti che un consumatore porta a termine dall'inizio alla fine: registrarsi, verificarsi, cercare, aggiungere al carrello, pagare, cambiare una prenotazione, chiudere l'account. Quell'elenco è il perimetro dell'audit.
2. Provare ogni compito con la tastiera e con uno screen reader. NVDA su Windows e VoiceOver su macOS e iOS sono gratuiti. Annotare dove si perde il focus, quale controllo non ha nome e quale errore non viene mai annunciato.
3. Risalire all'origine di ogni difetto. Dividere i risultati in tre gruppi: un token (contrasto, anello del focus), un componente (finestra di dialogo, combobox, campo di form) o una singola schermata. Correggere prima i primi due gruppi: una modifica lì sistema ogni schermata che li usa.
4. Correggere nel design system, rilasciare, poi riprovare i compiti. Una correzione del contrasto nei token e una del focus nella finestra di dialogo arrivano su tutte le schermate al rilascio successivo. La nostra checklist per un audit del design system in cinque giorni copre la parte su token e componenti.
5. Riscrivere la dichiarazione per ultima. Datarla, indicare lo standard (EN 301 549, che incorpora le WCAG 2.1 AA), descrivere il metodo, elencare ciò che ancora non funziona e quando verrà corretto, e lasciare un contatto per le segnalazioni.
6. Togliere l'overlay quando le correzioni sono online, o almeno smettere di citarlo come misura di conformità.

Una nota sullo standard. EN 301 549 V3.2.1 è il riferimento che gli auditor usano oggi, e nel 2022 la Commissione europea ha chiesto agli enti di normazione di adattarlo all'EAA (mandato M/587). Progettare sulle WCAG 2.1 AA, e verificare le WCAG 2.2 dove costa poco, copre anche la versione in arrivo.

Come si evita che il divario si riapra?

• Controlli automatici come soglia minima in CI. Far girare axe-core o un equivalente a ogni pull request. Intercetta le regressioni che una macchina vede e lascia il tempo manuale per quelle che non vede.
• L'accessibilità dentro il contratto del componente. Ogni componente documenta il comportamento da tastiera, la gestione del focus e cosa annuncia, con un test per ciascuna cosa. Un componente che non rispetta il contratto non entra nella libreria.
• Test di composizione per i compiti critici. Un test end-to-end che completa il checkout solo con la tastiera blocca la build quando il focus si perde tra due componenti.
• Contrasto verificato nei token. Abbinare ogni token di testo agli sfondi su cui può stare e controllare il rapporto quando il token cambia, non quando esce una pagina. Un sistema di token a tre livelli rende espliciti questi abbinamenti.
• Una verifica manuale a cadenza fissa: a ogni rilascio importante e almeno una volta l'anno, con la dichiarazione aggiornata nella data ogni volta.

Per il cambiamento più ampio nel modo di fare prodotto dopo l'entrata in vigore dell'Act, c'è il nostro articolo sul design accessibile dopo l'EU Accessibility Act. Questo pezzo descrive come si forma il divario. Non è una consulenza legale: ambito, esenzioni e sanzioni nazionali vanno verificati con un avvocato qualificato in ogni mercato in cui il prodotto è in vendita.