Nel panorama attuale della progettazione digitale, garantire l’accessibilità di un intero ecosistema — che si tratti di un portale bancario, un’app nativa o un chiosco interattivo — non è un’operazione che si può ridurre a una semplice checklist di controllo. Per chi lavora quotidianamente con i Criteri di Successo (Success Criteria) delle WCAG, la sfida non è solo tecnica, ma metodologica: come possiamo garantire che un’analisi rifletta l’esperienza reale dell’utente senza perderci in un campionamento superficiale o in dichiarazioni di conformità prive di fondamento?

La nuova metodologia WCAG-EM 2.0 (W3C Draft Note, Febbraio 2026) nasce proprio per rispondere a questa complessità. Non si limita a fornire istruzioni su “cosa” testare, ma traccia una tabella di marcia rigorosa su “come” farlo, integrando il supporto per le WCAG 2.2 e affrontando le insidie dei moderni prodotti digitali. Come auditor, ho imparato che il rigore nel processo è l’unico modo per evitare errori costosi e per spostare l’ago della bilancia verso un’inclusione autentica.

——————————————————————————–

1. Valutare un campione non equivale a una “Dichiarazione di Conformità”

Un errore sistematico che osservo spesso nelle organizzazioni è la tendenza a voler rilasciare una dichiarazione di conformità totale dopo aver testato solo una manciata di pagine. La Sezione 1.2 della metodologia WCAG-EM è categorica: il campionamento, per quanto accurato, non offre la certezza assoluta che ogni singola visualizzazione o stato del prodotto sia privo di barriere. Esisterà sempre la possibilità di “punti ciechi” nelle aree non testate.

Legalmente e tecnicamente, questo significa che utilizzare questa metodologia per valutare un sottoinsieme del prodotto non permette di effettuare una “WCAG Conformance Claim” per l’intero sito. Questa distinzione è vitale per proteggere l’utente finale: serve a impedire che le aziende si facciano scudo dietro una valutazione parziale per ignorare problemi critici sepolti in sezioni meno visibili. Come specifica chiaramente il documento:

“Le dichiarazioni di conformità WCAG 2 non possono essere effettuate per interi siti web basandosi esclusivamente sulla valutazione di un sottoinsieme selezionato di pagine web e funzionalità, poiché è sempre possibile che vi siano errori di conformità non identificati su tali siti.”

——————————————————————————–

2. Il “Principio di Chiusura” e il rischio dello “Scope Washing”

Il concetto di Product Enclosure (Chiusura del Prodotto), descritto nella Sezione 3.1, è il baluardo contro quello che mi piace definire “Scope Washing”. Troppo spesso, durante la definizione del perimetro di audit, si tenta di escludere parti “difficili” o contenuti di terze parti per presentare un report più pulito.

La metodologia impone invece che, se l’obiettivo è un sito di online banking, non si possano escludere i processi di autenticazione o i moduli di terze parti solo perché sono complessi da analizzare o modificare. La trasparenza del perimetro è l’unico modo per garantire che l’audit non sia solo una facciata. Escludere arbitrariamente delle funzionalità distorce i risultati e tradisce il requisito WCAG per i processi completi. Se una parte del perimetro decade, decade la credibilità dell’intero intervento.

——————————————————————————–

3. L’umiltà del campione casuale: la regola del 10%

Mentre il campione strutturato (Sezione 4.3.1) riflette la logica e l’esperienza dell’auditor nel selezionare template e funzionalità critiche, il Random Sample Set (Sezione 4.3.2) introduce un necessario elemento di imprevedibilità. La regola è chiara: il campione casuale deve corrispondere ad almeno il 10% della dimensione del campione strutturato.

L’aspetto fondamentale non è solo la quantità, ma il metodo di selezione. Per evitare bias e prevedibilità, l’esperto deve utilizzare strumenti rigorosi: crawlers, script automatici, log del server o motori di ricerca per estrarre URL che coprano l’intero perimetro definito. Se il campione random rivela barriere non identificate nel set strutturato, la metodologia ci impone di tornare indietro e rivedere l’intera selezione. È un esercizio di umiltà metodologica che ci ricorda che la logica dell’analista non sempre coincide con la vastità disordinata di un prodotto digitale reale.

——————————————————————————–

4. Analizzare i “Processi Completi”: la trappola della visualizzazione isolata

Un’accessibilità frammentata è, per l’utente, una non-accessibilità. La Sezione 4.3.3 e il Glossario ci obbligano a valutare non solo singoli URL, ma Processi Completi. Un processo è una serie di passaggi necessari per completare un’attività, e la sua valutazione richiede di mappare due percorsi distinti:

• Default Sequence: Il cosiddetto “happy path”, il percorso standard senza errori di input o opzioni aggiuntive.
• Branch Sequences: I percorsi alternativi ma critici (es. aggiungere un nuovo indirizzo di spedizione durante il checkout o gestire messaggi di errore).

Se un solo passaggio in una di queste sequenze fallisce un Criterio di Successo, l’intero processo è considerato non conforme. Testare solo la visualizzazione iniziale di un modulo senza percorrerne le ramificazioni significa ignorare dove avvengono i veri fallimenti dell’esperienza utente.

——————————————————————————–

5. Una metodologia agnostica: oltre l’URL per App e Kiosk

Uno dei punti di forza della Sezione 3.2 è la sua natura agnostica rispetto alla tecnologia. Sebbene le WCAG siano nate per il web, la metodologia WCAG-EM 2.0 si adatta a App Native, Kiosk e documenti digitali.

Tuttavia, questo pone una sfida tecnica per l’auditor: in contesti dove non esistono URL statici (come le app mobili o i terminali self-service), l’identificazione dei campioni deve cambiare registro. In questi casi, la metodologia richiede di identificare il campione tramite screenshot univoci e descrizioni dettagliate del percorso (path description) che portano a quello specifico stato dell’interfaccia. Questo livello di dettaglio garantisce la replicabilità del test, un pilastro di ogni audit professionale. Come recita il testo:

“Questa metodologia è applicabile a una vasta varietà di prodotti digitali.”

——————————————————————————–

Conclusione: L’accessibilità come processo iterativo

Adottare la metodologia WCAG-EM 2.0 trasforma l’audit da un semplice momento di “ispezione” a un processo continuo di miglioramento. Ci ricorda che il Supporto all’Accessibilità (Accessibility Support Baseline) deve essere definito all’inizio e verificato costantemente, considerando la combinazione reale di browser, tecnologie assistive e User Agent.

La conformità tecnica è solo la linea di partenza. La vera domanda per product owner e sviluppatori è: stiamo costruendo prodotti che soddisfano un punteggio o prodotti che permettono a chiunque di completare un acquisto, consultare un saldo o prenotare una visita medica? La responsabilità di andare oltre la checklist è nostra. Siete pronti ad abbandonare l’illusione della conformità per abbracciare un rigore che porti a un’inclusione reale?