Descrizione immagine: Mani su una tastiera meccanica con un documento sugli standard tecnici aperto su un monitor esterno — l’ambiente di lavoro dell’auditor di accessibilità in cui vive EN 301 549.

Tempo di lettura: 11 minuti

EN 301 549 è lo standard europeo armonizzato per i requisiti di accessibilità applicabili ai prodotti e servizi ICT. Pubblicato e mantenuto da ETSI — l’Istituto europeo per le norme di telecomunicazione — in cooperazione con CEN e CENELEC, è lo strumento tecnico che trasforma gli obblighi più astratti dell’European Accessibility Act (EAA), della Direttiva sull’accessibilità dei siti web (Direttiva (UE) 2016/2102) e della maggior parte delle norme nazionali sugli appalti pubblici in un elenco clausola per clausola che può essere misurato su un fornitore. Dove WCAG è uno standard per contenuti e interfacce web, EN 301 549 è il quadro più ampio che incorpora WCAG all’interno dei requisiti effettivamente richiesti dalla normativa UE negli appalti.

Nel 2026 la versione in vigore è la V3.2.1, pubblicata nel marzo 2021 e che incorpora WCAG 2.1 Livello AA per riferimento. Una nuova revisione che incorpora WCAG 2.2 AA — provvisoriamente numerata V4.0.0 — è in fase avanzata di redazione all’interno dell’organismo tecnico congiunto ETSI/CEN/CENELEC e si prevede venga pubblicata nel corso del 2026, con successiva citazione nella Gazzetta Ufficiale dell’Unione europea. Il presente testo è un primer: cosa sia lo standard, come siano organizzati i suoi dodici capitoli, dove si collocano il Capitolo 9 (web) e il Capitolo 11 (software) accanto al Capitolo 10 (documenti) e al Capitolo 12 (documentazione e supporto), come lo standard colleghi WCAG alla normativa UE sugli appalti, e dove viene citato nel quadro legislativo già noto.

Cos’è EN 301 549 — e cosa non è

EN 301 549 è uno standard europeo armonizzato. Questa espressione ha un significato preciso nel diritto UE: si tratta di uno standard sviluppato da uno dei tre Organismi europei di normazione riconosciuti (ETSI, CEN, CENELEC) su richiesta della Commissione europea tramite una formale «richiesta di normalizzazione» (detta anche «mandato»), poi citato nella Gazzetta Ufficiale dell’Unione europea come fonte di «presunzione di conformità» con la corrispondente normativa UE. Un prodotto o servizio che soddisfa lo standard armonizzato è presunto conforme ai requisiti legali che armonizza. La presunzione è confutabile, ma nella pratica gli acquirenti pubblici, i revisori dell’accessibilità e gli organismi di valutazione della conformità trattano lo standard come l’elenco di controllo operativo.

EN 301 549 ha origine dal Mandato M/376, emesso dalla Commissione nel 2005 per rendere le norme europee sugli appalti adeguate all’accessibilità — un riferimento unico, neutro rispetto alla tecnologia e armonizzato per definire cosa si intende per «ICT accessibile» nell’ambito delle procedure di gara del settore pubblico. La prima versione pubblicata, la V1.1.2, è apparsa nel 2014. Da allora lo standard ha subito tre revisioni sostanziali: V2 (2018) allineata a WCAG 2.1, V3.1.1 e V3.2.1 (2019–2021) con definizioni più precise e clausole aggiuntive per app mobile e strumenti di authoring, e la prossima V4 che incorporerà WCAG 2.2.

Cosa EN 301 549 non è: non è l’EAA, e non è la Direttiva sull’accessibilità dei siti web. Queste sono le leggi che fanno riferimento allo standard negli appalti. EN 301 549 è il documento dei criteri di test — la parte del sistema che uno sviluppatore o un responsabile degli appalti legge concretamente per sapere se un prodotto supera la verifica.

La struttura in dodici capitoli

EN 301 549 è organizzato attorno a dodici clausole sostanziali (numerate a partire dalla Clausola 4, poiché le Clausole 1–3 riguardano campo di applicazione e definizioni). L’architettura è deliberatamente modulare: un fornitore che definisce l’ambito di risposta a una gara identifica quali clausole si applicano al prodotto, applica solo quelle e dichiara la conformità rispetto alle clausole citate. I moduli principali si trovano nei Capitoli da 9 a 12.

