Accessibilità digitale: cosa manca ancora ai siti italiani
Accessibilità digitale · EAA 2025
Accessibilità digitale: cosa manca ancora ai siti italiani
Meta description: Dal 28 giugno 2025 l’European Accessibility Act è obbligatorio per ecommerce e servizi consumer italiani. Ecco i pattern WCAG 2.2 AA ancora assenti e cosa fare.
Dal 28 giugno 2025 la Direttiva UE 2019/882, nota come European Accessibility Act, è cogente per ecommerce e servizi digitali consumer italiani. A undici mesi dall’entrata in vigore, i pattern di accessibilità più critici — focus visibile, contrasto cromatico, semantica strutturale, gestione degli errori nei form — restano sistematicamente assenti in tre settori ad alta esposizione: vendita online, prenotazioni sanitarie e booking alberghiero.
In sintesi
- La Direttiva UE 2019/882 (European Accessibility Act) impone conformità accessibilità ai servizi digitali consumer dal 28 giugno 2025, senza soglia dimensionale esplicita: vale anche per le PMI.
- Lo standard tecnico di riferimento sono le WCAG 2.2 AA — le linee guida per l’accessibilità dei contenuti web versione 2.2, livello AA — pubblicate dal W3C, l’organizzazione internazionale che definisce gli standard del web.
- Il criterio 2.4.11 delle WCAG 2.2, introdotto proprio in questa versione, richiede che l’indicatore di focus — il bordo visibile che segnala quale elemento è selezionato da tastiera — non venga oscurato da altri elementi della pagina.
- I form di checkout ecommerce e di prenotazione sanitaria sono i punti di maggiore esposizione: criteri 3.3.1, 3.3.3 e 3.3.4 delle WCAG 2.2 riguardano identificazione, correzione e prevenzione degli errori in transazioni finanziarie o legali.
- AGID, l’Agenzia per l’Italia Digitale, ha pubblicato linee guida operative nel Design System Italia che costituiscono il riferimento tecnico per la conformità EAA nel contesto italiano.
Il quadro normativo: chi è obbligato e da quando
La Direttiva UE 2019/882, recepita in Italia, si applica alle imprese private che forniscono prodotti e servizi ai consumatori nell’Unione Europea. La Commissione Europea conferma esplicitamente che i servizi digitali — inclusi ecommerce e prenotazioni online — rientrano nel perimetro, senza una soglia dimensionale che escluda le piccole imprese.
Questo significa che un negozio online con venti dipendenti, una clinica odontoiatrica con prenotazioni sul sito, un hotel indipendente con booking proprietario: tutti sono soggetti agli obblighi dell’EAA dal 28 giugno 2025.
Lo standard tecnico che traduce la direttiva in requisiti misurabili sono le WCAG 2.2 AA — acronimo inglese per Web Content Accessibility Guidelines, in italiano linee guida per l’accessibilità dei contenuti web, versione 2.2, livello AA. AGID ha integrato questi criteri nel Design System Italia, fornendo pattern operativi specifici per il contesto italiano.
Cosa fare oggi: verificare se il proprio sito rientra nella definizione di “servizio consumer digitale” — la risposta è quasi certamente sì se ha un checkout, un form di prenotazione o un’area riservata utenti.
Focus visibile e navigazione da tastiera: il problema più diffuso
Il criterio 2.4.11 delle WCAG 2.2 — introdotto proprio in questa versione, non presente nelle precedenti — stabilisce che l’indicatore di focus visibile, cioè il bordo o l’evidenziazione grafica che appare quando si naviga un sito usando solo la tastiera, non deve essere coperto da altri elementi della pagina. Il criterio 2.4.13 aggiunge che questo indicatore deve avere un rapporto di contrasto minimo di 3:1 rispetto all’area circostante.
Nei calendari di selezione date dei booking alberghieri — uno degli elementi di interfaccia più complessi da rendere accessibili — l’assenza di focus visibile è quasi la norma. Chi usa la tastiera perché non può usare il mouse perde completamente il controllo della navigazione. Lo stesso accade nei menu a tendina per la selezione della camera o del numero di ospiti.
Il problema non è estetico: è funzionale. Una persona con disabilità motoria che non usa il mouse non riesce a completare la prenotazione. Per un hotel, questo si traduce in prenotazioni perse e in esposizione a contestazioni formali.
Cosa fare oggi: aprire il proprio sito e premere il tasto Tab ripetutamente. Se non si vede chiaramente quale elemento è selezionato in ogni momento, il sito non rispetta il criterio 2.4.11.
Contrasto cromatico e testi alternativi: errori evitabili
Il criterio 1.4.3 delle WCAG 2.2 stabilisce un rapporto di contrasto minimo di 4,5:1 tra testo e sfondo per il testo di dimensione normale. Nei siti ecommerce direct-to-consumer italiani, il grigio chiaro su bianco — usato spesso per descrizioni prodotto, note spese di spedizione o testi secondari — è uno degli errori più ricorrenti e più semplici da correggere.
Il criterio 1.1.1 riguarda i testi alternativi alle immagini, in inglese detti “alt text”: le immagini che trasmettono informazioni devono avere una descrizione testuale che i lettori di schermo — software che leggono il contenuto della pagina ad alta voce per persone con disabilità visive — possono annunciare. Le immagini puramente decorative devono invece avere un attributo alt vuoto, per non generare rumore inutile.
Nei siti di strutture alberghiere, le fotografie delle camere sono quasi sempre immagini informative — mostrano la tipologia, la vista, gli arredi — ma raramente hanno un alt text descrittivo. Il risultato è che un utente non vedente non riesce a distinguere tra una camera standard e una suite.
Cosa fare oggi: usare uno strumento gratuito come il WAVE Web Accessibility Evaluation Tool per una prima scansione automatica degli errori di contrasto e dei testi alternativi mancanti.
Form di prenotazione sanitaria: il punto di maggiore esposizione
I form di prenotazione online di cliniche e studi medici privati concentrano tre criticità simultanee. Prima: trattano dati sanitari, categoria particolare ai sensi del GDPR, sotto la vigilanza del Garante per la protezione dei dati personali. Seconda: sono form complessi, con molti campi, selezione di date, scelta del medico. Terza: sono spesso realizzati con soluzioni terze non verificate per accessibilità.
Le WCAG 2.2 prescrivono, per i form, tre criteri distinti. Il criterio 3.3.1 richiede che gli errori di compilazione siano identificati con testo descrittivo — non solo con un colore rosso, che una persona con daltonismo non percepisce. Il criterio 3.3.3 richiede che venga suggerita la correzione. Il criterio 3.3.4 richiede che per transazioni con conseguenze legali o finanziarie — e una prenotazione medica può rientrare in questa categoria — ci sia una possibilità di revisione o annullamento prima della conferma definitiva.
Sul piano tecnico, le etichette dei campi — in inglese “label” — devono essere associate programmaticamente all’input corrispondente tramite attributo for/id o aria-labelledby. I messaggi di errore devono essere collegati al campo tramite aria-describedby, un attributo HTML che indica ai lettori di schermo quale testo descrive un dato elemento, per essere annunciati automaticamente. Senza questa associazione, chi usa un lettore di schermo sente l’errore ma non sa a quale campo si riferisce.
Cosa fare oggi: chiedere al proprio fornitore web una verifica specifica dei criteri 3.3.1, 3.3.3 e 3.3.4 sui form di prenotazione, con test su almeno uno screen reader — software lettore di schermo — come NVDA (gratuito per Windows) o VoiceOver (integrato in macOS e iOS).
Semantica HTML strutturale: la base che manca
AGID nel Design System Italia indica come requisiti operativi minimi per la conformità EAA l’uso corretto degli elementi HTML semantici: nav per la navigazione, main per il contenuto principale, form con label associati. Questi non sono dettagli tecnici marginali: sono la struttura che permette ai lettori di schermo di orientarsi nella pagina.
Un ecommerce che usa div e span per costruire tutta la navigazione — pratica comune nei siti realizzati con certi costruttori visivi — è tecnicamente non conforme anche se graficamente impeccabile. Un utente che naviga con un lettore di schermo non riesce a saltare direttamente al contenuto principale o al menu, ed è costretto ad ascoltare ogni elemento della pagina in sequenza.
La semantica HTML corretta è anche il fondamento su cui si costruisce la compatibilità con tecnologie assistive future. Correggere la struttura semantica una volta sola risolve problemi su tutti i dispositivi e tutti gli screen reader.
Cosa fare oggi: chiedere al proprio sviluppatore di eseguire una validazione HTML con il validatore del W3C e verificare la presenza degli elementi semantici principali con gli strumenti per sviluppatori del browser.
Domande correlate
L’EAA si applica anche al mio piccolo ecommerce?
Sì. La Commissione Europea non ha previsto soglie dimensionali esplicite per i servizi digitali consumer. Se il tuo sito vende prodotti o servizi a consumatori nell’UE e gestisce un checkout o un form di prenotazione, rientra nel perimetro della Direttiva UE 2019/882 dal 28 giugno 2025.
Cosa rischio se il mio sito non è conforme all’EAA?
La direttiva prevede sanzioni amministrative la cui entità dipende dal recepimento nazionale. In Italia il decreto di recepimento definisce le autorità competenti e le misure applicabili. Il rischio aggiuntivo è la contestazione da parte di utenti o associazioni che documentano l’inaccessibilità del servizio.
Quanto tempo richiede un adeguamento WCAG 2.2 AA?
Dipende dallo stato di partenza. Un sito con struttura HTML semantica corretta può adeguarsi su contrasto e focus in poche settimane. Un sito costruito interamente con elementi non semantici o con un costruttore visivo non accessibile richiede interventi strutturali che possono durare mesi.
Le WCAG 2.2 AA sono diverse dalle WCAG 2.1 che già conoscevo?
Sì, ma in modo incrementale. Le WCAG 2.2 aggiungono nove nuovi criteri di successo rispetto alle 2.1, tra cui il criterio 2.4.11 sul focus non oscurato e il criterio 2.5.7 sui movimenti di trascinamento. Chi era già conforme alle WCAG 2.1 AA deve verificare solo i nuovi criteri.
Il mio sviluppatore dice che il sito “passa i test automatici”: è sufficiente?
No. Gli strumenti automatici rilevano circa il 30-40% dei problemi di accessibilità. Criteri come la qualità dei testi alternativi, la logica di navigazione da tastiera e la comprensibilità dei messaggi di errore richiedono test manuali e, idealmente, test con utenti reali che usano tecnologie assistive.
Fonti:
- Accessibilità - Design System Italia - AGID — accesso giugno 2025
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C — accesso giugno 2025
- Garante per la protezione dei dati personali — accesso giugno 2025
- European Accessibility Act — Commissione Europea — accesso giugno 2025
- Accessible Form Examples — Accessibility Developer Guide — accesso giugno 2025
Non costituisce parere legale.
Vuoi capire come applicarlo alla tua azienda?