Accessibilità Web ed E-commerce: Guida Completa per Siti Inclusivi e a Norma

Cos’è l’accessibilità web e perché è importante

Accessibilità web significa progettare siti e applicazioni in modo che chiunque possa utilizzarli, indipendentemente da disabilità o limitazioni individuali. In pratica, un sito accessibile rimuove barriere tecniche che impediscono l’interazione a persone con disabilità visive, uditive, motorie o cognitive. Ad esempio, include testi alternativi per le immagini, sottotitoli per i video e consente la navigazione da tastiera anziché solo da mouse. Queste accortezze aiutano direttamente chi ha disabilità, ma migliorano l’esperienza per tutti gli utenti, ad esempio chi naviga da mobile sotto il sole (ridotta visibilità) o con connessioni lente.

Perché l’accessibilità è fondamentale? Ecco alcuni motivi chiave:

Inclusione e diritti: Garantire accesso equo alle informazioni online è un diritto umano fondamentale. Un sito inaccessibile esclude le persone come farebbero barriere fisiche in un edificio.
Benefici universali: Molti miglioramenti pensati per la disabilità avvantaggiano tutti gli utenti. Ad esempio, un buon contrasto colori facilita la lettura per chiunque, e un sito ben strutturato è più usabile anche su schermi piccoli o dispositivi diversi.
Ampia base di utenti: Rendere un sito accessibile amplia il pubblico potenziale includendo milioni di persone con disabilità. In Italia si stima che quasi 13 milioni di persone abbiano una qualche forma di disabilità – ignorare l’accessibilità significa escludere un’enorme fetta di utenti (oltre il 20% della popolazione, considerando anche l’invecchiamento demografico).
Requisito legale: Molti Paesi impongono per legge l’accessibilità per siti pubblici e (sempre più) privati. Non adeguarsi espone ad azioni legali e sanzioni. Ad esempio, negli Stati Uniti un sito non accessibile può violare l’ADA (Americans with Disabilities Act), equiparando la discriminazione online a quella fisica. In Italia e UE la normativa impone standard tecnici precisi (come vedremo più avanti), con possibili multe o addirittura l’oscuramento del sito in casi gravi.
Immagine e SEO: Un’azienda che investe in inclusività migliora la propria reputazione e brand. Inoltre, molti accorgimenti accessibili (come una struttura HTML pulita, testi descrittivi, ecc.) aiutano anche il posizionamento sui motori di ricerca (SEO) e la compatibilità con dispositivi mobili, rendendo il sito più efficiente e fruibile da tutti.

In sintesi, l’accessibilità web non è beneficenza ma un elemento chiave di qualità: un obbligo morale, legale e un’opportunità strategica per raggiungere più utenti e offrire una migliore esperienza di navigazione.

Le linee guida WCAG 2.1 e 2.2: principi e livelli di conformità

Per aiutare sviluppatori e progettisti a creare contenuti accessibili esistono standard internazionali definiti dal W3C (World Wide Web Consortium). I principali sono le Web Content Accessibility Guidelines (WCAG), attualmente alla versione 2.2. Queste linee guida forniscono una serie di criteri tecnici da soddisfare affinché un sito web sia considerato accessibile.

Le WCAG sono organizzate in una struttura gerarchica con tre livelli principali:

4 Principi fondanti (POUR): Percepibile, Operabile, Comprensibile, Robusto. Costituiscono i pilastri dell’accessibilità e suddividono le varie raccomandazioni in aree tematiche.
Linee guida: Per ciascun principio, esistono linee guida che delineano obiettivi generali di accessibilità (in WCAG 2.1 ci sono 13 linee guida in totale).
Criteri di successo (success criteria): Sono requisiti tecnici verificabili in modo oggettivo, associati a ciascuna linea guida. Ad esempio, un criterio richiede un contrasto minimo tra testo e sfondo, un altro che tutte le immagini abbiano un equivalente testuale, ecc. Ogni criterio ha un livello di importanza (A, AA o AAA).

I 4 principi fondamentali (POUR)

Le WCAG si basano su quattro principi fondamentali, spesso indicati con l’acronimo POUR:

Percepibile (Perceivable): Le informazioni e componenti dell’interfaccia devono essere presentati in modo che possano essere percepiti da tutti gli utenti. Ciò significa, ad esempio, fornire alternative testuali al contenuto non testuale (immagini, video, controlli) così che un utente non vedente possa ricevere tali informazioni tramite sintesi vocale o Braille. Analogamente, per contenuti audio devono esserci sottotitoli o trascrizioni per utenti non udenti.
Operabile (Operable): I componenti dell’interfaccia e la navigazione devono essere utilizzabili tramite diversi mezzi. Ogni funzionalità dovrebbe essere accessibile sia con mouse che con tastiera o comandi vocali. Ad esempio, un menu a tendina deve poter essere aperto e navigato usando solo la tastiera, per chi non può usare il mouse.
Comprensibile (Understandable): Il contenuto e i meccanismi di interazione devono essere chiari e comprensibili. Il linguaggio dovrebbe essere semplice e il funzionamento prevedibile. Form e pagine web dovrebbero comportarsi in modo coerente (ad es. stesse azioni producono risultati simili) per non confondere l’utente. Eventuali istruzioni o messaggi di errore devono essere formulati in modo da essere facilmente capiti.
Robusto (Robust): Il contenuto deve essere abbastanza robusto da poter essere interpretato correttamente da una vasta gamma di agenti utente e tecnologie assistive. In pratica significa usare codice standard (HTML, ARIA) senza errori, così che browser diversi e screen reader possano elaborarlo senza problemi. Ad esempio, un pulsante dovrebbe essere realizzato con elementi standard (<button> o con ruoli ARIA appropriati) anziché con codice improvvisato, altrimenti un lettore di schermo potrebbe non riconoscerlo come pulsante.

Questi principi costituiscono la base teorica: se uno di essi non è soddisfatto, l’utente incontrerà una barriera. Ad esempio, un video senza sottotitoli non è percepibile per un utente sordo; un menu accessibile solo col mouse non è operabile da chi usa solo tastiera; un linguaggio troppo complesso rende le info non comprensibili a molti; un codice non standard potrebbe non essere robusto su alcuni dispositivi o tecnologie assistive.

Livelli di conformità (A, AA, AAA)

