Breve recap su cosa prevede la normativa sull’accessibilità web
L’European Accessibility Act è entrato ufficialmente in vigore il 28 giugno 2025, ma la normativa prevede comunque un periodo cuscinetto di 5 anni (2030, quindi) per permettere alle aziende private di mettere a norma i propri servizi digitali e siti web – purché fossero già esistenti prima di quella data o non abbiano subito “modifiche sostanziali” successive.
Cosa si intende per “modifica sostanziale”?
In generale: restyling importanti, rifacimenti grafici, nuove funzionalità interattive (chat, aree riservate, sistemi di prenotazione), nuovi checkout, nuove versioni dell’app.
In questi casi, la deroga decade e devi essere a norma subito.
Per cui se un servizio esistente è stato aggiornato in modo significativo dopo il 28 giugno 2025, la conformità diventa immediatamente obbligatoria, anche se rientrava nel periodo transitorio.
Aziende private e contenuti digitali coinvolti
La normativa impone a tutte le aziende private che contano più di 10 dipendenti OPPURE hanno un fatturato di oltre 2 milioni di Euro/anno di avere siti web e servizi digitali accessibili.
Con servizi digitali si intende qualsiasi contenuto fruibile dagli utenti tramite app, terminali, siti web ed e-commerce.
I criteri da rispettare sono descritti nel testo della UNI EN 301549 (186 simpatiche pagine scritte in tecnichese, che ti tradurrò in italiano facile nel corso di questo articolo) e fanno riferimento alle linee guida WCAG 2.1.
La norma prevede che i servizi digitali rispondano ai criteri di successo previsti dalle WCAG 2.1 di livello A e livello AA.
In questo articolo ti parlerò delle WCAG di livello A, che sono considerate il pre-requisito minimo.
Per le WCAG di livello AA, ho scritto questo articolo a parte.
I 30 criteri da rispettare per essere conformi al livello A
Per praticità suddividerò l’elenco secondo i 4 principi fondamentali previsti dalle linee guida:
Percepibile – il contenuto deve essere presentato in modo che tutte le persone possano fruirlo (es. testi ben leggibili, alternative testuali per immagini e video…).
Operabile – il sito deve potersi navigare facilmente anche senza mouse (es. solo con la tastiera o comandi vocali).
Comprensibile – i contenuti e le interazioni devono essere chiari, prevedibili e ben organizzati.
Robusto – il sito deve essere compatibile con le tecnologie assistive (come lettori vocali), oggi e in futuro.
Qui sotto troverai i criteri di successo previsti per il livello A delle WCAG 2.1, accompagnati da una spiegazione semplice e non tecnica.
Questa è la checklist minima da tenere a mente per progettare (o aggiornare) un sito che sia davvero inclusivo e conforme.
In corsivo riporterò il testo contenuto nelle WCAG 2.1 ed a seguire una breve spiegazione.
1. Percepibile
1.1.1 Contenuti non testuali
“Tutti i contenuti non testuali presentati all’utente hanno un’alternativa testuale equivalente che serva allo stesso scopo.”
Significa che: ogni immagine, icona, grafico o elemento visivo deve avere una descrizione testuale (il famoso alt text). Chi non vede le immagini usa lettori di schermo, che leggono il testo alternativo ad alta voce. Esempio: la foto di un prodotto non deve avere alt “immagine prodotto”, ma “borsa in pelle marrone con manico corto”.
1.2.1 Solo audio e solo video (preregistrati)
“Per i contenuti di solo audio preregistrato e di solo video preregistrato è fornita una alternativa ai media temporizzati”
Significa che: se pubblichi un podcast (solo audio) devi fornirne anche la trascrizione scritta. Se pubblichi un video senza audio, devi fornirne una descrizione testuale (o audio) di quello che accade.
1.2.2 Sottotitoli (preregistrati)
“Sono forniti i sottotitoli per tutti i contenuti audio preregistrati di media sincronizzati.”
Significa che: tutti i video con parlato o suoni importanti devono avere i sottotitoli. Servono a chi non sente l’audio, ma anche a chi guarda il video in contesti in cui non può attivarlo (treno, ufficio, metro…).
1.2.3 Audiodescrizione o media alternativo (preregistrati)
“È fornita un’alternativa ai media temporizzati o un’audiodescrizione per i contenuti video preregistrati.”
Significa che: per i video preregistrati serve un’audiodescrizione delle scene importanti (per chi non vede), oppure una versione testuale completa del contenuto. (Nota: al livello AA questo criterio viene rafforzato dal 1.2.5, che richiede espressamente l’audiodescrizione)
1.3.1 Informazioni e relazioni
“Le informazioni, la struttura e le relazioni trasmesse attraverso la presentazione possono essere determinate programmaticamente o sono disponibili sotto forma di testo.”
Significa che: titoli, elenchi, paragrafi, tabelle devono essere costruiti con il codice HTML corretto, non solo con la grafica. Un titolo deve essere marcato H1, H2, H3 – non essere solo “testo grande e in grassetto”.
Una lista deve essere una <ul> vera, non trattini scritti a mano. È così che i lettori di schermo riconoscono la struttura della pagina.
1.3.2 Sequenza significativa
“Quando la sequenza in cui il contenuto è presentato influisce sul suo significato, è possibile determinare programmaticamente una corretta sequenza di lettura”
Significa che: l’ordine con cui un lettore di schermo legge la pagina deve avere senso. Se il senso dipende dalla sequenza, quella sequenza deve essere rispettata anche nel codice (non solo visivamente grazie al CSS).
1.3.3 Caratteristiche sensoriali
“Le istruzioni fornite per comprendere e utilizzare il contenuto non si basano solo su caratteristiche sensoriali dei componenti, come la forma, il colore, la dimensione, l’ubicazione visiva, l’orientamento o il suono.“
Significa che: le istruzioni non devono basarsi solo su caratteristiche visive o sonore.
❌ Sbagliato: “clicca sul pulsante verde a destra”
✅ Corretto: “clicca sul pulsante Invia (verde, a destra)”.
1.4.1 Uso del colore
“Il colore non è utilizzato come unico mezzo visivo per trasmettere informazioni, indicare un’azione, richiedere una risposta o distinguere un elemento visivo.”
Significa che: il colore non deve essere l’unico modo per comunicare un’informazione. I link non devono essere riconoscibili solo perché blu: serve anche la sottolineatura o un altro elemento distintivo. Un campo con errore non può essere evidenziato solo col bordo rosso: serve anche un messaggio testuale (“Email non valida”). È fondamentale per chi ha daltonismo o bassa visione.
1.4.2 Controllo del suono
“Se un qualsiasi contenuto audio in una pagina Web è riprodotto automaticamente per più di 3 secondi, è disponibile un meccanismo per mettere in pausa o fermare l’audio, oppure un meccanismo per controllarne il volume indipendentemente dal livello generale dell’audio di sistema.”
Significa che: se sul sito parte un audio in automatico e dura più di 3 secondi, l’utente deve poterlo mettere in pausa, fermare o regolarne il volume, indipendentemente dal volume del dispositivo (evitare in generale audio che partono in automatico resta sempre una soluzione preferibile).
2. Operabile
2.1.1 Tastiera
“Tutte le funzionalità del contenuto sono utilizzabili tramite un’interfaccia a tastiera, senza richiedere specifici tempi per i singoli tasti.”
Significa che: tutto quello che si può fare col mouse deve potersi fare anche con la tastiera. Menu, moduli, pulsanti, filtri… tutto. Le uniche eccezioni sono le funzioni che richiedono movimenti specifici (es. disegno a mano libera).
2.1.2 Nessun blocco della tastiera (trap)
“Se il focus della tastiera può essere spostato su un componente della pagina usando un’interfaccia da tastiera, allora il focus può essere spostato via dal componente usando solo la tastiera”.
Significa che: se con la tastiera si entra in una sezione, con la tastiera si deve poter anche uscire. L’utente non deve mai restare “intrappolato” in un pop-up, un modulo, un widget.
2.1.4 Scorciatoie da tastiera a carattere singolo
“Se una scorciatoia da tastiera è implementata usando solo lettere, punteggiatura, numeri o simboli, almeno una delle seguenti è vera: può essere disattivata, rimappata, oppure attivata solo quando l’elemento ha il focus.”
Significa che: se sul sito esistono scorciatoie attivate da un singolo tasto (una lettera, un numero, un simbolo), l’utente deve poterle disattivare o rimappare. Questo previene attivazioni accidentali, soprattutto per chi usa comandi vocali.
2.2.1 Regolazione dei tempi
“Per ogni limite di tempo impostato dal contenuto, almeno uno dei seguenti è vero: l’utente può disattivarlo, regolarlo, o prolungarlo.“
Significa che: se c’è un limite di tempo (sessione che scade, tempo per compilare un modulo, ecc.) l’utente deve poterlo disattivare, estendere o regolare. Chi ha bisogno di più tempo (per disabilità cognitive, motorie, o anche solo perché sta rileggendo con calma) non può essere tagliato fuori.
2.2.2 Pausa, interruzione, nascondi
“Per ogni informazione in movimento, lampeggiante, scorrevole o con aggiornamento automatico, sono verificate tutte le seguenti condizioni: l’utente può metterla in pausa, fermarla o nasconderla.”
Significa che: animazioni, slider automatici, caroselli, notizie che si aggiornano da sole devono poter essere messe in pausa, fermate o nascoste dall’utente. Contenuti in movimento distraggono e disorientano, soprattutto chi ha disturbi dell’attenzione o della lettura.
2.3.1 Tre lampeggiamenti o meno
“Le pagine Web non contengono nulla che lampeggi più di tre volte nell’arco di un secondo, o il lampeggio è al di sotto delle soglie di flash generale e di flash rosso.”
Significa che: niente elementi che lampeggino più di 3 volte al secondo. Lampeggiamenti rapidi possono provocare crisi epilettiche in persone fotosensibili. È uno dei pochi criteri che può avere conseguenze davvero gravi e immediate se non rispettato.
2.4.1 Salto di blocchi
“È disponibile un meccanismo per saltare i blocchi di contenuto che si ripetono in più pagine Web.”
Significa che: serve un meccanismo per saltare i blocchi ripetuti (menu, header) e arrivare subito al contenuto principale. Tipicamente si implementa con un link “Salta al contenuto” che appare al primo Tab da tastiera. Per chi naviga con lettore di schermo, dover riascoltare ogni volta l’intero menu è sfiancante.
2.4.2 Pagina con titolo
“Le pagine Web hanno titoli che ne descrivono l’argomento o lo scopo.”
Significa che: ogni pagina deve avere un titolo descrittivo (quello che appare nella scheda del browser). “Home” non basta: serve qualcosa come “Home – Nome del sito” o “Contatti – Studio XY”.
2.4.3 Ordine di messa a fuoco (focus order)
“Se una pagina Web può essere navigata sequenzialmente e le sequenze di navigazione influiscono sul significato o sul funzionamento, i componenti ricevono il focus in un ordine che preserva il significato e l’operabilità.“
Significa che: quando si naviga col tasto Tab, l’ordine in cui gli elementi vengono selezionati deve essere logico. Non si può saltare dal footer al menu laterale, poi al titolo, poi ancora al contenuto. Tab deve seguire una sequenza che abbia senso per l’utente.
2.4.4 Scopo dei link (nel contesto)
“Lo scopo di ciascun link può essere determinato dal solo testo del link, oppure dal testo del link unito al contesto circostante.“
Significa che: il testo di ogni link deve far capire dove porta. Da solo, o almeno insieme al contesto immediato. ❌ Sbagliato: “clicca qui”, “leggi di più”, “scopri” ✅ Corretto: “leggi l’articolo sulle WCAG livello A”, “scarica il PDF della guida” (Questo criterio è legato al 2.4.6 del livello AA, che rafforza il concetto per intestazioni ed etichette).
2.5.1 Gesti da puntatore
“Tutte le funzionalità che utilizzano gesti a più punti o basati sul percorso possono essere azionate con un singolo punto senza un gesto basato sul percorso, a meno che non sia essenziale.”
Significa che: funzioni che richiedono gesti complessi (pinch per zoom, swipe, disegno di forme) devono avere un’alternativa con gesti semplici (singolo tocco o click). Chi ha difficoltà motorie o usa dispositivi assistivi può non essere in grado di fare uno swipe preciso.
2.5.2 Annullamento del puntamento
“Per le funzionalità che possono essere operate utilizzando un singolo puntatore, almeno una delle seguenti è vera: l’evento down non esegue la funzione, è possibile abortire/annullare la funzione, oppure l’up annulla e un’azione successiva completa la funzione.”
Significa che: le azioni attivate con un singolo click o tocco devono partire al rilascio (up), non alla pressione (down). E deve essere possibile annullare spostando il dito/mouse fuori dall’elemento prima di rilasciare. Protegge da click accidentali, soprattutto su touch.
2.5.3 Etichetta nel nome
“Per i componenti dell’interfaccia utente con etichette che includono testo o immagini di testo, il nome accessibile contiene il testo che è presentato visivamente.”
Significa che: se un pulsante mostra scritto “Cerca”, anche il nome accessibile (quello che leggono i lettori di schermo o riconoscono i comandi vocali) deve contenere la parola “Cerca”. Altrimenti chi dice “clicca Cerca” al comando vocale non riesce ad attivarlo perché internamente il pulsante si chiama, che so, “search-btn-main”
2.5.4 Attuazione tramite movimento
“Le funzionalità che possono essere operate dal movimento del dispositivo o da quello dell’utente possono essere operate anche dai componenti dell’interfaccia utente, e la risposta al movimento può essere disabilitata.”
Significa che: funzioni attivate muovendo il dispositivo (es. scuotere per annullare, inclinare per scorrere) devono avere un’alternativa con pulsanti, e la risposta al movimento deve poter essere disattivata. Non tutti possono scuotere o inclinare lo smartphone con precisione (o volontà).
3. Comprensibile
3.1.1 Lingua della pagina
“La lingua predefinita di ciascuna pagina Web può essere determinata programmaticamente”
Significa che: la lingua principale della pagina deve essere dichiarata nel codice (es. <html lang="it">). Così i lettori di schermo usano la pronuncia corretta. Senza questa indicazione, uno screen reader italiano potrebbe leggere un testo inglese con accento italiano, e viceversa – risultato: incomprensibile.
3.2.1 Al focus
“Quando un qualsiasi componente riceve il focus, non avvia un cambio di contesto.”
Significa che: quando un elemento viene selezionato (col Tab o col click), non deve succedere nulla di inaspettato: non deve aprirsi una nuova finestra, non deve essere inviato un modulo, non deve cambiare pagina. Il focus è solo “sto qui guardando”, non “sto eseguendo”.
3.2.2 All’input
“Modificare l’impostazione di un qualsiasi componente dell’interfaccia utente non causa automaticamente un cambio di contesto, a meno che l’utente non sia stato avvertito del comportamento prima dell’utilizzo del componente.“
Significa che: modificare un’impostazione o inserire dati non deve causare cambiamenti automatici inaspettati (invio del modulo, cambio pagina, refresh). L’utente deve confermare esplicitamente le azioni importanti, ad esempio cliccando un pulsante “Invia”.
3.3.1 Identificazione degli errori
“Se viene rilevato automaticamente un errore di input, l’elemento in errore viene identificato e l’errore viene descritto all’utente tramite testo.”
Significa che: se l’utente sbaglia a compilare un modulo, l’errore deve essere indicato chiaramente con un testo (non solo un bordo rosso). Esempio: “L’indirizzo email non è valido” scritto esplicitamente accanto al campo.
3.3.2 Etichette o istruzioni
“Sono fornite etichette o istruzioni quando il contenuto richiede inserimento di dati da parte dell’utente.”
Significa che: ogni campo di un modulo deve avere un’etichetta chiara che spieghi cosa inserire. E se ci sono requisiti particolari (formato data, lunghezza minima della password, formato del telefono), vanno indicati prima che l’utente compili, non solo dopo un errore.
4. Robusto
4.1.1 Analisi sintattica (parsing)
“Nei contenuti implementati utilizzando linguaggi di marcatura, gli elementi hanno tag di inizio e fine completi, sono annidati secondo le specifiche, non contengono attributi duplicati e gli ID sono univoci.“
Significa che: il codice HTML deve essere scritto correttamente: tag aperti e chiusi dove serve, elementi annidati nel modo giusto, niente ID duplicati.
(Nota: questo criterio è stato segnato come “obsoleto” nelle WCAG 2.2, perché i browser moderni gestiscono da soli gli errori. Ma per la normativa attuale, che si basa sulle WCAG 2.1, va comunque rispettato).
4.1.2 Nome, ruolo, valore
“Per tutti i componenti dell’interfaccia utente, il nome, il ruolo e il valore possono essere determinati programmaticamente, e le notifiche dei cambiamenti a questi elementi sono disponibili alle tecnologie assistive.”
Significa che: ogni elemento interattivo (pulsanti, campi, menu, slider, checkbox, tab…) deve:
– avere un nome che le tecnologie assistive possono leggere;
– avere un ruolo che indica che cos’è (es. “pulsante”, “link”, “casella di testo”);
– comunicare il valore o lo stato attuale (es. “selezionato”, “espanso”, “checked”).
È il criterio più “tecnico” ma anche uno dei più importanti: senza questi attributi corretti, chi usa uno screen reader non capisce nemmeno che su un’icona si può cliccare.
Ricapitolando: i 30 criteri A + i 21 criteri AA
Per essere conformi è indispensabile rispettare sia i criteri sopradescritti del livello A, che rappresentano la base dell’accessibilità, ma anche il livello AA (che prevede ulteriori 21 punti).
Per avere il quadro completo clicca qui per leggere cosa prevedono i criteri WCAG 2.1 Livello AA.
Non si può adeguare il sito solo al livello A, perché ti mancherebbe un gradino.
Per costruire un sito accessibile e a norma, quindi, occorre assicurarsi che tutti i requisiti A + AA siano correttamente implementati.
Sviluppare in modo accessibile, anche se non si rientra nelle categorie obbligate per legge, è la strada verso un web più inclusivo, usabile e aperto davvero a tutte le persone.
Inoltre, se fatta bene, migliora l’esperienza di chiunque navighi il tuo sito, nessuno escluso.
Domande frequenti
Sì, ne esistono diversi.
Personalmente utilizzo Silktide, un’estensione gratuita per browser che permette di fare i controlli primari e gran parte dell’audit di accessibilità in modo rapido e chiaro. È un ottimo punto di partenza, soprattutto se ti stai avvicinando ora al tema.
Esistono poi strumenti a uso professionale più avanzati (come Axe DevTools, WAVE, Lighthouse integrato in Chrome), ma per una prima verifica Silktide fa egregiamente il suo mestiere.
Importante: nessun tool automatico rileva il 100% dei problemi di accessibilità. Molti criteri (soprattutto quelli legati alla comprensibilità e all’esperienza reale con tecnologie assistive) richiedono una verifica manuale o il confronto con utenti reali.
No. È un equivoco molto comune: il livello A non basta, occorre rispettare anche i 21 criteri previsti dal livello AA.
I livelli di conformità WCAG funzionano a gradini cumulativi:
Livello A → i requisiti base, senza i quali il sito presenta barriere gravi
Livello AA → requisiti intermedi, che si aggiungono a quelli del livello A
Livello AAA → requisiti avanzati, che si aggiungono ai precedenti
Quando la normativa chiede la conformità al livello AA, in realtà intende A + AA. Non si può “saltare il gradino” e adeguare solo i 30 criteri del livello A ignorando i 21 criteri del livello AA.
Dipende da quanto sei a tuo agio nel mettere mano al sito.
Sulle cose più basilari puoi sicuramente intervenire in autonomia, ad esempio:
sistemare i contrasti di colore tra testo e sfondo;
aggiungere i sottotitoli ai video;
scrivere alt text descrittivi per le immagini;
rendere più chiari i testi dei bottoni (no “clicca qui”, sì “prenota consulenza”);
controllare che i titoli seguano una gerarchia logica (H1, H2, H3…).
Per tutto il resto e per essere davvero a norma ti conviene rivolgerti a chi padroneggia la materia e può fare da ponte tra la normativa e il codice. Perché un conto è sapere cosa va fatto, un altro è sapere come tradurlo concretamente in HTML, CSS e nelle logiche del tuo CMS.
Se hai un sito in WordPress, scrivimi: valutiamo insieme lo stato attuale e capiamo se e come posso fare al caso tuo.
In caso di mancato adeguamento sono previste sanzioni amministrative, oltre al rischio di segnalazioni da parte degli utenti.
Ma al di là delle sanzioni, un sito non accessibile significa tagliare fuori una fetta importante di potenziali clienti e utenti.
Dipende dallo stato di partenza.
Se il sito è deve essere realizzato ex novo, la progettazione sarà studiata per essere accessibile fin dall’inizio, il costo aggiuntivo è abbattuto.
Se invece si tratta di adeguare un sito esistente, il costo varia in base alla complessità, al numero di pagine e a quanto lavoro serve su codice, contenuti e design.
Il mio consiglio è sempre di partire da un audit per capire lo stato attuale, poi pianificare gli interventi per priorità.
No. Nessuna piattaforma ti rende automaticamente conforme. Temi, plugin, contenuti caricati (immagini senza alt, PDF non accessibili, video senza sottotitoli…) e personalizzazioni possono creare barriere anche su piattaforme nate con buone intenzioni in ambito accessibilità.
La conformità dipende sempre da come viene costruito e gestito il sito, non solo dalla tecnologia scelta.
L’accessibilità non è un traguardo, ma un processo continuo. Ti consiglio di:
verificare l’accessibilità ogni volta che aggiungi nuove funzionalità o pagine;
formare chi carica contenuti (redattori, marketing) affinché rispetti le buone pratiche ogni giorno (alt text, titoli, contrasti, ecc.);
fare un audit completo almeno una volta l’anno, se hai cambiato i contenuti presenti nel tuo sito.
Per gli enti pubblici è obbligatoria da tempo. Per i privati soggetti all’EAA, è buona pratica pubblicare una dichiarazione di accessibilità che indichi il livello di conformità raggiunto, eventuali contenuti non ancora accessibili e un canale di contatto per segnalare problemi.
Sì. I PDF sono contenuti a tutti gli effetti e devono rispettare i criteri di accessibilità: struttura semantica corretta, testo selezionabile (no scansioni di immagini), alt text sulle immagini, ordine di lettura logico, tag corretti.
Se hai molti PDF sul sito, valuta se sia il caso di convertirli in pagine HTML: quasi sempre è la soluzione più accessibile e anche più SEO-friendly.
Verifica sempre che il tema dichiari di essere conforme alle WCAG 2.1 AA. Attenzione però: “accessibility-ready” non significa automaticamente conforme. I temi forniscono una base, ma le personalizzazioni, i colori scelti, i contenuti caricati e i plugin aggiunti possono comunque compromettere l’accessibilità.
No. Come ho spiegato nell’articolo, gli overlay di accessibilità sono spesso soluzioni di facciata che non risolvono davvero i problemi per chi utilizza tecnologie assistive. In alcuni casi possono addirittura peggiorare l’esperienza.
La conformità vera si ottiene lavorando sul codice, sul design e sui contenuti – non applicando un cerotto sopra.
