WCAG 2.2 obbligatorie: il sito va rifatto adesso? No, e i sei criteri nuovi costano poco oggi

A settembre la norma europea sull'accessibilità digitale, la EN 301 549, è uscita in versione 4.1.1, e dentro ci sono le WCAG 2.2 al posto delle 2.1. Chi segue un sito e legge la notizia si fa una domanda sola: adesso va rifatto?

No. La versione nuova non è ancora il riferimento legale: finché la Commissione europea non la cita nella Gazzetta ufficiale dell'Unione, per dimostrare la conformità all'European Accessibility Act e alla direttiva sui siti pubblici vale ancora la v3.2.1 del 2021, cioè le WCAG 2.1 al livello AA. Quello che conviene fare adesso è guardare i sei criteri nuovi, perché su un sito fatto bene costano poco e tra qualche mese saranno il metro con cui ti misurano.

Cosa è cambiato nella EN 301 549 v4.1.1: tre cose, e una sparisce

La EN 301 549 è la norma tecnica che traduce «sito accessibile» in requisiti verificabili: quando una legge europea chiede accessibilità, è a questa norma che si guarda per dire se un sito è a posto. Dal 2021 la versione in vigore, la 3.2.1, incorporava le WCAG 2.1. Le WCAG 2.2 erano uscite a fine 2023 e la norma non le aveva ancora recepite: la 4.1.1 chiude quel ritardo.

In concreto cambiano tre cose. I requisiti web passano alle WCAG 2.2, che ai livelli A e AA aggiungono sei criteri nuovi. Sparisce il criterio 4.1.1 Parsing, che nelle WCAG 2.2 è stato ritirato perché superato. E arriva un allegato che collega direttamente i requisiti della norma agli obblighi dello European Accessibility Act, una cosa che prima toccava ricostruire a mano.

Finché non è in Gazzetta ufficiale, il riferimento resta WCAG 2.1 AA

Una norma armonizzata vale come prova di conformità solo dal momento in cui la Commissione la cita nella Gazzetta ufficiale dell'Unione europea. La 4.1.1 è stata pubblicata, ma quella citazione non c'è ancora. Quindi oggi un audit fatto sulle WCAG 2.1 AA è valido, una dichiarazione di accessibilità che cita la 2.1 è corretta, e nessuno può contestarti un criterio che la norma di riferimento non contiene.

Non sono un avvocato e questa non è una consulenza legale: è quello che dice la pagina dell'AccessibleEU Centre della Commissione, e che chiunque può rileggere. Quando la citazione arriverà, rispettare la 4.1.1 darà la presunzione di conformità sia per l'Accessibility Act sia per la direttiva sui siti pubblici. Nel frattempo c'è un dettaglio che rende tutto più semplice: le WCAG 2.2 sono costruite sopra le 2.1. Un sito che rispetta la 2.2 rispetta anche la 2.1, quindi lavorare sui criteri nuovi oggi non ti sposta fuori dal riferimento attuale.

I sei criteri nuovi, in ordine di quanto costano su un sito fatto bene

Li elenco partendo da quelli che su un sito costruito con criterio sono già a posto, fino a quelli che richiedono una decisione.

• Aiuto coerente (3.2.6, livello A). Se contatti, chat o assistenza compaiono su più pagine, devono stare sempre nello stesso posto relativo. Sui siti che facciamo è già così, perché quelle cose vivono nell'header o nel footer. Costo: zero, a meno che il bottone della chat non appaia solo su alcune pagine.
• Inserimento ridondante (3.3.7, livello A). Dentro uno stesso processo non puoi chiedere due volte lo stesso dato: se l'indirizzo di spedizione è uguale a quello di fatturazione, serve una spunta o un precompilato. Nei checkout fatti bene c'è già. Dove manca, è il criterio che si ripaga da solo, perché riduce i carrelli abbandonati.
• Dimensione del target (2.5.8, livello AA). Ogni elemento cliccabile deve misurare almeno 24 per 24 pixel CSS, oppure avere abbastanza spazio intorno da non sovrapporsi ai vicini. I punti deboli tipici: le icone social nel footer, la paginazione, la X che chiude un modale. Si risolve quasi sempre con del padding, senza toccare il disegno.
• Focus non oscurato (2.4.11, livello AA). Quando navighi con il Tab, l'elemento che ha il focus non può essere coperto del tutto da qualcosa che hai messo tu: header fisso, banner dei cookie, bolla della chat. È il criterio che trovo più spesso violato nei siti che eredito, e si sistema con un margine di scorrimento sull'elemento a fuoco.
• Movimenti di trascinamento (2.5.7, livello AA). Tutto quello che si fa trascinando deve potersi fare anche senza trascinare: uno slider di prezzo, un ordinamento, una mappa. Lo slider nativo di HTML si muove già con le frecce; un ordinamento costruito in JavaScript ha bisogno dei bottoni su e giù. Qui il costo dipende da quanta interazione custom hai.
• Autenticazione accessibile (3.3.8, livello AA). Il login non può richiedere un test cognitivo senza alternativa: ricordare una password senza poterla incollare, risolvere un puzzle, trascrivere caratteri distorti. Nella pratica vuol dire non bloccare l'incolla nel campo password, lasciar lavorare i gestori di password, e scegliere una protezione anti-bot che non sia un rompicapo. Questo è l'unico dei sei dove a volte tocca cambiare un servizio di terze parti.

Il criterio che sparisce: 4.1.1 Parsing, e perché non è un permesso

Il 4.1.1 chiedeva un markup pulito: ID unici, tag chiusi, annidamenti corretti. È stato ritirato perché i browser e le tecnologie assistive di oggi tollerano quegli errori, e il criterio produceva segnalazioni senza impatto reale sulle persone. Nei report automatici smetterai di vedere la voce «Parsing».

Non vuol dire che l'HTML può essere scritto male. Un ID duplicato continua a rompere il collegamento tra un'etichetta e il suo campo, e quello lo intercettano altri criteri che restano in piedi. È cambiato dove viene contato l'errore, non se conta.

Cosa fare adesso, se il sito è tuo

Non rifare niente. Chiedi a chi ti segue il sito di passare i sei criteri come una checklist sui template che contano: header, footer, moduli, login, checkout. Su un sito costruito bene è il lavoro di mezza giornata; se la stima che ti arriva è di settimane, il problema non sono le WCAG 2.2, è il sito. Se non sai da dove partire, i dieci controlli per la conformità EAA che ho messo in fila in un altro articolo valgono ancora tutti.

Se invece un rifacimento era già in programma per i prossimi mesi, scrivi WCAG 2.2 AA nel brief al posto di 2.1 AA. Costa uguale, e il sito nasce già dentro il riferimento che verrà. Nei brief nuovi quella riga la mettiamo noi, e non sposta il preventivo: nello sviluppo di un sito la differenza fra i due livelli è una manciata di scelte fatte all'inizio invece che alla fine.

Le norme che arrivano in due tempi sono le più comode che esistano, perché ti dicono in anticipo cosa ti chiederanno. Usare quel preavviso per rifare tutto di corsa, o per non fare niente, secondo me è lo stesso errore.