Per anni l’accessibilità è stata trattata come quella cosa importante che qualcuno avrebbe controllato alla fine. Di solito lo sviluppatore. Possibilmente il venerdì prima del rilascio, con un plugin e una certa fiducia nella provvidenza.
L’European Accessibility Act non inventa l’accessibilità, ma cambia il tono della conversazione. In Italia è stato recepito dal D.Lgs. 82/2022 e le sue disposizioni si applicano dal 28 giugno 2025, fatti salvi i regimi transitori previsti dal decreto.
Per noi designer la questione è molto concreta: contrasto, gerarchia, focus, moduli, errori e modalità di navigazione prendono forma prima in Figma e solo dopo nel codice. Se nascono male, difficilmente diventano accessibili per magia durante lo sviluppo.
Questa guida prova a fare quello che abbiamo già fatto con l’AI Act: togliere la legge dal PDF e portarla dentro gli schermi. Con meno latinorum possibile e una checklist verificabile punto per punto.
1. Prima domanda: questa legge riguarda il mio prodotto?
Non necessariamente. L’EAA non si applica a qualsiasi sito, app o software solo perché vive su uno schermo. Riguarda categorie precise di prodotti e servizi offerti ai consumatori: e-commerce, servizi bancari, e-book, comunicazioni elettroniche, accesso ai media audiovisivi e alcuni servizi digitali legati al trasporto passeggeri. Sul fronte dei prodotti include, tra gli altri, computer, smartphone, terminali di pagamento, biglietterie automatiche ed e-reader.
Per “servizio di commercio elettronico” si intende un servizio finalizzato alla conclusione a distanza di un contratto con un consumatore: non qualsiasi sito commerciale rientra quindi automaticamente nel perimetro.
È comunque un cambio di perimetro importante. La Legge Stanca continua a regolare la Pubblica Amministrazione e alcuni grandi soggetti privati; l’EAA porta requisiti di accessibilità dentro molte esperienze B2C che fino a ieri potevano considerare solo una scelta virtuosa. Virtuosa, quindi rimandabile.
Le eccezioni non sono un pulsante “salta”
Una microimpresa occupa meno di 10 persone e ha un fatturato annuo oppure un totale di bilancio annuo non superiore a 2 milioni di euro. L’esenzione riguarda le microimprese che forniscono servizi, non gli operatori che producono o distribuiscono prodotti coperti dal decreto.
Sono previste anche deroghe quando l’adeguamento comporta una modifica sostanziale del servizio o un onere sproporzionato. Ma vanno valutate e documentate: “costava troppo” scritto in una mail non è un’analisi di proporzionalità.
In Italia il D.Lgs. 82/2022 prevede regimi sanzionatori diversi in base al soggetto e alla violazione. Per gli operatori economici le sanzioni amministrative possono arrivare, in generale, da 5.000 a 40.000 euro. Per i grandi soggetti privati già ricompresi nella Legge Stanca, la mancata ottemperanza alla diffida AgID può comportare una sanzione fino al 5% del fatturato.
EAA, EN 301 549 e WCAG: legge, riferimento tecnico e target progettuale
- Legge: l’EAA e il decreto italiano definiscono gli obblighi e i requisiti funzionali.
- Riferimento tecnico corrente: le Linee guida AgID 2026 utilizzano nelle schede di controllo la EN 301 549 v3.2.1 e le WCAG 2.1.
- Target progettuale: le WCAG 2.2 sono un riferimento più aggiornato e utile per designer e developer, ma i criteri aggiunti nella versione 2.2 non coincidono automaticamente con il minimo tecnico-normativo oggi applicabile.
Le WCAG restano uno strumento operativo fondamentale, ma non sono un lasciapassare automatico. Superare una checklist tecnica non esaurisce l’obbligo legale: contano anche le informazioni fornite alle persone, i servizi di assistenza, la documentazione e il mantenimento dell’accessibilità nel tempo.
2. Dalla legge allo schermo
Accessibilità non significa progettare una versione parallela e un po’ più triste del prodotto per una minoranza astratta. Significa progettare un’unica esperienza che possa essere vista, ascoltata da uno screen reader, ingrandita, navigata da tastiera, usata con un comando vocale o toccata con una precisione ridotta.
Le domande da portare in design review sono quattro:
- Le informazioni restano comprensibili anche senza colore, immagini o audio?
- Ogni funzione può essere raggiunta e usata senza mouse?
- L’interfaccia mantiene senso e gerarchia quando viene ingrandita o letta in sequenza?
- Errori, cambiamenti di stato e istruzioni vengono comunicati in modo chiaro?
Questi aspetti lavorano insieme. Un form accessibile richiede etichette o istruzioni sufficienti, ordine di focus coerente, errori testuali collegati ai campi e annunci corretti alle tecnologie assistive. Mantenere una label visibile e persistente è una buona pratica; il solo placeholder non la sostituisce. Sistemare il contrasto del bordo rosso e dichiarare vittoria è un po’ poco.
Colore e contrasto
Obiettivo di accessibilità: testi, componenti e informazioni devono restare percepibili anche da persone con ipovisione o difficoltà nella percezione dei colori.
Impatto sul design: il testo normale deve raggiungere un contrasto di almeno 4,5:1; il testo grande almeno 3:1. Anche bordi, icone e stati necessari a comprendere o usare un componente richiedono almeno 3:1 rispetto ai colori adiacenti. E il colore non può essere l’unico segnale: a un bordo rosso va affiancato un messaggio, un’icona o un’altra indicazione esplicita.
Tipografia, zoom e reflow
Obiettivo di accessibilità: il contenuto deve poter essere ingrandito e adattarsi allo spazio disponibile senza perdere informazioni o funzionalità.
Impatto sul design: evitare layout rigidi, altezze bloccate e testi trasformati in immagini. Il testo deve poter essere ingrandito fino al 200%; il contenuto a scorrimento verticale deve funzionare a una larghezza equivalente a 320 CSS pixel senza richiedere scorrimento orizzontale, salvo i contenuti per cui una disposizione bidimensionale è essenziale. Una tabella complessa può esserlo. Una hero con il titolo tagliato, no.
Navigazione da tastiera e focus
Obiettivo di accessibilità: tutte le funzioni devono essere utilizzabili anche senza un dispositivo di puntamento e l’utente deve sapere dove si trova.
Impatto sul design: l’ordine di focus deve seguire la logica del contenuto, non soltanto la sua disposizione visiva. Ogni componente interattivo deve avere un indicatore di focus chiaramente visibile e il componente focalizzato non deve essere completamente nascosto da header sticky, cookie banner o overlay. Idealmente, nessuna sua parte viene coperta. Rimuovere outline: none senza progettare un’alternativa non rende l’interfaccia più elegante. La rende semplicemente inutilizzabile per qualcuno.
Form, errori e feedback
Obiettivo di accessibilità: campi, istruzioni ed errori devono essere identificabili e comprensibili; quando possibile, l’utente deve poter correggere ciò che non ha funzionato.
Impatto sul design: quando è richiesto un input, il campo deve avere un’etichetta o istruzioni sufficienti. Una label visibile e persistente resta una buona pratica e non viene sostituita dal solo placeholder. Il messaggio di errore deve spiegare cosa è successo e come risolverlo, stare vicino al campo e non affidarsi soltanto al colore. Nei flussi complessi serve spesso un riepilogo iniziale degli errori e una gestione del focus che porti la persona al problema, non a cercarlo come in una caccia al tesoro.
Touch target e alternative di interazione
Obiettivo di accessibilità: i controlli devono poter essere attivati anche da persone con mobilità o precisione ridotte.
Impatto sul design: le WCAG 2.2 introducono un criterio AA che prevede target di almeno 24×24 CSS pixel, oppure sufficiente spazio tra target più piccoli, con alcune eccezioni. Per i controlli principali 44×44 pixel resta una buona pratica. È una distinzione meno sexy di un post “le 10 regole assolute dell’accessibilità”, ma almeno è vera.
Contenuti non testuali e movimento
Obiettivo di accessibilità: le informazioni non testuali devono avere un’alternativa equivalente e i contenuti in movimento non devono ostacolare la lettura o provocare disagio.
Impatto sul design: il ruolo delle immagini va deciso mentre si progetta, non affidato a un alt text generico scritto a valle. Le immagini informative richiedono una descrizione utile, quelle decorative devono essere ignorate dalle tecnologie assistive. Animazioni, carousel e video devono poter essere messi in pausa quando necessario e rispettare le preferenze di riduzione del movimento.
3. Checklist essenziale per la design review
Questa checklist essenziale serve durante design review, handoff e QA. Ogni voce rimanda al criterio tecnico specifico: così possiamo distinguere una prescrizione da una buona pratica senza trasformare ogni opinione di design in legge dello Stato.
Non sostituisce una verifica completa rispetto alle WCAG e alla EN 301 549, né gli obblighi documentali e organizzativi previsti dal D.Lgs. 82/2022.
🔴 Criterio WCAG 2.2 di livello A o AA
🟠 Criterio da verificare in base al contenuto o al contesto
🟡 Best practice, utile ma non prescritta in questi termini
Colore e contenuti visivi
Il testo standard raggiunge un contrasto minimo di 4,5:1.
Testo grande, icone funzionali, bordi e stati dei componenti raggiungono il contrasto richiesto.
Errori, stati e categorie sono riconoscibili anche senza percepire il colore.
Le immagini informative hanno un’alternativa testuale utile; quelle decorative vengono ignorate dallo screen reader.
Tipografia e layout
Il testo può essere ingrandito al 200% senza perdita di contenuto o funzionalità.
Il contenuto a scorrimento verticale funziona a 320 CSS pixel senza richiedere scorrimento orizzontale, salvo i contenuti per cui una disposizione bidimensionale è essenziale.
Titoli, sezioni ed elenchi hanno una gerarchia coerente anche quando vengono letti fuori dal contesto visivo.
La larghezza delle righe, l’interlinea e la spaziatura rendono i testi lunghi leggibili.
Navigazione e interazione
Tutte le azioni sono raggiungibili e utilizzabili da tastiera.
L’ordine di focus segue una sequenza logica e prevedibile.
Il focus è sempre visibile e il componente focalizzato non viene completamente nascosto da elementi sticky o overlay.
Idealmente, nessuna parte del componente focalizzato viene coperta.
I target interattivi rispettano dimensioni o spaziatura minime; i controlli principali sono più generosi.
Gesti complessi, drag e movimenti hanno un’alternativa semplice.
Form, feedback ed errori
Quando è richiesto un input, il campo dispone di un’etichetta o di istruzioni sufficienti.
La label visibile resta persistente e non viene sostituita dal solo placeholder.
Gli errori indicano chiaramente il problema e, quando possibile, come correggerlo.
I messaggi di stato vengono comunicati anche alle tecnologie assistive.
Le operazioni con conseguenze legali, finanziarie o rilevanti sui dati prevedono almeno un meccanismo tra reversibilità, controllo degli errori o revisione e conferma prima dell’invio.
Movimento, audio e tempo
I contenuti in movimento possono essere messi in pausa quando previsto dai criteri applicabili.
Le animazioni rispettano la preferenza
prefers-reduced-motion.Video e audio hanno sottotitoli, alternative o audiodescrizioni quando richiesto.
I limiti di tempo possono essere estesi o disattivati, salvo i casi in cui siano essenziali.
4. Gli strumenti aiutano. Non assolvono
I test automatici trovano errori ricorrenti, ma non possono decidere se un flusso è comprensibile, se l’ordine di focus ha senso o se un alt text descrive davvero ciò che conta. E gli overlay che promettono di rendere accessibile un sito con una riga di codice non sono il mantello dell’invisibilità della compliance.
Nel workflow possiamo combinare:
- plugin come Stark o Able per i controlli preliminari in Figma;
- ARIA Authoring Practices Guide per struttura e comportamento dei pattern interattivi;
- axe-core, Accessibility Insights e Chrome DevTools per controlli automatici e ispezione dell’albero di accessibilità;
- test manuali da tastiera e con screen reader sulle interfacce implementate;
- test con persone con disabilità, soprattutto nei flussi critici.
L’ultimo punto è quello che rovina la festa agli amanti delle scorciatoie: la conformità tecnica è necessaria, ma non garantisce da sola che un prodotto sia usabile. Un audit può dirci che un pulsante ha un nome accessibile. Soltanto una persona può dirci se quel nome ha senso nel contesto.
5. L’accessibilità non è una fase
Il costo vero arriva quando la si verifica a prodotto finito. A quel punto bisogna riaprire il Design System, modificare componenti già sviluppati, riscrivere flussi e litigare con deadline che, naturalmente, non si sono spostate di un millimetro.
Conviene distribuirla lungo tutto il lavoro:
- nella ricerca, includendo persone con capacità e modalità d’uso diverse;
- nei wireframe, definendo struttura, ordine di lettura e navigazione da tastiera;
- nel Design System, progettando stati, contrasto, target e comportamenti accessibili;
- nell’handoff, documentando semantica e interazioni, non soltanto misure e colori;
- nel QA, combinando controlli automatici, test manuali e test con utenti.
Questa è forse la conseguenza più utile della legge: costringe l’accessibilità a uscire dalla checklist finale e a entrare nel processo di progetto, dove avrebbe dovuto stare fin dall’inizio.
Conclusioni
L’European Accessibility Act non trasforma i designer in consulenti legali. Ci ricorda però una cosa scomoda: molte decisioni di conformità prendono forma nell’interfaccia, molto prima che qualcuno apra il codice.
Progettare un prodotto accessibile significa renderlo più chiaro, prevedibile e resistente alle condizioni reali d’uso. Non è un limite creativo, non è una versione speciale e non è la rifinitura che faremo “se resta tempo”. È qualità del design. Solo che adesso rimandarla è diventato un po’ più complicato.
Questa guida nasce da una lettura operativa dell’European Accessibility Act, del D.Lgs. 82/2022 e delle Linee guida AgID 2026, che utilizzano EN 301 549 v3.2.1 e WCAG 2.1 come riferimenti tecnici per le verifiche. La checklist adotta le WCAG 2.2 come target progettuale più aggiornato. Non costituisce consulenza legale: per una valutazione formale di conformità è necessario fare riferimento alle fonti ufficiali e, quando opportuno, a professionisti qualificati. Articolo aggiornato a luglio 2026.