EN 301 549 e WCAG: comprendere la norma tecnica dell’UE

Nelle settimane successive al 28 giugno 2025 — la data in cui il European Accessibility Act è diventato applicabile — le organizzazioni francesi di tutela dei diritti delle persone con disabilità hanno inviato diffide formali a quattro grandi catene di supermercati, chiedendo che le loro piattaforme di e-commerce rispettassero gli standard di accessibilità entro pochi mesi. A novembre sono seguiti provvedimenti d’urgenza. Questo non è un rischio ipotetico futuro. La conformità a EN 301 549 è ora una realtà di enforcement attivo, e comprendere lo standard tecnico che la sostiene non è più facoltativo per nessuna organizzazione che serva utenti europei.

Che cos’è EN 301 549?

EN 301 549 è uno standard europeo che specifica i requisiti di accessibilità per i prodotti e i servizi di tecnologie dell’informazione e della comunicazione (ICT), stabilendo linee guida per l’accessibilità digitale, anche per le persone con disabilità. Non è una legge in sé, ma è il ponte tecnico fondamentale tra le linee guida che gli sviluppatori già conoscono e la legislazione che ha una reale forza legale.

Questo standard è stato prodotto congiuntamente dalle tre organizzazioni europee di normazione — CEN (Comitato Europeo di Normazione), CENELEC (Comitato Europeo di Normazione Elettrotecnica) ed ETSI (European Telecommunications Standards Institute). EN 301 549 è stato pubblicato originariamente nel 2014 per supportare gli appalti pubblici di ICT accessibili ed è stato aggiornato più volte da allora.

EN 301 549 armonizza gli standard di accessibilità digitale tra gli Stati membri dell’UE, creando un quadro unificato per valutare e migliorare l’accessibilità dei prodotti e servizi ICT. La conformità a EN 301 549 è richiesta per i prodotti e servizi tecnologici che rientrano nell’ambito della Direttiva UE sull’accessibilità del web (WAD) ed è una best practice per la conformità al European Accessibility Act (EAA).

EN 301 549 è uno standard europeo di accessibilità che definisce criteri tecnici di accessibilità per prodotti e servizi ICT. Sviluppato da un consorzio di agenzie europee, questo standard fornisce indicazioni dettagliate per garantire che varie tecnologie — inclusi hardware, software, siti web, app mobili e apparecchiature di telecomunicazione — siano accessibili alle persone con disabilità. In altre parole, se la tua organizzazione rientra in una di queste categorie e opera nel mercato UE, questo standard è pensato per te.

Il rapporto tra EN 301 549 e WCAG

La domanda più comune da parte di sviluppatori e responsabili della conformità è: se siamo già conformi a WCAG, abbiamo finito? La risposta onesta è: in gran parte sì, ma non del tutto. Comprendere il rapporto preciso tra questi due framework è essenziale prima di poter rispondere a questa domanda per la tua situazione specifica.

EN 301 549 incorpora le Web Content Accessibility Guidelines (WCAG) come fondamento per i requisiti di accessibilità digitale. L’ultima versione di EN 301 549, la versione 3.2.1, integra WCAG 2.1 nella sua interezza. Non si tratta solo di un rinvio per citazione — l’ultima versione dello standard, EN 301 549 V3.2.1, include il testo completo di WCAG 2.1. I due standard condividono la stessa architettura di base: EN 301 549 segue gli stessi principi fondamentali di WCAG: Perceivable (Percepibile), Operable (Utilizzabile), Understandable (Comprensibile), Robust (Robusto) (POUR).

La distinzione chiave riguarda l’ambito. Mentre WCAG si concentra principalmente sui contenuti web e mobili, EN 301 549 amplia il proprio ambito per includere hardware, telecomunicazioni e altri componenti ICT, rendendolo un quadro più completo per l’accessibilità digitale. Quindi, per i contenuti web nello specifico, il Capitolo 9 di EN 301 549 fa riferimento diretto ai criteri di successo WCAG 2.1 di livello A e AA. Se i tuoi contenuti web sono conformi a WCAG 2.1 AA, soddisfano i requisiti del Capitolo 9 di EN 301 549.

