Quando si selezionano CMS, plugin, widget o piattaforme SaaS, la documentazione può offrire indicazioni importanti sull’accessibilità dei siti web e dei prodotti digitali. Tuttavia, trovare un VPAT o un ACR non permette di concludere automaticamente che il prodotto sia accessibile.
Il rapporto raccoglie dichiarazioni di conformità che devono essere interpretate alla luce della versione analizzata, del perimetro coperto, degli standard applicati e dei metodi di valutazione. Per agenzie web, digital agency e professionisti, è quindi soprattutto uno strumento di due diligence da affiancare a verifiche dirette.
Di cosa parlerò in questa pagina
Perché un ACR non è un semplice bollino di accessibilità
La domanda «questo prodotto è accessibile?» raramente può ricevere una risposta utile basata soltanto su un sì o un no. Un prodotto può presentare parti conformi, barriere circoscritte, componenti esterni e flussi con livelli differenti di accessibilità.
Un ACR ben compilato aiuta a comprendere:
- quale prodotto e quale versione sono stati valutati;
- quali parti rientrano nel perimetro del rapporto;
- rispetto a quali standard è stata esaminata la conformità;
- quali metodi di valutazione sono stati impiegati;
- quali barriere rimangono e come possono incidere sugli utenti.
Non è però una certificazione né una prova definitiva. Anche una lunga sequenza di dichiarazioni positive perde valore se non è accompagnata da spiegazioni, metodi di test e informazioni verificabili.
VPAT e ACR: qual è la differenza
VPAT significa Voluntary Product Accessibility Template. È il modello predisposto dall’Information Technology Industry Council per documentare la conformità di prodotti e servizi digitali rispetto a requisiti e standard di accessibilità.
ACR significa invece Accessibility Conformance Report: è il rapporto ottenuto compilando il modello per uno specifico prodotto e una determinata versione.
I due termini vengono spesso usati come sinonimi, ma indicano elementi diversi:
- il VPAT è il modello da compilare;
- l’ACR è il documento compilato con le dichiarazioni relative al prodotto.
È inoltre importante chiarire che l’Information Technology Industry Council non esamina né approva gli ACR. Di conseguenza, non esiste una «certificazione VPAT» rilasciata o approvata da ITI.
Le edizioni VPAT e le versioni WCAG di riferimento
Il VPAT 2.5Rev, pubblicato nell’aprile 2025, è disponibile in quattro edizioni. La scelta dipende dal mercato, dagli standard pertinenti e dagli eventuali requisiti contrattuali.
| Edizione | Riferimento WCAG incluso |
|---|---|
| VPAT 508 | WCAG 2.0 |
| VPAT EU | WCAG 2.1 |
| VPAT WCAG | WCAG 2.2 |
| VPAT INT | WCAG 2.2 |
Il numero della versione del modello non è quindi sufficiente per capire che cosa sia stato valutato. Occorre controllare sempre edizione VPAT, standard applicato e versione WCAG dichiarata.
L’edizione 508, l’edizione EU, quella WCAG e quella internazionale non sono intercambiabili in ogni contesto. Per scegliere il documento pertinente bisogna considerare il prodotto, il mercato di destinazione e i requisiti applicabili al progetto, senza trasformare il rapporto in un parere legale.
Checklist: come leggere e valutare un ACR
Una lettura critica dell’ACR dovrebbe partire dalle informazioni che permettono di collegare il documento al prodotto realmente acquistato o utilizzato.
1. Identificare prodotto, versione e data
Il rapporto dovrebbe indicare chiaramente il prodotto analizzato, la versione o configurazione e la data di compilazione. Un documento riferito a una versione diversa può non descrivere correttamente l’ambiente effettivamente in uso.
2. Controllare il perimetro
Bisogna verificare quali elementi sono inclusi: sito pubblico, area riservata, applicazione, documenti, funzionalità principali e componenti di terze parti. La valutazione deve riguardare anche i flussi essenziali, non soltanto la homepage o alcune schermate dimostrative.
3. Verificare standard ed edizione VPAT
L’ACR dovrebbe dichiarare l’edizione adottata, gli standard considerati e la relativa versione WCAG. Queste informazioni permettono di capire secondo quali criteri sono state formulate le dichiarazioni.
4. Esaminare i metodi di valutazione
È utile cercare dettagli su test manuali e automatici, browser, tecnologie assistive e ambienti impiegati. La semplice indicazione di uno strumento automatico non è sufficiente a dimostrare la conformità complessiva.
5. Leggere le motivazioni, non solo i livelli
Il modello prevede i livelli Supports, Partially Supports, Does Not Support e Not Applicable. Le spiegazioni associate sono essenziali per comprendere quali parti soddisfano il criterio, dove emergono problemi e su quali verifiche si basa la valutazione.
Una sequenza di «Supports» senza motivazioni o evidenze non costituisce, da sola, una prova credibile.
6. Approfondire le barriere note
In presenza di conformità parziale o mancata, conviene chiedere quali utenti siano interessati, quali attività vengano ostacolate e se sia previsto un piano di correzione. Una non conformità circoscritta non rende necessariamente il prodotto inutilizzabile per tutti: deve essere valutata considerando la barriera e i flussi coinvolti.
7. Verificare l’accessibilità dell’ACR
Anche il rapporto dovrebbe essere strutturato, leggibile e utilizzabile con tastiera e tecnologie assistive. Un documento sull’accessibilità che non può essere consultato da una parte dei destinatari introduce una barriera nel processo di valutazione.
Dall’ACR alla verifica dell’accessibilità del sito web
Un ACR può essere compilato internamente dal produttore. Una verifica indipendente può aumentarne l’affidabilità, ma non rappresenta un requisito universale. In entrambi i casi, le dichiarazioni più rilevanti dovrebbero essere confermate sul prodotto reale.
Secondo il W3C, gli strumenti automatici non possono stabilire da soli la conformità di un sito web: sono necessarie valutazioni condotte da persone competenti. Un processo adeguato integra quindi:
- controlli automatici;
- verifiche manuali;
- test con tecnologie assistive;
- analisi dei flussi essenziali;
- quando opportuno, coinvolgimento di utenti con disabilità.
Per un sito web, i controlli dovrebbero comprendere almeno navigazione da tastiera, visibilità e ordine del focus, struttura semantica, form e gestione degli errori, contrasto, zoom, reflow e uso con screen reader.
WCAG-EM offre inoltre una metodologia strutturata per condurre e documentare una valutazione dell’accessibilità web. Il suo impiego aiuta a definire il perimetro e a organizzare le verifiche, evitando di limitare l’analisi a pagine o componenti isolati.
Due diligence per agenzie, freelance e web agency
L’ACR è particolarmente utile prima di introdurre nel progetto un CMS, un plugin, un widget o una piattaforma SaaS. Un processo operativo può essere organizzato in questi passaggi:
- Richiedere l’ACR prima della selezione o dell’acquisto.
- Controllare versione e configurazione rispetto a quelle che saranno effettivamente utilizzate.
- Esaminare perimetro, standard e metodi di test, prestando attenzione alle spiegazioni associate ai livelli di conformità.
- Verificare sul prodotto reale le dichiarazioni relative ai flussi più importanti.
- Definire requisiti WCAG verificabili e responsabilità per gli eventuali componenti di terze parti all’interno degli accordi di progetto.
- Richiedere un aggiornamento del rapporto dopo modifiche sostanziali del prodotto.
Nel caso di componenti integrati, è importante valutare anche il risultato finale. Un widget può modificare navigazione da tastiera, focus, struttura semantica o comportamento dei form. Allo stesso modo, l’accessibilità di un CMS non garantisce automaticamente quella del sito costruito con temi, plugin, contenuti e configurazioni specifiche.
Trasparenza e disponibilità degli ACR: i dati esplorativi WebAIM
Un’indagine esplorativa citata da WebAIM ha considerato 231 prodotti EdTech riconducibili a 186 fornitori unici. Riferimenti a informazioni VPAT sono stati individuati presso 35 fornitori, circa il 19%. Tra questi, il 22% richiedeva ai potenziali clienti di domandare il documento invece di renderlo pubblico.
Questi dati derivano da una ricerca settoriale basata anche sull’intelligenza artificiale e non costituiscono una valutazione rappresentativa dell’intero mercato digitale. Evidenziano però un possibile punto di frizione: la difficoltà di reperire i rapporti prima di scegliere un prodotto.
La pubblicazione dell’ACR favorisce la trasparenza, ma non ne garantisce qualità, completezza o attendibilità. Anche un documento pubblico deve essere letto criticamente e confrontato con il prodotto reale.
Conclusione: un punto di partenza, non una prova definitiva
Un ACR ben costruito aiuta a individuare le parti dichiarate conformi, le barriere residue e la solidità delle prove presentate. Non sostituisce però una valutazione diretta e non garantisce automaticamente una buona esperienza per ogni persona con disabilità.
Per valutare seriamente l’accessibilità di siti e prodotti digitali è necessario unire documentazione, competenze specialistiche e verifiche sul campo.
Hai bisogno di supporto per leggere un ACR o verificare nella pratica l’accessibilità di un sito o prodotto digitale? Contattami per saperne di più.
Fonte di approfondimento: WebAIM, “If you have to ask, is it accessible?”.
Fonti
- If you have to ask, is it accessible? (webaim.org)
- VPAT – Information Technology Industry Council (lists.itic.org)
- Evaluating Web Accessibility Overview | Web Accessibility Initiative (WAI) | W3C (www.w3.org)
Domande frequenti su VPAT, ACR e accessibilità
Il VPAT è il modello predisposto dall’Information Technology Industry Council. L’ACR è il rapporto compilato per documentare la conformità di uno specifico prodotto e di una determinata versione.
No. Un ACR raccoglie dichiarazioni di conformità, ma non è una certificazione. ITI non esamina né approva i rapporti compilati e non esiste una «certificazione VPAT».
Occorre verificare prodotto, versione, data, perimetro, standard applicati, metodi di valutazione e motivazioni associate ai livelli di conformità. Vanno inoltre approfondite le barriere note, il loro impatto e gli eventuali piani di correzione.
La scelta dipende dal mercato, dagli standard pertinenti e dai requisiti contrattuali del progetto. È necessario controllare anche la versione WCAG inclusa nell’edizione, senza basarsi soltanto sul numero della versione del modello.
No. Gli strumenti automatici sono utili, ma non possono determinare da soli la conformità complessiva. Devono essere affiancati da controlli manuali, valutazioni competenti, test con tecnologie assistive e analisi dei flussi essenziali.
Bisogna richiedere un ACR pertinente alla versione utilizzata, controllarne perimetro e metodi di test e verificare direttamente le funzionalità essenziali. Occorre inoltre considerare configurazione, componenti di terze parti e risultato finale prodotto dall’integrazione.