Capitolo 9 — Contenuti web

Il Capitolo 9 è quello a cui la maggior parte dei professionisti dell’accessibilità arriva per primo, perché è quello che incorpora WCAG per riferimento. Nella V3.2.1, il Capitolo 9 importa verbatim i criteri di successo WCAG 2.1 Livello A e Livello AA: la clausola 9.1 riguarda i criteri di successo percepibili, la 9.2 quelli operabili, la 9.3 quelli comprensibili, la 9.4 quelli robusti. Un prodotto web conforme a WCAG 2.1 AA è conforme al Capitolo 9. Lo standard non parafrasa il testo WCAG; lo cita. Nella V4, lo stesso capitolo farà riferimento a WCAG 2.2 AA, incorporando i nove criteri di successo nuovi e rivisti — tra cui 2.4.11 Focus non oscurato (minimo), 2.4.12 Focus non oscurato (migliorato), 2.4.13 Aspetto del focus, 2.5.7 Movimenti di trascinamento, 2.5.8 Dimensione dell’obiettivo (minima), 3.2.6 Guida coerente, 3.3.7 Inserimento ridondante, 3.3.8 Autenticazione accessibile (minima) e 3.3.9 Autenticazione accessibile (migliorata).

Capitolo 10 — Documenti non web

Il Capitolo 10 applica requisiti equivalenti a WCAG ai documenti non web — PDF, file Word, presentazioni, ePub e qualsiasi altro documento fornito a corredo o al di fuori del web. Lo fa riprendendo ogni criterio di successo WCAG 2.1 applicabile a un documento non web e riformulandolo nel contesto documentale. Un PDF taggato, navigabile e con descrizioni appropriate è conforme al Capitolo 10; una scansione non taggata di un documento stampato non lo è. Gli acquirenti pubblici che si procurano pubblicazioni di policy, condizioni contrattuali, materiali formativi e dichiarazioni di accessibilità si affidano al Capitolo 10 per stabilire il livello minimo accettabile di un prodotto consegnato.

Capitolo 11 — Software non web

Il Capitolo 11 è il modulo più ampio e quello di maggiore rilevanza per lo stack applicativo moderno. Applica requisiti equivalenti a WCAG al software non web — applicazioni desktop, app mobile native, interfacce integrate, chioschi con software personalizzato — e aggiunge requisiti specifici per il software che non hanno un analogo in WCAG: clausole sui servizi di accessibilità della piattaforma (11.5), sulla compatibilità con le tecnologie assistive (11.6) e sugli strumenti di authoring (11.8, derivate dalle Linee guida W3C per l’accessibilità degli strumenti di authoring). La copertura delle app mobile nel Capitolo 11 è la ragione per cui la Direttiva sull’accessibilità dei siti web può estendersi alle applicazioni mobile del settore pubblico, e per cui l’EAA può applicarsi ai lettori di ebook, alle macchine per la biglietteria e ai terminali self-service senza necessità di uno standard separato per ciascuno.

Capitolo 12 — Documentazione e servizi di supporto

Il Capitolo 12 riguarda la documentazione e i servizi di assistenza al cliente: manuali utente, sistemi di guida, call center di supporto, chat online, formati accessibili su richiesta. Le clausole richiedono che la documentazione del prodotto descriva le sue funzionalità di accessibilità, che la documentazione stessa sia accessibile e che i servizi di supporto siano disponibili attraverso canali accessibili. È il capitolo che lega l’accessibilità all’esperienza post-acquisto — la fase del percorso d’acquisto in cui gli utenti interagiscono concretamente con il prodotto e hanno bisogno di assistenza.

Capitoli 5–8 — i requisiti generici trasversali

I Capitoli da 5 a 8 si collocano a monte dei moduli specifici per formato. Il Capitolo 5 copre i requisiti generici applicabili a qualsiasi prodotto o servizio ICT — funzionalità chiuse, biometria, preservazione delle informazioni di accessibilità durante la conversione. Il Capitolo 6 riguarda le ICT con comunicazione vocale bidirezionale: testo in tempo reale, servizi di video relay e i requisiti di interoperabilità che rendono possibile la comunicazione accessibile tra provider. Il Capitolo 7 riguarda le ICT con capacità video — audiodescrizione, sottotitoli, presentazione in lingua dei segni. Il Capitolo 8 riguarda l’hardware: tastiere, controlli, connettori, accesso fisico. Un prodotto raramente rientra nell’ambito di un solo capitolo; un’app di video streaming su smart TV riguarderà contemporaneamente i Capitoli 5, 7, 9 (se ha un’interfaccia web), 11 (l’app stessa) e 12 (la sua documentazione).