Tuttavia, c’è una importante sfumatura legale che molti professionisti trascurano. Poiché EN 301 549 va oltre i requisiti delle WCAG, soddisfare tutti i criteri di successo di WCAG 2.1 non garantisce una presunzione di conformità alla Direttiva sull’accessibilità del web. Lo standard contiene clausole aggiuntive — per elementi come comunicazioni testuali in tempo reale, controlli dei video player e accessibilità biometrica — che non hanno un equivalente in WCAG. EN 301 549 è unico in quanto va oltre WCAG, estendendosi a coprire le biometrie — richiedendo che le persone con disabilità abbiano accesso a tecnologie che scansionano dati biologici, inclusi il riconoscimento facciale e le impronte digitali.

WCAG ti dice come rendere accessibili i tuoi contenuti. EN 301 549 ti dice quali tipi di ICT devono essere accessibili e in quale misura — e poi prende in prestito i criteri di WCAG per definire l’asticella tecnica per i contenuti web nello specifico.

La struttura dei capitoli che ti serve davvero conoscere

EN 301 549 è organizzato in 14 clausole (capitoli), ognuna delle quali copre una diversa categoria di ICT. Lo standard è organizzato in capitoli che coprono diversi tipi di ICT, e non tutti i capitoli si applicano a ogni prodotto — la chiave è identificare quali capitoli sono rilevanti per la tua tecnologia specifica. Per la maggior parte dei proprietari di siti web e degli sviluppatori, tre capitoli sono i più immediatamente rilevanti.

Capitolo 9 — Contenuti web: Questo capitolo copre i requisiti di accessibilità web, facendo riferimento diretto a WCAG 2.1 di livello AA, ed è il capitolo più rilevante per siti web e applicazioni web. Il sistema di numerazione rende il confronto incrociato semplice: i numeri delle clausole corrispondono direttamente a WCAG — la clausola EN 301 549 9.X.Y.Z mappa a WCAG X.Y.Z. Ad esempio, la clausola EN 301 549 9.1.4.3 corrisponde a WCAG 1.4.3 (Contrasto).

Capitolo 10 — Documenti non web: Per i documenti e il software non web, EN 301 549 adatta i criteri WCAG a questi contesti. L’intento è lo stesso — i contenuti devono essere percepibili, utilizzabili, comprensibili e robusti — ma le tecniche specifiche differiscono per le applicazioni native e i formati di documento. Questo è estremamente importante per le organizzazioni che pubblicano PDF, documenti Word o fogli di calcolo scaricabili. Una correzione importante arrivata con la v3.2.1: a causa di un errore redazionale nella v2.1.2, WCAG 2.1 ora si applica ai documenti scaricati dal web.

Capitolo 11 — Software non web e app mobili: Questo capitolo copre i requisiti per le applicazioni native (desktop e mobili) e le piattaforme software, inclusi i requisiti per l’interoperabilità con le tecnologie assistive. Vale la pena notare: le applicazioni mobili non sono coperte da WCAG, anche se il Capitolo 11 utilizza requisiti tratti da WCAG. Questo perché WCAG in realtà non si applica alle applicazioni mobili. Se la tua organizzazione distribuisce un’app nativa iOS o Android, il tuo riferimento è il Capitolo 11, non il Capitolo 9.

Oltre a questi tre, capitoli aggiuntivi rilevanti includono il Capitolo 6 (comunicazione vocale bidirezionale e testo in tempo reale), il Capitolo 7 (funzionalità video e audio, incluse sottotitoli e audiodescrizione) e il Capitolo 12 (documentazione e servizi di supporto — l’unico capitolo che non è auto-delimitato e si applica sempre).

Come EN 301 549 si inserisce nel quadro giuridico dell’UE

Esistono due diverse leggi UE che fanno riferimento a EN 301 549, e confonderle porta a lacune di conformità. Comprendere la differenza è particolarmente importante per le organizzazioni del settore privato che hanno dato per scontato che le leggi sull’accessibilità si applicassero solo ai governi.

La prima è la Direttiva sull’accessibilità del web (WAD), Direttiva (UE) 2016/2102. La Direttiva sull’accessibilità del web si concentra principalmente sui siti web e sulle applicazioni mobili del settore pubblico. Tutti i siti web del settore semi-pubblico nell’Unione europea dovevano soddisfare lo standard dal 23 settembre 2020, e tutte le app mobili del settore semi-pubblico dovevano soddisfare lo standard entro il 23 giugno 2021. Gli enti pubblici devono inoltre pubblicare una dichiarazione di accessibilità e fornire un meccanismo di feedback.

