La pubblicazione delle WCAG 2.2 ha prodotto una conseguenza pratica per chi governa un sito industriale: occorre decidere quale versione assumere come riferimento, anche se le precedenti non sono state cancellate. Adottare quella più recente è una scelta sostenuta dal W3C, ma non equivale né a dichiarare obsolete le WCAG 2.1 né a risolvere automaticamente la diversa questione degli obblighi di legge.

La carta d’identità dello standard

Le WCAG 2.1 sono diventate una Recommendation W3C nel giugno 2018. Il 9 agosto 2023 è stata notificata al W3C l’intenzione di avviare la traduzione italiana della versione successiva, insieme alla presentazione dei partner del comitato incaricato. Le WCAG 2.2 sono poi state pubblicate ufficialmente il 5 ottobre 2023 come W3C Recommendation, con l’identificativo REC-WCAG22-20231005. La traduzione italiana autorizzata, coordinata da Roberto Scano per IWA Italy, è arrivata il 5 dicembre dello stesso anno.

Questa cronologia descrive un’evoluzione tecnica, non una sostituzione formale. Il W3C precisa che le WCAG 2.0 e 2.1 restano Recommendation. Al tempo stesso raccomanda di utilizzare la versione 2.2 per massimizzare l’applicabilità futura del lavoro svolto. La distinzione è rilevante: una versione può essere preferibile come riferimento corrente senza rendere invalide quelle precedenti.

Il rapporto tra 2.1 e 2.2 è inoltre asimmetrico. Un contenuto conforme alle WCAG 2.2 risulta conforme anche alle WCAG 2.1; il contrario non può essere dato per acquisito. Se il criterio di confronto è la continuità con verifiche e documentazione già esistenti, mantenere temporaneamente il riferimento alla 2.1 può ridurre l’impatto organizzativo. Se il criterio è evitare di impostare oggi un progetto su un riferimento meno aggiornato, la raccomandazione del W3C orienta invece verso la 2.2. Il compromesso riguarda tempi, evidenze disponibili e capacità di aggiornamento, non una presunta validità assoluta di una versione contro l’altra.

Dalla promessa generica a una proprietà verificabile

Dire che un sito è “accessibile” esprime un obiettivo ampio. Dichiarare una conformità alle WCAG richiede invece un riferimento identificabile e riscontri controllabili. Il W3C definisce i criteri di successo come istruzioni testabili e indipendenti dalla tecnologia impiegata: il confronto non verte quindi sul fatto che il sito utilizzi un determinato CMS o framework, ma sul comportamento del contenuto e dell’interfaccia rispetto ai criteri applicabili.

Questo sposta il lavoro industriale dalla sola fase di progetto alla gestione continuativa. Un nuovo catalogo, una scheda macchina, un modulo per la richiesta di offerta, un’area ricambi o un documento tecnico possono modificare ciò che deve essere verificato. Lo standard riguarda contenuti destinati a desktop, laptop, tablet e dispositivi mobili; non basta quindi controllare una singola rappresentazione della pagina e trasferire il risultato a tutte le altre.

Neppure lo strumento automatico, da solo, chiude la verifica. Secondo il W3C, la valutazione richiede una combinazione di test automatici e giudizio umano. I due approcci sono omogenei solo per funzione — entrambi producono evidenze — ma non sono intercambiabili: l’automazione rende ripetibili alcuni controlli e aiuta a intercettare regressioni, mentre la valutazione umana affronta aspetti che non possono essere decisi in modo affidabile dalla sola scansione del codice.

Il memo che rende motivata la scelta

Per un responsabile digitale, il passaggio utile non è trasformare il nome dello standard in una formula rassicurante. È redigere un memo decisionale breve ma aggiornabile, capace di collegare la versione adottata alle ragioni, alle prove e alle condizioni che potrebbero richiedere una revisione. In un sito industriale questo documento crea continuità tra direzione, marketing, IT, fornitori e persone che pubblicano nuovi contenuti, senza presumere che tutti attribuiscano lo stesso significato alla parola “conformità”.

Versione di riferimento

Il memo deve identificare la versione in modo non ambiguo. Scrivere soltanto “standard WCAG” lascia aperta una differenza sostanziale tra 2.0, 2.1 e 2.2. Se si adotta la 2.2, va registrato che la scelta segue la versione pubblicata come Recommendation il 5 ottobre 2023 e che, per indicazione del W3C, un contenuto conforme a questa versione è conforme anche alla 2.1.

Questa compatibilità non autorizza però a descrivere la 2.2 come una sostituzione che annulla il lavoro precedente. Un audit o un capitolato costruito sulla 2.1 conserva il proprio riferimento tecnico; semmai occorre decidere se e quando estenderlo. Il confronto corretto è dunque tra due basi tecniche tuttora riconosciute, valutate rispetto all’orizzonte del progetto. Non è un confronto tra uno standard valido e uno scaduto.

Ragione della scelta