Capitolo 13 e allegati

Il Capitolo 13 riguarda le ICT che forniscono servizi relay e accesso ai servizi di emergenza — lo strato di comunicazione di interesse pubblico. Gli allegati sono dove lo standard svolge il lavoro vincolante per gli appalti: l’Allegato A contiene la metodologia di conformità, incluso il modello obbligatorio di «dichiarazione di accessibilità»; l’Allegato B mappa le clausole di EN 301 549 rispetto ai corrispondenti requisiti della Section 508 statunitense — utile per i fornitori che operano su entrambe le sponde dell’Atlantico; l’Allegato C fornisce indicazioni sulle dichiarazioni di prestazione funzionale; la bibliografia elenca ogni standard, incluso WCAG, che il documento incorpora per riferimento.

Come WCAG 2.1 AA si colloca all’interno di EN 301 549

Il rapporto tra WCAG e EN 301 549 è la domanda più frequente nel lavoro di conformità, e la risposta è più precisa di «EN 301 549 include WCAG». WCAG 2.1 Livello AA è incorporato nel Capitolo 9 (contenuti web) e in parti del Capitolo 11 (software, dove i criteri di successo sono applicabili al software non web). L’incorporazione avviene per riferimento, non per parafrasi: le clausole del Capitolo 9 sono numerate in modo da rispecchiare la struttura di WCAG, e ogni clausola rimanda al corrispondente criterio di successo nella raccomandazione W3C. Una dichiarazione di conformità a WCAG 2.1 AA si traduce direttamente in una dichiarazione di conformità al Capitolo 9.

Dove EN 301 549 va oltre WCAG è nelle clausole specifiche per software, hardware e documentazione che WCAG non era stato concepito per coprire. WCAG si occupa di contenuti percepibili, operabili, comprensibili e robusti all’interno di un agente utente web. EN 301 549 aggiunge i requisiti che gestiscono, ad esempio, l’interazione di un’app desktop con un’API di screen reader su Windows, la distinguibilità tattile dei tasti di una tastiera hardware, o l’interoperabilità TTY di un contact center. Un prodotto può essere conforme a WCAG 2.1 AA e non superare EN 301 549 — tipicamente perché i Capitoli 11 o 12 coprono requisiti che WCAG non affronta.

Dove EN 301 549 è citato nel diritto UE

Il ruolo portante dello standard è nel grafo delle citazioni. Tre strumenti giuridici primari nominano EN 301 549 come riferimento tecnico; lo stesso fanno diverse decine di normative nazionali sugli appalti e leggi sull’accessibilità.

L’European Accessibility Act (Direttiva (UE) 2019/882)

L’European Accessibility Act stabilisce requisiti di accessibilità funzionale per un elenco definito di prodotti e servizi — computer, smartphone, lettori di ebook, ATM, macchine per la biglietteria, e-commerce, ebook, telefonia, servizi di media audiovisivi, servizi bancari, informazioni per il trasporto passeggeri. I requisiti funzionali dell’Atto (Allegato I) sono astratti; richiedono, ad esempio, che le informazioni siano fornite in formati accessibili, che le interfacce utente supportino le tecnologie assistive, che le comunicazioni di emergenza funzionino per gli utenti sordi. Per rendere operativi questi requisiti astratti, l’EAA si affida agli standard armonizzati citati ai sensi dell’articolo 15 del Regolamento (UE) 1025/2012 — e EN 301 549 è lo standard armonizzato che la Commissione europea sta usando per rendere operativi i requisiti web, software e documentazione dell’EAA. Un prodotto conforme alle clausole rilevanti di EN 301 549 gode della presunzione di conformità con l’EAA. La prima citazione nella Gazzetta Ufficiale di EN 301 549 specificamente ai fini EAA è stata pubblicata nel 2024; le revisioni seguono ogni nuova versione.

La Direttiva sull’accessibilità dei siti web (Direttiva (UE) 2016/2102)