La seconda, e ora più rilevante per il settore privato, è il European Accessibility Act (EAA), Direttiva (UE) 2019/882. Per il settore privato, l’Europa ha sviluppato la Direttiva UE 2019/882, nota anche come European Accessibility Act, che è applicabile a settori specifici tra cui e-commerce, servizi bancari, e-book ed elettronica. Il European Accessibility Act è applicabile dal 28 giugno 2025, e tutti i siti web, le app mobili e i servizi digitali coperti devono rispettare gli standard di accessibilità. Questo requisito si applica alle imprese che offrono servizi digitali come e-commerce, servizi finanziari e telecomunicazioni.

Fondamentalmente, l’EAA ha una portata extraterritoriale. In particolare, l’EAA riguarda sia le aziende con sede nell’UE sia le imprese al di fuori dell’Europa che vendono a consumatori dell’UE. Una società SaaS con sede negli Stati Uniti con clienti europei, o un rivenditore del Regno Unito con uno store online per l’UE, rientra nell’ambito. L’unica deroga significativa: le microimprese con meno di 10 dipendenti e meno di 2 milioni di € di fatturato hanno esenzioni limitate, ma la maggior parte delle imprese che operano nell’UE è coperta.

EN 301 549 è lo standard tecnico che fornisce una presunzione di conformità sia ai sensi della WAD che dell’EAA. Conformarsi ad esso è il percorso più chiaro e più difendibile dal punto di vista legale per dimostrare la conformità a entrambe le direttive.

Ciò che EN 301 549 richiede oltre WCAG

Se il tuo team mantiene già la conformità a WCAG 2.1 AA, hai una base solida. Ma diversi requisiti di EN 301 549 si collocano completamente al di fuori di WCAG, ed è utile esaminarli nel dettaglio.

Dichiarazioni di prestazione funzionale: La clausola 4 di EN 301 549 introduce una serie di obiettivi funzionali di alto livello — utilizzo senza vista, senza udito, senza parola, con capacità cognitive limitate e così via. Queste dichiarazioni fungono da rete di sicurezza: se nessun requisito tecnico specifico si applica a una determinata situazione, i prodotti dovrebbero comunque soddisfare l’obiettivo funzionale sottostante. Questo incoraggia i designer a pensare in termini di risultati per l’utente, non solo di conformità a una checklist.

Testo in tempo reale (RTT) e telecomunicazioni: Il Capitolo 6 copre i requisiti per chiamate vocali, videochiamate e testo in tempo reale. Questi sono importanti per servizi VoIP, videoconferenze e telecomunicazioni. Ciò è sempre più rilevante man mano che più organizzazioni integrano funzionalità di chat, audio e video direttamente nelle loro applicazioni web o nei portali clienti.

Documentazione e supporto accessibili: EN 301 549 include criteri che richiedono che guide utente, contenuti di help e assistenza clienti per l’ICT siano accessibili. Il Capitolo 12 si applica a tutti i prodotti senza eccezioni — il che significa che la tua documentazione di supporto, le interfacce per l’apertura di ticket e i chatbot devono tutti soddisfare lo standard insieme al prodotto principale.

Accessibilità dell’hardware: EN 301 549 include criteri a supporto dell’accessibilità dell’hardware — i dispositivi devono essere fisicamente accessibili agli utenti con disabilità, ad esempio offrendo feedback tattile o altezza regolabile per i chioschi. Per la maggior parte dei team che si occupano solo di web, i capitoli sull’hardware non rientrano direttamente nell’ambito. Ma se l’ecosistema del tuo prodotto include dispositivi POS, chioschi self-service o integrazioni con ATM, queste clausole diventano molto rilevanti.

Esistono anche standard specifici per singoli Paesi all’interno dell’Europa che possono andare oltre EN 301 549. Ci sono situazioni in Europa in cui una legge o uno standard locale più specifico supera EN 301 549 — esempi includono BITV in Germania e RGAA in Francia. Le organizzazioni che operano in specifici Stati membri dovrebbero verificare se i recepimenti nazionali hanno introdotto requisiti aggiuntivi rispetto alla base armonizzata.

Livelli di conformità e cosa significa davvero il livello AA