Non tutti i requisiti WCAG hanno la stessa priorità. Per questo esistono tre livelli di conformità:

Livello A: è il livello base (minimo) di accessibilità. I criteri di livello A sono quelli considerati fondamentali; un sito che non li rispetta presenta barriere gravi. Ad esempio, livello A include avere testi alternativi per le immagini, navigazione da tastiera, ecc.
Livello AA: è il livello intermedio, che include tutti i criteri A più ulteriori criteri (livello AA) che migliorano sensibilmente l’accessibilità. La maggior parte delle normative – come la legge italiana e la direttiva UE – richiede la conformità al livello AA, perché fornisce un buon equilibrio tra accessibilità e fattibilità tecnica. Il livello AA include requisiti come contrasto minimo 4.5:1 per il testo, sottotitoli per video registrati, strutture di navigazione coerenti, ecc..
Livello AAA: è il livello più elevato, che comprende tutti i criteri A + AA più criteri aggiuntivi (AAA) per un’accessibilità ancora maggiore. Esempi di AAA sono contrasto ancora più elevato (7:1), linguaggio semplificato, descrizioni audio per i video, ecc. Il livello AAA non è richiesto dalla maggior parte delle leggi e spesso non è realisticamente raggiungibile per tutti i contenuti (alcuni criteri AAA possono essere difficili da implementare su certi siti). Tuttavia rappresenta l’eccellenza in termini di inclusività.

Nota: La conformità ai livelli è cumulativa: se un sito è conforme AA, significa che soddisfa tutti i criteri di livello A e di livello AA. Analogamente AAA implica il rispetto anche di AA e A. In pratica, l’obiettivo comune è raggiungere almeno il livello AA, mentre il livello AAA può essere un traguardo aggiuntivo su sezioni limitate o progetti particolarmente sensibili.

WCAG 2.1 vs 2.2: cosa è cambiato?

Le WCAG 2.1 (pubblicate nel 2018) hanno esteso la versione 2.0 introducendo criteri aggiuntivi – ad esempio miglioramenti per accessibilità mobile (come il supporto all’orientamento verticale/orizzontale, maggiore visibilità del focus) e per utenti con disabilità cognitive. Le WCAG 2.2 sono state pubblicate come raccomandazione W3C nell’ottobre 2023 e apportano ulteriori 9 criteri di successo aggiuntivi rispetto alla 2.1. Questi nuovi criteri mirano, tra l’altro, a:

Migliorare la navigazione da tastiera: ad esempio assicurarsi che l’elemento attivo via tastiera sia sempre visibile sullo schermo e non coperto da elementi in sovrimpressione (criterio Focus not obscured) – questo aiuta chi naviga senza mouse a non “perdere” il focus.
Facilitare interazioni e autenticazione: ad esempio il criterio Dragging movements richiede alternative al drag&drop (trascinamento) per utenti con difficoltà motorie; Accessible Authentication impone metodi di login che non richiedano solo la memorizzazione di informazioni (utile per chi ha disabilità cognitive).
Ampliare aree cliccabili e aiuti consistenti: ad es. Target Size (Minimum) definisce una dimensione minima per gli elementi interattivi (bottoni, link) per facilitarne il click/tap, mentre Consistent Help richiede che l’help (assistenza) su un sito sia reperibile in modo consistente (sempre nello stesso posto o modo) per non disorientare l’utente.

Importante sottolineare che tutti i criteri delle WCAG 2.1 restano validi anche in WCAG 2.2 (eccetto una piccola deprecazione tecnica). Quindi, chi ha già reso il proprio sito conforme alla 2.1 ha solo alcuni requisiti in più da implementare per allinearsi alla 2.2. Inoltre, è già in sviluppo la futura WCAG 3.0, che rappresenterà un approccio ancora diverso e più flessibile, ma la sua adozione stabile richiederà tempo. Ad oggi, WCAG 2.1 AA è lo standard di riferimento minimo citato nelle normative, con un progressivo interesse verso WCAG 2.2 man mano che viene recepita nei requisiti ufficiali.

Adeguamenti pratici per siti web ed e-commerce accessibili

Passando dalla teoria alla pratica, quali interventi bisogna implementare su un sito web (in particolare un sito di e-commerce) per renderlo accessibile e conforme alle WCAG 2.1/2.2 livello AA? Di seguito esaminiamo i principali aspetti, con consigli ed esempi:

1. Testo alternativo per le immagini

Ogni immagine informativa deve avere un testo alternativo (attributo alt) appropriato. Il testo alternativo descrive brevemente il contenuto o la funzione dell’immagine, così che gli utenti non vedenti (che utilizzano screen reader) possano capire cosa viene raffigurato. Ad esempio, <img src=”carrello.png” alt=”Icona carrello degli acquisti”> permette allo screen reader di annunciare “Icona carrello degli acquisti”. Evitare descrizioni vaghe come “immagine1” o “foto”; il testo deve essere significativo. Per immagini puramente decorative si può usare alt vuoto (alt=””) in modo che vengano ignorate dal lettore di schermo. Questo accorgimento garantisce che nessuna informazione visiva vada persa per chi non può vederla.

2. Contrasto colore sufficiente

Un contrasto cromatico adeguato tra testo e sfondo è essenziale per la leggibilità, soprattutto per utenti con ridotta capacità visiva o daltonici. Le WCAG 2.1 livello AA richiedono un contrasto minimo di 4.5:1 per il testo normale (corpo) e 3:1 per testi grandi (titoli). Ciò significa, ad esempio, che scritte grigie su sfondo bianco molto chiaro non vanno bene. Esistono tool che calcolano il contrasto (fornendo il rapporto) per verificare i colori del sito. Garantire un buon contrasto non solo aiuta ipovedenti e daltonici, ma migliora l’esperienza di tutti in condizioni difficili (schermo sotto la luce del sole, monitor scadenti, etc.). Suggerimento: definire i colori usando le guide WCAG o usare i colori del brand assicurandosi che rispettino i rapporti richiesti – in caso contrario, prevedere variazioni ad alto contrasto per la modalità accessibile.

3. Navigazione da tastiera completa

