EAA 2025: quali obblighi restano ignorati
La Direttiva UE 2019/882 è in vigore dal 28 giugno 2025. Ecommerce, cliniche e hotel italiani presentano ancora errori sistematici. Cosa devi correggere oggi.
Dal 28 giugno 2025 la EAA, sigla inglese di European Accessibility Act (legge europea sull’accessibilità digitale), è pienamente applicabile ai servizi consumer italiani. A quasi un anno dall’entrata in vigore, i pattern di non conformità più gravi restano gli stessi: contrasto insufficiente, moduli inaccessibili, navigazione da tastiera assente.
In sintesi
- La Direttiva (UE) 2019/882 si applica a ecommerce, sistemi di prenotazione e servizi consumer indipendentemente dalla dimensione dell’impresa, con scadenza al 28 giugno 2025.
- Lo standard minimo di conformità sono le WCAG 2.2 AA, sigla inglese di Web Content Accessibility Guidelines (linee guida internazionali per l’accessibilità dei contenuti web), livello AA.
- Il rapporto di contrasto minimo richiesto è 4,5:1 per testo normale e 3:1 per testo grande: la maggior parte dei siti italiani analizzati non lo rispetta nei form di prenotazione.
- Gli errori più frequenti riguardano etichette di campo assenti, messaggi di errore non descrittivi e focus visibile disabilitato via CSS.
- La mancata conformità espone a sanzioni amministrative e, su reclamo, a procedimenti davanti alle autorità designate.
Cosa prescrive la direttiva: il quadro in tre minuti
La Direttiva (UE) 2019/882, recepita in Italia con D.Lgs. 82/2022, stabilisce requisiti di accessibilità per prodotti e servizi immessi sul mercato UE dopo il 28 giugno 2025. Non è una raccomandazione. È un obbligo di legge.
Per i servizi digitali, l’obbligo riguarda l’intera esperienza d’uso. Non solo la homepage vetrina, ma ogni flusso transazionale: il checkout di un ecommerce, il form di prenotazione di una clinica, il motore di booking di un hotel indipendente.
Il riferimento tecnico indicato da AGID, l’Agenzia per l’Italia Digitale, sono le WCAG 2.2 livello AA. Queste linee guida sono organizzate secondo il principio POUR, acronimo inglese di Perceivable, Operable, Understandable, Robust (in italiano: percepibile, utilizzabile, comprensibile, robusto). Le quattro proprietà definiscono cosa deve garantire qualsiasi servizio digitale a utenti con disabilità visive, motorie o cognitive.
La direttiva non prevede soglie dimensionali. Una clinica odontoiatrica con form di anamnesi online, un agriturismo con booking proprietario, un ecommerce di nicchia: tutti soggetti agli stessi obblighi di una grande piattaforma. L’unica eccezione, prevista all’art. 14, riguarda i microoperatori con meno di 10 dipendenti e meno di 2 milioni di fatturato annuo.
Cosa fai oggi: verifica se il tuo servizio rientra nell’ambito applicativo. Se hai un sistema di prenotazione online o un ecommerce con fatturato sopra i 2 milioni, sei già dentro.
Contrasto e focus visibile: l’errore che tutti hanno e nessuno vede
Le WCAG 2.2 AA fissano un rapporto di contrasto minimo di 4,5:1 tra testo e sfondo per il corpo del testo, e 3:1 per testo grande (sopra i 18pt o 14pt grassetto). Il focus visibile, ovvero l’indicatore grafico che segnala quale elemento è selezionato quando si naviga con la tastiera, deve essere presente su ogni elemento interattivo: pulsanti, link, campi modulo.
Nella pratica italiana, due violazioni ricorrono quasi ovunque.
La prima: testo grigio chiaro su sfondo bianco, usato per microcopy di supporto come “campo obbligatorio” o “inserisci il codice fiscale”. Scende spesso sotto il rapporto 2:1. Illeggibile per chi ha ridotta sensibilità al contrasto, frequente negli over 60.
La seconda è più subdola. Molti sviluppatori rimuovono il focus visibile via CSS con la regola outline: none, una scelta puramente estetica. Risultato: chi naviga con la tastiera, per disabilità motoria o per abitudine, perde completamente l’orientamento nel flusso d’acquisto. Non sa su quale pulsante si trova. Non può procedere.
Un ecommerce di abbigliamento con checkout a più step azzera tipicamente il focus su tutti i pulsanti “Continua” per ragioni di stile grafico. È un errore documentato, sanzionabile, e facilissimo da correggere con due righe di CSS.
Cosa fai oggi: apri il tuo sito e naviga premendo solo il tasto Tab. Se non vedi un bordo o un’evidenziazione spostarsi tra i link e i pulsanti, il focus visibile è disabilitato. È il primo test da fare, gratis, in cinque minuti.
Form e prenotazioni: dove cliniche e hotel perdono punti
I flussi di prenotazione concentrano la maggior parte degli errori strutturali. Tre problemi ricorrono sistematicamente, e tutti e tre sono invisibili a un’ispezione visiva superficiale.
Etichette non associate. Un campo “Data di nascita” visivamente leggibile può non avere un’etichetta HTML (<label>) collegata al campo tramite attributo for. Uno screen reader, software di lettura dello schermo usato da persone non vedenti, legge il campo come “modifica testo” senza contesto. Nelle cliniche con form di anamnesi online, questo errore è quasi universale nei sistemi di prenotazione di terze parti non personalizzati.
Messaggi di errore non descrittivi. “Errore nel campo 3” non è conforme. Le WCAG richiedono che il messaggio identifichi il campo, descriva il problema e, dove possibile, suggerisca la correzione. Un hotel con booking proprietario che restituisce “Dati non validi” dopo un tentativo fallito viola questo requisito. L’utente non sa cosa correggere. Abbandona.
Focus non gestito dopo l’invio del modulo. Quando un form viene inviato e genera un errore, il focus deve spostarsi sul messaggio di errore o sul primo campo non valido. Se rimane dov’era, o torna in cima alla pagina, l’utente con screen reader non capisce cosa è successo. Questo problema è frequente nei moduli di contatto degli hotel indipendenti costruiti su CMS standard non configurati per l’accessibilità.
Cosa fai oggi: chiedi al tuo fornitore tecnico di verificare che ogni campo del form abbia un <label> associato e che i messaggi di errore descrivano il problema in modo specifico. Non è una richiesta esoterica: è manutenzione ordinaria.
Semantica HTML: il problema invisibile che gli scanner non trovano
Le WCAG 2.2 AA richiedono che la struttura semantica della pagina sia corretta. La navigazione principale deve usare l’elemento <nav>, il contenuto principale <main>, i moduli <form> con i relativi <fieldset> e <legend> dove necessario. Non sono raccomandazioni stilistiche. Sono la base su cui gli strumenti assistivi costruiscono la mappa della pagina per l’utente.
Il problema è che gli strumenti di verifica automatica, gli scanner online che analizzano il codice HTML, rilevano meno del 30% degli errori reali, secondo le stime del W3C. Gli errori semantici profondi emergono solo con test manuali o con l’uso diretto di uno screen reader.
Un ecommerce di prodotti alimentari con navigazione a categorie costruita interamente con <div> e JavaScript invece di <nav> e link HTML standard risulta “verde” nei test automatici ma è di fatto inaccessibile. Questo crea una falsa sicurezza pericolosa: il titolare ha fatto girare lo scanner, ha visto zero errori, ritiene di essere conforme. Non lo è.
Cosa fai oggi: uno scanner automatico è un punto di partenza, non una certificazione. Commissiona un audit manuale del flusso di checkout o prenotazione, con verifica specifica su contrasto, focus visibile, etichette dei form e messaggi di errore.
Vigilanza e sanzioni: chi controlla e cosa rischi
La Direttiva (UE) 2019/882 delega agli Stati membri la designazione delle autorità di vigilanza. In Italia il quadro attuativo è ancora in fase di consolidamento, ma il D.Lgs. 82/2022 prevede sanzioni amministrative per mancata conformità. I procedimenti possono essere attivati su reclamo di singoli utenti o associazioni di categoria.
AGID svolge un ruolo di orientamento tecnico e ha pubblicato linee guida operative per i soggetti privati soggetti alla EAA. Non ha funzioni sanzionatorie dirette sui privati, ma le sue indicazioni costituiscono il riferimento tecnico in caso di contenzioso.
C’è un aspetto che quasi nessuno considera. I cookie banner e i form di raccolta dati devono essere accessibili. Un banner di consenso non navigabile da tastiera o privo di etichette leggibili da screen reader tocca simultaneamente la conformità EAA e i principi di privacy by design indicati dal Garante per la protezione dei dati personali. Le due normative si sovrappongono su questo punto: progettare un’interfaccia accessibile non è separabile dal progettarla rispettosa della privacy.
Resta il fatto che il rischio principale, oggi, non è la sanzione diretta. È l’esposizione a reclami e, in caso di contenzioso, l’onere della prova sulla mancata adozione di misure ragionevoli. Chi non ha documentazione tecnica a supporto parte svantaggiato.
Cosa fai oggi: verifica contrattualmente che il tuo fornitore di sistema di prenotazione o ecommerce garantisca la conformità WCAG 2.2 AA e ottienigli documentazione scritta. La responsabilità verso l’utente finale rimane in capo a te, indipendentemente da chi ha sviluppato il sistema.
Domande correlate
La EAA si applica anche alle piccole imprese italiane?
Sì. La Direttiva (UE) 2019/882 non prevede soglie dimensionali per i servizi digitali consumer. Un’azienda con ecommerce o sistema di prenotazione online è soggetta agli stessi obblighi di una grande impresa. L’unica eccezione riguarda i microoperatori con meno di 10 dipendenti e meno di 2 milioni di fatturato annuo, ai sensi dell’art. 14 della direttiva.
Uno scanner automatico di accessibilità è sufficiente per la conformità?
No. Gli strumenti automatici rilevano una quota limitata degli errori reali, stimata attorno al 20-30% secondo il W3C. Errori semantici, gestione del focus e messaggi di errore richiedono test manuali o verifica con screen reader. Lo scanner è un punto di partenza, non una certificazione di conformità.
Cosa rischio se il mio sito non è conforme alla EAA?
Il D.Lgs. 82/2022 prevede sanzioni amministrative. I procedimenti possono essere attivati su reclamo di utenti o associazioni. Oltre alla sanzione, la non conformità espone a rischi reputazionali e, in caso di contenzioso, all’onere della prova sulla mancata adozione di misure ragionevoli.
Le WCAG 2.2 AA sono diverse dalle WCAG 2.1?
Le WCAG 2.2, pubblicate dal W3C nel 2023, aggiungono nove nuovi criteri rispetto alla versione 2.1, tra cui requisiti più stringenti sul focus visibile e sulla dimensione minima degli elementi interattivi. La conformità alla 2.1 non è automaticamente sufficiente per la 2.2.
Il mio sistema di prenotazione è gestito da un fornitore terzo: sono comunque responsabile?
Sì. La responsabilità verso l’utente finale rimane in capo all’operatore del servizio, indipendentemente da chi ha sviluppato il sistema. Verifica contrattualmente che il fornitore garantisca la conformità WCAG 2.2 AA e ottieni documentazione tecnica a supporto.
Fonti:
- [AGID – Accessibilità e WCAG: linee guida per siti web accessibili](https://www.agid.gov.it/it/design-system/accessibilita-linee-
Vuoi capire come applicarlo alla tua azienda?