Come WCAG, EN 301 549 prevede tre livelli di conformità: A, AA e AAA. Il livello A si riferisce al livello più basso di conformità (minimo) e il livello AAA è il più alto (massimo). Il livello AA è il livello obbligatorio. In pratica, questo significa che i tuoi contenuti web devono soddisfare tutti i criteri di successo di livello A e AA, senza alcun fallimento, per poter rivendicare una conformità completa.

Il livello AAA non è richiesto — e per una buona ragione. Non si raccomanda che la conformità di livello AAA sia richiesta come politica generale per interi siti, perché non è possibile soddisfare tutti i criteri di successo di livello AAA per alcuni contenuti. Detto ciò, molti criteri di livello AAA — come fornire interpretazione in lingua dei segni per i contenuti audio o offrire audiodescrizioni estese — sono realmente utili per una parte significativa della tua base utenti, e implementarli dove possibile dimostra buona fede.

Una sfumatura importante sul peso legale dei livelli di conformità: le nuove versioni di WCAG o di EN 301 549 non modificano automaticamente gli obblighi legali degli Stati membri rispetto alla WAD. Perché le modifiche abbiano effetto, lo standard deve prima essere aggiornato e poi deve essere citato nella Gazzetta ufficiale. Ciò significa che, sebbene WCAG 2.2 sia stato pubblicato nell’ottobre 2023, diventa giuridicamente vincolante ai sensi della WAD solo quando la versione aggiornata di EN 301 549 lo richiama e tale versione è armonizzata. Per la pianificazione pratica della conformità, tuttavia, progettare secondo WCAG 2.2 è fortemente consigliabile, poiché è la direzione verso cui ci si sta muovendo.

La strada da percorrere: EN 301 549 versione 4.1.1 e WCAG 2.2

L’attuale versione armonizzata di EN 301 549, la v3.2.1, è basata su WCAG 2.1. Ma lo standard è in fase di aggiornamento attivo. EN 301 549 sarà revisionato con l’obiettivo di pubblicare la V4.1.1 nel 2026 a supporto della Direttiva europea (UE) 2019/882 sui requisiti di accessibilità per prodotti e servizi, in risposta al Mandato 587 della Commissione europea.

La prossima versione di EN 301 549, la v4.1.1, è prevista a supporto del European Accessibility Act e includerà WCAG 2.2 AA, oltre a importanti aggiornamenti dei requisiti relativi al testo in tempo reale. WCAG 2.2 ha introdotto nove nuovi criteri di successo, rivolti a utenti con ipovisione, utenti con disabilità cognitive e di apprendimento e utenti mobili con disabilità motorie — aree in cui WCAG 2.1 presentava lacune note. Ha inoltre rimosso il criterio 4.1.1 (Parsing), che i browser moderni avevano reso obsoleto.

L’implicazione pratica per i team che oggi lavorano sull’accessibilità: progettare già ora secondo WCAG 2.2 AA, non WCAG 2.1. EN 301 549 definisce requisiti tecnici e attualmente include WCAG 2.1. Tuttavia, lo standard è destinato a essere aggiornato come parte del supporto all’attuazione dell’EAA ed è in corso di aggiornamento per includere WCAG 2.2. Le organizzazioni che attendono l’armonizzazione ufficiale prima di innalzare il proprio obiettivo di conformità si ritroveranno a dover correre per recuperare. Il delta tra WCAG 2.1 e 2.2 a livello AA è di nove criteri — non una riscrittura totale, ma comunque un lavoro significativo.

Vale anche la pena notare la portata globale di EN 301 549. EN 301 549 è stato adottato da altri Paesi come standard volontario, tra cui Australia e Canada, e si allinea strettamente con la Section 508 del Rehabilitation Act negli Stati Uniti. Se la tua organizzazione ha obblighi di conformità a livello globale, allinearsi a EN 301 549 non è solo una strategia per l’UE — ti posiziona bene rispetto a più quadri normativi contemporaneamente.

Passi pratici per proprietari di siti web e team di conformità

Alla luce di tutto quanto sopra, da dove iniziare concretamente? L’approccio seguente funziona per la maggior parte delle organizzazioni focalizzate sul web, anche se i team con app mobili, componenti hardware o di telecomunicazione dovranno sovrapporre i capitoli pertinenti di EN 301 549.