Un sito accessibile deve poter essere navigato usando solo la tastiera, senza necessità di mouse. Questo perché molti utenti con disabilità motorie (o non vedenti) si spostano tramite tasto Tab (per saltare da un link/un campo al successivo) e usano Invio/Spazio per attivare pulsanti o link. È fondamentale quindi che tutti i link, bottoni e controlli interattivi siano raggiungibili e utilizzabili via Tab. Inoltre, mentre si naviga con Tab, l’elemento attivo deve essere evidenziato da un indicatore di focus visibile (ad esempio un bordo o un’ombra), in modo che sia chiaro cosa si sta “selezionando” in quel momento. Su molti siti questo stile è assente o disabilitato via CSS: è buona norma mantenerlo ben visibile (personalizzandolo nel design se necessario). Prevedere anche meccanismi come “skip link” (collegamenti nascosti all’inizio della pagina che permettono di saltare direttamente al contenuto principale, evitando di dover tabulare attraverso il menu su ogni pagina). Una navigazione solo tastiera ben implementata è cruciale per utenti con disabilità motorie, ma anche per power user che preferiscono la tastiera e per l’uso su dispositivi dove il mouse non c’è.

4. Struttura semantica e layout corretti

Usare un HTML semantico e una struttura logica dei contenuti è un pilastro dell’accessibilità. Ciò significa utilizzare i tag appropriati per titoli, paragrafi, liste, tabelle, moduli, etc., in base al loro significato, non solo per l’aspetto grafico. Ad esempio, il titolo principale della pagina dovrebbe essere racchiuso in un tag <h1>, i sottotitoli in <h2>, <h3> e così via, rispettando un ordine gerarchico. Questo non solo permette ai lettori di schermo di comprendere la struttura del documento e navigarlo facilmente (molti screen reader possono elencare i titoli per saltare alle sezioni), ma migliora anche la SEO. Allo stesso modo, sezioni ricorrenti come header, menu di navigazione, main content e footer andrebbero marcate con i tag HTML5 <header>, <nav>, <main>, <footer>. Una buona struttura semantica assicura che il layout sia consistente e “logico” indipendentemente dal CSS: se il sito fosse visualizzato in modalità solo testo o tramite assistente vocale, gli elementi avrebbero ancora un senso compiuto e un ordine naturale. Inoltre, una struttura pulita facilita anche chi naviga con ingranditori di testo o su schermi piccoli, perché può adattare il contenuto senza perdere informazioni.

5. Supporto per screen reader (etichette e ARIA)

I screen reader sono software che trasformano il contenuto in voce o Braille per utenti ciechi o ipovedenti. Per rendere un sito compatibile con i lettori di schermo occorre innanzitutto rispettare quanto detto finora (testi alternativi, semantica HTML, etc.). In aggiunta, si possono usare gli attributi ARIA (Accessible Rich Internet Applications) per fornire informazioni aggiuntive utili. Ad esempio, per un elemento interattivo non standard (come un widget personalizzato in JavaScript) si può impostare role=”button” e aria-label=”Descrizione funzione” in modo che il lettore di schermo lo annunci come “pulsante” con la giusta etichetta. Alcuni casi d’uso comuni di ARIA: aria-label o aria-labelledby per etichettare elementi che non hanno un <label> visibile; aria-hidden=”true” per marcare elementi puramente decorativi da ignorare; regioni con role=”navigation”, role=”main”, etc., se non si possono usare i tag HTML5 equivalenti. Attenzione: ARIA non sostituisce l’uso di buon HTML, ma lo integra. La regola aurea è “HTML prima, ARIA poi”. Inoltre, è importante che i contenuti dinamici (come popup, avvisi, modali) siano gestiti in modo da notificare il cambiamento allo screen reader (es. con focus management e attributi ARIA come aria-live). In sintesi, ogni elemento dell’interfaccia deve avere un nome, un ruolo e uno stato comprensibile per chi usa tecnologie assistive. Adottando queste accortezze, utenti ciechi possono navigare e utilizzare il sito efficacemente, ascoltando descrizioni accurate di link, pulsanti e sezioni.

6. Moduli e form accessibili (etichette ed errori chiari)

I form (moduli di contatto, registrazione, checkout e-commerce, ecc.) richiedono particolare cura. Ogni campo di input deve avere un’etichetta testuale chiara, associata tramite il tag <label> (col suo attributo for che punta all’id dell’input corrispondente). In questo modo, lo screen reader annuncerà la label quando il focus entra nel campo (es. “Email: campo di testo”). Se per ragioni di design non è possibile mostrare una label visibile, occorre comunque fornire un’etichetta per tecnologie assistive, ad esempio con aria-label=”Email” o usando classi CSS per nascondere il <label> visivamente ma lasciarlo accessibile. Oltre alle etichette, istruzioni e indicazioni vanno fornite per aiutare l’utente a compilare correttamente (es: formattazione richiesta per date, campi obbligatori marcati chiaramente). Cruciale è anche la gestione degli errori di input: se l’utente dimentica un campo o inserisce un dato sbagliato, il messaggio di errore deve essere chiaro e facilmente percepibile. Ciò significa, ad esempio, che non basta colorare di rosso il bordo del campo (un utente cieco o daltonico non lo percepirebbe): bisogna aggiungere un testo esplicito tipo “Errore: il campo Email è obbligatorio” vicino al campo, magari collegato con aria-describedby così che venga letto dallo screen reader. Se un campo in errore è evidenziato visivamente, assicurarsi che ci sia anche un’icona o testo per utenti daltonici. Quando possibile, fornire suggerimenti per correggere l’errore (es: “La password deve avere almeno 8 caratteri”). In sintesi, un modulo accessibile guida l’utente nella compilazione e lo informa chiaramente di cosa manca o va corretto, senza confonderlo. Questo migliora la user experience per tutti – chi non ha mai sbagliato a compilare un form? – e assicura che nessuno abbandoni il processo (ad esempio di acquisto) perché non capisce come proseguire.

7. Contenuti multimediali accessibili

