Descrizione dell’immagine: una bozza di lavoro WCAG 3 stampata con segnalibri colorati su una scrivania accanto a un documento WCAG 2.2 — il riferimento visivo per il primer sulla bozza WCAG 3.
Tempo di lettura: 12 minuti
WCAG 3 — le linee guida di nuova generazione che il W3C elabora sotto il nome di lavoro Silver dal 2017 — è ancora, a metà del 2026, una W3C Working Draft. Questo singolo dato è la cosa più importante da sapere al riguardo. Non si tratta di una Recommendation, non è una Candidate Recommendation e nessuna sua disposizione può ancora essere citata da un’autorità di regolamentazione, un tribunale o un responsabile degli appalti con valore giuridico. WCAG 2.2 rimane lo standard rispetto al quale il mondo sta attualmente effettuando audit, e EN 301 549, la Section 508 statunitense e le implementazioni nazionali della Direttiva sull’accessibilità dei siti web fanno tutte riferimento a WCAG 2.x. WCAG 3 rappresenta una riscrittura architettonica deliberata del modo in cui viene misurata la conformità all’accessibilità — e un’anticipazione di come si presenterà il decennio di adozione normativa successivo, una volta che il documento si stabilizzerà.
Questo primer illustra cos’è WCAG 3, cosa cambia a livello strutturale, come funzionano i livelli di conformità proposti bronzo/argento/oro, quando potrebbe realisticamente comparire la Candidate Recommendation, le tensioni politiche con WCAG 2.2 (che le autorità nazionali stanno ancora nel mezzo del processo di adozione), e cosa dovrebbero fare concretamente adesso i team che operano con lo standard 2.x. La versione breve: leggere la bozza di lavoro, non effettuare refactoring per conformarsi ad essa, e considerare qualsiasi fornitore che prometta «conformità WCAG 3» oggi come confuso o interessato a vendere qualcosa.
Cos’è WCAG 3 — e cosa non è
WCAG 3 è il titolo di lavoro di una nuova linea di Recommendation presso l’Accessibility Guidelines Working Group (AG WG) del W3C, distinta dalla serie WCAG 2.x. Il progetto è iniziato nel 2017 con il nome Silver (il simbolo chimico Ag, un gioco di parole su «Accessibility Guidelines») e la prima bozza di lavoro pubblica è stata pubblicata nel gennaio 2021. La più recente Working Draft è la versione che i lettori trovano all’URL w3.org/TR/wcag-3.0/ — e il W3C data quella bozza, come ogni bozza precedente, con un banner di intestazione ben visibile che recita: «Questo documento è una Working Draft. Non è stabile e non dovrebbe essere citato né utilizzato come base per implementazioni.»
Quel banner ha un ruolo reale. All’interno del processo del W3C, un documento attraversa cinque livelli di maturità: Working Draft, Candidate Recommendation (CR), Proposed Recommendation (PR), Recommendation (REC) e infine Superseded Recommendation. WCAG 2.0 ha raggiunto lo stato REC nel dicembre 2008. WCAG 2.1 nel giugno 2018. WCAG 2.2 nell’ottobre 2023. WCAG 3 non ha ancora raggiunto la fase CR — e il W3C ha dichiarato esplicitamente che diverse questioni di progettazione sostanziali devono ancora essere risolte prima che ciò possa avvenire. Lo stato attuale, in base alla bozza pubblicata più recentemente, è quello di un documento di ricerca e progettazione con sezioni sviluppabili e problemi aperti chiaramente segnalati, non di una specifica stabile.
Cosa WCAG 3 non è: non è un sostituto di WCAG 2.2. Il W3C ha dichiarato che WCAG 2.2 e WCAG 3 coesisteranno probabilmente per un prolungato periodo di transizione dopo che WCAG 3 raggiungerà lo stato di Recommendation. WCAG 3 non è nemmeno «WCAG 2.3» — il modello dei contenuti, il modello di conformità e la struttura editoriale sono sufficientemente diversi da aver reso impraticabile, già nelle prime fasi del processo di progettazione, una semplice rinumerazione all’interno della serie 2.x.
Finalità e campo di applicazione: perché una nuova serie
Tre problemi strutturali con WCAG 2.x hanno portato alla decisione di avviare una nuova serie anziché continuare ad incrementare la numerazione 2.x.
In primo luogo, il campo di applicazione. WCAG 2.x è, tecnicamente, le Web Content Accessibility Guidelines — si rivolge ai contenuti web resi da uno user agent. Il mandato del Working Group, tuttavia, si è ampliato nel corso di un decennio fino a coprire l’intera superficie dell’accessibilità digitale: applicazioni mobile native, chioschi, interfacce vocali, realtà virtuale e aumentata, strumenti AAC (comunicazione aumentativa e alternativa), superfici di intelligenza artificiale conversazionale. WCAG 3 è progettato sin dall’inizio per essere indipendente dal contenuto e dalla piattaforma, con la stessa linea guida applicabile a una pagina web, a una schermata di app nativa, a un flusso vocale e a un dialogo di chiosco, senza costringere i team a redigere tre diverse dichiarazioni di conformità rispetto a una linea guida il cui nome dice ancora «Web».
In secondo luogo, il modello di conformità. La conformità WCAG 2.x è binaria: ogni criterio di successo applicabile è superato o non superato, e un singolo insuccesso su un singolo criterio AA compromette la dichiarazione di conformità della pagina. Questo funziona bene per criteri precisi a livello di interfaccia come «usa intestazioni semantiche» — funziona meno bene per criteri in cui la barriera sottostante è graduata piuttosto che categorica, come la complessità del linguaggio, il carico cognitivo o la chiarezza con cui un messaggio di errore comunica cosa è andato storto. WCAG 3 introduce esiti ponderati in modo che una pagina possa ottenere un risultato misurabilmente migliore su, ad esempio, «linguaggio chiaro» senza imporre la valutazione binaria richiesta da WCAG 2.x.
In terzo luogo, gli utenti non ancora adeguatamente serviti. WCAG 2.x presenta lacune documentate per gli utenti con disabilità cognitive, gli utenti con basso livello di alfabetizzazione, gli utenti che si affidano a dispositivi AAC, gli utenti di interfacce vocali, gli utenti sordociechi che navigano con display braille aggiornabili e le modalità di tecnologia assistiva emergenti come il tracciamento oculare e le interfacce cervello-computer. I criteri di successo 2.x possono essere applicati a questi utenti — ma sono stati redatti avendo principalmente in mente gli utenti di screen reader, lente di ingrandimento, solo tastiera e ipovedenti. L’architettura delle linee guida WCAG 3 accoglie esplicitamente contributi per le modalità cognitive, vocali, AAC e di AT emergente come obiettivi di prima classe.
Cambiamenti principali: esiti, non criteri di successo
Il cambiamento più significativo in WCAG 3 — quello da cui discendono tutti gli altri — è il passaggio dai criteri di successo agli esiti.
Un criterio di successo WCAG 2.x è un’affermazione binaria e verificabile. 1.4.3 Contrasto (Minimo) stabilisce: il testo e le immagini di testo hanno un rapporto di contrasto di almeno 4,5:1, con due eccezioni specifiche. Una pagina soddisfa il criterio oppure no. Questo è eccellente per test ripetibili e per un uso avversariale (contenziosi, audit, appalti), ma penalizzante per criteri in cui l’esigenza dell’utente sottostante non si divide nettamente in superato/non superato.
Un esito WCAG 3, nella bozza attuale, è un’affermazione verificabile associata a uno o più metodi che descrivono come verificare l’esito e come ponderare il risultato. Gli esiti possono essere binari quando il formato binario è quello appropriato (un campo di un modulo ha o non ha un’etichetta), ma possono anche essere ponderati su una scala numerica quando l’esigenza dell’utente sottostante è graduata (quanto è leggibile questo paragrafo; quanto è recuperabile questo stato di errore; quanto è prevedibile questa navigazione). Il risultato di conformità per un prodotto viene quindi calcolato trasversalmente agli esiti anziché essere condizionato al superamento di ogni criterio.
Seguono diversi altri cambiamenti architettonici:
- Le linee guida come unità organizzativa. WCAG 3 raggruppa gli esiti sotto linee guida (che corrispondono approssimativamente allo strato principi-e-linee-guida di WCAG 2.x, ma sono redatte in modo più dichiarativo).
- Metodi, non tecniche. WCAG 2.x dispone di tecniche informative che suggeriscono come soddisfare un criterio di successo. WCAG 3 dispone di metodi normativi che descrivono come viene verificato un esito. Il passaggio da «informativo» a «normativo» ha importanza: significa che la procedura di test viaggia con la linea guida anziché essere un accompagnamento separato e discutibile.
- Test atomici e olistici. Alcuni esiti sono testati a livello atomico (un elemento, una regola) e altri sono testati in modo olistico sull’intera vista o sul flusso di attività. Gli esiti relativi al carico cognitivo e al linguaggio chiaro sono intrinsecamente olistici; quelli relativi al contrasto e all’etichettatura sono intrinsecamente atomici. WCAG 3 rende esplicita tale distinzione nel metodo.
- Categorie di esigenze funzionali. La bozza introduce le esigenze funzionali — vista, udito, cognizione, linguaggio, mobilità, multisensoriale — come asse trasversale. Ogni esito è mappato alle esigenze funzionali che affronta, in modo che un tester o un’autorità di regolamentazione possa chiedere «mostratemi tutto ciò che riguarda gli utenti con esigenze cognitive» senza rileggere l’intero documento.
Livelli di conformità: bronzo, argento, oro
Laddove WCAG 2.x presenta tre livelli di conformità — A, AA, AAA — WCAG 3 propone tre livelli di conformità: Bronzo, Argento e Oro. Le etichette non sono deliberatamente lettere e non sono deliberatamente cumulative per regola; segnalano che i livelli superiori riflettono un’esperienza significativamente migliore per gli utenti, non «lo stesso prodotto con più caselle spuntate».
Bronzo è il livello minimo di conformità. È inteso a corrispondere, approssimativamente, a «equivalente WCAG 2.x AA» — vale a dire, un prodotto conforme a Bronzo non dovrebbe essere sostanzialmente peggiore dell’attuale prodotto conforme ad AA. La conformità Bronzo richiede il superamento di tutti gli errori critici (esiti contrassegnati nella bozza come barriere fondamentali — ad esempio, testo alternativo mancante su immagini informative) e il raggiungimento di una soglia definita nel punteggio degli esiti sull’intero prodotto. La bozza propone che gli errori critici rimangano binari anche all’interno del modello a punteggio: qualsiasi errore critico blocca la conformità Bronzo indipendentemente da quanto bene il prodotto si comporta altrove.
Argento è il livello intermedio ed è inteso a corrispondere, approssimativamente, a un prodotto AA-plus solido — meglio della soglia WCAG 2.x AA ma non ancora ad AAA. Argento richiede tipicamente una soglia più elevata sugli stessi esiti ponderati, oltre al superamento di esiti aggiuntivi non richiesti a livello Bronzo. Le soglie specifiche sono ancora in consultazione nella bozza di lavoro.
Oro è il livello più elevato. È inteso a rappresentare un prodotto progettato e testato per l’intera gamma di esigenze funzionali coperte dalla linea guida, non solo quelle che i criteri WCAG 2.x AA affrontavano principalmente. Oro è il livello in cui gli esiti cognitivi, vocali, AAC e di AT emergente hanno il peso maggiore, perché sono i gruppi di utenti per i quali la conformità 2.x attualmente non produce un risultato comparabile.
Due importanti proprietà del modello a livelli vale la pena notare. In primo luogo, l’ambito è per vista o per flusso, non per pagina: un prodotto può avere livelli di conformità diversi su superfici diverse, il che è più onesto del modello per pagina di WCAG 2.x per le applicazioni complesse. In secondo luogo, la dichiarazione di conformità viaggia con i metodi utilizzati per verificarla — quindi una dichiarazione Argento ai sensi di WCAG 3 dovrebbe essere riproducibile da un altro tester che segue gli stessi metodi, in un modo in cui le dichiarazioni WCAG 2.x AA (che si basano pesantemente sul giudizio del tester ai margini) spesso non lo sono.
Modalità di tecnologia assistiva emergenti
Un impegno editoriale importante del progetto WCAG 3 è il supporto di prima classe per le modalità di tecnologia assistiva che WCAG 2.x ha storicamente affrontato solo in modo obliquo.
L’accessibilità cognitiva è la più ampia di tali espansioni. La bozza attuale incorpora lavori sugli esiti che erano stati precedentemente sviluppati nell’output separato della Cognitive Accessibility Task Force del W3C (il documento Making Content Usable for People with Cognitive and Learning Disabilities). Gli esiti in quest’area riguardano la chiarezza del linguaggio, la prevedibilità della navigazione, il supporto all’orientamento e alla ricerca del percorso, la prevenzione e il recupero dagli errori e la minimizzazione del carico cognitivo non necessario. Molti di questi esiti sono ponderati piuttosto che binari — non esiste un superato/non superato netto per «questa frase è sufficientemente leggibile» — ed è proprio il caso che il modello di conformità a punteggio è stato costruito per gestire.
Le interfacce vocali e conversazionali rientrano esplicitamente nel campo di applicazione. Gli esiti riguardano la riconoscibilità dei prompt vocali, la scopribilità dei comandi vocali, il percorso di recupero quando si verifica un errore di riconoscimento vocale e l’equivalenza tra interazione vocale e visiva nelle interfacce a doppia modalità. Questa è la parte della bozza in cui l’architettura della linea guida indipendente dalla piattaforma è più importante: un flusso solo vocale su uno smart speaker non può essere significativamente testato rispetto ai criteri di successo «contenuto web» di WCAG 2.x, ma può essere testato rispetto agli esiti WCAG 3 redatti per essere neutrali rispetto alla modalità.
Gli utenti AAC (comunicazione aumentativa e alternativa) — persone che comunicano principalmente attraverso tavole di simboli, sistemi di scambio di immagini o dispositivi di generazione vocale — sono esplicitamente contemplati nelle destinazioni di ricerca sugli utenti della bozza. Gli esiti in quest’area riguardano la coerenza dei simboli, il supporto all’input AAC come modalità di interazione di prima classe e la prevedibilità cognitiva degli stati di dialogo che un utente AAC deve navigare.
La AT emergente — tracciamento oculare, interfacce a interruttore, interfacce cervello-computer, head-tracking e le superfici assistive dei dispositivi di realtà mista — è nominata nella roadmap della bozza. La posizione di lavoro del Working Group è che l’architettura della linea guida dovrebbe accogliere queste modalità senza richiedere al documento di enumerare ogni possibile AT; l’asse delle esigenze funzionali è uno dei meccanismi per raggiungere questo obiettivo.
Tempistiche: quando potrebbe arrivare la Candidate Recommendation
La risposta onesta è che nessuno al di fuori dell’AG WG può fornire una data attendibile, e nessuno al suo interno ne ha pubblicata una. Il processo del W3C è basato sul consenso, e le questioni di progettazione ancora aperte in WCAG 3 — la metodologia di punteggio precisa, le soglie esatte per Bronzo/Argento/Oro, il formato della dichiarazione di conformità, la verificabilità degli esiti cognitivi, la relazione con WCAG 2.2 durante la transizione — non sono banali. Le Working Draft in qualsiasi linea di standard possono rimanere a quel livello di maturità per anni.
Ciò che si può affermare con ragionevole certezza è la forma del percorso. La Candidate Recommendation è il prossimo passo di maturità dopo l’attuale Working Draft, e la fase CR non può essere avviata finché il Working Group non risolve i problemi aperti attualmente segnalati nella bozza e non dimostra che gli esiti proposti sono verificabili (un processo che il W3C chiama revisione delle «funzionalità a rischio» e che richiede una sostanziale esperienza implementativa per essere superato). Diverse dichiarazioni pubbliche di rappresentanti del W3C durante il 2025 indicavano che la CR per WCAG 3 era ancora lontana e che il progetto doveva essere considerato come un percorso che si misura in anni, non in mesi, verso una specifica stabile.
Una volta raggiunta la fase CR, il calendario standard prevede almeno un periodo di implementazione di diversi mesi durante il quale il working group raccoglie prove che gli esiti siano stati verificati rispetto a prodotti reali. Seguono PR e REC. Dopo la REC, inizia il lento processo di adozione normativa — che storicamente si è misurato in anni, non in mesi. La citazione in stile EAA di WCAG 3 attraverso una EN 301 549 rivista (una V5 o successiva) è, ad una lettura realistica, una prospettiva della fine degli anni 2020 piuttosto che immediata.
La tensione con WCAG 2.2
WCAG 3 si trova in reale tensione politica con WCAG 2.2, e tale tensione è il sottotesto di ogni discussione su WCAG 3 all’interno del settore. WCAG 2.2 ha raggiunto lo stato di Recommendation nell’ottobre 2023 — uno standard pubblicato, stabile e citabile che le autorità di regolamentazione nazionali stanno ancora nel mezzo del processo di adozione. Alcune l’hanno già adottato. Altre no. La prossima V4 di EN 301 549 incorporerà WCAG 2.2; la Section 508 statunitense è nel mezzo di un aggiornamento che fa riferimento a WCAG 2.x; la difesa nel contenzioso privato negli Stati Uniti cita WCAG 2.x per impostazione predefinita.
La tensione non riguarda davvero quale documento sia «migliore». Riguarda se le autorità di regolamentazione possano adottare uno standard ancora in evoluzione — e se i team che hanno appena investito nella conformità WCAG 2.2 debbano credere che un diverso framework sia dietro l’angolo. La posizione dichiarata del Working Group è che le due serie non sono a somma zero: WCAG 2.2 rimane lo standard operativo per l’adozione normativa, e WCAG 3 è la prossima generazione che, col tempo, lo sostituirà. Entrambi i documenti saranno mantenuti parallelamente presso il W3C una volta che WCAG 3 raggiungerà lo stato di Recommendation, e il W3C ha segnalato che la transizione sarà deliberatamente abbastanza lunga da non costringere i team a una migrazione forzata.
In pratica questo significa tre cose. Il lavoro di audit WCAG 2.2 non è sprecato — le barriere di accesso sottostanti che identifica non scompaiono sotto WCAG 3, vengono riorganizzate in esiti. Le autorità di regolamentazione che stanno ancora adottando WCAG 2.2 non stanno commettendo un errore — stanno svolgendo il lavoro necessario per questo decennio. E i fornitori che commercializzano la «conformità WCAG 3» rispetto a una bozza di lavoro stanno travisando la maturità dello standard; nessuna dichiarazione di conformità rispetto a una Working Draft instabile ha significato.
WCAG 2.2 vs WCAG 3: confronto per dimensioni
| Dimensione | WCAG 2.2 (Recommendation attuale) | WCAG 3 (Working Draft attuale) |
|---|---|---|
| Maturità | W3C Recommendation dall’ottobre 2023 | Working Draft, non ancora Candidate Recommendation |
| Unità di conformità | Criterio di successo (superato/non superato binario) | Esito con metodi (binario o ponderato) |
| Livelli di conformità | A, AA, AAA — cumulativi per criterio | Bronzo, Argento, Oro — per punteggio aggregato degli esiti |
| Campo di applicazione | Contenuto web reso da uno user agent | Indipendente da contenuto e piattaforma (web, mobile, voce, chiosco) |
| Esiti cognitivi | Limitati; affrontati indirettamente attraverso diversi criteri di successo | Di prima classe, incorporati dal lavoro della cognitive-task-force del W3C |
| Voce / AAC / AT emergente | Non affrontati direttamente | Denominati come modalità nell’ambito con esiti dedicati |
| Artefatto di test | Tecniche informative accompagnano i criteri | Metodi normativi viaggiano con ciascun esito |
| Granularità della dichiarazione | Dichiarazione di conformità per pagina | Dichiarazione di conformità per vista o per flusso |
| Citato dalle autorità oggi | Sì (EAA tramite EN 301 549, Direttiva WAD, aggiornamento Section 508, tribunali) | No — la Working Draft non può essere citata normativamente |
| Orizzonte di adozione realistico | Operativo ora; diffusione normativa pluriennale ancora in corso | Fine degli anni 2020 al più presto, subordinata all’avanzamento CR/PR/REC |
Implicazioni per i siti 2.x oggi
La domanda pratica per qualsiasi team che gestisce un sito, un’app o un prodotto con WCAG 2.x oggi è: dovremmo fare qualcosa di diverso perché WCAG 3 è in arrivo? La risposta si articola in tre punti.
Effettuare audit e correzioni rispetto a WCAG 2.2 AA. Questo è lo standard che le autorità di regolamentazione stanno adottando, che EN 301 549 V4 incorporerà e che i tribunali nelle giurisdizioni con diritti di azione privata citano. Un audit WCAG 2.2 AA ben condotto nel 2026 non è un lavoro superfluo — le barriere sottostanti saranno ancora barriere sotto WCAG 3, e lo sforzo di correzione per rimediare è lo stesso. I team che hanno rimandato il lavoro su 2.2 nella speranza di «fare WCAG 3 invece» stanno scegliendo un risultato peggiore su un orizzonte temporale più lungo.
Leggere la Working Draft WCAG 3, senza effettuare refactoring per conformarsi ad essa. La bozza è una finestra utile su dove si sta dirigendo lo standard e quali esigenze degli utenti saranno in primo piano nel prossimo decennio. I team dovrebbero leggerla (è disponibile gratuitamente sul sito W3C TR), condividerla all’interno del team di design e ingegneria, e utilizzarla per avviare conversazioni sull’accessibilità cognitiva, le interfacce vocali e l’AAC. Non dovrebbero tuttavia iniziare a redigere dichiarazioni di conformità rispetto ad essa, a elaborare clausole di appalto rispetto ad essa o a ristrutturare i programmi di audit in previsione di essa. La bozza non è sufficientemente stabile per nessuna di queste attività.
Investire nella capacità di ricerca sugli utenti e di ricerca sul design che WCAG 3 richiederà. Gli esiti ponderati, olistici e indipendenti dalla modalità che WCAG 3 introduce non possono essere verificati dai soli strumenti di scansione automatizzata. Richiedono ricerca di design con utenti con disabilità cognitive, con utenti AAC, con utenti di interfacce vocali. I team che saranno pronti quando WCAG 3 raggiungerà lo stato di Recommendation non sono quelli con gli strumenti automatizzati più sofisticati — sono quelli con relazioni consolidate di ricerca sugli utenti attraverso l’intera gamma di esigenze funzionali. Costruire queste relazioni adesso è un investimento che paga dividendi con entrambi gli standard.
WCAG 3 nel grafo degli standard già noti
Per chi ha seguito l’arco degli standard di accessibilità — dalla Section 508 attraverso EN 301 549, da WCAG 2.0 del W3C attraverso 2.1 e fino a 2.2 — WCAG 3 è la prossima generazione di quell’arco, attualmente a metà progettazione. È il documento che la comunità degli standard sta costruendo perché i limiti del modello binario, solo-web, basato su criteri di successo di WCAG 2.x sono diventati difficili da ignorare man mano che l’accessibilità digitale si è espansa nelle interfacce mobile, vocali, AAC e cognitive. È anche, oggi, una Working Draft instabile che nessuna autorità di regolamentazione può ancora citare e contro la quale nessun fornitore responsabile può ancora dichiarare conformità.
Per i professionisti che pianificano il resto di questo decennio: WCAG 2.2 è lo standard rispetto al quale effettuare audit, EN 301 549 V4 è lo strumento di appalto con cui allinearsi, e WCAG 3 è il documento da leggere un venerdì pomeriggio per capire dove si sta dirigendo il lavoro. L’atteggiamento corretto è la pazienza informata — tenere WCAG 3 nella visione periferica, svolgere il lavoro WCAG 2.2 di fronte a sé e costruire la capacità di ricerca sugli utenti che conterà indipendentemente da quale documento citeranno gli auditor tra cinque anni. Per la puntata successiva di questa serie di primer, si veda il sondaggio sul tasso di adozione di WCAG 2.2 che traccia quali autorità di regolamentazione nazionali hanno già attraversato il traguardo.