La Direttiva sull’accessibilità dei siti web, in vigore dal dicembre 2016, richiede agli enti del settore pubblico negli Stati membri UE di rendere accessibili i propri siti web e le proprie applicazioni mobile. L’articolo 6 della Direttiva stabilisce che i contenuti conformi allo standard armonizzato citato nella Gazzetta Ufficiale sono presunti conformi ai corrispondenti requisiti di accessibilità di cui all’articolo 4. EN 301 549 è lo standard così citato — la V2 del 2018 è stata la prima versione nominata ai fini della WAD, con ogni revisione successiva che ha determinato una nuova citazione nella GU. I siti web e le app mobile del settore pubblico conformi al Capitolo 9 e alle parti applicabili del Capitolo 11 sono considerati conformi alla Direttiva.

Le normative nazionali sugli appalti e l’articolo 42 della Direttiva sugli appalti pubblici

L’articolo 42 della Direttiva 2014/24/UE (Direttiva sugli appalti pubblici) richiede che le specifiche tecniche nelle gare pubbliche per prodotti e servizi destinati all’uso da parte di persone fisiche «tengano conto dei criteri di accessibilità per le persone con disabilità o della progettazione per tutti gli utenti». Gli Stati membri hanno recepito tale obbligo nei propri codici degli appalti, e i testi di recepimento nominano tipicamente EN 301 549 come standard di riferimento — dalla BITV 2.0 tedesca e il regolamento EU citato negli appalti federali, al Real Decreto 1112/2018 spagnolo, al RGAA francese (che allinea i propri criteri al Capitolo 9 di EN 301 549), alle Linee Guida AgID italiane, al Tijdelijk besluit digitale toegankelijkheid overheid olandese. Il livello degli appalti nazionali è quello in cui EN 301 549 ha il maggiore impatto commerciale quotidiano, perché determina quali fornitori possono partecipare a quali gare pubbliche.

Cosa cambia con la V4 — e cosa non cambia

La prossima V4 di EN 301 549 è il titolo di lavoro per la revisione che incorporerà WCAG 2.2 AA al posto di WCAG 2.1 AA, aggiungendo i nove criteri di successo che il W3C ha introdotto o rivisto nell’aggiornamento del 2023. La revisione in lavorazione è visibile nell’archivio pubblico del Comitato Tecnico Human Factors di ETSI dal 2024, e il gruppo di lavoro congiunto ETSI/CEN/CENELEC si è riunito nel 2025 per finalizzarla. La pubblicazione nel 2026 è l’ipotesi di lavoro della comunità degli standard; la citazione nella GU ai sensi dell’EAA e della WAD seguirà secondo il calendario ordinario della Commissione (tipicamente alcuni mesi dopo la pubblicazione ETSI).

Le variazioni sostanziali nella V4 si concentrano in due aree. In primo luogo, i criteri di successo WCAG 2.2 in quanto tali — il Capitolo 9 recepisce i nove nuovi criteri, i più rilevanti sul piano operativo essendo Focus non oscurato, Dimensione dell’obiettivo (minima), Movimenti di trascinamento e i due criteri di Autenticazione accessibile, che insieme imporranno una nuova verifica per qualsiasi prodotto che utilizzi banner sovrapposti, modali per i cookie, campi per le password o aree di tocco di piccole dimensioni. In secondo luogo, le clausole software dello standard (Capitolo 11) vengono rafforzate per allinearsi più strettamente a WCAG 2.2 per il software a cui i criteri di successo si applicano, e per aggiornare il linguaggio relativo ai servizi di accessibilità della piattaforma in modo da riflettere le API delle tecnologie assistive rilasciate dal 2021.

Cosa la V4 non cambia: l’architettura in dodici capitoli, il modello della dichiarazione di conformità nell’Allegato A, il rapporto con EAA e WAD, o la mappatura con la Section 508 nell’Allegato B. Un fornitore che dispone di una dichiarazione di conformità aggiornata rispetto alla V3.2.1 dovrà, nella maggior parte dei casi, ri-testare per i nuovi criteri WCAG 2.2, ma non dovrà ri-architettare il proprio approccio alla conformità.

Usare EN 301 549 nella pratica: la dichiarazione di conformità

L’artefatto operativo prodotto da EN 301 549 è una dichiarazione di conformità — talvolta chiamata «dichiarazione di accessibilità» nell’accezione della WAD, o Voluntary Product Accessibility Template (VPAT) nella tradizione della Section 508. L’Allegato A dello standard contiene il modello. Per ogni clausola applicabile, il fornitore dichiara se il prodotto «Supporta», «Supporta parzialmente», «Non supporta» o è «Non applicabile». Ogni «Supporta parzialmente» o «Non supporta» deve essere accompagnato da un campo note e spiegazioni che descriva la lacuna.