I contenuti audio-video richiedono accorgimenti per essere fruibili anche da chi non vede o non sente. Per ogni video dovrebbero essere disponibili i sottotitoli sincronizzati (per utenti sordi o con problemi di udito) e, per contenuti più complessi, una audio-descrizione o testo alternativo che descriva le scene importanti per chi non può vederle. In pratica, se il video mostra qualcosa di fondamentale non deducibile dall’audio, andrebbe fornita una traccia audio descrittiva o una descrizione testuale separata. Per i contenuti audio (es. podcast) bisogna fornire una trascrizione testuale completa, così che gli utenti non udenti possano accedere alle stesse informazioni. Inoltre, i player multimediali devono essere accessibili: i controlli di play/pausa, volume, progress bar, ecc. devono essere etichettati correttamente e utilizzabili via tastiera. Evitare player che richiedano solo interazioni col mouse. Assicurarsi anche che i controlli siano visibili e chiari (ad esempio, non affidarsi a icone non etichettate testualmente). Un altro aspetto: se i media partono in automatico all’apertura della pagina (auto-play), deve esserci un modo facile per metterli in pausa o silenziarli, altrimenti l’utente potrebbe essere disorientato (oltre che violare criteri WCAG). Implementando sottotitoli, trascrizioni e controlli accessibili, garantiamo che video e audio possano essere compresi da tutti – che sia una presentazione di prodotto, un tutorial o un webinar registrato.

8. Dimensioni del testo regolabili

Molti utenti necessitano di ingrandire il testo per leggere comodamente (pensiamo agli anziani, agli ipovedenti o semplicemente a chi usa schermi piccoli). Un sito accessibile deve permettere di zoomare il testo fino al 200% senza perdita di funzionalità o di informazioni. In pratica, se un utente imposta caratteri più grandi (tramite browser o impostazioni di sistema), il layout del sito dovrebbe adattarsi di conseguenza (design responsive) senza che elementi si sovrappongano o diventino illeggibili. Per ottenere ciò, è consigliato utilizzare unità di misura relative per i font (come em o rem in CSS) invece di pixel fissi. In questo modo, un aumento del 200% nelle preferenze utente scala effettivamente i testi. È utile anche offrire controlli lato interfaccia per aumentare/ridurre il testo (ci sono script e plugin appositi), ma non è strettamente richiesto se il sito è ben realizzato e il browser può fare zoom senza rompere nulla. Consiglio: testare il sito al 200% di zoom e in modalità “alto contrasto” per vedere se tutto rimane usabile. Inoltre, verificare che testi dentro elementi dinamici (come modali, menu a scomparsa) possano anch’essi ingrandirsi senza problemi. Questo punto è spesso trascurato, ma è vitale per garantire leggibilità: un sito che rimane usabile e gradevole anche con testi grandi denota qualità e attenzione a ogni utente.

9. Evitare contenuti lampeggianti o elementi a intermittenza

Elementi che lampeggiano velocemente (flash) o creano effetti stroboscopici possono rappresentare non solo un disturbo, ma un pericolo: flash oltre una certa frequenza possono scatenare crisi epilettiche in soggetti fotosensibili. Le WCAG indicano di evitare lampeggiamenti superiori a 3 volte al secondo. In generale, è meglio evitare del tutto contenuti lampeggianti inutili (banner animati aggressivi, GIF lampeggianti, etc.). Se proprio necessario un effetto di evidenziazione, farlo a frequenza molto bassa e dare sempre all’utente la possibilità di pausare o bloccare l’animazione. Questo rientra nel criterio “non provocare epilessia o disturbi visivi”. Oltre al rischio sanitario, elementi che lampeggiano possono distrarre e infastidire chi ha disturbi dell’attenzione o della vista. Quindi, un design accessibile preferisce modi più sicuri per attirare l’attenzione (es. usare il colore o un bordo per evidenziare, anziché un lampeggio continuo). Se si incorporano video esterni o pubblicità con flash, assicurarsi che rispettino questi standard (altrimenti meglio rimuoverli o sostituirli). Un web privo di “sfarfallii” non solo è più sicuro, ma risulta anche più professionale e meno stressante per tutti gli utenti.

10. Chiarezza del linguaggio e delle istruzioni

Ultimo ma non meno importante, il contenuto testuale deve essere comprensibile al pubblico più ampio possibile. Ciò significa usare un linguaggio semplice, diretto, evitando gergo tecnico complesso quando non necessario. Per un pubblico generale, frasi brevi e ben strutturate migliorano la comprensione. Se il sito si rivolge a specialisti e deve includere termini tecnici, può essere utile fornire un glossario o spiegazioni a margine per i termini più complessi. Questo accorgimento aiuta le persone con disabilità cognitive o di apprendimento, che possono avere difficoltà con testi molto articolati, ma in generale giova a tutti (specialmente a chi legge in fretta o magari non nella propria lingua madre). Anche le istruzioni operative (es. “compila questo modulo per registrarti”) vanno scritte in modo chiaro, magari spezzettando le azioni in passi numerati se il processo è lungo. Evitare frasi ambigue o doppie negazioni. Inoltre, uniformare il tono e i termini in tutto il sito: ad esempio, non usare “carrello” in una pagina e “cestino” in un’altra per indicare la stessa cosa, altrimenti l’utente potrebbe confondersi. Un contenuto chiaro e coerente riduce gli errori, le richieste di supporto e rende il sito accogliente. Per verificarne la leggibilità, esistono anche strumenti (come l’indice di leggibilità Flesch-Kincaid) che analizzano i testi – alcuni plugin di accessibility check li includono. In sintesi, scrivere per essere compresi non è un semplificare banalmente, ma un rendere l’informazione accessibile a più persone possibili, obiettivo ultimo dell’accessibilità.

Normativa italiana: Legge Stanca e aggiornamenti recenti

In Italia la legge di riferimento sull’accessibilità digitale è la cosiddetta Legge Stanca, ovvero la Legge n.4 del 9 gennaio 2004. Questa legge, fin dalla sua origine, riconosce e tutela “il diritto di ogni persona ad accedere a tutte le fonti d’informazione e ai relativi servizi” indipendentemente da disabilità, obbligando i soggetti pubblici (e alcune categorie di privati) ad adottare accorgimenti per eliminare gli ostacoli ai servizi informatici e telematici. Inizialmente la Legge Stanca si applicava soprattutto alla Pubblica Amministrazione e a pochi altri soggetti, ma nel corso degli anni il suo ambito è stato esteso.

Ecco le tappe principali dell’evoluzione normativa italiana:

