EN 301 549 V4.1.1: che cosa è cambiato e quale versione conta ancora
La norma dietro allo European Accessibility Act ha una nuova versione, pubblicata a settembre 2026. Porta WCAG 2.2 dentro la clausola sul software. La versione a cui rimanda la legge, però, resta la V3.2.1 del 2021. Qui c'è la differenza, requisito per requisito, e di che cosa deve rispondere oggi l'audit di un'app mobile.
A quale versione rimanda la legge
Una norma diventa il riferimento giuridico quando il suo riferimento viene pubblicato nella Gazzetta ufficiale dell'Unione europea. È questo a far sì che la conformità alla norma valga come presunzione di conformità alla legge. Per la EN 301 549 la versione citata è la V3.2.1, del marzo 2021, che rimanda a WCAG 2.1 livello AA.
La V4.1.1 è stata pubblicata a settembre 2026. A oggi non è citata, quindi da sola non cambia alcun obbligo. AccessibleEU, il centro della Commissione stessa, ha dichiarato il 7 settembre 2026 che finché la citazione non arriva il riferimento in vigore resta la V3.2.1.
I testi nazionali stanno passando a un rimando dinamico invece che a una versione fissa. In Francia il décret n° 2026-816 del 24 agosto 2026 ha riscritto il decreto precedente: un servizio è accessibile quando è conforme alle norme armonizzate i cui riferimenti sono pubblicati nella Gazzetta ufficiale. Quando la citazione cambia, l'obbligo la segue senza bisogno di un altro decreto.
La conseguenza pratica per chi fa un audit oggi: una relazione che risponde solo per la V4.1.1 non risponde alla domanda che pone la legge, e una relazione che risponde solo per la V3.2.1 ignora WCAG 2.2. Nella tabella devono esserci tutte e due le versioni.
Che cosa ha guadagnato la clausola 11
La clausola 11 è la parte sul software, quella a cui risponde un'app mobile. Nella V4.1.1 porta i 50 criteri WCAG 2.2 di livello A e AA che valgono per il software, contro WCAG 2.1 nella V3.2.1.
Sette requisiti della clausola 11 non hanno un corrispettivo nella V3.2.1. Cinque arrivano da WCAG 2.2: 11.2.4.11 Focus not obscured (minimum), 11.2.5.7 Dragging movements, 11.2.5.8 Target size (minimum), 11.3.3.7 Redundant entry e 11.3.3.8 Accessible authentication (minimum). Due nella V3.2.1 erano semplicemente void e adesso sono requisiti: 11.2.4.2, che riprende WCAG 2.4.2 come Non-web software titled, e 11.3.2.4 Consistent identification.
Di questi, l'11.2.5.8 è quello che cambia l'esito della maggior parte degli audit su mobile. Un target di tocco sotto i 24 × 24 con WCAG 2.1 era un'indicazione e con la 2.2 è un criterio non soddisfatto, e i target piccoli sono il difetto che i nostri controlli trovano più spesso.
Un criterio di WCAG 2.2 nella clausola sul software non è entrato: 3.2.6 Consistent help. La clausola 11.3.2.6 è void, quindi qui un'app non viene misurata su quel criterio.
Che cosa ha perso, e che cosa si è solo spostato
Parsing non c'è più. WCAG 2.2 ha rimosso il criterio 4.1.1, e con lui se n'è andato il requisito 11.4.1.1.1 della V3.2.1. Se una vecchia relazione boccia un'app su Parsing, quel rilievo non esiste più.
I requisiti sui servizi di accessibilità in sé sono stati riscritti. La V3.2.1 chiedeva al software di usare i servizi di accessibilità documentati della piattaforma (11.5.2.3) e chiedeva alle piattaforme di fornirli (11.5.2.1, 11.5.2.2). Nella V4.1.1 l'11.5.2.3 è una raccomandazione e l'11.5.2.2 è void, mentre il dovere della piattaforma è enunciato una volta sola nell'11.5.2.1.
Gli strumenti di authoring sono usciti dalla clausola 11 e sono passati nella clausola 5: i cinque requisiti numerati da 11.8.1 a 11.8.5 adesso sono da 5.10.1 a 5.10.5, con gli stessi titoli.
Documentazione e assistenza sono state ristrutturate. I requisiti 12.1.1, 12.1.2, 12.2.2, 12.2.3 e 12.2.4 della V3.2.1 sono diventati 12.1, 12.2 e 12.3, e le guide elettroniche ai programmi si sono aggiunte come 12.4 e 12.5.
La clausola 6, quella per le app con le chiamate, è stata riscritta attorno a scenari operativi (da 6.0.2 a 6.0.9) e i suoi requisiti sul testo in tempo reale sono stati rinumerati e rinominati. La clausola 7 adesso dice subtitles dove la V3.2.1 diceva captions.
La trappola sono i numeri sopravvissuti a una rinumerazione. Nella V3.2.1 il 6.2.3 è Interoperability; nella V4.1.1 lo stesso numero è DTMF touch-tone generation during RTT operations. Una tabella di corrispondenza deve far combaciare i requisiti, non i numeri.
Di che cosa deve rispondere un audit oggi
Contando i requisiti che un'app mobile nativa può soddisfare o mancare, il nostro protocollo risponde di 144: i requisiti della V4.1.1 delle clausole 5, 6, 7, 11 e 12, più i 19 requisiti della V3.2.1 che non hanno un corrispettivo identico nella V4.1.1 e appartengono ancora alla versione citata dalla legge.
Ogni requisito è verificato a mano sulle schermate riportate nella relazione, con gli screen reader dell'ambiente di prova, che la relazione indica per nome. I controlli automatici corrono in parallelo e indicano la riga di codice, ma rispondono di una parte dell'elenco, non di tutto.
La relazione indica la clausola in entrambe le numerazioni, così lo stesso documento risponde a un'autorità che legge la V3.2.1 e a un team che si prepara alla V4.1.1.
Oppure fate verificare l'intera build: la verifica degli store costa 190 €, 2 giorni lavorativi.