L’introduzione della direttiva europea, European Accessibility Act, conosciuta come EAA, ha sollevato una questione importante: ora siti web, applicazioni e applicativi vari (come i terminali) devono adeguarsi in modo da rendere i propri prodotti e servizi accessibili.
Oggi, però, non parleremo solo della direttiva e delle situazioni in cui si applica, ma cercheremo di fare chiarezza anche in senso più esteso, soprattutto sul tema dell’accessibilità dei siti web. Vedremo quindi di sfatare alcune false credenze (specie sui famosi overlay) e porteremo degli esempi di alcuni dei criteri WCAG a cui fare riferimento.
Table of Contents
Cos’è l’European Accessibility Act
L’European Accessibility Act (EAA) è una direttiva europea, direttiva EU 2019/882, che è volta a stabilire degli obiettivi di accessibilità. Trattandosi di una direttiva, i singoli Stati membri dell’UE possono recepirla con delle norme a livello locale.
Nello specifico in Italia è stato pubblicato il decreto legislativo del 27 maggio 22, n°82 “Attuazione della Direttiva (UE) 2019/882 del Parlamento europeo e del Consiglio, del 17 aprile 2019, sui requisiti di accessibilità dei prodotti e dei servizi”.
A sua volta la direttiva europea si fonda su norme tecniche (come standard a livello europeo). In aggiunta si può anche fare riferimento alle linee guida di AgID disponibili per la consultazione dal 15 maggio 2025.
Tra i riferimenti tecnici è bene sottolineare la presenza delle Web Content Accessibility Guidelines (WCAG) nella versione 2.1. Di cui parleremo in dettaglio più avanti.
Quali imprese e servizi sono interessati dall’EAA
L’European Accessibility Act si applica a servizi e prodotti: da hardware a software fino ad applicazioni e siti web. Puoi trovare tutta la lista consultando direttamente la direttiva, qui per darti un’idea in breve, vediamo alcuni esempi.
Esempi di prodotti e servizi inclusi: servizi di ecommerce, servizi bancari, terminali self service, terminali di pagamento, servizi di trasporto, ebook reader e siti web.
Per quanto riguarda i servizi digitali è importante fare attenzione quando si dà la possibilità di effettuare transazioni online, per questo tra i servizi inclusi risultano esserci ad esempio gli e-commerce.
Definizioni utili da conoscere, come indicate nella direttiva:
PMI (piccole e medie imprese): imprese con meno di 250 dipendenti e fatturato che non supera i 50 milioni di euro oppure con bilancio annuo che non supera i 43 milioni di Euro.
Microimpresa: impresa con meno di 10 dipendenti e che ha un fatturato annuo (o totale di bilancio annuo) che non supera i 2 milioni di euro.
Chi deve rispettare la direttiva?
Solo le microimprese sono escluse dall’obbligo. Gli obblighi riguardano, infatti, le aziende che non rientrano nella definizione di microimprese perché superano i 2 milioni di euro e hanno più di 10 dipendenti.
Per le PMI ci possono essere delle eccezioni. Infatti, nel caso in cui l’applicazione dei requisiti di accessibilità richieda un onere sproporzionato (dal punto di vista finanziario o organizzativo), allora non si è tenuti a conformarsi al requisito. È importante, però, evidenziare come nella direttiva venga sottolineato che:
“Tuttavia, l’operatore economico dovrebbe rendere quanto più possibile accessibile un servizio o un prodotto rientrante nell’ambito di applicazione della presente direttiva applicando tali requisiti nella misura in cui non impongano un onere sproporzionato.”
Infatti, non dimentichiamo che bisognerà riuscire a rendere conto del fatto che la spesa sia sproporzionata e per farlo occorrerà fornire una valutazione documentata e comunicarla ad AgID.
Le date degli obblighi
Le disposizioni della direttiva e, in particolare in Italia, del decreto legislativo 82/2022 hanno effetto a partire dal 28 giugno 2025. Da questa data, quindi, i servizi (e prodotti) che rientrano nell’ambito del decreto devono rispettare i requisiti di accessibilità.
Mentre per servizi e prodotti specifici possono esserci disposizioni transitorie che spostano la data di scadenza più avanti. Ad esempio l’uso dei terminali self-service è consentito fino alla fine della “vita economica utile” degli stessi (ma non oltre vent’anni dalla messa in funzione).
Attenzione alle false informazioni: se stai seguendo l’argomento in varie discussioni, ti sarai imbattuto anche tu in menzioni di una possibile proroga fino al 2030. In realtà basta leggere l’articolo 4.3 delle linee guida Agid per capire come funziona:
“In particolare, fino al 28 giugno 2030 i fornitori di servizi possono continuare a prestare i loro servizi utilizzando prodotti che utilizzavano in modo legittimo prima di tale data per fornire servizi analoghi.”
Si riferisce ai “prodotti” intesi come prodotti fisici come ad esempio terminali e altri hardware oppure prodotti digitali su supporto fisico (ad esempio CD o chiavette USB).
Non c’è quindi nessuna proroga per quanto riguarda i servizi digitali.
Visto che stanno girando diverse informazioni inesatte, ti invitiamo anche a dare un’occhiata anche a questo approfondimento sulle 8 inesattezze sull’accessibilità digitale.
Accessibilità per i siti web
Come dicevamo, l’accessibility act si riferisce a svariati servizi, ma in questo caso ci concentreremo in particolare sull’accessibilità dei siti web.
Parleremo quindi di accessibilità by design, di widget e altri plugin, ma soprattutto dello standard introdotto dalle WCAG (le linee guida che costituiscono la Bibbia per chi vuole interessarsi dell’accessibilità).
Perché si parla di accessibility by design?
La prima considerazione che andrebbe fatta è che l’arrivo di questa direttiva – per quanto venga sempre più utilizzata da qualcuno come sistema per creare allarmismo per spingere a “correre ai ripari” acquistando servizi e tool di sorta – non dovrebbe essere visto come un evento negativo.
Al centro della questione, infatti, non dovrebbe tanto esserci la domanda “Come faccio a mettere il sito a norma per evitare le sanzioni?“, ma questo argomento dovrebbe farci chiedere “Cosa posso fare per rendere il mio sito fruibile a tutti?“.
Non dovremmo quindi tanto guardare alla questione come un obbligo, ma come un invito a riflettere su come muoverci per una giusta causa, anche nei casi in cui non si rientra nella direttiva e quindi non si è “obbligati” a rendere accessibile il proprio sito.
Dovremmo quindi esaminare la questione a priori ogni volta che creiamo un nuovo progetto. Iniziare a pensare in termini di usabilità e accessibilità come fattori imprescindibili per la realizzazione di un sito può portare a molti vantaggi perché progettare i servizi in modo che siano già accessibili (da qui la definizione di accessibilità by design) è molto più efficace rispetto a trovare in seguito soluzioni per “riparare” quello che è stato fatto.
Dal lato opposto all’accessibilità by design troviamo quello che potremo definire uno dei più grandi specchietti per le allodole in questo ambito: i widget overlay.
Cosa sapere su plugin e widget di accessibilità
Se hai già letto qualcosa riguardo all’accessibilità o frequenti forum e gruppi di settore, avrai sentito pareri discordanti riguardo alla presenza di plugin e widget che promettono una soluzione facile e immediata alla risoluzione del “problema dell’accessibilità”.
Già da diversi anni si parla di questi widget o accessibility overlay, vale a dire sistemi che possono essere installati per aggiungere al sito delle funzioni di accessibilità.
Il problema di questi sistemi è che, al di là di come vengono presentati a livello di marketing, non hanno una reale utilità e a volte rischiano di essere controproducenti.
Uno dei maggiori problemi riscontrato è che questi strumenti vanno a modificare le configurazioni esistenti e possono quindi andare a interferire con gli strumenti di assistenza, ad esempio gli screen reader.
Oltre ai problemi di conflitti, un altro rischio più nascosto dell’adozione di questi strumenti è che una soluzione adottata in maniera temporanea può finire per essere poi mantenuta, come sottolineato da WebAccesible.
Ci sono state già diverse controversie, soprattutto negli USA.
Più di recente, a giugno del 2024 c’è stata un’azione legale contro una società AccesiBe che offriva uno strumento accessWidget che garantiva la conformità all’ADA (Americans with Disabilities Act – la legge federale che regola anche l’accessibilità nel web negli Stati Uniti). In seguito, nell’aprile 2025, l’FTC ha imposto all’azienda di pagare una sanzione di 1 milione di dollari proprio per via delle pratiche commerciali scorrette.
Overlay e pratiche scorrette: sul sito overlayFalseClaims puoi trovare diversi esempi di come sistemi di overlay siano stati pubblicizzati in modo scorretto per sembrare la soluzione a tutti i mali.
Inoltre questi strumenti – da soli – non possono riuscire a rendere il sito conforme alle WCAG. Un lavoro serio di analisi e di modifiche per rendere un sito accessibile (su un sito esistente e quindi non costruito in base al principio di accessibilità by design) può richiedere anche mesi di lavoro.
Gli strumenti per verificare l’accessibilità dei siti web (e i loro limiti)
Ad oggi esistono numerosi strumenti di test che possono aiutare a individuare problemi di accessibilità nei siti web. Bisogna però tenere presente che non si dovrebbe fare affidamento ciecamente su questi strumenti.
Alcuni criteri delle WCAG non possono essere automatizzati e richiedono, quindi, dei controlli manuali. Un audit completo dovrebbe, infatti, anche mettere alla prova l’esperienza reale e la fruibilità dei siti tramite l’uso di tecnologie assistive.
Gli strumenti di test possono essere utili, ma non possono offrire una valutazione completa.
In particolare solo una piccola percentuale, compresa tra un quarto e un terzo del totale, delle verifiche della conformità alle WCGA può essere testata in modo efficace con sistemi automatici, per il resto sono necessari dei test manuali.
Sul blog di Adrian Roselli si può trovare un interessante studio di confronto tra l’audit manuale e un’analisi effettuata con sistemi automatici che ci aiuta a capire in quanti casi i test automatizzati possono non rivelare tutta la verità.
Esempi di strumenti che ci aiutano a individuare alcuni problemi con le WCAG:
- Wave – uno strumento disponibile sia online (basta inserire l’indirizzo della pagina) che come estensione per il browser (opzione comoda perché utilizzabile anche per siti in locale).
- Accessibilitychecker – funziona inserendo l’URL.
Per una lista più completa, si può controllare l’elenco di tool su W3.org.
Comprendere le WCAG, lo standard per l’accessibilità
Le WCAG (Web Content Accessibility Guidelines) sono delle linee guida che aiutano a rendere i contenuti accessibili. Periodicamente vengono aggiornate con nuove versioni con l’aggiunta di raccomandazioni.
La versione su cui si basa l’European Accessibility Act è WCAG 2.1, la versione integrale delle linee guida pul essere consultata sul sito W3.org in versione originale e nella versione italiana (traduzione autorizzata).
Le WCAG si basano sui quattro principi dell’accessibilità del web:
- Percepibile: le informazioni e l’interfaccia devono essere presentate in modo che possano essere percepite (non possono essere invisibili a tutti i sensi).
- Utilizzabile: l’interfaccia e i menu di navigazione devono essere utilizzabili (non può essere richiesta un’interazione che la persona non può eseguire).
- Comprensibile: le informazioni devono essere comprensibili.
- Robusto: il contenuto deve poter essere interpretato da diversi user agent, comprese le tecnologie assistive (deve restare accessibile anche con l’evoluzione delle tecnologie).
La conformità alle linee guida viene definita in base a tre livelli:
- A (livello di conformità minimo);
- AA
- AAA (livello di conformità massimo).
Nel caso specifico della direttiva European Accessibility Act si parla di un livello di conformità AA.
La versione 2.1 delle WCAG include 78 criteri organizzati in base ai principi di cui abbiamo parlato prima.
Per darti un’idea più precisa del tipo di criteri, vediamo degli esempi pratici.
Contenuti non testuali
- Versione: WCAG 2.1
- Criterio di successo: 1.1.1 Contenuti non testuali
- Livello A
In base a questo criterio tutti gli elementi non testuali dovrebbero avere una versione alternativa testuale a eccezione di alcuni elementi specifici tra cui i captcha o dei test (nel caso in cui non possono essere presentati come testo).
Questo criterio si applica in diversi casi, vediamo alcuni esempi.
Presenza di emoji, emoticon, ASCII art e similari
Se le emoji (o altri elementi simili) sono importanti per la comprensione del testo, dovrebbe essere rese comprensibili anche a chi non può vederle.
Esempio di tecnica da usare: usare la proprietà aria label con role="img" per spiegare l’emoticon.
Esempio di codice HTML:
<!--
<p>Ciao, eccomi!
<span role="img" aria-label="hand waving">👋</span>
</p> -->Test per verificare il criterio:
- verificare se nel contenuto ci sono emoji e altri elementi simili;
- controllare se ogni emoji (ecc) ha un testo alternativo.
Formule matematiche
Anche le formule, ad esempio quelle indicate usando il linguaggio di markup MathML, sono considerabili elementi che devono poter essere letti attraverso screen reader e altre tecnologie assistive.
Anche in questo caso, come per le emoji, si possono usare le proprietà aria label per dare una spiegazione della formula.
Ecco un esempio pratico:
<div role="math" aria-label="6 diviso 4 è uguale a 1,5">
<math xmlns="https://www.w3.org/1998/Math/MathML">
<mfrac>
<mn>6</mn>
<mn>4</mn>
</mfrac>
<mo>=</mo>
<mn>1,5</mn>
</math>
</div>Immagini
Quando utilizziamo immagini nel sito, dovremmo inserire un testo che le descriva usando il testo alternativo tramite l’attributo alt.
Suggerimento: spesso ci si limita a ottimizzare le immagini per la SEO, inserendo il testo alternativo per i motori di ricerca, ma in realtà lo si dovrebbe fare soprattutto pensando che verrà letto dagli screen reader.
Per esempio per una infografica con del testo si dovrebbe descrivere anche il contenuto testuale all’interno dell’immagine.
Esempio di codice HTML:
<img src="infografica-cms" alt="Grafico che mostra l'utilizzo di WordPress nel tempo con percentuale di utilizzo: 2012 15,2%, 2016 25,6%, 2023 43%">Test per verificare il criterio:
- verificare se nel contenuto ci sono immagini;
- assicurarsi che ogni immagine significativa (e non puramente descrittiva) abbia il suo attributo alt.
Utilizzo corretto dei tag H1-Hn
- Versione: WCAG 2.1
- Criterio di successo: 1.3.1 Informazioni e correlazioni
- Livello A
Secondo questo principio, è importante che la struttura dei contenuti sia correttamente formattata in modo da essere comprensibile a tutti. Questo include anche l’utilizzo corretto dei tag HTML heading che si usano per indicare titolo di pagina, titoli principali e secondari.
Per dividere il testo in sezioni e sotto-sezioni nel caso di un articolo o anche di una pagina, è importante usare la giusta gerarchia di titoli.
L’errore più grande qui è quello di andare a modificare lo stile della pagina in modo che ad esempio un titolo abbia la dimensione per essere interpretato come un H2, ma senza aver utilizzato il tag html appropriato.
Un esempio di codice errato sarebbe:
<style>
.heading2{
font-family: Times, serif;
font-size:200%;
font-weight:bold;
}
</style>
<p class="heading2">Titolo</p>
<p>Esempio di paragrafo con del testo ...</p>Per identificare correttamente il titolo, va invece usato il tag HTML corretto, in questo modo:
<h2>Titolo</h2>E se si vuole modificare la dimensione (o altri elementi di stile), lo si può fare aggiungendo una classe CSS a tutti gli H2.
Contrasto minimo
- Versione: WCAG 2.1
- Criterio di successo: 1.4.3 Contrasto (minimo)
- Livello AA
I testi essenziali per la comprensione del contenuto e anche le immagini che contengono testo devono avere il giusto contrasto in modo da essere leggibili. Questo criterio non si applica a testi e immagini usati solo a scopi decorativi e ai logotipi.
Per verificare il contrasto si possono usare strumenti come:
- Strumento per sviluppatori (DevTools) di Chrome: permette di ispezionare gli elementi delle pagine web, prelevare i colori e verificare il rapporto di contrasto (potrebbe non essere efficace per verificare il contrasto quando ci sono colori con gradienti o trasparenze);
- Contrast Checker su WebAIM.org: basta inserire i valori esadecimali dei due colori (testo e sfondo) (o prelevarli) per testare il contrasto e avere subito un risultato anche in base alla dimensione.
Qui sotto un esempio di combinazione di colori (rosso su sfondo bianco) che supera il valore di contrasto per testi grandi, ma non per testi più piccoli.
Bisogna ricordarsi, infatti, che il contrasto minimo da raggiungere dipende sia dalla dimensione del testo che dalla formattazione (bold o regular).
Testi piccoli: contrasto 4,5:1
Caso 1: testo regolare di dimensioni inferiori a 18 pt oppure testo in grassetto inferiore a 14 pt.
In questa situazione il contrasto tra testo e sfondo deve essere di 4,5:1.
Testi più grandi: contrasto 3:1
Caso 2: testo regolare di dimensioni di almeno 18 pt oppure testo in grassetto di almeno a 14 pt.
Per questi testi, il contrasto tra testo e sfondo deve essere di 3:1.
Salto di blocchi
- Versione: WCAG 2.1
- Criterio di successo: 2.4.1 Salto di blocchi
- Livello A
L’obiettivo di questo criterio per l’accessibilità è permettere alle persone di arrivare più velocemente al contenuto principale della pagina, saltando gli elementi che si ripetono nelle varie pagine (ad esempio l’header, i link nel menu di navigazione, ecc.)
Ci sono diverse tecniche che possiamo utilizzare in base a come è costruito il sito.
Un esempio è quello di aggiungere all’inizio di ogni pagina un link che rimanda alla sezione con il contenuto principale. In pratica si tratta di utilizzare un link “Skip to main content” che quando attivato porta alla sezione principale.
In questo esempio sul sito Starbucks, dopo aver premuto “Tab” diventa visibile il pulsante “Skip to main content“.
Per essere utile, questo link deve essere impostato come il primo che si attiva quando l’utente usa il tasto “Tab” e che permette una volta attivato di arrivare alla sezione più importante della pagina (ad esempio il contenuto di un articolo).
Altre verifiche da fare:
- il link deve essere il primo elemento focusable;
- la descrizione del link deve far capire che permette di raggiungere il contenuto principale;
- dopo che il link viene attivato, il focus si deve spostare sulla sezione principale.
Applicazione: se stai usando Elementor con Hello o altri temi e da una verifica con un tool come PageSpeed Insights risulta l’errore “Skip Link are no focusable“, puoi risolvere aggiungendo al primo blocco della pagina l’id #content.
Ordine del focus
- Versione: WCAG 2.1
- Criterio di successo: 2.4.3 Ordine del focus
- Livello A
Quando è importante che le pagine web siano navigate con un certo ordine (in modo sequenziale), bisogna strutturare gli elementi che possono diventare focusable in modo che sia mantenuto l’ordine del focus corretto.
Per esempio immaginiamo un form di contatto che richiede l’inserimento dei dati, il focus dovrà mantenere un ordine coerente.
In questo esempio di AccessGuide.io, a sinistra è mostrato l’ordine corretto: indirizzo, città, stato e CAP. A destra l’ordine è errato: indirizzo, CAP, città, stato.
Nella pratica ci sono diversi sistemi che si possono utilizzare per stabilire l’ordine di focus degli elementi in una pagina. Per esempio si può far sì che l’ordine visivo degli elementi segua l’ordine DOM.
Per farlo bisogna fare attenzione nell’uso dell’attributo HTML tabindex che permette sia di rendere gli elementi focusable che di assegnare una posizione in modo da stabilire l’ordine di focus. La situazione migliore è quella in cui l’ordine nel codice equivale a quello visivo e quindi tutti saranno in grado di visualizzare e interagire con il contenuto nello stesso ordine.
Conclusioni
Oggi il tema dell’accessibilità dei siti web è al centro dell’attenzione per via dell’introduzione della direttiva European Accessibility Act. In realtà, però, si tratta di una questione che va ben oltre l’obbligo. Anche realtà che non sono interessate dalla direttiva possono iniziare a pensare a un nuovo modo di realizzare i propri progetti e siti in modo che siano fruibili da tutti.
Con gli esempi di WCAG che abbiamo visto abbiamo solo scalfito la superficie. In realtà come dicevamo ci sono 78 criteri, ognuno dei quali può prevedere numerosi controlli su aspetti diversi come abbiamo visto ad esempio per quanto riguarda i contenuti non testuali. La fase di adeguamento e di test, come avrai capito, non è quindi affatto semplice e non si può esaurire con un semplice controllo con degli strumenti automatici (che per quanto sia di aiuto, non possono essere ritenuti infallibili).
E tu cosa pensi al riguardo di questo tema? Facci sapere con un commento.
Lascia un commento