2004: Entrata in vigore della Legge Stanca (L.4/2004) – prima normativa italiana sull’accessibilità web, rivolta a Pubbliche Amministrazioni, enti pubblici economici, concessionari di servizi pubblici e poche altre categorie. Prevedeva già l’adozione di requisiti tecnici (all’epoca basati su WCAG 1.0) e sanzioni in caso di inadempienza (per i dirigenti PA responsabili).
2016/2018: L’Unione Europea adotta la Direttiva (UE) 2016/2102 sull’accessibilità dei siti web e app mobili degli enti pubblici. L’Italia recepisce questa direttiva nel 2018 con il D.Lgs. 106/2018, che modifica la Legge Stanca. Da allora, tutti i siti web e le app della PA italiana devono rispettare le WCAG 2.1 livello AA, pubblicare una Dichiarazione di accessibilità annuale e sono soggetti a monitoraggi da parte di AgID. In pratica, la normativa italiana si è allineata agli standard comunitari per il settore pubblico.
2020: Con il Decreto Legge 76/2020 (convertito dalla L.120/2020, Decreto Semplificazioni) l’ambito soggettivo dell’accessibilità viene esteso anche a imprese private di grandi dimensioni che offrono servizi di pubblico interesse essenziali. In particolare, sono state incluse aziende con fatturato medio annuo superiore a 500 milioni di € che forniscano servizi essenziali al pubblico tramite web o app (energia, telecomunicazioni, trasporti, servizi finanziari, sanità, istruzione, e anche grandi e-commerce). Questi soggetti cosiddetti “erogatori privati” sono obbligati (entro il 2022) ad adeguare i propri siti e applicazioni ai requisiti di accessibilità analoghi a quelli delle PA, e a pubblicare la dichiarazione di accessibilità. L’AgID è deputata a vigilare anche su di essi, potendo comminare sanzioni in caso di inosservanza.
2022: Il passo più importante e recente è l’attuazione della Direttiva (UE) 2019/882, nota come European Accessibility Act (EAA). L’Italia ha recepito questa direttiva con il D.Lgs. 27 maggio 2022 n.82. Questa normativa introduce obblighi di accessibilità per un’ampia gamma di prodotti e servizi digitali nel settore privato, con effetto scaglionato entro giugno 2025. In sostanza, entro il 28 giugno 2025 tutti i nuovi siti web, e-commerce, app mobili, ATM, terminali self-service, ebook, servizi bancari, servizi di trasporto passeggeri ecc., destinati al pubblico nell’UE dovranno essere accessibili. L’Italia con il d.lgs. 82/2022 ha stabilito che dal giugno 2025 l’obbligo di conformità si estende anche alle piccole e medie imprese che offrono tali servizi/prodotti digitali, esentando solo le micro-imprese. In altre parole, non solo le grandi aziende >500M€, ma praticamente quasi tutte le aziende online (oltre 10 dipendenti o 2M€ fatturato) dovranno adeguarsi. Le categorie coperte includono: siti di e-commerce, servizi di comunicazione elettronica, piattaforme di media audiovisivi, servizi bancari al consumo, trasporto aereo/ferroviario/navale per passeggeri, libri elettronici e relativi software.

Le sanzioni in Italia sono ora piuttosto severe per chi non rispetta le norme di accessibilità. L’AgID (Agenzia per l’Italia Digitale) vigila sui servizi digitali, mentre il Ministero delle Imprese (MIMIT) sui prodotti. Possono essere comminate multe fino al 5% del fatturato annuo per i grandi privati soggetti a Legge Stanca (>500M€), e fino a 40.000 € per le altre imprese inadempienti (importo variabile in base alla gravità e numero di utenti coinvolti). Inoltre, le autorità possono ordinare provvedimenti drastici come l’oscuramento del sito web o la rimozione dell’app dagli store digitali, nei casi di persistente non conformità. Già dal 2022 le imprese sopra 500M€ dovevano adeguarsi (pena sanzioni), ma dal 2025 come detto l’obbligo diventa generale in attuazione dell’EAA.

In sintesi, la normativa italiana oggi impone agli enti pubblici e a molti privati di rispettare le linee guida internazionali (WCAG 2.1 AA, in futuro WCAG 2.2) e di dichiarare lo stato di accessibilità dei propri siti/app. L’AgID ha emanato apposite Linee Guida che dettagliano i requisiti tecnici da seguire e ha predisposto un modello di dichiarazione di accessibilità da pubblicare annualmente. L’enfasi non è solo sulla regola, ma sulla trasparenza verso gli utenti (che devono poter segnalare le inadempienze) e sul miglioramento continuo. Per gli imprenditori digitali italiani, adeguarsi non è più opzionale: oltre a evitare sanzioni, farlo in tempo entro il 2025 può diventare un vantaggio competitivo, trasformando la compliance in valore aggiunto (accessibilità come “selling point”). Come afferma il legislatore, l’obiettivo finale è garantire a tutti i cittadini la possibilità di usufruire dei servizi digitali senza barriere, promuovendo un ecosistema online inclusivo.

Accessibilità digitale in Svizzera: stato dell’arte

La Svizzera, pur non facendo parte dell’UE, sta anch’essa muovendosi verso una maggiore accessibilità digitale. Attualmente, la situazione svizzera può essere riassunta così:

