Audit accessibilità WCAG 2.2 con agenti AI: servizio e onboarding

Se stai valutando se un agente AI può fare l’audit di accessibilità del tuo sito, la risposta onesta è: può fare la parte ripetitiva, e non è la parte che ti mette in regola. Un audit accessibilità WCAG con AI oggi automatizza scansione, classificazione e una quota consistente di remediation, ma si ferma davanti ai criteri che richiedono giudizio umano, l’ordine di focus, la sensatezza di un testo alternativo, la coerenza tra flusso visivo e flusso da tastiera. Questo articolo spiega dove passa esattamente quel confine, come si costruisce un processo che regge a un controllo, e perché la differenza tra chi si mette in regola e chi resta esposto non è il tool che compra, ma chi glielo configura e chi forma il team a usarlo.

In questo articolo scoprirai:

• Il 2026 non è l’anno dell’entrata in vigore: è l’anno dei controlli
• Come funziona un audit accessibilità WCAG con AI: scansione, classificazione, remediation
• Il soffitto dell’automazione: cosa un audit AI non può vedere
• Overlay di accessibilità: la scorciatoia che l’audit WCAG con AI non deve diventare
• Dal report alla remediation: il metodo WCAG-EM e il campione rappresentativo
• Perché un tool di audit non basta: regole aziendali e integrazione CMS
• Onboarding e formazione: rendere l’audit un processo continuo, non un PDF

Il 2026 non è l’anno dell’entrata in vigore: è l’anno dei controlli

Prima di tutto una correzione che circola male in rete: l’European Accessibility Act non entra in vigore nel 2026. La direttiva (UE) 2019/882, recepita in Italia con il D.Lgs. 82/2022, si applica dal 28 giugno 2025. Il 2026 è la fase diversa e più scomoda: quella della vigilanza. Chi ha aspettato non è in anticipo, è in ritardo.

Il segnale operativo italiano è arrivato con la Determinazione AgID n. 84/2026 del 15 maggio 2026, che disciplina come l’Agenzia istruisce e sanziona le violazioni di accessibilità digitale. Il meccanismo è a due fasi: una pre-istruttoria in cui l’organizzazione riceve un rilievo formale e propone tempi di rimedio, con possibilità di chiudere senza sanzione, e una fase sanzionatoria che si apre solo se le scadenze concordate saltano. Le violazioni del D.Lgs. 82/2022 valgono da 5.000 a 40.000 euro ciascuna, mentre i soggetti già coperti dalla Legge Stanca rischiano fino al 5% del fatturato annuo.

Un punto che conviene fissare subito, perché cambia l’oggetto dell’audit: lo standard tecnico di riferimento non è la sola WCAG. La norma armonizzata europea EN 301 549 incorpora i criteri WCAG di Livello AA e li estende a requisiti che riguardano anche hardware, software non web e documentazione di supporto. La sua storia di revisioni successive spiega perché “conformi alle WCAG” e “conformi alla normativa” non sono mai esattamente la stessa affermazione.

Chi apre il procedimento non è solo AgID

Il dettaglio che cambia il calcolo del rischio: il procedimento parte anche da segnalazioni degli utenti, inoltrate tramite il link alla dichiarazione di accessibilità e la piattaforma di segnalazione predisposta da AgID. Non serve un’ispezione: basta un utente che non riesce a completare un checkout. I settori nel mirino sono quelli elencati dalle linee guida, e-commerce, servizi bancari, trasporto passeggeri, comunicazioni elettroniche, e-book e media audiovisivi.

Qui non ripercorriamo né i criteri né l’impianto sanzionatorio: li abbiamo già trattati nella guida completa alle WCAG 2.2 e nell’analisi su cosa rischia davvero la tua azienda con l’European Accessibility Act. Da qui in avanti parliamo solo di metodo.

Come funziona un audit accessibilità WCAG con AI: scansione, classificazione, remediation

Un audit assistito da agenti AI si articola in tre momenti distinti, e confonderli è il primo errore. La scansione non è l’audit: è solo il primo dei tre.