La motivazione dovrebbe essere più precisa di “è la versione più nuova”. Il W3C raccomanda la 2.2 per massimizzare l’applicabilità futura: questa è una ragione documentabile per adottarla in una riprogettazione, in un nuovo capitolato o nell’aggiornamento del sistema editoriale. In un progetto già verificato sulla 2.1, invece, il passaggio può richiedere una nuova delimitazione delle pagine esaminate, ulteriori valutazioni e un adeguamento della documentazione.

La motivazione deve richiamare la traduzione italiana autorizzata dal W3C, distinguendo ciò che il documento afferma da ciò che l’organizzazione decide di applicare. Quella fonte consente di controllare lo stato della Recommendation, la relazione con le versioni precedenti e i limiti dichiarati dallo standard.

Quando la decisione entra in una riprogettazione, il memo deve assegnare responsabilità anche a sviluppo, contenuti e controllo nel tempo. La home klc.it presenta questi aspetti dentro un progetto digitale integrato e può essere consultata per la fase organizzativa; resta estranea alla prova dei requisiti WCAG e degli eventuali obblighi giuridici.

Nello stesso punto va esclusa un’inferenza impropria: essere una W3C Recommendation descrive lo status dello standard presso il W3C, non dimostra da solo l’esistenza di uno specifico obbligo legale per una determinata impresa. La domanda normativa richiede fonti e valutazioni ulteriori, legate almeno al contesto applicabile. Il materiale tecnico dello standard non basta per chiuderla.

Evidenze richieste

Una decisione verificabile indica quali evidenze dovranno sostenerla. Non è sufficiente registrare il risultato di uno scanner senza chiarire a quale versione si riferisca, quale parte del sito sia stata esaminata e quale contributo abbia avuto la valutazione umana. Il memo può richiedere che rapporti automatici, esiti delle verifiche manuali, data dell’analisi e perimetro dei contenuti rimangano associati alla decisione.

Il criterio di confronto, qui, è la forza probatoria rispetto alla conformità tecnica. Un’affermazione generale sull’attenzione all’accessibilità comunica un orientamento, ma non identifica una prova. Un insieme di risultati riferiti a criteri testabili permette invece di ricostruire cosa sia stato esaminato e con quali modalità. Resta comunque necessario evitare il salto da “sono disponibili queste evidenze” a “ogni possibile esigenza è soddisfatta”.

Le disabilità considerate dalle WCAG comprendono, tra le altre, cecità e ipovisione, sordità e perdita dell’udito, limitazioni motorie, disabilità del linguaggio, fotosensibilità, disturbi dell’apprendimento e limitazioni cognitive. Lo stesso W3C precisa però che le linee guida non sono esaustive per tutte le esigenze e per tutte le loro combinazioni. La conformità allo standard può dunque essere documentata; l’accessibilità completa per chiunque, in ogni situazione, non discende automaticamente da quella documentazione.

Condizioni di revisione

Un sito industriale cambia anche quando il progetto grafico sembra fermo. Entrano nuove famiglie di prodotto, configuratori, documenti, moduli, video, lingue e integrazioni con sistemi esterni. Il memo dovrebbe perciò indicare quali trasformazioni rendono opportuno riesaminare la scelta o aggiornare le evidenze.

Non serve presumere che ogni modifica imponga lo stesso intervento. Il criterio è l’effetto sul perimetro verificato: una correzione editoriale circoscritta e l’introduzione di un nuovo processo digitale non presentano il medesimo rischio di invalidare valutazioni precedenti. Anche l’emergere di un requisito contrattuale o di un quadro giuridico pertinente può riaprire la decisione, ma su basi diverse da quelle usate per scegliere tra WCAG 2.1 e 2.2.

Tre piani che non devono sovrapporsi

La Recommendation W3C stabilisce un riferimento tecnico ufficiale. La conformità riguarda l’esito di verifiche rispetto a criteri testabili. L’obbligo giuridico dipende invece da fonti normative che non possono essere dedotte dal solo status W3C del documento. Sono piani collegabili, ma non equivalenti.

Confonderli produce due errori opposti. Il primo è trattare l’adozione delle WCAG 2.2 come una dichiarazione legale autosufficiente. Il secondo è ritenere inutile lo standard finché non sia stata definita la questione normativa. In realtà un’organizzazione può scegliere e documentare un riferimento tecnico senza anticipare conclusioni giuridiche non dimostrate; allo stesso modo, un eventuale obbligo deve essere esaminato con fonti appropriate e non risolto da un’etichetta di conformità.

Il memo dovrebbe quindi chiudersi non con la formula indeterminata “sito conforme”, ma con una decisione circoscritta: versione adottata, ragione documentata, evidenze disponibili e condizioni di revisione. La domanda normativa resta esplicitamente aperta finché non viene affrontata sul proprio terreno, mentre i limiti dichiarati dal W3C impediscono di trasformare la conformità tecnica in una promessa di accessibilità assoluta.