Settore pubblico: le autorità federali svizzere sono tenute per legge a rendere accessibili i propri servizi digitali. La Confederazione ha adottato uno Standard di accessibilità eCH-0059 (versione 3) che richiede il rispetto delle WCAG 2.1 livello AA per i siti web governativi. Questo standard eCH-0059 è applicato nell’amministrazione federale e funge da riferimento anche per cantoni e comuni. La base giuridica di ciò sta in varie normative elvetiche: l’art. 8 cpv.2 della Costituzione Federale vieta ogni discriminazione verso persone con disabilità; inoltre la Legge sui disabili (LDis) e la relativa ordinanza (ODis) stabiliscono che i servizi della Confederazione devono essere concepiti in modo accessibile. Anche la Legge federale sull’uso di mezzi elettronici (LMeCA) impone alle autorità di offrire prestazioni accessibili a tutta la popolazione. In pratica, tutti i siti della pubblica amministrazione svizzera devono essere accessibili, pubblicare una dichiarazione di accessibilità (come fa ad es. il sito dell’AFC che dichiara conformità WCAG 2.1 AA), e sono soggetti a monitoraggio. Questo contesto è molto simile a quello UE per il settore pubblico.
Settore privato: al momento attuale (2025) non esiste ancora in Svizzera una legge che obblighi in modo esplicito tutti i siti web privati a essere accessibili. Tuttavia, valgono i principi generali di non discriminazione: ad esempio, un’azienda potrebbe incorrere in un caso di discriminazione se rendesse un servizio online inutilizzabile a persone con disabilità (ci sono state mozioni parlamentari e discussioni su questo). Di fatto però, a differenza dell’UE, non c’è un requisito legale specifico che imponga criteri tecnici ai siti privati né sanzioni dedicate. Questo potrebbe cambiare a breve: a fine 2024 è stata presentata una proposta di modifica della Legge sui disabili (LDis) per promuovere maggiore inclusività anche nel digitale. Inoltre, l’arrivo dell’Accessibility Act in UE sta facendo da traino: molte aziende svizzere con pubblico internazionale dovranno comunque adeguarsi per non perdere mercato nell’UE. Infatti, se un e-commerce svizzero vende a consumatori UE, di fatto dovrà rispettare i requisiti EAA per quei servizi, pena l’esclusione da quei mercati. Si cita spesso il precedente del GDPR (regolamento privacy europeo) che ha spinto la Svizzera a varare una legge analoga; ci si attende che accada qualcosa di simile con l’accessibilità digitale. Già nel 2023-2025 sono in corso lavori parlamentari per rafforzare l’accessibilità nel settore privato (mozioni 21.3185 e 23.3582). Dunque, gli osservatori si aspettano che anche la Svizzera adotterà standard di accessibilità per i privati, tenendo conto degli sviluppi UE.

In conclusione, in Svizzera per ora l’accessibilità è obbligatoria per gli enti pubblici (con standard WCAG 2.1 AA già in uso), mentre per i privati vige una sorta di moral suasion e principi generali. Molte organizzazioni illuminate (anche PMI) stanno comunque adottando le WCAG su base volontaria, riconoscendo i benefici in termini di usabilità e apertura a clienti con disabilità. Si noti che circa il 21% della popolazione svizzera convive con una disabilità (dato Ufficio Federale di Statistica) – un valore simile alle percentuali europee – quindi ignorare l’accessibilità significa escludere potenzialmente 1 persona su 5. Per le aziende svizzere, adeguarsi agli standard internazionali è non solo una responsabilità sociale, ma anche un modo per migliorare la presenza online e raggiungere un pubblico più ampio, come sottolineano gli esperti locali. Con l’entrata in vigore dell’EAA nell’UE, questo tema è destinato a diventare sempre più rilevante anche nel contesto elvetico (“onda lunga” dell’UE in Svizzera). Restare all’avanguardia su questo fronte può preparare le aziende svizzere a un futuro digitale più equo e competitivo.

Panoramica di altre normative globali rilevanti

Oltre alle normative italiane e svizzere, è utile conoscere alcuni degli standard e leggi più importanti a livello internazionale in tema di accessibilità digitale:

Direttiva Europea 2019/882 – European Accessibility Act (EAA): Ne abbiamo già parlato in ambito italiano, ma in generale questa direttiva UE impone dal giugno 2025 requisiti di accessibilità uniformi per molti prodotti e servizi digitali in tutto il Mercato Unico. Gli standard tecnici di riferimento dell’EAA sono basati su EN 301 549, norma europea che a sua volta incorpora le WCAG 2.1 AA per la parte web. Ogni Stato UE ha proprie sanzioni (in Italia come visto fino al 5% fatturato o 40k €). L’EAA impatterà anche operatori extra-UE che vogliono offrire servizi in Europa (devono adeguarsi agli stessi requisiti). È una delle legislazioni più avanzate e ampie: copre web, mobile, e-reader, bancomat, biglietterie automatiche, servizi bancari, e-commerce, trasporti, ecc., con l’obiettivo di un mercato europeo senza barriere digitali.
ADA – Americans with Disabilities Act (USA): Negli Stati Uniti non esiste (ancora) una legge specifica sulle caratteristiche tecniche dei siti web, ma l’ADA (legge federale del 1990 contro le discriminazioni delle persone disabili) viene interpretata estensivamente per includere anche i servizi online. In particolare il Titolo II (enti pubblici) e Titolo III (esercizi aperti al pubblico) dell’ADA richiedono che le informazioni e i servizi siano accessibili. Il Dipartimento di Giustizia USA ha chiarito che i siti web di aziende aperte al pubblico devono essere accessibili così come lo sono le loro sedi fisiche. In mancanza di uno standard legale esplicito, la prassi consolidata è adottare le WCAG (livello AA) come riferimento per la conformità ADA. Numerose cause legali negli USA contro aziende per siti non accessibili si sono risolte richiedendo l’adeguamento ai criteri WCAG. Inoltre, per i siti del governo federale vige la Section 508 del Rehabilitation Act, che già dal 2017 richiede la conformità a WCAG 2.0 AA. Una nuova normativa specifica per il web (regolamento) è in fase di finalizzazione (nel 2024). In sintesi, chi opera negli USA dovrebbe considerare l’accessibilità de facto obbligatoria, per evitare contenziosi e garantire pari opportunità di accesso.
AODA – Accessibility for Ontarians with Disabilities Act (Ontario, Canada): È una delle leggi più avanzate a livello locale. La provincia dell’Ontario impone che i siti web di enti pubblici e di imprese private sopra una certa dimensione siano accessibili secondo WCAG 2.0 AA (con l’eccezione di sottotitoli live e audio-descrizioni). Questo obbligo è scattato definitivamente dal 1° gennaio 2021 per il contenuto web pubblicato dopo il 2012. In pratica, in Ontario scuole, ospedali, ma anche aziende con 50+ dipendenti devono avere siti conformi WCAG 2.0 AA, altrimenti possono ricevere sanzioni (anche qui esistono meccanismi ispettivi). Il Canada a livello federale ha emanato l’Accessible Canada Act (2019) che fissa obiettivi di accessibilità entro il 2040, e diverse province hanno leggi simili all’AODA. Chi ha pubblico o clienti in Canada (specialmente nel settore pubblico o grandi imprese) deve tener conto di questi requisiti.
RGAA – Référentiel Général d’Accessibilité pour les Administrations (Francia): In Francia dal 2005 esiste una legge che obbliga i siti web pubblici all’accessibilità (Loi n°2005-102), e il RGAA è il insieme di criteri tecnici ufficiali per verificare la conformità. Il RGAA nella versione attuale (RGAA 4.1) è basato sulle WCAG 2.0 (non ancora 2.1) con qualche requisito aggiuntivo specifico. Esso prevede test e punti di controllo da soddisfare e la pubblicazione di una dichiarazione di accessibilità. In pratica è un checklist dettagliata in francese allineata alle WCAG. Anche qui l’obbligo vige per amministrazioni, enti pubblici e alcune categorie private (ad es. aziende con delega di servizio pubblico). La Francia con l’EAA dovrà aggiornare anche il RGAA o sostituirlo con la norma europea. Intanto, seguire le WCAG è il modo più semplice per essere conforme al RGAA, poiché ne costituisce la base. Da notare che in Francia non conformarsi può portare a sanzioni e a una pubblica “denuncia” sul sito ministeriale. Il RGAA è un esempio di come un Paese declina gli standard internazionali nel proprio contesto, e molti altri stati hanno linee guida simili (in Germania le BITV, in UK gli “Accessibility Regulations” legati all’Equality Act, in Australia gli standard WCAG incorporati nel Disability Discrimination Act, ecc.).

