L’accessibilità dei siti web significa avere un sito che le persone con disabilità possono percepire, usare e comprendere, e con l’European Accessibility Act è oggi un obbligo di legge per molte aziende che vendono ai consumatori nell’UE. In pratica l’atto rimanda alla norma armonizzata EN 301 549, che a sua volta si basa sulle Web Content Accessibility Guidelines del W3C al livello AA. Questa guida spiega chi è coinvolto e da quando, cosa chiedono le norme, gli errori che troviamo più spesso e come correggerli, un processo di audit numerato, la dichiarazione di accessibilità e come funzionano i controlli negli Stati membri.
Ultimo aggiornamento: 27 ottobre 2026.
Cos’è l’European Accessibility Act?
L’European Accessibility Act è la direttiva (UE) 2019/882, adottata il 17 aprile 2019. Stabilisce requisiti di accessibilità comuni per un elenco di prodotti e servizi in tutto il mercato unico europeo, così un’azienda rispetta un solo insieme di regole invece di uno diverso in ogni paese.
Trattandosi di una direttiva, ogni Stato membro ha dovuto recepirla nella legge nazionale entro il 28 giugno 2022 e applicare quelle norme dal 28 giugno 2025. Dal 28 giugno 2025 l’European Accessibility Act si applica ai prodotti coinvolti immessi sul mercato e ai servizi coinvolti forniti ai consumatori. Ciò che un’azienda deve fare concretamente è stabilito da ciascuna legge nazionale, che segue da vicino la direttiva ma aggiunge le proprie autorità di controllo e le proprie sanzioni.
L’atto si affianca a un testo più vecchio, la direttiva sull’accessibilità del web, che riguarda i siti web e le app degli enti pubblici. È l’European Accessibility Act a raggiungere le aziende private.
In sintesi: se vendi determinati servizi ai consumatori nell’UE, il tuo sito web e la tua app devono essere accessibili. Il metro di misura è la EN 301 549, che usa le WCAG al livello AA. Le microimprese che forniscono servizi sono esentate. Ogni paese applica la propria versione delle regole.
In Odduel, agenzia creativa e tecnologica con sedi a Barcellona e São Paulo, l’accessibilità entra in ogni sito dal primo wireframe: è così che definiamo il perimetro dei nostri progetti di realizzazione siti web. Il resto di questa guida è ciò che diciamo ai clienti che ci chiedono a che punto sono.
Chi deve rispettare l’EAA?
L’atto riguarda prodotti e servizi elencati, non tutti i siti web. Tra i servizi, quelli che toccano la maggior parte dei siti e delle app sono:
- Servizi di e-commerce: qualsiasi servizio venduto a distanza ai consumatori tramite un sito web o un’app mobile. Per questo la maggior parte dei negozi online rientra nell’ambito di applicazione.
- Servizi bancari per i consumatori, compresi i siti web e le app con cui vengono offerti.
- E-book e i software usati per leggerli.
- Servizi di comunicazione elettronica e servizi che danno accesso a media audiovisivi.
- Elementi dei servizi di trasporto passeggeri aereo, in autobus, ferroviario e per vie navigabili: siti web, app, biglietti elettronici e informazioni di viaggio in tempo reale.
Sul fronte dei prodotti rientrano computer, smartphone, lettori di e-book, terminali di pagamento, sportelli bancomat e biglietterie automatiche. Se li produci o li importi, l’atto si applica all’hardware e al suo software, non solo a un sito web.
Un’azienda fuori dall’UE non è fuori portata: conta che il servizio sia offerto ai consumatori nell’UE. Un’azienda che vende solo ad altre aziende, senza servizi rivolti ai consumatori, in genere è fuori dall’ambito dell’e-commerce; molti siti però servono entrambi, e la parte rivolta ai consumatori allora è coinvolta.
L’esenzione per le microimprese
La direttiva esenta le microimprese che forniscono servizi. Una microimpresa, secondo la definizione della direttiva, ha meno di dieci dipendenti e un fatturato annuo o un totale di bilancio sotto una soglia bassa fissata nel testo. Un piccolo studio che vende servizi online può quindi essere fuori dall’obbligo.
Due aspetti sfuggono spesso. L’esenzione vale solo per i servizi: una microimpresa che produce o vende prodotti coinvolti deve comunque rispettare i requisiti per i prodotti, con meno documentazione. Ed essere esenti oggi non rende una buona idea un sito non accessibile, perché un’azienda che supera la soglia rientra nell’ambito, e i clienti con disabilità sono clienti in ogni caso.
Contenuti e contratti con un trattamento particolare
La direttiva lascia fuori dai requisiti alcuni contenuti: audio e video preregistrati pubblicati prima del 28 giugno 2025, documenti d’ufficio pubblicati prima di quella data, contenuti d’archivio non più modificati, mappe online le cui informazioni essenziali sono offerte in modo accessibile e contenuti di terzi che l’azienda non finanzia né controlla. I contratti di servizio stipulati prima del 28 giugno 2025 possono proseguire invariati fino alla scadenza, per un massimo di cinque anni.
Un’azienda può anche sostenere che un requisito imporrebbe un onere sproporzionato o modificherebbe in modo sostanziale il servizio. Questa valutazione va fatta e documentata secondo i criteri della direttiva, e le autorità possono chiedere di vederla. Non è una via d’uscita generale.
Quale standard si applica?
La direttiva descrive l’accessibilità in termini funzionali: i contenuti devono essere percepibili, utilizzabili, comprensibili e robusti. Per trasformare questi principi in test, l’UE si affida a norme armonizzate, e per siti web e app quella rilevante è la EN 301 549, la norma europea sull’accessibilità delle tecnologie dell’informazione e della comunicazione. Rispettare una norma armonizzata il cui riferimento è pubblicato per l’atto dà una presunzione di conformità.
Per i contenuti web, la EN 301 549 incorpora i criteri di successo delle Web Content Accessibility Guidelines del W3C ai livelli A e AA. La versione attuale della norma si basa sulle WCAG 2.1. Le più recenti WCAG 2.2, raccomandazione del W3C da ottobre 2023, mantengono i criteri della 2.1 (tranne un criterio obsoleto sul parsing) e ne aggiungono altri nove, sei dei quali ai livelli A e AA.
Il nostro consiglio è progettare e testare secondo le WCAG 2.2 AA. Un sito che le rispetta soddisfa anche i criteri 2.1 che la norma verifica oggi, ed è pronto per la prossima revisione della EN 301 549 senza bisogno di un secondo intervento.
| WCAG 2.1 AA | WCAG 2.2 AA | |
|---|---|---|
| Stato | Raccomandazione W3C, 2018 | Raccomandazione W3C, ottobre 2023 |
| Usata oggi dalla EN 301 549 | Sì | Non ancora |
| Focus visibile e non nascosto | Il focus deve essere visibile | Il focus non deve nemmeno essere del tutto coperto da barre fisse o banner |
| Controlli piccoli | Nessuna dimensione minima al livello AA | Target di almeno 24 × 24 pixel CSS, o spaziatura sufficiente |
| Azioni di trascinamento | Non previsto al livello AA | Un’alternativa al trascinamento con un solo puntatore |
| Moduli | Etichette e aiuto sugli errori | Inoltre, nessuna richiesta di ridigitare informazioni già fornite |
| Accesso | Non previsto | Nessun test di memoria o rompicapo senza un’alternativa |
| Aiuto | Non previsto | Opzioni di aiuto nello stesso punto su ogni pagina |
Cosa significa WCAG 2.2 AA in pratica?
Le WCAG sono scritte come criteri di successo verificabili, raggruppati sotto quattro principi. Tradotto in ciò che vive un visitatore, il livello AA chiede più o meno quanto segue:
- Percepibile: le immagini hanno alternative testuali, i video hanno i sottotitoli, il testo ha un contrasto sufficiente con lo sfondo (4,5 a 1 per il testo corrente, 3 a 1 per il testo grande e per gli elementi dell’interfaccia) e la pagina funziona ancora quando il testo è ingrandito al 200% o lo schermo è stretto.
- Utilizzabile: tutto si può fare con la sola tastiera, il focus è sempre visibile, nulla lampeggia in modo pericoloso, i contenuti in movimento si possono mettere in pausa e i visitatori hanno tempo sufficiente per agire.
- Comprensibile: la pagina dichiara la propria lingua, la navigazione si comporta in modo coerente, i moduli hanno etichette e spiegano gli errori, e nulla cambia contesto senza preavviso.
- Robusto: il codice espone correttamente nomi, ruoli e stati alle tecnologie assistive come gli screen reader, e i messaggi di stato vengono annunciati.
Niente di tutto questo impone un sito spoglio o noioso. I siti che realizziamo hanno movimento, caratteri grandi e colori decisi; ciò che cambia è che il movimento rispetta l’impostazione di riduzione del movimento del visitatore, il colore non porta mai significato da solo e ogni interazione ha un percorso da tastiera. L’accessibilità funziona meglio quando fa parte delle regole dell’identità: un documento di brand guidelines che indica coppie di colori accessibili evita discussioni in seguito.
Quali sono gli errori di accessibilità più comuni e come si correggono?
La maggior parte degli audit trova sempre gli stessi difetti. Nascono da decisioni di design prese senza tenere conto delle regole e da componenti copiati da un progetto all’altro. La tabella elenca quelli che vediamo più spesso e come si correggono.
| Errore | Chi ne è colpito | Criterio WCAG | Rimedio |
|---|---|---|---|
| Testo a basso contrasto, soprattutto grigio su bianco o bianco su colori accesi | Ipovedenti, visitatori più anziani, chiunque sia al sole | 1.4.3 Contrasto (minimo) | Definire coppie di colori accessibili nei design token e misurare ogni nuova coppia |
| Immagini senza un testo alternativo utile | Chi usa uno screen reader | 1.1.1 Contenuti non testuali | Descrivere le immagini informative; dare a quelle decorative un alt vuoto |
| Campi dei moduli senza etichetta, o con il placeholder come unica etichetta | Chi usa screen reader e comandi vocali | 1.3.1, 3.3.2, 4.1.2 | Un’etichetta visibile legata a ogni campo; errori scritti accanto al campo |
| Controlli che funzionano solo con il mouse | Chi usa tastiera e sensori | 2.1.1 Tastiera | Usare veri pulsanti e link; testare ogni percorso con la sola tastiera |
| Contorno del focus rimosso o nascosto da un header fisso | Chi usa la tastiera | 2.4.7, 2.4.11 | Uno stile di focus marcato; scroll padding perché il focus non sia mai coperto |
| Titoli usati per la dimensione, non per la struttura | Chi usa uno screen reader | 1.3.1 Informazioni e correlazioni | Un solo H1, titoli in ordine, stili applicati con le classi |
| Link che dicono solo «clicca qui» o «leggi di più» | Chi usa uno screen reader | 2.4.4 Scopo del link | Testo del link che nomina la destinazione |
| Video senza sottotitoli | Visitatori sordi e con ipoacusia | 1.2.2 Sottotitoli | Sottotitoli per ogni video parlato; trascrizioni per l’audio |
| Banner dei cookie e pop-up che intrappolano o saltano il focus | Chi usa tastiera e screen reader | 2.1.2, 2.4.3 | Portare il focus nella finestra di dialogo, tenerlo lì, restituirlo alla chiusura |
| Pulsanti a icona minuscoli e vicini | Disabilità motorie, chi usa il telefono | 2.5.8 Dimensione del target (minima) | Target di almeno 24 × 24 pixel CSS, o spazio intorno |
| Animazioni che non si possono fermare | Disturbi vestibolari, difficoltà di attenzione | 2.2.2 Pausa, stop, nascondi | Un controllo di pausa; rispettare l’impostazione di riduzione del movimento |
Gli strumenti automatici ne individuano alcuni, come testo alternativo mancante, basso contrasto ed etichette assenti. Non sanno dire se un testo alternativo ha senso, se l’ordine della tastiera è logico o se un messaggio di errore aiuta. Per questo il processo che segue unisce strumenti e test manuali.
Come verificare e correggere l’accessibilità di un sito web?
Un audit è utile solo se si chiude con delle correzioni e resta valido dopo il rilascio successivo. Questo è il processo che seguiamo, che il sito sia nostro o ereditato.
- Fissa l’obiettivo e il perimetro. Concorda le WCAG 2.2 AA ed elenca i modelli e i percorsi da testare: home, una pagina di contenuto, una pagina prodotto o servizio, la ricerca, il carrello e il checkout, l’accesso, i moduli di contatto e il banner dei cookie. Sulla maggior parte dei siti una dozzina di modelli copre quasi tutte le pagine.
- Esegui i controlli automatici. Usa un motore di regole riconosciuto su ogni modello e in ogni versione linguistica. Registra i problemi per criterio, non per pagina, perché un difetto di un componente si ripete ovunque.
- Testa con la sola tastiera. Completa ogni percorso chiave senza mouse: raggiungi ogni controllo, vedi sempre il focus, apri e chiudi menu e finestre di dialogo, invia i moduli con errori e senza.
- Testa con uno screen reader e con lo zoom. Ascolta i percorsi principali con almeno uno screen reader su desktop e uno su telefono, poi ingrandisci il testo al 200% e guarda la pagina a larghezza ridotta. Controlla titoli, landmark, etichette e annunci.
- Rivedi contenuti e media. Controlla testi alternativi, formulazione dei link, sottotitoli, documenti scaricabili e linguaggio semplice in istruzioni ed errori.
- Dai le priorità in base all’impatto. Correggi prima ciò che blocca un’attività (un checkout che non si completa da tastiera), poi ciò che la rende difficile, poi il resto. La maggior parte delle correzioni va fatta nei componenti condivisi e nei design token, così una modifica sistema molte pagine.
- Correggi, poi ritesta. Ripeti gli stessi test sui modelli corretti e conserva i risultati con le date, così puoi mostrare cosa è stato trovato e quando è stato corretto.
- Pubblica la dichiarazione e inseriscila nel processo di rilascio. Scrivi la dichiarazione di accessibilità (più avanti), poi aggiungi i controlli di accessibilità a ogni rilascio, accanto al resto della tua checklist di lancio del sito web.
I test con persone con disabilità aggiungono ciò che nessuna checklist può dare: se il sito è davvero piacevole da usare. Se il budget lo consente, un breve ciclo di sessioni sui percorsi principali vale più di un’altra scansione automatica.
L’accessibilità si intreccia anche con la manutenzione. Plugin e temi aggiornati senza verifica possono rompere la gestione del focus o le etichette, quindi la stessa disciplina che tiene al sicuro un sito, descritta nella nostra guida alla sicurezza WordPress, lo mantiene accessibile.
Serve una dichiarazione di accessibilità?
Con l’European Accessibility Act i fornitori di servizi devono rendere disponibili informazioni su come il loro servizio rispetta i requisiti di accessibilità, nelle condizioni generali o in un altro punto facile da trovare, e in un formato accessibile. La maggior parte delle aziende lo fa con una dichiarazione di accessibilità collegata dal footer di ogni pagina.
Una dichiarazione chiara indica:
- la norma a cui miri (WCAG 2.2 AA, tramite la EN 301 549) e fino a che punto il sito la rispetta;
- le lacune note, con il motivo e una data per la correzione, se ce l’hai;
- i contenuti esclusi dai requisiti e ogni onere sproporzionato documentato;
- come e quando il sito è stato valutato l’ultima volta;
- un contatto con cui i visitatori possono segnalare un problema o chiedere un contenuto in un altro formato, e in quanto tempo rispondi;
- dove un visitatore può presentare reclamo se la risposta non lo soddisfa, che dipende dalla tua autorità nazionale.
Scrivila in modo semplice e tienila aggiornata. Una dichiarazione che dichiara piena conformità su un sito con difetti evidenti fa più danni di una dichiarazione onesta che elenca ciò che si sta ancora correggendo.
Come si applica l’EAA e quali sono le sanzioni?
Ogni Stato membro nomina le proprie autorità di vigilanza del mercato e stabilisce le proprie sanzioni, che la direttiva richiede siano efficaci, proporzionate e dissuasive. Autorità, procedure ed entità delle sanzioni quindi variano da paese a paese, e alcune leggi nazionali consentono di agire anche alle associazioni dei consumatori o ai singoli.
Per un’azienda che vende in più paesi dell’UE, la risposta pratica è rispettare ovunque la norma comune invece di seguire ogni variante nazionale. Se ti servono le regole esatte sulle sanzioni di un mercato, leggi la legge di recepimento di quel paese o chiedi a un avvocato che vi esercita: le cifre sono nazionali, e qui non le riportiamo.
Ciò che le autorità possono chiedere, in generale, sono le prove: la norma che hai seguito, i risultati dei test, la dichiarazione e l’eventuale valutazione dell’onere sproporzionato. La documentazione del processo descritto sopra è quella prova.
Le domande più comuni
L’European Accessibility Act si applica al mio sito web?
Si applica se il tuo sito web o la tua app offre un servizio coinvolto ai consumatori nell’UE, come e-commerce, servizi bancari al consumo, e-book, comunicazioni elettroniche o informazioni sul trasporto passeggeri. Un sito aziendale puramente informativo può essere fuori ambito, e le microimprese che forniscono servizi sono esentate. Verifica con l’elenco della direttiva e con la legge di recepimento del tuo paese.
Le WCAG 2.2 AA sono obbligatorie per legge?
La legge richiede l’accessibilità, e la norma armonizzata EN 301 549 dà una presunzione di conformità. Per i contenuti web quella norma usa oggi le WCAG 2.1 AA. Le WCAG 2.2 AA includono quei criteri e ne aggiungono alcuni, quindi un sito costruito secondo le WCAG 2.2 AA rispetta la norma attuale ed è pronto per la sua prossima revisione.
Un overlay o un plugin di accessibilità può rendere il mio sito conforme?
No. Overlay e barre degli strumenti cambiano come una pagina appare o viene letta, ma non correggono il codice, le etichette, l’ordine della tastiera o i contenuti sottostanti, e alcuni interferiscono con gli screen reader che i visitatori già usano. Un sito conforme richiede modelli e componenti corretti. I plugin possono aiutare con i controlli durante la modifica, ma non sostituiscono il lavoro.
Quanto dura un audit di accessibilità di un sito web?
Dipende dal numero di modelli e di percorsi più che dal numero di pagine, perché la maggior parte dei difetti sta nei componenti condivisi. Un sito piccolo con pochi modelli si verifica in fretta; un grande negozio online con account, ricerca e checkout richiede più tempo. Un piano a prezzo fisso arriva dopo una breve analisi del sito e dei suoi percorsi chiave.
Cosa succede se il mio sito non è accessibile?
Rischi un intervento dell’autorità nazionale di vigilanza del mercato, che può imporre correzioni e sanzioni secondo la legge nazionale, e in alcuni paesi reclami da parte di consumatori o associazioni. Altrettanto importante, perdi i clienti che non riescono a completare un acquisto. Correggi prima i problemi bloccanti e pubblica una dichiarazione onesta mentre completi il resto.
Se non sai se il tuo sito rispetta l’European Accessibility Act, parti da un audit dei modelli e dei percorsi che contano di più, poi correggi i componenti condivisi che causano la maggior parte dei difetti. Realizziamo siti accessibili dal primo wireframe e sistemiamo quelli ereditati nell’ambito dei nostri progetti di realizzazione siti web. Parlaci del tuo sito e ti diremo con chiarezza a che punto è.
Per approfondire: Checklist per un audit UX: cosa controllare e come condurlo in sette passaggi.