Fase 1: scansione e inventario delle viste

Un motore deterministico come axe-core attraversa il DOM e verifica regole meccaniche: presenza dell’attributo alt, rapporto di contrasto sopra soglia, label associata agli input, lingua del documento dichiarata. Su un sito reale questo produce migliaia di righe. Il dato di scala che spiega perché serve automazione: secondo l’analisi WebAIM Million di febbraio 2026, il 95,9% delle home page presenta errori WCAG rilevabili automaticamente, con una media di 56,1 errori per pagina, in peggioramento del 10% rispetto all’anno precedente, perché le pagine sono diventate più complesse (1.437 elementi in media, +22,5%).

Fase 2: classificazione e priorità, dove l’AI aggiunge valore

È qui che un agente AI fa qualcosa che un linter non fa. Sei famiglie di errori, contrasto basso, alt mancanti, label assenti, link vuoti, bottoni vuoti, lingua non dichiarata, coprono il 96% dei problemi rilevati automaticamente. Un modello linguistico può leggere il contesto della pagina e passare dal binario “l’alt esiste” al giudizio “l’alt descrive il prodotto giusto”, raggruppare 400 occorrenze in un unico difetto di componente, e ordinare per impatto reale sull’utente invece che per numero di violazioni.

Fase 3: remediation assistita, non automatica

L’agente propone la patch e la apre come pull request, dove un umano la approva o la rifiuta. Il caso più documentato è quello di GitHub: il loro agente di accessibilità ha revisionato 3.535 pull request con un tasso di risoluzione del 68%, concentrandosi su relazioni strutturali, denominazione dei controlli, annunci di stato, testi alternativi e ordine di focus. Il loro stesso team scrive che l’agente aumenta l’expertise umana e non la sostituisce, con checkpoint di escalation che instradano i casi complessi verso gli specialisti. Questo è il modello agentico applicato a un dominio verificabile, lo stesso principio che descriviamo negli agenti AI per il back-office.

Il soffitto dell’automazione: cosa un audit AI non può vedere

Nessun fornitore serio promette conformità automatica, e c’è un motivo numerico. L’automazione copre circa il 57% dei problemi di accessibilità: è il risultato del rapporto Deque sulla copertura dei test automatici, costruito su oltre 2.000 audit, più di 13.000 pagine e quasi 300.000 issue, considerando solo i primi audit per evitare distorsioni da remediation già avvenuta.

Attenzione a come si legge quel numero. Il 57% è il volume di problemi intercettati, non la percentuale di criteri WCAG verificabili: quella è molto più bassa, tra il 30% e il 40%. La divergenza esiste perché pochi tipi di errore molto frequenti (contrasto, alt) gonfiano il conteggio. Chi misura per volume ha numeri lusinghieri; chi misura per criteri scopre i buchi.

I criteri WCAG 2.2 che nessun agente può giudicare al posto tuo

Il rapporto Deque quantifica il fallimento per singolo criterio, ed è impietoso: Ordine di focus (2.4.3) è rilevabile automaticamente allo 0%, Navigazione da tastiera (2.1.1) al 2,49%, Sequenza significativa (1.3.2) a zero, Visibilità del focus (2.4.7) e Contrasto degli elementi non testuali (1.4.11) integralmente manuali. GitHub arriva alla stessa conclusione da un’altra strada: circa il 36% dei criteri di Livello A/AA non è rilevabile in automatico, e i pattern ad alto rischio, drag-and-drop, data grid, tree view, editor rich text, restano terreno umano.

Sono esattamente i criteri che decidono se una persona che naviga con screen reader può completare un acquisto. Un sito può passare la scansione con zero errori e restare inutilizzabile.

Il punteggio di accessibilità non è la conformità