In generale, lo scenario globale mostra una convergenza: le WCAG come standard comune e leggi nazionali che ne richiedono l’applicazione. Per un imprenditore o sviluppatore che opera su scala internazionale, è prudente seguire sempre le WCAG 2.1/2.2 livello AA come minimo, poiché ciò garantisce di soddisfare la gran parte delle normative locali (e future). Inoltre, va tenuto presente che in diversi paesi le cause legali per discriminazione digitale sono in aumento: anticipare la conformità significa anche proteggersi legalmente e dimostrare due diligence. L’accessibilità sta diventando una sorta di “lingua franca” della qualità web in tutto il mondo.

Strumenti e plugin WordPress per migliorare l’accessibilità

Adeguare un sito o e-commerce ai requisiti di accessibilità può sembrare un compito complesso, ma esistono molti strumenti che aiutano sviluppatori e content editor nel processo. In particolare, per chi utilizza WordPress, sono disponibili plugin dedicati che facilitano sia l’analisi dei problemi sia l’implementazione di soluzioni. Di seguito presentiamo due plugin noti:

“All in One Accessibility” di Skynet (Plugin WordPress)

“All in One Accessibility” di Skynet è un plugin/widget per WordPress pensato per migliorare rapidamente la conformità ADA/WCAG del sito. Si tratta di una soluzione basata su intelligenza artificiale e tecnologie assistive che aggiunge al sito una toolbar con una serie di funzionalità di accessibilità attivabili dall’utente. In pratica, una volta installato, compare un’icona (di solito un omino o una sedia a rotelle stilizzata) che apre un menu di opzioni per l’utente finale: ad esempio screen reader integrato (lettura vocale del testo), profili di accessibilità predefiniti, ingrandimento del testo, regolazione di contrasto e colori, sottotitoli per video, navigazione da tastiera facilitata, evidenziazione di link e titoli, font per dislessia, tastiera virtuale, ecc.. L’utente può personalizzare l’esperienza in base alle proprie esigenze cliccando sulle varie opzioni (ad esempio attivare modalità alto contrasto se daltonico, oppure far partire il lettore vocale se ipovedente). Il plugin punta quindi sull’approccio “user-triggered enhancements”: lascia all’utente la scelta di quale aiuto attivare.

Secondo il produttore, questo strumento è allineato alle principali normative globali (USA, UK, UE, Canada) e conforme agli standard come WCAG 2.1/2.2, Equality Act e EN 301 549 (lo standard europeo). Lo scopo è mitigare il rischio legale rendendo immediatamente disponibili funzionalità inclusive senza dover riprogettare da zero il sito. Skynet sostiene infatti che l’uso del suo plugin riduce il rischio di cause legali legate all’accessibilità, un tema sentito specie negli USA dove le cosiddette “accessibility lawsuit” sono frequenti. Dal punto di vista tecnico, l’installazione è rapida (circa 5 minuti) e il plugin supporta oltre 140 lingue, adattandosi quindi anche a siti multilingue. Esiste in versione gratuita di prova e piani a pagamento in base al traffico del sito.

Va notato che soluzioni di questo tipo, spesso chiamate “overlay di accessibilità”, sono dibattute nella comunità: offrono un miglioramento immediato, ma non risolvono tutti i problemi di accessibilità del codice sorgente. Possono essere utili come integrazione, ma non sostituiscono le buone pratiche di sviluppo (ad esempio, un’immagine senza alt testuale rimane tale, anche se il plugin può cercare di descriverla automaticamente). Detto ciò, plugin come quello di Skynet possono aiutare i siti esistenti ad offrire subito opzioni aggiuntive agli utenti disabili mentre si lavora sulle soluzioni definitive. Per un imprenditore che gestisce un e-commerce in WordPress, potrebbe essere uno strumento da valutare: con un costo relativamente basso, consente di dichiarare una certa aderenza agli standard e di mostrare sensibilità verso l’inclusione (molti siti esibiscono il banner “Accessibility Adjustments” come segnale positivo). In conclusione, All in One Accessibility è un “kit di pronto soccorso” per l’accessibilità: non guarisce tutti i mali del codice, ma fornisce ai visitatori gli strumenti per navigare meglio il sito secondo le proprie esigenze.

“Accessibility Checker” di Equalize Digital (Scanner WCAG per WordPress)

“Accessibility Checker” è un plugin sviluppato dalla società Equalize Digital che funge da sistema di auditing automatico dell’accessibilità per siti WordPress. A differenza del precedente, questo strumento non aggiunge funzionalità visibili all’utente finale, ma aiuta gli sviluppatori e i content editor a individuare e correggere gli errori di accessibilità durante la creazione dei contenuti. Una volta installato, infatti, il plugin scansiona le pagine e i post direttamente nell’editor di WordPress e fornisce un report di problemi riscontrati, con indicazione di gravità (errori o avvisi). Ad esempio, mentre stiamo modificando una pagina, in una metabox laterale vedremo segnalazioni tipo “Immagine X priva di testo ALT” oppure “Contrasto insufficiente per il testo Y su sfondo Z”. Questo permette di “trovare e risolvere i problemi sul posto” rapidamente, anziché scoprirli dopo via tool esterni.

