Ti è stato chiesto di garantire che un sito web o un'applicazione sia conforme alle WCAG. Poi, un altro documento cita la norma EN 301 549. Il team tecnico inizia a cercare di capire quale standard utilizzare e cosa debba essere effettivamente testato.
La confusione è comprensibile. I due standard sono strettamente collegati, ma hanno ruoli e ambiti di applicazione differenti.
Per i team che creano o gestiscono prodotti digitali, questa distinzione è importante, soprattutto quando l'accessibilità deve essere integrata nei processi di design, sviluppo, QA e conformità.
Cos'è la norma EN 301 549?
EN 301 549 è lo standard europeo per i requisiti di accessibilità di prodotti e servizi di tecnologia dell'informazione e della comunicazione (TIC).
Il suo ambito di applicazione è più ampio dei soli siti web. Lo standard copre i requisiti per tecnologie come siti web e documenti non web, software e applicazioni mobili, hardware e altri prodotti e servizi TIC.
Questo cambia la prospettiva per un team di prodotto.
Se la tua organizzazione gestisce un servizio digitale complesso, l'accessibilità deve essere considerata in tutte le componenti rilevanti di tale servizio, non solo nella pagina web principale.
Per i team tecnici, la norma EN 301 549 fornisce requisiti che possono essere integrati nelle specifiche, nei processi di approvvigionamento, nello sviluppo e nei test.
La Commissione Europea chiarisce che lo standard va oltre i requisiti delle WCAG. Di conseguenza, soddisfare tutti i criteri di successo WCAG pertinenti non significa automaticamente che tutti i requisiti della EN 301 549 siano stati coperti.
Qual è il ruolo delle WCAG?
Le WCAG (Web Content Accessibility Guidelines) sono lo standard internazionale sviluppato dal W3C per l'accessibilità dei contenuti web.
I criteri di successo WCAG sono organizzati attorno a quattro principi:
- Percepibile
- Utilizzabile
- Comprensibile
- Solido
Sotto questi principi si trovano criteri di successo verificabili, organizzati in tre livelli di conformità: A, AA e AAA.
In pratica, questi criteri si traducono in requisiti molto concreti.
Un'immagine informativa necessita di un'alternativa testuale appropriata.
Il contenuto deve avere un contrasto sufficiente.
Le funzionalità devono essere utilizzabili attraverso i metodi richiesti dai criteri di successo applicabili.
I moduli devono essere implementati in modo che le informazioni e le relazioni necessarie agli utenti possano essere determinate a livello programmatico, laddove richiesto dal criterio pertinente.
Il focus della tastiera deve essere visibile e tracciabile.
I componenti interattivi devono essere implementati in modo che le tecnologie assistive possano ricevere le informazioni necessarie al loro riguardo.
Improvvisamente, l'“accessibilità” diventa un insieme di requisiti che un designer, uno sviluppatore e uno specialista QA possono effettivamente discutere e testare.
EN 301 549 e WCAG non sono la stessa cosa
Questa è una delle distinzioni più importanti da comprendere.
Le WCAG si concentrano sull'accessibilità dei contenuti web. La norma EN 301 549 ha un ambito ICT più ampio e incorpora i requisiti WCAG per i contenuti web all'interno della propria struttura, insieme a requisiti aggiuntivi.
La versione della norma EN 301 549 attualmente rilevante per i requisiti di accessibilità armonizzati europei utilizza le WCAG 2.1. La Commissione Europea dichiara che le WCAG 2.2 non sono ancora utilizzate in uno standard EN 301 549 armonizzato tramite la pubblicazione del relativo riferimento nella Gazzetta ufficiale dell'Unione europea.
Questa distinzione è importante nel 2026.
Ma le WCAG 2.2 esistono già
Le WCAG 2.2 sono l'ultima versione definitiva della famiglia WCAG e il W3C raccomanda di utilizzare la versione più recente quando le organizzazioni sviluppano o aggiornano le proprie politiche e pratiche di accessibilità.
Le WCAG 2.2 aggiungono nove nuovi criteri di successo rispetto alle WCAG 2.1. Questi includono requisiti relativi all'aspetto del focus, alla dimensione minima dei target, alle alternative alle interazioni di trascinamento, all'autenticazione accessibile e all'evitare l'inserimento ridondante di informazioni in determinate situazioni.
Dal 2025, le WCAG 2.2 sono anche uno standard internazionale ISO: ISO/IEC 40500:2025.
Per un team tecnico, questo crea una distinzione tra lo standard europeo utilizzato per il quadro normativo di riferimento e la versione delle WCAG raccomandata dal W3C per l'attuale sviluppo dell'accessibilità.
Il W3C spiega inoltre che i contenuti conformi alle WCAG 2.2 sono conformi anche alle WCAG 2.1 e 2.0, grazie al modo in cui sono state progettate le versioni successive.
Cosa significa questo per i team di prodotto?
L'accessibilità funziona meglio quando diventa parte dei requisiti di prodotto prima dell'inizio dello sviluppo.
Prendiamo come esempio un semplice modulo di creazione account.
Il team definisce i campi e le regole di convalida. L'UX definisce l'interazione. Il design prepara i componenti e i relativi stati. Lo sviluppo li implementa. Il QA verifica il risultato.
Se l'accessibilità viene presa in considerazione solo dopo il lancio, i problemi riscontrati potrebbero richiedere modifiche in diverse di queste aree.
Se i requisiti vengono definiti durante la pianificazione, il team può discutere fin da subito di etichette, focus, messaggi di errore, contrasto e navigazione da tastiera.
Questo riduce anche le situazioni in cui l'accessibilità diventa un elenco separato di bug da correggere dopo il rilascio.
Cosa dovrebbero considerare i team di UX e Design?
Un buon design system può evitare che lo stesso problema di accessibilità si ripeta su decine di pagine.
Pulsanti, moduli, finestre modali, navigazione, componenti interattivi e stati di focus dovrebbero essere tutti definiti includendo i requisiti di accessibilità nelle loro specifiche.
Il contrasto è un esempio evidente.
Ma l'accessibilità non si limita al colore.
I designer devono anche considerare come gli utenti comprendono la gerarchia delle informazioni, gli stati dei componenti, i messaggi di errore e le interazioni che non dipendono da un unico metodo di input.
Un componente può apparire perfetto in un file di design e creare comunque problemi di accessibilità dopo l'implementazione.
Ecco perché i test di accessibilità devono proseguire anche nel prodotto funzionale.
Cosa dovrebbero considerare i team di sviluppo?
L'HTML semantico e la corretta implementazione dei componenti giocano un ruolo diretto nell'accessibilità.
Gli sviluppatori devono capire cosa succede quando un utente mette da parte il mouse e prova a navigare nell'interfaccia usando solo la tastiera.
Altrettanto importante è ciò che ricevono le tecnologie assistive.
Qual è il nome accessibile del componente?
Qual è il suo ruolo?
In quale stato si trova?
Cosa succede al focus quando si apre o si chiude una finestra modale?
Il modulo può essere effettivamente compilato?
Queste domande sono molto più utili durante lo sviluppo rispetto al vago requisito secondo cui "la pagina deve essere accessibile".
Cosa dovrebbero considerare i team di QA?
I test automatizzati sono utili, ma non possono verificare autonomamente ogni requisito di accessibilità.
Il W3C spiega che le WCAG sono progettate in modo che la conformità possa essere valutata attraverso una combinazione di valutazione automatizzata e giudizio umano.
È qui che i test manuali rimangono fondamentali.
Il QA può verificare la navigazione da tastiera, l'ordine di focus e il comportamento dei componenti. I test con tecnologie assistive aggiungono un ulteriore livello di validazione.
I test automatizzati, d'altra parte, possono identificare rapidamente determinati problemi ricorrenti su molte pagine.
Combinare questi metodi offre un quadro molto più utile rispetto all'affidarsi a un singolo punteggio.
Un punteggio di accessibilità non racconta tutta la storia
La dashboard mostra 92/100. Sembra ottimo.
Ma cosa succede se il problema rimanente riguarda proprio il pulsante che finalizza un pagamento?
L'impatto sull'utente non è necessariamente proporzionale al numero totale di errori.
Ecco perché i team dovrebbero considerare anche la gravità di un problema, il componente interessato e la sua posizione all'interno di un percorso utente critico.
Il checkout, l'autenticazione, la creazione di un account, il pagamento e la prenotazione sono esempi in cui una singola barriera di accessibilità può impedire a un utente di completare un'azione.
Le priorità di risoluzione dovrebbero tenere conto di questo contesto.
L'accessibilità continua dopo il rilascio
Un prodotto digitale cambia.
Vengono aggiunte nuove pagine, componenti e integrazioni. Il team di marketing pubblica nuovi contenuti. Un modulo viene modificato. L'esperienza di checkout viene aggiornata.
Un test eseguito sei mesi fa descrive il prodotto com'era sei mesi fa.
Ecco perché il tuo processo dovrebbe includere test dopo modifiche rilevanti e il monitoraggio dei problemi che potrebbero emergere man mano che il prodotto si evolve.
Wawsome può aiutare a identificare i problemi di accessibilità rilevabili automaticamente e a monitorare l'accessibilità del sito web nel tempo.
Come dovrebbe essere un processo interno di accessibilità?
Per un team che gestisce costantemente un prodotto digitale, l'accessibilità dovrebbe essere presente in più fasi del processo.
Nei requisiti, quando viene definita la funzionalità.
Nel design system, per i componenti riutilizzabili.
Nello sviluppo e nella revisione del codice, quando tali componenti vengono implementati.
Nel QA, tramite test automatizzati e manuali.
Dopo il rilascio, monitorando e testando nuovamente le aree che hanno subito modifiche.
Questo trasforma le norme EN 301 549 e WCAG da standard astratti in requisiti concreti, attività di sviluppo e casi di test con cui i team possono lavorare concretamente.
FAQ
Dovrei usare le WCAG 2.1 o le WCAG 2.2?
La norma EN 301 549 utilizza attualmente le WCAG 2.1 nella versione armonizzata pertinente a livello europeo. Il W3C raccomanda di utilizzare l'ultima versione delle WCAG e dichiara che i contenuti conformi alle WCAG 2.2 sono conformi anche alle WCAG 2.1.
Per gli obblighi legali, è necessario verificare lo standard specifico e il quadro normativo applicabile al prodotto o servizio in questione.
Se sono conforme alle WCAG, significa automaticamente che sono conforme alla EN 301 549?
No. La norma EN 301 549 ha un ambito di applicazione più ampio. La Commissione Europea dichiara esplicitamente che il solo rispetto di tutti i criteri di successo delle WCAG 2.1 non fornisce una presunzione di conformità a tutti i requisiti pertinenti basati sulla EN 301 549.
Posso testare automaticamente tutti i criteri di successo WCAG?
No. La valutazione dell'accessibilità richiede anche controlli che coinvolgono il giudizio umano. I test automatizzati sono utili per le problematiche rilevabili tecnicamente e in modo coerente, ma non possono sostituire la valutazione manuale.
Quando dovrei testare l'accessibilità?
Durante lo sviluppo e prima del rilascio, e di nuovo dopo modifiche che potrebbero influire sull'esperienza utente. Per i prodotti aggiornati frequentemente, un monitoraggio costante può aiutare i team a identificare nuovi problemi non appena si presentano.
Da dove iniziare?
Se il tuo team gestisce un sito web esistente, inizia comprendendo quali problemi di accessibilità possono essere identificati subito. I risultati di una scansione iniziale possono fornire un punto di partenza per dare priorità ai test successivi e alla risoluzione dei problemi.
Per una valutazione completa, i risultati automatizzati dovrebbero essere integrati con i controlli manuali necessari per i criteri che non possono essere valutati automaticamente.