Come rendere il tuo sito a norma EAA? Dieci controlli che puoi fare da solo
Autore: Dimitri
Frontend developer
Dal 28 giugno 2025 l'accessibilità è un obbligo per chi vende online e non è una microimpresa. Dieci controlli che chiunque può fare sul proprio sito, prima di chiedere un preventivo.
Da giugno dell'anno scorso mi arrivano con regolarità mail inoltrate dai clienti. Le manda un fornitore di widget per l'accessibilità e dicono più o meno tutte la stessa cosa: il tuo sito non è a norma EAA, rischi una multa fino a 40.000 euro, installa il nostro script. Il tono è quello di una raccomandata. Ogni volta devo spiegare due cose: cosa dice davvero la norma, e perché lo script non la risolve.
Un sito a norma EAA non lo si ottiene con un plugin. Si ottiene con un HTML scritto bene: titoli in gerarchia, bottoni veri, contrasto sufficiente, tutto raggiungibile da tastiera, form con le etichette. Qui sotto c'è la lista dei dieci controlli che faccio io quando mi passano un sito da valutare, e nessuno richiede di aprire il codice. Se li passi tutti, la parte tecnica è quasi fatta. Se ne fallisci più di tre, il widget non ti salva.
Prima di tutto: la norma ti riguarda?
L'EAA è la direttiva europea 2019/882, recepita in Italia con il decreto legislativo 82 del 2022. Si applica dal 28 giugno 2025 ai servizi che elenca, e fra quelli c'è il commercio elettronico. Se vendi online, ci sei dentro. Se il sito è una vetrina che non vende niente, la lettera della norma probabilmente non ti tocca; i dieci punti qui sotto servono comunque, per il semplice motivo che una parte dei tuoi visitatori li incontra tutti i giorni.
L'esenzione riguarda le microimprese: meno di dieci dipendenti e fatturato o bilancio annuo fino a due milioni di euro. Basta superare uno dei due limiti per rientrare nell'obbligo. Le sanzioni amministrative previste dal decreto arrivano fino a 40.000 euro, e la vigilanza sui servizi digitali spetta ad AgID. Lo standard tecnico di riferimento è la norma europea EN 301 549, che per il web rimanda alle WCAG 2.1 di livello AA. Cifre e riferimenti sono nel testo del decreto, che è pubblico: controllali, non fidarti della mail del fornitore e nemmeno di me.
I dieci controlli
Ti servono un browser, la tastiera e mezz'ora. Non c'è niente da installare.
- Contrasto del testo. Le WCAG chiedono un rapporto di almeno 4,5:1 fra testo e sfondo, che scende a 3:1 per i testi grandi. Il grigio chiaro su bianco che piace a tutti noi designer spesso non ce la fa. Il selettore colore degli strumenti per sviluppatori di Chrome mostra il rapporto direttamente: clicca sul colore di un testo e leggi il numero.
- Navigazione da tastiera. Chiudi il mouse in un cassetto e premi Tab dall'inizio della pagina. Devi poter raggiungere ogni link, ogni bottone, ogni campo del form, aprire il menu e chiuderlo. Se ti fermi da qualche parte, o resti intrappolato in un carosello, chi usa solo la tastiera si ferma lì.
- Focus visibile. Mentre premi Tab devi vedere dove sei. Quel bordo blu che tanti siti tolgono con una riga di CSS perché «è brutto» è l'unica cosa che dice a un utente da tastiera dove si trova. Si può ridisegnare, non si può togliere.
- Testi alternativi sulle immagini. Ogni immagine che porta informazione ha bisogno di un testo alternativo che dica quella informazione; le immagini decorative ne hanno bisogno di uno vuoto, così lo screen reader le salta. Il caso peggiore è anche il più comune: il nome del file al posto dell'alt, letto ad alta voce lettera per lettera.
- Form etichettati. Ogni campo ha un'etichetta collegata, non solo un testo segnaposto che scompare appena scrivi. Gli errori si spiegano a parole, non con un bordo rosso: «il campo email non contiene una chiocciola» funziona per tutti, il rosso da solo no.
- Gerarchia dei titoli. Un solo H1, e sotto gli H2 e gli H3 in ordine, senza salti. Chi usa uno screen reader naviga la pagina saltando di titolo in titolo, come tu la scorri con gli occhi. Se i titoli sono testo scritto grande, per quel lettore la pagina è un blocco unico.
- Bottoni veri. Le azioni sono elementi button, la navigazione sono link. Un div con un click sopra sembra un bottone in tutto, ma la tastiera non lo raggiunge e lo screen reader non lo annuncia. È il difetto che trovo più spesso nei siti costruiti con i builder visuali.
- Video sottotitolati. Ogni video con parlato ha i sottotitoli, e se un video parte da solo deve avere un comando per fermarlo a portata di mano. Se produci contenuti con l'AI, questo è il momento buono per generare anche la trascrizione.
- Zoom al 200 per cento. Ingrandisci la pagina con Ctrl e più fino al 200 per cento: il testo deve restare leggibile senza scorrimento orizzontale e senza elementi che si sovrappongono. Su mobile, lo zoom con due dita non deve essere bloccato dal codice.
- Lingua dichiarata e icone con un nome. L'attributo di lingua sull'HTML dice allo screen reader con che pronuncia leggere. I bottoni fatti solo di un'icona (lente, carrello, hamburger) hanno bisogno di un nome testuale che il lettore possa annunciare; altrimenti sente «bottone» e basta.
Il widget non è nella lista
Non per partito preso. L'overlay che si installa con una riga di script lavora sopra la pagina: cambia colori, ingrandisce il testo, aggiunge qualche attributo al volo. Non tocca il markup che c'è sotto. Se i bottoni sono div e i titoli non hanno gerarchia, lo screen reader continua a vedere div e testo grande. La conformità la fa l'HTML, e dei dieci punti qui sopra il widget ne sistema da solo forse uno e mezzo.
Il documento che manca sempre
C'è un punto undici, e non è tecnico. Il decreto chiede a chi fornisce il servizio di spiegare come rispetta i requisiti di accessibilità, in una forma che sia accessibile a sua volta. Nella pratica è una pagina del sito: cosa è conforme, cosa non lo è ancora e perché, e un modo per segnalare un problema. Nei siti che mi passano per una valutazione questa pagina non c'è quasi mai, ed è la cosa più facile da sistemare.
Se stai per rifare il sito
Qui sta la decisione concreta per chi commissiona. Rendere accessibile un sito esistente costa in proporzione a quanto è stato costruito male: ogni div-bottone va sostituito, ogni form ricablato, ogni colore ridiscusso. Farlo dall'inizio costa quasi niente, perché è il modo normale di scrivere HTML.
Quindi la voce da mettere nel brief, o da cercare nel preventivo, è una riga sola: conformità WCAG 2.1 livello AA, verificata con i dieci controlli qui sopra prima della consegna. Se chi ti fa il sito non sa cosa significa, hai già la tua risposta. Se te la propone come «modulo accessibilità» a parte, con un prezzo a parte, chiedi cosa c'è dentro: quasi sempre è il widget.
La mia posizione è che la multa sia il motivo meno interessante per fare questo lavoro. I dieci controlli descrivono un sito che funziona per chi ha una disabilità visiva o motoria, per chi ha lo schermo al sole, per chi naviga con una mano sola sul treno, e per il crawler di Google, che di fatto è un utente da tastiera senza occhi. La norma ha solo messo una data a una cosa che andava fatta comunque.
Leggi anche
-
Guide Sviluppo web E-commerce · 6 min di lettura
Voucher digitalizzazione PMI 2026: ci si paga il sito nuovo? No, ma il CMS e l'e-commerce in abbonamento sì
Il voucher MIMIT paga il 50% di software in abbonamento, cloud e sicurezza, CMS ed e-commerce compresi. Lo sviluppo su misura del sito no: ecco come dividere il preventivo.
-
Sviluppo web Guide · 6 min di lettura
Sito non sicuro Chrome: perché adesso l'avviso compare anche sul tuo? Il certificato sulla home non basta
Da Chrome 154 il browser chiede il permesso prima di aprire qualsiasi indirizzo pubblico che risponde solo in HTTP. Il certificato sulla home non c'entra: l'avviso compare sui sottodomini e sui nomi dimenticati che però sono ancora stampati e linkati.
Hai un progetto in mente?
Prenota una call gratuita di 30 minuti: parliamo del tuo progetto, senza impegno. Lavoriamo da Modena con aziende in tutta Italia.