Per prima cosa, stabilisci la tua baseline WCAG 2.1 AA. Poiché EN 301 549 incorpora WCAG 2.1 di livello AA, le organizzazioni che sono già conformi a leggi che fanno riferimento allo standard globale sono ben posizionate per raggiungere la conformità a EN 301 549. Esegui una combinazione di scansioni automatiche e test manuali con tecnologie assistive — screen reader, navigazione solo da tastiera, controllo vocale — sui tuoi percorsi utente più critici. Gli strumenti automatici sono utili ma limitati: gli strumenti automatici intercettano circa il 30–40% delle barriere di accessibilità, e la conformità a EN 301 549 richiede test manuali con tecnologie assistive su flussi di lavoro reali degli utenti.

In secondo luogo, identifica quali capitoli di EN 301 549 si applicano al tuo prodotto. Se il tuo sito offre PDF scaricabili, si applica il Capitolo 10. Se hai un video player incorporato, è rilevante il Capitolo 7. Se offri chat dal vivo o VoIP, esamina il Capitolo 6. Se il tuo prodotto ha un’app mobile complementare, il Capitolo 11 rientra nell’ambito.

In terzo luogo, pubblica una dichiarazione di accessibilità. La Direttiva UE sull’accessibilità del web richiede che siti web e applicazioni mobili abbiano una dichiarazione di accessibilità sul loro livello di conformità, indicando qualsiasi contenuto non accessibile e, ove opportuno, le alternative accessibili fornite. Non si tratta solo di un adempimento burocratico — dimostra buona fede, informa gli utenti su cosa aspettarsi e fornisce un quadro per il monitoraggio continuo delle attività di correzione.

In quarto luogo, aggiorna il tuo obiettivo a WCAG 2.2 AA. Considerato che EN 301 549 v4.1.1 incorporerà WCAG 2.2, iniziare ad affrontare fin da ora i nove nuovi criteri di successo — in particolare quelli relativi all’aspetto del focus, ai movimenti di trascinamento e all’autenticazione accessibile — significa evitare una corsa alla conformità quando la nuova versione sarà armonizzata.

In quinto luogo, integra l’accessibilità nel tuo processo di sviluppo, non sopra di esso. L’accessibilità ai sensi dell’EAA non è una pietra miliare una tantum. Richiede monitoraggio continuo, attività di correzione e sforzi di conformità documentati su tutte le proprietà digitali. Una dichiarazione di accessibilità pubblicata una volta e poi dimenticata è una passività, non un asset. Pianifica audit regolari, integra controlli automatici nella tua pipeline CI/CD e assegna responsabilità chiare per l’accessibilità tra prodotto, design e ingegneria.

Punti chiave

• EN 301 549 è lo standard tecnico armonizzato dell’UE per l’accessibilità ICT, che incorpora integralmente WCAG 2.1 AA per i contenuti web, estendendosi però ben oltre WCAG per coprire hardware, app mobili, documenti, telecomunicazioni e servizi di supporto. Superare WCAG ti porta gran parte del percorso per il tuo sito web, ma non fino in fondo.
• Il European Accessibility Act (EAA) è diventato applicabile il 28 giugno 2025 e si applica alle imprese del settore privato — incluse le aziende non UE — che offrono prodotti o servizi digitali ai consumatori dell’UE. La conformità a EN 301 549 è il meccanismo principale per dimostrare la conformità all’EAA.
• Il Capitolo 9 di EN 301 549 mappa direttamente a WCAG 2.1 AA per i contenuti web, ma i Capitoli 10, 11, 6, 7 e 12 introducono requisiti aggiuntivi per documenti, app mobili, comunicazioni, video e servizi di supporto rispettivamente — tutti elementi che devono essere valutati in relazione all’ambito specifico del tuo prodotto.
• EN 301 549 v4.1.1, la cui pubblicazione è prevista per il 2026, incorporerà WCAG 2.2 AA. Progettare già ora secondo WCAG 2.2 evita debiti di correzione futuri e posiziona la tua organizzazione in anticipo rispetto al prossimo ciclo di armonizzazione.
• La conformità continua è importante quanto la conformità iniziale. Dichiarazioni di accessibilità pubblicate, test manuali con tecnologie assistive reali e processi di governance documentati sono ciò che autorità di controllo e tribunali considerano quando valutano se un’organizzazione prende seriamente l’accessibilità.