Da qui la regola pratica: un punteggio non è una dichiarazione di conformità. L’automazione produce falsi negativi per costruzione (non vede ciò che non sa testare) e falsi positivi per prudenza (segnala pattern legittimi come sospetti). Un agente AI riduce i secondi, perché sa leggere il contesto, ma non tocca i primi. Il rischio vero è psicologico: il cruscotto verde spegne la ricerca. È lo stesso schema che si vede quando si adotta AI senza criteri di verifica, come discutiamo nell’analisi sulla AI agent readiness.

Overlay di accessibilità: la scorciatoia che l’audit WCAG con AI non deve diventare

Va detto senza giri di parole perché è la prima cosa che viene proposta a chi ha fretta: un overlay non è un audit e non produce conformità. È uno script JavaScript di terze parti che tenta di riparare il sito a runtime, e la comunità professionale dell’accessibilità lo ha respinto in modo compatto.

Cosa dice l’Overlay Fact Sheet

L’Overlay Fact Sheet, firmato da centinaia di professionisti e organizzazioni, elenca i limiti in modo tecnico: l’applicazione automatica di testi alternativi non è affidabile; la riparazione automatica di label, gestione degli errori e controllo del focus nei form non è affidabile; la riparazione automatica dell’accesso da tastiera non è affidabile. Gli overlay non intervengono su PDF, HTML5 Canvas, SVG e file multimediali, e nei framework a componenti (React, Angular, Vue) il contenuto cambia sotto di loro. La conclusione dei firmatari è testuale: la piena conformità non si ottiene con un overlay. Nel sondaggio WebAIM, il 67% dei professionisti li giudica inefficaci, quota che sale al 72% tra i rispondenti con disabilità.

Il dato legale: l’overlay non è una difesa

Il mercato statunitense, più avanti sul contenzioso, offre il controllo empirico. Secondo l’analisi di Usablenet sulle cause per accessibilità del 2026, sono attese circa 6.000 cause tra corti federali e statali (+20-25% sul 2025), l’80% contro aziende e-commerce, e circa il 20% dei convenuti aveva un widget di accessibilità installato. Un quarto dei casi riguarda aziende già citate in precedenza. Tradotto per il contesto italiano: davanti a una segnalazione AgID, la presenza di un overlay non è una circostanza attenuante, semmai documenta che il problema era noto e non è stato risolto nel codice.

Dal report alla remediation: il metodo WCAG-EM e il campione rappresentativo

Un audit che regge a un controllo non è un file esportato dallo scanner: è una procedura tracciabile. Lo standard di riferimento è WCAG-EM del W3C, cinque passi in sequenza: definire l’ambito e il livello di conformità (A, AA, AAA), esplorare il prodotto identificando viste chiave, funzionalità e tecnologie richieste, selezionare un campione rappresentativo combinando viste strutturate e viste scelte casualmente, valutare il campione registrando successi, fallimenti e passaggi eseguiti, e infine aggregare i risultati in un report con dichiarazioni di valutazione.

Perché il campione casuale è la parte che l’AI non decide

La componente casuale non è un vezzo metodologico: serve a impedire che si testino solo le pagine che si sa essere a posto. Un agente AI può scansionare tutto, e su siti grandi conviene, ma la scelta di cosa dichiarare come rappresentativo è una decisione di responsabilità, perché finisce nella dichiarazione di accessibilità che qualcuno firma.

Il dopo-report: dove si perdono i progetti

La distanza tra scansione e audit è quantificata bene da accessible.org: le scansioni coprono circa il 25% dei problemi, il restante 75% emerge solo valutando manualmente comportamenti interattivi, navigazione da tastiera, gestione del focus, annunci dello screen reader. Il flusso che funziona dopo il report è sempre lo stesso: priorità per gravità e impatto sull’utente, issue caricate nel tracker di progetto, fix implementati, e una valutazione di follow-up che verifica che le correzioni siano corrette. Senza quel giro di ritorno il report resta un PDF, e il PDF non chiude un procedimento.

Perché un tool di audit accessibilità con AI non basta: regole aziendali e integrazione CMS

Arriviamo al punto che nella SERP italiana nessuno copre. Il tool è la parte facile: si compra, si installa, produce numeri il primo giorno. La parte che decide l’esito è la configurazione, e la configurazione è un lavoro di contesto, non di prodotto.