Accessibility Checker verifica oltre 40 regole basate sulle WCAG 2.1 livello A/AA/AAA: copre quindi gran parte dei criteri, dai form ai link, dalle immagini alla struttura delle intestazioni. Lo scopo è aiutare a rendere il sito conforme a WCAG, ADA, Section 508, AODA e altre normative fornendo un feedback continuo durante lo sviluppo. Tra i vantaggi dichiarati: non necessita di chiamate esterne (tutto il checking avviene in locale sul server, quindi è GDPR compliant e non impatta le performance del sito), e funziona con i principali page builder (Elementor, Divi, Beaver Builder, ecc.). La versione gratuita consente scansioni illimitate di post e pagine standard, mentre la versione Pro aggiunge scansione di tipi di post personalizzati (es. prodotti WooCommerce), scansioni dell’intero sito on demand, riepiloghi centralizzati di tutti gli errori riscontrati, e funzioni di gestione (come ignorare determinati falsi positivi, esportare report, ecc.).

In sostanza, Accessibility Checker diventa come un “validator WCAG integrato” nel CMS: ogni volta che si salva un contenuto, effettua i controlli e guida il redattore su cosa sistemare. Ciò riduce la necessità di correzioni costose a posteriori e soprattutto forma il team a produrre fin da subito contenuti accessibili. Ad esempio, se un editor prova a pubblicare un articolo con un’immagine non descritta, vedrà l’errore e imparerà a inserire sempre il testo alternativo. Questo approccio proattivo è fortemente raccomandato dagli esperti, perché costruire l’accessibilità by-design è più efficace che “ripararla” dopo. Il plugin, raccomandato anche da professionisti certificati IAAP, può essere visto come parte di un workflow di qualità: simile ai controlli ortografici o SEO integrati, ora c’è il controllo accessibilità.

Per uno sviluppatore o agenzia che realizza siti WordPress, strumenti come Accessibility Checker aiutano a garantire la conformità legale (evitando che errori grossolani passino inosservati) e a dimostrare ai clienti l’attenzione a questi aspetti. Un sito creato con il supporto di Accessibility Checker ha buone probabilità di essere già aderente agli standard richiesti (spesso si raggiunge con facilità il livello AA su tutti i contenuti testuali). Chiaramente non tutto può essere automatizzato (ad esempio, la valutazione della chiarezza del linguaggio o l’appropriatezza di un testo alternativo richiede giudizio umano), ma il plugin copre la gran parte dei requisiti oggettivi.

In conclusione, Equalize Digital Accessibility Checker è lo strumento ideale “dall’interno” per chi vuole fare dell’accessibilità una pratica quotidiana di sviluppo. Abbinato a test manuali con utenti reali e ad eventuali audit professionali sui dettagli più complessi, offre un solido punto di partenza per avere siti WordPress non solo belli e performanti, ma anche inclusivi e a prova di legge.

Conclusioni

L’accessibilità web non è più un aspetto opzionale o di nicchia: è diventata parte integrante di ciò che significa progettare esperienze digitali di qualità. Come abbiamo visto, investire in accessibilità porta benefici trasversali: include milioni di potenziali clienti in più, migliora l’usabilità generale, rafforza il brand come attento e innovativo, e mantiene il business al riparo da sanzioni o contenziosi. Per imprenditori digitali e sviluppatori, adottare le linee guida WCAG e seguire le best practice descritte significa mettere gli utenti al centro, tutti gli utenti nessuno escluso.

Naturalmente, raggiungere un’elevata conformità richiede impegno: a volte bisogna correggere codice preesistente, modificare design o rivedere alcuni flussi. Ma gli strumenti a supporto non mancano – dai validator automatici, ai plugin WordPress come quelli citati, fino ai servizi di consulenza specialistica. L’importante è iniziare fin da subito: ad esempio effettuando un primo audit di accessibilità del proprio sito per capire i punti critici, quindi pianificando gli adeguamenti necessari (magari partendo dalle priorità WCAG livello A/AA), coinvolgendo il team in formazione specifica e prevedendo la verifica continua ad ogni nuovo contenuto o funzionalità.

Vale la pena ricordare che l’accessibilità non è una lista di controllo da soddisfare una tantum, ma un processo continuo di miglioramento. Le tecnologie evolvono, così come le esigenze degli utenti. Mantenere un sito accessibile significa anche aggiornarsi sulle nuove versioni degli standard (come WCAG 2.2 e oltre) e sulle normative. Significa testare periodicamente con utenti reali, perché nessun test automatico può sostituire il riscontro diretto di una persona cieca, sorda o con dislessia che prova ad usare il vostro e-commerce. In definitiva, significa adottare una filosofia progettuale inclusiva: dalla concezione iniziale fino ai piccoli aggiornamenti di contenuto, chiedersi sempre “questo elemento è fruibile da tutti?”.

In un mondo dove il digitale permea ogni aspetto della vita (dallo shopping al lavoro, dalla formazione ai servizi pubblici), garantire accessibilità è un dovere etico e un contributo a una società più equa. Ma è anche – come abbiamo sottolineato – una strategia intelligente di business e di sviluppo. Le aziende e i professionisti che si muovono per tempo su questo fronte acquisiscono un vantaggio competitivo e dimostrano leadership. Come recita un famoso detto di Tim Berners-Lee (inventore del Web): “The power of the Web is in its universality. Access by everyone, regardless of disability, is an essential aspect” – il potere del Web sta nella sua universalità. Renderlo davvero per tutti è compito nostro, ed è ciò che in ultima analisi farà del Web un luogo migliore.

Fonti e riferimenti utilizzati

edoardo guzzi - web designer e sviluppo siti web

Cerchi un web designer esperto per la realizzazione di siti web professionali?

Mi chiamo Edoardo Guzzi e da oltre 10 anni aiuto aziende e startup a sviluppare siti web performanti, ottimizzati per la SEO e pensati per convertire.

Mi occupo di sviluppo siti web su WordPress e Odoo, creazione di e-commerce, ottimizzazione UX/UI e strategie per migliorare la visibilità online.

Opero tra Svizzera e Italia, offrendo soluzioni su misura per chi vuole distinguersi sul web. Scopri di più su aifb.ch, webwakeup.it.

Scopri chi sono

> Accessibilità Web ed E-commerce: Guida Completa per Siti Inclusivi e a Norma

Table Of Contents