In una risposta a una gara, il responsabile degli appalti definisce i capitoli rilevanti per il prodotto, richiede una dichiarazione di conformità clausola per clausola, e valuta le lacune. La dichiarazione è contrattualmente vincolante nella maggior parte dei quadri europei di appalto pubblico — se il fornitore dichiara «Supporta» rispetto a una clausola e il prodotto fallisce successivamente su quella clausola durante il collaudo, il contratto di solito dà all’acquirente motivo per richiedere la correzione, applicare penali o risolvere il contratto. È per questo che EN 301 549 ha più forza commerciale del documento WCAG sottostante: WCAG è una raccomandazione W3C senza rilevanza negli appalti; EN 301 549 è il documento che un contratto nomina.

EN 301 549 nel quadro legislativo già noto

Se si è seguito l’arco della legislazione UE sui diritti delle persone con disabilità — l’EAA, la Direttiva sull’accessibilità dei siti web, i codici nazionali degli appalti che recepiscono la Direttiva 2014/24/UE — EN 301 549 è il substrato tecnico che collega quelle leggi al processo di test quotidiano di un fornitore. WCAG stabilisce le regole per i contenuti web. EN 301 549 incorpora WCAG nel più ampio insieme di requisiti (software, documenti, documentazione, hardware, comunicazioni bidirezionali) che la normativa UE sugli appalti acquista concretamente. L’EAA e la WAD citano poi EN 301 549 come lo standard che determina la presunzione di conformità. I codici nazionali degli appalti nominano lo standard nelle proprie specifiche tecniche, e i revisori dell’accessibilità eseguono i test rispetto ad esso clausola per clausola.

Per i professionisti che definiscono l’ambito di un audit 2026: la V3.2.1 è la versione su cui testare oggi, la V4 è la versione per cui iniziare a prepararsi, e i delta su cui prendere vantaggio sono i nove criteri di successo WCAG 2.2 — in particolare i criteri sull’aspetto del focus e sulla dimensione dell’obiettivo, che sono quelli su cui la maggior parte dei prodotti sta silenziosamente fallendo. Il modo più rapido per individuare quali criteri 2.2 il proprio sito già viola è una scansione WCAG 2.2 gratuita su una pagina rappresentativa. Per il quadro di rendicontazione 2026 sull’interazione di questo standard con l’applicazione nazionale, si veda l’indice degli articoli di Disability World; per il quadro dell’applicazione nel primo anno dell’EAA tra gli Stati membri, si veda il primer sull’EAA. Per una traduzione pratica di V3.2.1 con i delta 2.2 in un audit funzionante, si veda il manuale operativo WCAG 2.2 step-by-step; per le piattaforme di monitoraggio che mantengono la conformità tra un audit e l’altro, si veda la guida all’acquisto degli strumenti di monitoraggio dell’accessibilità.

Fonti primarie

  1. ETSI / CEN / CENELEC. EN 301 549 V3.2.1 (2021-03) — Accessibility requirements for ICT products and services. etsi.org
  2. Commissione europea. Richiesta di normalizzazione M/376 (2005) sull’accessibilità ICT per gli appalti pubblici.
  3. Direttiva (UE) 2019/882 del Parlamento europeo e del Consiglio sui requisiti di accessibilità per prodotti e servizi (European Accessibility Act).
  4. Direttiva (UE) 2016/2102 del Parlamento europeo e del Consiglio sull’accessibilità dei siti web e delle applicazioni mobile degli enti del settore pubblico.
  5. Direttiva 2014/24/UE del Parlamento europeo e del Consiglio sugli appalti pubblici, articolo 42.
  6. Regolamento (UE) n. 1025/2012 del Parlamento europeo e del Consiglio sulla normazione europea.
  7. W3C. Web Content Accessibility Guidelines (WCAG) 2.1 (Raccomandazione W3C, giugno 2018) e WCAG 2.2 (Raccomandazione W3C, ottobre 2023).
  8. Comitato Tecnico Human Factors di ETSI. Archivio pubblico sull’attività di revisione di EN 301 549 (2024–2025).