Le regole non sono universali: sono le tue

Un agente che apre pull request su un design system deve sapere quali componenti sono proprietari e quali di libreria, quali pattern sono già stati validati da un audit manuale (e vanno lasciati stare), quale livello di conformità è l’obiettivo, e cosa fare quando la correzione tecnicamente giusta rompe un vincolo di brand. GitHub ha risolto questo problema usando come materiale di riferimento lo storico delle proprie issue documentate: l’agente funzionava perché esisteva già un corpus aziendale a cui ancorarsi. Chi parte da zero deve costruirlo, e quel corpus è dati aziendali, lo stesso lavoro preliminare descritto nella guida alla data readiness per agenti AI.

L’integrazione con il CMS è dove l’audit smette di essere un evento

Il secondo pezzo è tecnico. Se il controllo vive solo in un cruscotto esterno, il sito torna fuori conformità alla prima pubblicazione di un redattore che carica un’immagine senza alt. L’integrazione utile è nel punto in cui il contenuto nasce: validazione in fase di editing sul CMS, controllo bloccante in pipeline sulle pull request front-end, verifica post-deploy. È qui che entra Mimír come sistema AI per le aziende: non un widget da incollare nel footer, ma agenti collegati ai vostri sistemi con regole scritte insieme a voi. È anche il motivo per cui l’accessibilità tecnica e la visibilità del sito sui motori e sulle AI si muovono insieme: markup semantico corretto, struttura dei titoli coerente e testi alternativi sensati sono esattamente ciò che serve a entrambe.

Onboarding e formazione: rendere l’audit un processo continuo, non un PDF

L’ultimo miglio è organizzativo, ed è quello dove i progetti di accessibilità muoiono più spesso. Un audit vale finché il team continua a produrre codice e contenuti conformi dopo che il consulente è uscito dalla stanza. La lezione più netta del caso GitHub è proprio questa: l’investimento manuale nelle fasi iniziali di design previene ridisegni costosi a valle. Nessun agente recupera a posteriori una scelta di interazione sbagliata a monte.

Cosa deve contenere l’onboarding di un agente di audit

Tre cose, in ordine. Primo, definire chi legge l’output dell’agente e con quale autorità: chi approva una pull request di accessibilità, chi decide un’eccezione, chi firma la dichiarazione. Sono ruoli, e vanno scritti, la logica è la stessa della governance degli agenti AI tra policy, ruoli e AI Act. Secondo, addestrare le persone a riconoscere ciò che l’agente non vede: se il team crede al 57%, il restante 43% non verrà mai cercato. Terzo, fissare la cadenza: un audit completo va rifatto a ogni rilascio maggiore o restyling, con controlli continui in pipeline nel mezzo.

Il servizio, non solo il prodotto

Questo è il motivo per cui in Mimír trattiamo l’attivazione come un percorso e non come una consegna: l’affiancamento descritto nella guida pratica all’onboarding di agenti AI in azienda e il lavoro di formazione del team sono ciò che trasforma uno strumento in una capacità interna.

Se hai un sito che ricade nell’ambito dell’European Accessibility Act e non sai da dove iniziare, il primo passo non è comprare uno scanner: è capire quale parte del problema puoi automatizzare e quale no. Su questo puoi parlare con noi di Mimír e valutare insieme un percorso di audit e adozione tarato sul tuo stack e sul tuo team.

Fonti:

• Determinazione AgID n. 84/2026 del 15 maggio 2026
• ETSI EN 301 549 — Requisiti di accessibilità per prodotti e servizi ICT
• WebAIM Million — analisi di febbraio 2026
• GitHub — Building a general purpose accessibility agent
• Deque — Automated Accessibility Coverage Report
• Overlay Fact Sheet
• Usablenet — Digital accessibility lawsuits in 2026
• W3C WAI — Website Accessibility Conformance Evaluation Methodology (WCAG-EM)
• accessible.org — Cosa comprende un audit di accessibilità