L'accessibilità dei siti web non è più soltanto un tema legato alla User Experience. Per molte aziende e servizi digitali è diventata anche un requisito normativo, oltre che un elemento importante per permettere al maggior numero possibile di persone di utilizzare siti, ecommerce e applicazioni.
In Europa il quadro è diventato particolarmente rilevante con l'European Accessibility Act, applicabile dal 28 giugno 2025 a una serie di prodotti e servizi, compresi i servizi di commercio elettronico.
Dal punto di vista tecnico, uno dei principali riferimenti internazionali è rappresentato dalle WCAG 2.2 – Web Content Accessibility Guidelines, pubblicate dal W3C, che definiscono criteri per rendere i contenuti web maggiormente accessibili alle persone con disabilità visive, uditive, motorie, cognitive e neurologiche.
Ma cosa prevedono realmente le WCAG? Qual è il rapporto con la normativa europea? E come è possibile capire se un sito web o un ecommerce presenta problemi di accessibilità?
Cosa sono le WCAG 2.2?
Le WCAG 2.2 sono linee guida internazionali sviluppate dal Web Accessibility Initiative del W3C per rendere i contenuti web più accessibili.
La versione 2.2 è stata pubblicata come W3C Recommendation nel 2023 e amplia le precedenti WCAG 2.1 introducendo nuovi criteri di successo, con particolare attenzione anche a persone con disabilità cognitive, visive e motorie e all'utilizzo di dispositivi touch.
Le WCAG sono organizzate attraverso:
- principi generali di accessibilità;
- linee guida;
- criteri di successo verificabili;
- livelli di conformità A, AA e AAA.
WCAG livello A, AA e AAA: cosa significa?
I criteri WCAG sono suddivisi in tre livelli.
- Livello A: comprende i requisiti di accessibilità di base.
- Livello AA: aggiunge criteri più avanzati ed è il livello utilizzato più frequentemente come riferimento nei progetti di accessibilità web.
- Livello AAA: comprende requisiti ancora più stringenti e non è necessariamente applicabile integralmente a qualsiasi sito o tipologia di contenuto.
È però importante distinguere tra conformità alle WCAG e conformità normativa: rispettare un determinato livello WCAG non significa automaticamente soddisfare ogni requisito previsto dalla normativa applicabile al proprio servizio.
Se vuoi conoscere i principali requisiti da verificare sul tuo sito, contattaci compilando il nostro form per ricevere maggiori informazioni.
WCAG 2.2 ed European Accessibility Act: qual è la differenza?
Le WCAG sono uno standard tecnico sviluppato dal W3C, mentre l'European Accessibility Act è una direttiva europea che stabilisce requisiti di accessibilità per determinati prodotti e servizi.
In Italia la direttiva è stata recepita attraverso il Decreto Legislativo 27 maggio 2022, n. 82.
Il decreto si applica, tra gli altri, a:
- servizi di commercio elettronico;
- servizi bancari per consumatori;
- e-book e relativo software;
- determinati servizi di trasporto passeggeri;
- servizi di comunicazione elettronica;
- servizi che consentono l'accesso a media audiovisivi.
Le disposizioni previste dal decreto sono applicabili dal 28 giugno 2025, con alcune eccezioni e disposizioni transitorie.
L'European Accessibility Act si applica a tutti i siti web?
No. Uno degli errori più frequenti è affermare che dal 28 giugno 2025 qualsiasi sito aziendale debba automaticamente rispettare gli stessi obblighi.
Il campo di applicazione dipende dal soggetto e soprattutto dal tipo di prodotto o servizio offerto.
Il Decreto Legislativo 82/2022 comprende espressamente i servizi di commercio elettronico, mentre le microimprese che forniscono servizi sono escluse dall'applicazione del decreto.
Esistono inoltre deroghe e situazioni specifiche, ad esempio quando l'adeguamento determinerebbe una modifica sostanziale del prodotto o servizio oppure un onere sproporzionato, secondo le condizioni previste dalla normativa.
Per valutare l'obbligo applicabile a una specifica azienda è quindi necessario analizzare il singolo caso e non basarsi esclusivamente sulla tipologia di sito.
EN 301 549 e WCAG: quale standard si applica in Europa?
Nel quadro europeo è importante considerare anche la norma tecnica EN 301 549, dedicata ai requisiti di accessibilità dei prodotti e servizi ICT.
La versione EN 301 549 v3.2.1, attualmente utilizzata come riferimento armonizzato in ambito europeo, incorpora i criteri delle WCAG 2.1 livello A e AA e comprende anche requisiti ulteriori.
Nel 2026 è stata pubblicata una nuova versione della norma EN 301 549 che adotta le WCAG 2.2 come riferimento tecnico. La nuova versione rappresenta la direzione futura dello standard europeo, ma il suo utilizzo come riferimento armonizzato richiede la formale citazione nella Gazzetta ufficiale dell'Unione europea.
Per questo, progettare oggi secondo WCAG 2.2 livello AA può essere una scelta utile per preparare un'interfaccia ai requisiti più aggiornati, ma non bisogna confondere questo obiettivo tecnico con la verifica completa della conformità normativa.
I 4 principi delle WCAG: POUR
Le WCAG si basano su quattro principi fondamentali, riassunti dall'acronimo POUR:
- Perceivable – Percepibile;
- Operable – Utilizzabile;
- Understandable – Comprensibile;
- Robust – Robusto.
1. Percepibile
Le informazioni devono poter essere percepite dagli utenti anche quando non possono utilizzare uno specifico senso, come vista o udito.
Testi alternativi per le immagini
Le immagini informative devono fornire un'alternativa testuale adeguata. Le immagini puramente decorative dovrebbero invece poter essere ignorate dalle tecnologie assistive.
Sottotitoli e alternative ai contenuti multimediali
I contenuti audio e video devono essere valutati considerando sottotitoli, trascrizioni e, quando richiesto dal criterio applicabile, audiodescrizioni o altre alternative accessibili.
Contrasto dei colori
Per il testo normale, il criterio WCAG AA prevede generalmente un rapporto di contrasto minimo di 4.5:1. Per testi grandi il requisito può essere inferiore, mentre elementi grafici e componenti dell'interfaccia sono soggetti a criteri specifici.
Zoom e reflow
Gli utenti devono poter ingrandire i contenuti e utilizzare il sito senza perdere informazioni o funzionalità, nei limiti previsti dai criteri WCAG applicabili.
2. Utilizzabile
Componenti e navigazione devono poter essere utilizzati attraverso differenti modalità di interazione.
Navigazione da tastiera
Le principali funzionalità del sito devono poter essere utilizzate senza dipendere esclusivamente dal mouse o dal touch.
Pulsanti, link, menu, form e altri componenti interattivi devono essere raggiungibili e utilizzabili da tastiera senza creare blocchi nella navigazione.
Focus visibile
Durante la navigazione da tastiera deve essere possibile capire chiaramente quale elemento dell'interfaccia possiede il focus.
Contenuti in movimento
Slider, caroselli e altri elementi animati devono essere progettati tenendo conto della possibilità, quando richiesta, di mettere in pausa, fermare o controllare il movimento.
Target touch sufficientemente utilizzabili
WCAG 2.2 dedica particolare attenzione anche alla dimensione e alla distanza degli elementi interattivi, per ridurre il rischio di attivazioni involontarie soprattutto per persone con difficoltà motorie.
3. Comprensibile
Contenuti e interazioni devono essere chiari e prevedibili.
Lingua della pagina
Il documento deve dichiarare correttamente la lingua principale e, quando necessario, indicare i cambi di lingua all'interno dei contenuti.
Form accessibili
I campi devono avere etichette comprensibili e gli errori devono essere segnalati in modo chiaro, evitando di affidare l'informazione esclusivamente al colore.
Aiuto e autenticazione accessibile
WCAG 2.2 introduce inoltre nuovi criteri relativi alla coerenza dei meccanismi di aiuto e all'autenticazione accessibile, con l'obiettivo di ridurre alcune barriere cognitive durante operazioni come login e compilazione di processi complessi.
4. Robusto
Il contenuto deve poter essere interpretato correttamente da browser, dispositivi e tecnologie assistive.
Questo significa utilizzare HTML semantico e costruire componenti che espongano correttamente informazioni come:
- nome;
- ruolo;
- stato;
- valore;
- etichette accessibili.
Gli attributi ARIA possono aiutare quando l'HTML nativo non è sufficiente, ma devono essere utilizzati correttamente e solo quando necessari.
Quali sono le principali novità delle WCAG 2.2?
WCAG 2.2 ha introdotto nuovi criteri rispetto alla versione 2.1, concentrandosi in particolare su navigazione da tastiera, focus, dimensione dei target, autenticazione e assistenza durante la compilazione.
Tra i temi introdotti troviamo:
- focus non nascosto;
- aspetto del focus;
- dimensione minima dei target interattivi;
- aiuto coerente;
- riduzione della necessità di reinserire le stesse informazioni;
- autenticazione più accessibile.
Il precedente criterio 4.1.1 Parsing è invece stato rimosso nella versione WCAG 2.2.
Accessibilità ecommerce: quali elementi controllare?
Per un ecommerce l'accessibilità riguarda l'intero percorso d'acquisto e non soltanto le pagine informative.
Tra gli elementi da verificare troviamo:
- menu e navigazione;
- ricerca;
- filtri;
- schede prodotto;
- gallery e immagini;
- selettori di taglia, colore e variante;
- carrello;
- checkout;
- form;
- login e registrazione;
- pagamenti;
- messaggi di errore;
- contenuti dinamici;
- cookie banner e altri overlay;
- email e documentazione collegate al servizio, quando applicabile.
Nel quadro dell'European Accessibility Act sono particolarmente rilevanti anche le funzionalità di identificazione, sicurezza e pagamento fornite nell'ambito del servizio ecommerce.
Accessibilità, User Experience e SEO
Accessibilità, UX e SEO non sono la stessa disciplina, ma condividono alcune buone pratiche.
Un sito accessibile tende a richiedere particolare attenzione a:
- struttura semantica dei contenuti;
- gerarchia degli heading;
- testi dei link comprensibili;
- alternative testuali alle immagini;
- navigazione coerente;
- form ben strutturati;
- esperienza mobile;
- chiarezza dei contenuti.
Molti di questi elementi possono avere benefici anche sulla qualità generale del sito e sulla comprensibilità dei contenuti da parte dei motori di ricerca.
È però importante evitare una semplificazione frequente: la conformità WCAG non rappresenta di per sé un fattore diretto di ranking SEO. Accessibilità e SEO hanno obiettivi differenti, anche se alcune attività possono produrre benefici comuni.
Un plugin rende automaticamente un sito accessibile?
No. Widget e plugin che permettono di modificare contrasto, dimensione del testo o altre impostazioni possono offrire funzionalità aggiuntive, ma non risolvono automaticamente problemi presenti nel codice, nella struttura o nei contenuti.
Problemi come:
- form privi di label;
- componenti non utilizzabili da tastiera;
- ordine del focus scorretto;
- markup semantico errato;
- contrasto insufficiente;
- messaggi di errore poco comprensibili;
- componenti JavaScript non accessibili;
- alternative testuali mancanti;
richiedono generalmente interventi sul design, sul codice o sui contenuti.
Come verificare l'accessibilità di un sito web?
La valutazione dell'accessibilità richiede un processo strutturato che combini strumenti automatici e verifica manuale.
1. Audit tecnico iniziale
Analizziamo template, codice, componenti UI, contenuti e comportamenti interattivi per individuare possibili barriere rispetto ai criteri tecnici applicabili al progetto.
2. Test automatici
Validator, scanner ed estensioni dedicate permettono di individuare rapidamente alcune categorie di problemi, come determinati errori di contrasto, markup o attributi mancanti.
I test automatici non sono però sufficienti per determinare da soli la conformità complessiva di un sito.
3. Test manuali
La verifica deve essere completata con test manuali su aspetti che richiedono valutazione umana.
Tra questi:
- navigazione esclusivamente da tastiera;
- ordine e visibilità del focus;
- utilizzo con screen reader;
- correttezza dei testi alternativi;
- comprensibilità dei messaggi di errore;
- sequenza logica dei contenuti;
- funzionamento dei componenti dinamici;
- zoom e reflow;
- utilizzo su differenti dispositivi.
4. Piano di remediation
Le criticità vengono organizzate in base a severità, impatto sull'utente, diffusione e priorità di intervento.
Il piano può coinvolgere designer, sviluppatori e content editor, perché l'accessibilità non riguarda soltanto il codice.
5. Retest
Dopo la remediation è necessario verificare nuovamente i componenti modificati per controllare che il problema sia effettivamente risolto e che l'intervento non abbia introdotto nuove criticità.
6. Monitoraggio continuo
L'accessibilità non è un'attività da svolgere una sola volta.
Nuovi contenuti, plugin, template, funzionalità e campagne possono introdurre nuove barriere. Per questo è utile integrare controlli di accessibilità nei processi di design, sviluppo e pubblicazione.
Test automatico o audit manuale: cosa serve?
Un report generato automaticamente può rappresentare un buon punto di partenza, ma non è sufficiente per dichiarare che un sito sia accessibile o conforme.
Molti criteri richiedono infatti una valutazione contestuale: un software può rilevare la presenza di un attributo alt, ad esempio, ma non sempre può stabilire se il testo alternativo descriva correttamente il contenuto dell'immagine.
Per questo un audit completo combina automazione, analisi manuale e test delle interazioni reali.
Quando intervenire sull'accessibilità di un sito?
Il momento migliore è durante la progettazione.
Integrare i requisiti di accessibilità fin dall'inizio permette di considerarli nella scelta di colori, componenti, navigazione, form e struttura del codice.
È comunque possibile intervenire anche su un sito esistente attraverso un'attività di accessibility remediation.
In presenza di problemi strutturali importanti può invece essere utile valutare un redesign più ampio.
Accessibilità by design: prevenire è meglio che correggere
L'approccio più efficace consiste nel considerare l'accessibilità come requisito del progetto e non come controllo finale.
Questo significa coinvolgerla durante:
- UX Design;
- UI Design;
- sviluppo;
- creazione dei componenti;
- scrittura dei contenuti;
- Quality Assurance;
- data entry;
- manutenzione.
In questo modo diventa più semplice mantenere nel tempo un livello di accessibilità coerente anche quando il sito evolve.
Vuoi verificare l'accessibilità del tuo sito o ecommerce?
In Addlab possiamo supportare aziende e organizzazioni nell'analisi tecnica dell'accessibilità del sito, nell'individuazione delle criticità e nella definizione degli interventi necessari su UX, UI, codice e contenuti.
Possiamo inoltre integrare i requisiti di accessibilità all'interno di nuovi progetti di sviluppo o redesign, evitando di considerarli soltanto dopo la pubblicazione.
Contattaci se vuoi maggiori informazioni o vuoi valutare l'accessibilità del tuo sito o ecommerce.