# Accessibilità come il GDPR: audit WCAG periodici, dichiarazione e progettazione inclusiva > Trattare l'accessibilità come la privacy: ruoli, audit WCAG-EM, cadenza dei controlli, CI con baseline, monitoraggio, dichiarazione di accessibilità e fornitori. - Autore / Author: Diego Betto (https://diegobetto.com/about/) - Pubblicato / Published: 2026-10-29 - URL: https://diegobetto.com/accessibilita-come-gdpr-audit-wcag/ - Tag: accessibilità, wcag, compliance, testing, web-development Nel 2018 il GDPR ha insegnato alle aziende europee una cosa scomoda: la conformità non è un documento, è un processo. Non basta un'informativa privacy scritta bene. Servono un registro dei trattamenti, una persona responsabile, valutazioni d'impatto prima di lanciare qualcosa di nuovo, contratti con i fornitori e un modo per reagire quando qualcosa va storto. Con l'**European Accessibility Act** l'accessibilità sta seguendo la stessa strada. Nell'articolo sulla [guida pratica all'EAA e alle WCAG 2.2](https://diegobetto.com/european-accessibility-act-guida-sviluppatori/) ho spiegato chi è obbligato e come si scrive codice accessibile: HTML semantico, tastiera, contrasti, form, test. Qui affronto l'altra metà del problema, quella che decide se un sito conforme oggi lo sarà ancora tra sei mesi: **come si organizza l'accessibilità** perché regga nel tempo. ### Il parallelo con il GDPR Il confronto non è solo una metafora. Quasi ogni pezzo di un programma privacy ha un equivalente per l'accessibilità, e se la tua azienda ha già fatto il lavoro per il GDPR, metà della struttura esiste già. | GDPR | Accessibilità | | -------------------------------------------- | ----------------------------------------------------------------- | | Privacy by design (art. 25) | Accessibility by design: requisiti nei ticket e nel design system | | Registro dei trattamenti (art. 30) | Inventario di pagine, flussi e componenti con il loro stato di conformità | | DPIA prima di un nuovo trattamento (art. 35) | Revisione di accessibilità prima di rilasciare una nuova funzionalità | | DPO o referente privacy | Referente accessibilità con autorità reale sul backlog | | Informativa privacy | Dichiarazione o informazioni sull'accessibilità | | Contratti con i responsabili (art. 28) | Requisiti EN 301 549 nei contratti con fornitori e widget di terze parti | | Gestione dei data breach (art. 33) | Canale di segnalazione e tempi di risposta per le barriere | | Garante privacy | AgID (per i servizi soggetti all'EAA) | Una differenza importante: l'EAA non impone a un'azienda privata di nominare un "responsabile accessibilità" come il GDPR fa con il DPO in certi casi. Ma in pratica, senza una persona che ne risponde, l'accessibilità finisce sempre in fondo al backlog. > Per le pubbliche amministrazioni italiane il processo è già codificato dalla Legge Stanca e dalle > Linee guida AgID: obiettivi di accessibilità da pubblicare entro il 31 marzo e dichiarazione di > accessibilità da compilare ogni anno entro il 23 settembre tramite il form di AgID. È un buon > modello anche per i privati, che hanno obblighi meno formalizzati ma lo stesso problema di > continuità. ### Ruoli: chi fa cosa L'accessibilità non è un problema degli sviluppatori. Una buona parte delle barriere nasce prima del codice (un design senza stati di focus, un flusso che chiede due volte gli stessi dati) o dopo (un redattore che carica un'infografica senza testo alternativo). | Ruolo | Responsabilità | | -------------------- | ------------------------------------------------------------------------------------------------- | | **Referente** | Tiene l'inventario, pianifica gli audit, decide le priorità con il product owner, aggiorna la dichiarazione | | **Product owner** | Mette i criteri di accessibilità nei requisiti; una barriera bloccante è un bug, non una feature | | **Design** | Palette verificata, stati di focus e di errore, ordine di lettura e target nei mockup | | **Sviluppo** | Componenti accessibili, test automatici in CI, nessuna regressione | | **QA** | Test manuali con tastiera e screen reader sui flussi critici a ogni rilascio | | **Contenuti** | Testi alternativi, titoli strutturati, linguaggio chiaro, sottotitoli e trascrizioni | | **Acquisti e legale** | Requisiti nei contratti, richiesta dei report di conformità ai fornitori | ### Audit: un metodo, non un giro di Lighthouse Un audit serio ha bisogno di un metodo ripetibile, altrimenti due audit a sei mesi di distanza non sono confrontabili. Il riferimento è **WCAG-EM** (Website Accessibility Conformance Evaluation Methodology) del W3C, che divide il lavoro in cinque passi: 1. **Definire il perimetro**: quale sito o app, quale versione delle WCAG (oggi 2.2 AA), quali browser e tecnologie assistive. 2. **Esplorare il sito**: individuare le pagine comuni (home, ricerca, contatti), le funzionalità essenziali (acquisto, registrazione, login), i tipi di pagina e le tecnologie usate. 3. **Selezionare un campione rappresentativo**: un campione strutturato con un esempio di ogni template e di ogni flusso, più un campione casuale pari almeno al 10% del campione strutturato. Quello casuale serve a scoprire ciò che non avevi previsto. 4. **Valutare il campione**: ogni criterio WCAG su ogni pagina, con strumenti automatici e verifiche manuali. 5. **Riportare i risultati**: criterio per criterio, con dove si trova il problema, l'impatto e come correggerlo. Per i flussi, il campione non sono pagine singole ma **processi completi**: un checkout è conforme solo se tutti i suoi passi lo sono. Una pagina di pagamento perfetta dopo un carrello inutilizzabile da tastiera non serve a nessuno. Il risultato di un audit va scritto in un formato che altri possano leggere. Per i prodotti software lo standard di fatto è l'**Accessibility Conformance Report** (ACR), compilato sul modello VPAT di ITI, che ha un'edizione europea basata su EN 301 549. Se vendi software ad altre aziende, prima o poi qualcuno te lo chiederà. ### La cadenza: quando controllare cosa Il GDPR non chiede di rifare la DPIA ogni settimana, ma chiede di rifarla quando cambia qualcosa di rilevante. L'accessibilità funziona allo stesso modo: controlli leggeri e frequenti, controlli profondi e rari. | Quando | Cosa | Chi | | ------------------------------ | -------------------------------------------------------------------- | ---------------------- | | **Ogni pull request** | axe in CI su componenti e pagine toccate, lint di accessibilità | Automatico | | **Ogni rilascio** | Tastiera sui flussi modificati, controllo del focus e degli errori | QA | | **Ogni settimana** | Scansione automatica di un campione casuale delle pagine in produzione | Automatico | | **Ogni trimestre** | Mini-audit dei flussi critici con screen reader | Referente o QA | | **Ogni anno** | Audit completo WCAG-EM, possibilmente esterno; aggiornamento della dichiarazione | Audit esterno | | **Prima di un lancio importante** | Revisione di design e audit del nuovo flusso, come una DPIA | Design, QA, referente | La scansione settimanale in produzione è quella che manca quasi sempre, ed è quella che trova le sorprese: il banner promozionale aggiunto dal marketing, il widget di chat aggiornato dal fornitore, la pagina creata dal CMS con un template vecchio. ### CI con baseline: niente nuove barriere Il test che ho mostrato nella guida all'EAA fallisce se una pagina ha **anche una sola** violazione. È la regola giusta per un sito nuovo, ma su un sito esistente con duecento violazioni note la build sarebbe rossa per mesi, e una build sempre rossa viene ignorata. La soluzione è la stessa che si usa con i linter su codice legacy: una **baseline**. Le violazioni note vengono registrate in un file versionato, e la CI fallisce solo per quelle nuove. Il debito si riduce nel tempo, ma non cresce. ```ts // tests/a11y-baseline.spec.ts import { test, expect } from "@playwright/test"; import AxeBuilder from "@axe-core/playwright"; import { existsSync, readFileSync, writeFileSync } from "node:fs"; const BASELINE_FILE = "a11y-baseline.json"; const UPDATE = process.env.UPDATE_A11Y_BASELINE === "1"; const PAGES = ["/", "/prodotti/", "/prodotti/scarpe-trail/", "/carrello/", "/checkout/"]; // path -> elenco di "regola|selettore" già noti type Baseline = Record; const baseline: Baseline = existsSync(BASELINE_FILE) ? JSON.parse(readFileSync(BASELINE_FILE, "utf-8")) : {}; // Tutti i test nello stesso worker, così afterAll scrive una baseline completa test.describe.configure({ mode: "serial" }); for (const path of PAGES) { test(`${path}: nessuna nuova violazione WCAG`, async ({ page }) => { await page.goto(path); const { violations } = await new AxeBuilder({ page }) .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"]) .analyze(); const current = violations.flatMap((v) => v.nodes.map((node) => `${v.id}|${node.target.join(" ")}`)); if (UPDATE) { baseline[path] = current.sort(); return; } const known = new Set(baseline[path] ?? []); const added = current.filter((f) => !known.has(f)); const fixed = [...known].filter((f) => !current.includes(f)); if (fixed.length > 0) { console.log(`${path}: ${fixed.length} violazioni risolte, aggiorna la baseline`); } expect(added, "Violazioni nuove rispetto alla baseline").toEqual([]); }); } test.afterAll(() => { if (UPDATE) writeFileSync(BASELINE_FILE, JSON.stringify(baseline, null, 2) + "\n"); }); ``` Due regole per non trasformare la baseline in un tappeto sotto cui nascondere tutto: - **La baseline si aggiorna solo per scendere.** Rigenerarla per far passare una PR che aggiunge violazioni deve richiedere una revisione esplicita del referente, per esempio con un `CODEOWNERS` sul file. - **Il numero di voci è una metrica.** Se dopo tre mesi non è calato, la baseline sta solo nascondendo il problema. Il selettore CSS come chiave non è perfetto: un refactoring del markup può far "comparire" violazioni vecchie con un selettore nuovo. È un falso positivo accettabile, perché costringe a guardare la pagina, ed è molto meglio di una CI che non controlla niente. ### Monitoraggio in produzione La CI controlla le pagine che conosci. Il monitoraggio controlla quelle che non conosci: tutto ciò che arriva dal CMS, dai fornitori e dalle campagne. Uno script che legge la sitemap, prende i flussi critici più un campione casuale e lancia axe su ciascuna pagina: ```ts // scripts/a11y-monitor.ts — Node 22.18+ esegue TypeScript direttamente (serve "type": "module") import { appendFile } from "node:fs/promises"; import { chromium } from "playwright"; import AxeBuilder from "@axe-core/playwright"; const SITE = process.env.SITE_URL ?? "https://example.com"; const SAMPLE_SIZE = Number(process.env.SAMPLE_SIZE ?? 25); const CRITICAL = ["/", "/carrello/", "/checkout/", "/accedi/"]; async function sitemapUrls(url: string): Promise { const xml = await (await fetch(url)).text(); const locs = [...xml.matchAll(/\s*([^<\s]+)\s*<\/loc>/g)].map((m) => m[1]); // Una sitemap index contiene altre sitemap, non pagine if (xml.includes("(items: T[], n: number): T[] { const copy = [...items]; for (let i = copy.length - 1; i > 0; i--) { const j = Math.floor(Math.random() * (i + 1)); [copy[i], copy[j]] = [copy[j], copy[i]]; } return copy.slice(0, n); } const all = await sitemapUrls(`${SITE}/sitemap-index.xml`); const targets = [...new Set([...CRITICAL.map((p) => new URL(p, SITE).href), ...sample(all, SAMPLE_SIZE)])]; const browser = await chromium.launch(); const page = await browser.newPage(); const rows: { url: string; rule: string; impact: string; nodes: number }[] = []; for (const url of targets) { await page.goto(url, { waitUntil: "networkidle" }); const { violations } = await new AxeBuilder({ page }) .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"]) .analyze(); for (const v of violations) { rows.push({ url, rule: v.id, impact: v.impact ?? "unknown", nodes: v.nodes.length }); } } await browser.close(); const report = [ `## Monitoraggio accessibilità — ${new Date().toISOString().slice(0, 10)}`, "", `Pagine controllate: ${targets.length}. Violazioni: ${rows.length}.`, "", "| Pagina | Regola | Impatto | Elementi |", "| --- | --- | --- | --- |", ...rows.map((r) => `| ${new URL(r.url).pathname} | ${r.rule} | ${r.impact} | ${r.nodes} |`), ].join("\n"); if (process.env.GITHUB_STEP_SUMMARY) await appendFile(process.env.GITHUB_STEP_SUMMARY, report + "\n"); else console.log(report); // Fallisce solo sulle violazioni critiche: il resto finisce nel report settimanale process.exitCode = rows.some((r) => r.impact === "critical") ? 1 : 0; ``` E una GitHub Action che lo esegue ogni lunedì mattina: ```yaml # .github/workflows/a11y-monitor.yml name: Monitoraggio accessibilità on: schedule: - cron: "0 6 * * 1" # ogni lunedì alle 6:00 UTC workflow_dispatch: jobs: axe: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 24 - run: npm ci - run: npx playwright install --with-deps chromium - run: node scripts/a11y-monitor.ts env: SITE_URL: https://example.com ``` Il report compare nel riepilogo dell'esecuzione. Il passo successivo naturale è aprire in automatico una issue per ogni violazione critica, ma all'inizio un report letto ogni lunedì dal referente è più utile di cinquanta issue generate da un bot. ### Triage e debito di accessibilità Le barriere vanno ordinate per **impatto sull'utente**, non per numero di occorrenze o per criterio WCAG. Cento immagini decorative senza `alt=""` sono meno gravi di un solo bottone "Paga" che non si raggiunge con la tastiera. axe classifica le violazioni come `critical`, `serious`, `moderate` e `minor`; per il triage io uso una scala orientata al compito: | Livello | Definizione | Tempo di correzione (esempio) | | ------------- | ------------------------------------------------------- | ----------------------------- | | **Bloccante** | Impossibile completare un compito (pagare, accedere, inviare un form) | Prossimo rilascio, al massimo 5 giorni lavorativi | | **Grave** | Possibile solo con grande fatica o con un aiuto esterno | 30 giorni | | **Moderato** | Fastidioso, ma aggirabile | 90 giorni | | **Minore** | Fastidio lieve, nessun impatto sul compito | Quando si tocca il componente | I tempi sono un esempio, non un obbligo di legge. Quello che conta è che siano scritti, concordati e misurati, come i tempi di risposta a un incidente di sicurezza. Ogni barriera diventa una issue con etichette coerenti, così il debito si può contare. Un modulo di issue per GitHub aiuta anche chi non è sviluppatore a segnalare bene: ```yaml # .github/ISSUE_TEMPLATE/accessibilita.yml name: Problema di accessibilità description: Una barriera che impedisce o rende difficile usare il sito labels: ["a11y"] body: - type: input id: url attributes: label: Pagina o flusso placeholder: "/checkout/ — passo pagamento" validations: required: true - type: dropdown id: impatto attributes: label: Impatto options: - "Bloccante: non riesco a completare il compito" - "Grave: ci riesco con molta fatica o con un aiuto" - "Moderato: fastidioso ma aggirabile" - "Minore" validations: required: true - type: input id: wcag attributes: label: Criterio WCAG (se noto) placeholder: "2.4.7 Focus visibile" - type: textarea id: ambiente attributes: label: Tecnologia assistiva e ambiente placeholder: "NVDA + Firefox su Windows 11; solo tastiera" - type: textarea id: passi attributes: label: Passi per riprodurre e risultato atteso validations: required: true ``` ### La dichiarazione di accessibilità È l'equivalente dell'informativa privacy: un documento pubblico che dice agli utenti cosa possono aspettarsi. L'EAA chiede ai fornitori di servizi di spiegare come il servizio soddisfa i requisiti di accessibilità, in un formato a sua volta accessibile. Il modello W3C per le dichiarazioni è un buon punto di partenza anche fuori dalla PA. Una dichiarazione utile contiene: - **Lo standard di riferimento**: WCAG 2.2 livello AA, EN 301 549. - **Lo stato di conformità**: pienamente, parzialmente o non conforme. "Parzialmente conforme" con un elenco onesto vale più di un "pienamente conforme" che non regge al primo test. - **Le non conformità note**, con il motivo e un'alternativa: "I grafici storici dei prezzi non hanno un'alternativa testuale; i dati sono disponibili in tabella a questo link". - **Come è stata valutata**: autovalutazione o audit esterno, e la data. - **Un canale di segnalazione** che funziona davvero, con un tempo di risposta dichiarato. - **La procedura di reclamo**: a chi può rivolgersi l'utente se la risposta non arriva o non è soddisfacente (per l'EAA in Italia, AgID). - **La data dell'ultimo aggiornamento**, che deve corrispondere all'ultimo audit, non all'ultimo deploy. > Una dichiarazione copiata da un altro sito, o che dichiara la piena conformità senza un audit, > è peggio di nessuna dichiarazione: è un'affermazione pubblica falsa, e la prima segnalazione di > un utente la smentisce. ### Fornitori e componenti di terze parti Per l'utente il sito è uno solo. Non gli interessa che il widget di chat sia di un fornitore, che il calendario delle prenotazioni sia un iframe o che il banner dei cookie arrivi da una CMP. Se non riesce a chiuderlo con la tastiera, il sito non è accessibile. Ed è lo stesso ragionamento che si fa per la [sicurezza della supply chain](https://diegobetto.com/sicurezza-supply-chain-nodejs/): quello che includi diventa tuo. I componenti da controllare per primi, perché compaiono su ogni pagina o sui flussi che portano soldi: - **Banner dei cookie**: è il punto in cui GDPR e accessibilità si incontrano. Deve ricevere il focus, essere utilizzabile da tastiera, avere contrasti corretti e non coprire l'elemento con il focus (criterio 2.4.11). - **Pagamento** in iframe o redirect del provider. - **Chat e assistenti**, compresi quelli basati su AI. - **Mappe, calendari, player video, widget di recensioni.** Nei contratti e nelle gare, chiedi un ACR aggiornato, la conformità a EN 301 549 come requisito, tempi di correzione per le barriere segnalate e il diritto di testare il componente prima dell'acquisto. Esattamente come si chiede a un responsabile del trattamento di garantire misure di sicurezza adeguate. ### Progettazione inclusiva: prima del codice Gli audit trovano i problemi. La progettazione inclusiva evita di crearli, ed è molto più economica: spostare un bottone in un mockup costa un minuto, in produzione un rilascio. I principi di inclusive design di Microsoft sono un buon punto di partenza, e si riassumono in tre idee: 1. **Riconoscere l'esclusione.** Ogni scelta di design include qualcuno ed esclude qualcun altro. Chiederselo esplicitamente è già metà del lavoro. 2. **Risolvere per uno, estendere a molti.** I sottotitoli nati per le persone sorde li usano tutti in treno. Il contrasto alto serve a chi ha una bassa visione e a chi legge al sole. 3. **Imparare dalla diversità.** Le persone con disabilità sono esperte nell'adattarsi a interfacce difficili: coinvolgerle (e pagarle) nei test produce informazioni che nessuna checklist dà. L'idea più utile per i team è lo **spettro delle disabilità**: una limitazione può essere permanente, temporanea o situazionale. Chi ha un solo braccio, chi ha un braccio ingessato e chi tiene in braccio un neonato hanno lo stesso bisogno: usare l'interfaccia con una mano. Progettare per il primo caso risolve anche gli altri due, e trasforma l'accessibilità da "funzionalità per pochi" a qualità del prodotto. In pratica, prima che un design arrivi allo sviluppo: - [ ] Palette dai design token verificati, anche per il tema scuro - [ ] Stati di focus, hover, errore e disabilitato disegnati, non lasciati al caso - [ ] Ordine di lettura e di tabulazione annotato nei mockup complessi - [ ] Struttura dei titoli definita (un `h1`, gerarchia senza salti) - [ ] Testi alternativi delle immagini informative scritti dai contenuti, non inventati dallo sviluppatore - [ ] Target interattivi di almeno 24×24 px, alternative al trascinamento - [ ] Messaggi di errore che spiegano come correggere, non solo che c'è un errore - [ ] Linguaggio chiaro: frasi brevi, termini comuni, niente gergo interno ### Metriche: misurare il programma, non solo il sito Un programma senza metriche diventa un'attività che si fa quando c'è tempo. Quelle che uso: - **Copertura**: percentuale di flussi critici sottoposti ad audit negli ultimi 12 mesi. - **Debito**: barriere aperte per livello di impatto, e voci nella baseline della CI. Entrambe devono scendere. - **Tempo di correzione**: dalla segnalazione alla soluzione, per livello di impatto, confrontato con i tempi concordati. - **Regressioni bloccate**: quante PR la CI ha fermato. Un numero alto all'inizio è un buon segno, vuol dire che il controllo funziona. - **Segnalazioni degli utenti**: quante arrivano e in quanto tempo ricevono una risposta. ### Errori da evitare - **Audit una tantum.** Un PDF di audit di due anni fa descrive un sito che non esiste più. - **Solo test automatici.** Trovano una parte dei problemi; il resto richiede tastiera, screen reader e persone. - **Overlay "magici".** Non correggono il codice e spesso peggiorano l'esperienza con gli screen reader. Ne ho parlato nella [guida all'EAA](https://diegobetto.com/european-accessibility-act-guida-sviluppatori/). - **Accessibilità come compito degli sviluppatori.** Se design e contenuti non sono coinvolti, ogni sprint produce nuove barriere da correggere. - **Dichiarazione decorativa.** Pubblicata una volta, mai aggiornata, con un indirizzo email che nessuno legge. - **Ignorare i fornitori.** Il componente di terze parti più usato del sito è spesso quello meno accessibile. ### Checklist del programma - [ ] Un referente per l'accessibilità con autorità sul backlog - [ ] Inventario di template, flussi critici e componenti di terze parti - [ ] Audit WCAG-EM annuale, con campione strutturato e casuale - [ ] axe in CI con baseline che può solo scendere - [ ] Scansione settimanale di un campione delle pagine in produzione - [ ] Test manuali con tastiera e screen reader sui flussi modificati a ogni rilascio - [ ] Scala di impatto e tempi di correzione scritti e misurati - [ ] Modulo di segnalazione per il team e canale pubblico per gli utenti - [ ] Dichiarazione di accessibilità onesta, datata, aggiornata dopo ogni audit - [ ] Requisiti EN 301 549 e ACR nei contratti con i fornitori - [ ] Revisione di accessibilità nel design, prima dello sviluppo - [ ] Formazione per design, sviluppo, QA e contenuti ### Domande frequenti > **Ogni quanto va fatto un audit di accessibilità?** > > Un audit completo con metodo WCAG-EM almeno una volta all'anno e prima di ogni lancio o redesign > importante. In mezzo servono controlli più leggeri: axe in CI a ogni pull request, una scansione > settimanale in produzione e un mini-audit trimestrale dei flussi critici con screen reader. > **L'audit va fatto da un consulente esterno?** > > Non è obbligatorio, ma un audit esterno almeno una volta all'anno è consigliabile: chi ha > costruito il sito tende a usarlo come previsto e non come lo userebbe un utente reale. I controlli > frequenti possono restare interni, purché il team sia formato sull'uso di tastiera e screen reader. > **Cos'è una baseline di accessibilità in CI?** > > Un file versionato con le violazioni già note. La pipeline fallisce solo se compare una violazione > nuova, così un sito con molto debito pregresso può comunque bloccare le regressioni da subito, > mentre il numero di violazioni note viene ridotto un po' alla volta. > **Cosa deve contenere una dichiarazione di accessibilità?** > > Lo standard di riferimento, lo stato di conformità, le non conformità note con le alternative > disponibili, il metodo e la data della valutazione, un canale di segnalazione con i tempi di > risposta e la procedura di reclamo presso l'autorità competente. > **Sono responsabile anche dei widget di terze parti?** > > Per l'utente sì: se il banner dei cookie, la chat o il pagamento non sono utilizzabili, il servizio > non è accessibile. Per questo conviene inserire la conformità a EN 301 549 nei contratti, chiedere > un ACR aggiornato e testare il componente prima di adottarlo. ### Conclusione Il GDPR ha funzionato quando le aziende hanno smesso di considerarlo un documento da firmare e hanno iniziato a trattarlo come un processo con ruoli, registri, controlli e fornitori. L'accessibilità sta facendo lo stesso percorso, con una differenza a favore: buona parte del lavoro si può automatizzare. Una baseline in CI, una scansione settimanale, un audit l'anno, una dichiarazione onesta e un design che pensa all'inclusione prima del codice bastano a trasformare la conformità da progetto che scade a proprietà del prodotto. **Riferimenti:** - [W3C WAI — WCAG-EM Overview](https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/) - [W3C WAI — Developing an Accessibility Statement](https://www.w3.org/WAI/planning/statements/) - [W3C WAI — Planning and Managing Web Accessibility](https://www.w3.org/WAI/planning/) - [ITI — VPAT e Accessibility Conformance Report](https://www.itic.org/policy/accessibility/vpat) - [Microsoft Inclusive Design](https://inclusive.microsoft.design/) - [AgID — Accessibilità](https://www.agid.gov.it/it/accessibilita)