WCAG 2.2: Guida Completa all’Accessibilità Web Obbligatoria nel 2026

Le WCAG 2.2 sono lo standard internazionale che definisce come rendere siti web, app e servizi digitali accessibili a persone con disabilità e dal 28 giugno 2025, rispettarle non è più una scelta ma un obbligo di legge nell’Unione Europea. L’European Accessibility Act impone sanzioni fino a 40.000 euro per le aziende non conformi e in Italia la normativa si estende a tutte le imprese con fatturato superiore a 2 milioni di euro. Per chi sviluppa, progetta o gestisce prodotti digitali, comprendere le WCAG 2.2 e lo standard EN 301 549 è oggi una necessità operativa e legale.

In questo articolo scoprirai:

• Perché l’accessibilità è diventata obbligatoria nel 2026 e quali sanzioni rischi
• Come funzionano le WCAG 2.2, l’EN 301 549 e i loro requisiti tecnici chiave
• Le regole pratiche su contrasto colori, HTML semantico, ARIA e accessibilità cognitiva
• Quali tool gratuiti usare per testare la conformità del tuo sito
• Il ruolo dell’AI nell’accessibilità e come rendere accessibili chatbot e agenti AI

Accessibilità web obbligatoria nel 2026

L’accessibilità web è obbligatoria perché l’European Accessibility Act (Direttiva UE 2019/882) è entrato in vigore il 28 giugno 2025, imponendo a tutti gli Stati membri dell’Unione Europea di garantire che prodotti e servizi digitali siano utilizzabili da persone con disabilità. In Italia, il recepimento tramite il D.Lgs. 82/2022 ha esteso l’obbligo anche al settore privato, andando oltre la storica Legge Stanca che riguardava solo la Pubblica Amministrazione.

Il contesto normativo attuale rappresenta un cambio di paradigma. Per oltre un decennio, l’accessibilità digitale in Europa è stata regolata in modo frammentato: la Direttiva Web Accessibility (UE 2016/2102) riguardava solo i siti della Pubblica Amministrazione, lasciando il settore privato sostanzialmente libero di autoregolarsi. L’EAA ha colmato questa lacuna con un approccio armonizzato che copre e-commerce, servizi bancari, trasporti, telecomunicazioni e qualsiasi servizio digitale rivolto ai consumatori.

Le sanzioni previste dalla normativa italiana sono significative. Secondo quanto stabilito dal D.Lgs. 82/2022, le multe vanno da 2.500 a 40.000 euro a seconda della gravità della violazione, del numero di prodotti o servizi non conformi e del numero di utenti coinvolti. Per i soggetti già vincolati dalla Legge Stanca (PA e grandi aziende), le sanzioni possono arrivare fino al 5% del fatturato annuo. Nei casi più gravi, le autorità possono disporre l’oscuramento del sito web o la rimozione dell’app dagli store.

Ma l’obbligo normativo è solo una parte della motivazione. Oltre un miliardo di persone nel mondo, circa il 16% della popolazione globale secondo l’OMS, convive con qualche forma di disabilità. Progettare in modo accessibile significa raggiungere un pubblico più ampio, migliorare la SEO (i motori di ricerca premiano i siti strutturati secondo principi di accessibilità) e ridurre il rischio legale. L’accessibilità non è un costo: è un investimento nel design inclusivo che produce benefici per tutti gli utenti.

Soggetti obbligati all’accessibilità digitale

L’obbligo di accessibilità app 2026 e siti web riguarda tutte le imprese dell’Unione Europea con più di 10 dipendenti o un fatturato annuo superiore a 2 milioni di euro, oltre a tutta la Pubblica Amministrazione.

Le microimprese, definite come aziende con meno di 10 dipendenti e fatturato o bilancio totale non superiore a 2 milioni di euro, sono le uniche esentate dagli obblighi dell’EAA.

Il perimetro dei soggetti obbligati si è ampliato progressivamente. In Italia, la normativa nazionale di recepimento ha incluso esplicitamente i seguenti settori e servizi:

• E-commerce: qualsiasi sito o app che vende prodotti o servizi online
• Servizi bancari e finanziari: home banking, app di pagamento, piattaforme di investimento
• Telecomunicazioni: siti e app di operatori telefonici e provider di servizi digitali
• Trasporti: piattaforme di prenotazione, biglietterie online, app di mobilità
• Media e editoria digitale: siti di informazione, piattaforme streaming, e-book reader
• Pubblica Amministrazione: tutti i siti e servizi digitali, senza eccezioni di dimensione

L’11 marzo 2026, l’AgID ha pubblicato le nuove Linee Guida che implementano i requisiti di accessibilità per i servizi, stabilendo un nuovo quadro regolatorio che estende la copertura oltre la PA al settore privato. Le aziende devono pubblicare una dichiarazione di accessibilità sul proprio sito, aggiornata annualmente, che documenta il livello di conformità raggiunto e le eventuali misure correttive pianificate.

Un aspetto spesso trascurato riguarda la catena di fornitura: anche le aziende che sviluppano software, CMS o componenti UI per conto terzi sono indirettamente coinvolte. Se il prodotto finale non rispetta gli standard di accessibilità, la responsabilità ricade sull’azienda che eroga il servizio al pubblico, ma i contratti di fornitura includono sempre più frequentemente clausole di conformità WCAG.

WCAG 2.2: novità e criteri introdotti

Le WCAG 2.2 (Web Content Accessibility Guidelines 2.2) sono le linee guida internazionali pubblicate dal W3C nell’ottobre 2023 che definiscono i criteri tecnici per rendere i contenuti web accessibili a persone con disabilità visive, uditive, motorie e cognitive. Questa versione introduce 9 nuovi criteri di successo rispetto alle WCAG 2.1, con un focus particolare sulla navigazione da dispositivi mobili, l’autenticazione semplificata e la coerenza dell’aiuto agli utenti.

Le WCAG si fondano su quattro principi fondamentali, sintetizzati nell’acronimo POUR:

• Percepibile: le informazioni e i componenti dell’interfaccia devono essere presentati in modi che tutti gli utenti possano percepire (testo alternativo per immagini, sottotitoli per video, contrasto sufficiente)
• Operabile: i componenti dell’interfaccia e la navigazione devono essere utilizzabili da tutti (navigazione da tastiera, tempi sufficienti, assenza di contenuti che causano convulsioni)
• Comprensibile: le informazioni e il funzionamento dell’interfaccia devono essere comprensibili (testo leggibile, comportamento prevedibile, aiuto nella prevenzione degli errori)
• Robusto: i contenuti devono essere interpretabili in modo affidabile da un’ampia varietà di tecnologie assistive, inclusi screen reader e display braille

Ogni principio contiene linee guida con criteri di successo classificati su tre livelli: A (requisiti minimi), AA (standard raccomandato e richiesto dalla normativa europea) e AAA (massima accessibilità). L’European Accessibility Act richiede la conformità al livello AA, che rappresenta l’equilibrio tra impatto per l’utente e fattibilità tecnica.

Tra i 9 nuovi criteri introdotti dalle WCAG 2.2, i più rilevanti per sviluppatori e designer sono:

• Focus Not Obscured (2.4.11 – AA): quando un elemento riceve il focus da tastiera, non deve essere completamente nascosto da altri contenuti come header fissi, banner o modali
• Dragging Movements (2.5.7 – AA): ogni funzionalità che richiede un movimento di trascinamento deve offrire un’alternativa con singolo click o tap
• Target Size Minimum (2.5.8 – AA): gli elementi interattivi devono avere una dimensione minima di 24×24 pixel CSS o spaziatura sufficiente
• Accessible Authentication (3.3.8 – AA): i processi di autenticazione non devono richiedere test cognitivi come CAPTCHA, memorizzazione di password o risoluzione di puzzle, a meno che non sia disponibile un’alternativa
• Consistent Help (3.2.6 – A): i meccanismi di assistenza (chat, telefono, FAQ) devono trovarsi nella stessa posizione relativa su tutte le pagine
• Redundant Entry (3.3.7 – A): le informazioni già inserite dall’utente in un processo a più step non devono essere richieste di nuovo, a meno che non sia essenziale per la sicurezza

Un cambiamento significativo nelle WCAG 2.2 è la rimozione del criterio 4.1.1 (Parsing), precedentemente presente nelle WCAG 2.1. Il W3C ha riconosciuto che i browser moderni gestiscono autonomamente gli errori di markup HTML, rendendo questo criterio obsoleto. Questo semplifica la conformità per gli sviluppatori senza ridurre l’accessibilità effettiva.

EN 301 549: standard europeo di conformità

Lo standard EN 301 549 è la norma tecnica europea che traduce i principi delle WCAG in requisiti operativi applicabili a tutti i prodotti e servizi ICT — non solo ai siti web, ma anche ad app mobili, software desktop, hardware, documenti digitali e servizi di telecomunicazione. La conformità allo standard EN 301 549 garantisce la presunzione di conformità all’European Accessibility Act: chi lo rispetta è considerato in regola con la legge.

La relazione tra WCAG e EN 301 549 è di tipo gerarchico. Le WCAG definiscono i criteri per i contenuti web; lo standard EN 301 549 li incorpora integralmente (Capitolo 9 per il web, Capitolo 11 per il software) e aggiunge requisiti specifici per le tecnologie non web. Ad esempio, il Capitolo 5 copre i requisiti generici (chiusura, privacy con tecnologie assistive), il Capitolo 6 riguarda le comunicazioni bidirezionali (inclusa la “Total Conversation”), il Capitolo 7 copre i video con sottotitoli e audiodescrizione, e il Capitolo 8 riguarda l’hardware.

Il Draft EN 301 549 V4.1.0 (2025-11) è l’aggiornamento più recente dello standard, che integra il riferimento alle WCAG 2.2 e riorganizza i requisiti di conformità in cinque tabelle nell’Annex ZB: una per tutti i prodotti, una per le interfacce e funzionalità, e tabelle specifiche per categorie di servizi come e-commerce e servizi bancari. Questa struttura funziona come una mappa che guida le aziende nella valutazione di conformità.

Per le aziende italiane, il percorso di EN 301 549 compliance passa attraverso tre fasi concrete. La prima è l’audit iniziale: verificare quali requisiti dello standard si applicano ai propri prodotti e servizi digitali. La seconda è la remediation: correggere le non conformità identificate, dando priorità ai criteri di livello AA. La terza è il monitoraggio continuo: l’accessibilità non è un progetto con una data di fine, ma un processo che richiede verifiche periodiche, soprattutto dopo ogni aggiornamento del sito o dell’app.

Accessibilità visiva e contrasto colori

Il requisito principale di accessibilità visiva è il rapporto di contrasto minimo di 4.5:1 tra il testo in primo piano e lo sfondo (criterio WCAG 1.4.3, livello AA). Per il testo grande (almeno 18pt o 14pt in grassetto), il rapporto minimo scende a 3:1. Questi valori garantiscono la leggibilità per persone con ipovisione, daltonismo o che utilizzano schermi in condizioni di forte luminosità ambientale.

Il problema del contrasto insufficiente è più diffuso di quanto si pensi. Uno studio su larga scala condotto da Vaughan e Ortiz Suarez (2026) ha analizzato i 500 domini più frequentemente indicizzati da Common Crawl, identificando 4.327 combinazioni colore uniche. Il risultato è allarmante: il 40,9% delle combinazioni non rispetta la soglia 4.5:1 per il testo normale. Solo il 20,4% dei siti analizzati ha raggiunto la piena conformità su tutte le combinazioni di colore rilevate, con un tasso mediano di conformità per sito del 62,7%.

Oltre al contrasto del testo, le WCAG 2.2 (criterio 1.4.11, livello AA) richiedono un rapporto di contrasto di almeno 3:1 per i componenti dell’interfaccia utente (bordi dei campi input, icone funzionali, indicatori di focus, bordi dei pulsanti) e per gli elementi grafici necessari alla comprensione del contenuto, come grafici e diagrammi. Un pulsante grigio chiaro su sfondo bianco, un campo di testo senza bordo visibile o un’icona a basso contrasto viola problemi concreti di usabilità.

Le regole pratiche per il design inclusivo nell’ambito visivo includono:

• Non usare il colore come unico mezzo informativo: un messaggio di errore non deve essere segnalato solo dal colore rosso, aggiungere un’icona, un testo esplicativo o un bordo aggiuntivo (criterio 1.4.1)
• Spaziatura del testo personalizzabile: il contenuto deve rimanere leggibile e funzionale quando l’utente modifica l’interlinea a 1.5 volte la dimensione del font, la spaziatura tra paragrafi a 2 volte, la spaziatura tra lettere a 0.12 volte e tra parole a 0.16 volte (criterio 1.4.12)
• Ridimensionamento del testo fino al 200%: lo zoom al 200% non deve causare perdita di contenuto o funzionalità (criterio 1.4.4)
• Reflow: a 320px CSS di larghezza (equivalente a uno zoom del 400% su desktop a 1280px), il contenuto deve essere presentato senza scrolling orizzontale (criterio 1.4.10)

Per verificare il contrasto, strumenti come il Colour Contrast Analyser (gratuito, disponibile per Windows e Mac) permettono di misurare il rapporto esatto tra due colori. Il tool WebAIM Contrast Checker è utilizzabile direttamente nel browser e indica immediatamente se una combinazione di colori supera le soglie AA e AAA.

HTML semantico e ARIA per l’accessibilità

L’HTML semantico è il fondamento dell’accessibilità strutturale: usare i tag HTML corretti — <nav>, <main>, <header>, <footer>, <article>, <aside> — consente agli screen reader di costruire una mappa navigabile della pagina, permettendo agli utenti di saltare direttamente alla sezione desiderata.

ARIA (Accessible Rich Internet Applications) è un set di attributi HTML che integra la semantica nativa quando questa non è sufficiente, ad esempio per componenti interattivi personalizzati come tab, accordion, dialog e menu dinamici.

La regola d’oro dello sviluppo accessibile è: usare HTML nativo prima di ARIA. Un <button> è automaticamente focusabile, attivabile con tastiera e annunciato come pulsante dagli screen reader. Un <div onclick="..."> non lo è, e richiede role="button", tabindex="0" e gestione dei tasti Enter e Spazio — più codice, più possibilità di errore, meno robustezza.

La struttura degli heading (<h1>–<h6>) è critica per la navigazione assistiva. Le best practice prevedono:

• Un solo <h1> per pagina, corrispondente al titolo principale
• Gerarchia senza salti: non passare da <h2> a <h4> senza un <h3> intermedio
• Heading descrittivi, non generici: “Prodotti in offerta” è meglio di “Sezione 3”

Per i componenti interattivi complessi, ARIA fornisce tre categorie di attributi essenziali:

• Ruoli (roles): definiscono cosa è un elemento — role="dialog", role="tablist", role="alert", role="navigation"
• Proprietà: descrivono le caratteristiche — aria-label per etichette invisibili, aria-describedby per descrizioni aggiuntive, aria-required="true" per campi obbligatori
• Stati: comunicano cambiamenti dinamici — aria-expanded="true/false" per accordion, aria-selected per tab attivi, aria-hidden="true" per contenuto nascosto agli screen reader

Le live regions sono un meccanismo ARIA fondamentale per le Single Page Application e le interfacce dinamiche. L’attributo aria-live="polite" fa sì che gli screen reader annuncino i cambiamenti di contenuto senza interrompere l’utente, mentre aria-live="assertive" interrompe immediatamente per comunicare informazioni urgenti (come messaggi di errore). Senza live regions, un utente di screen reader non saprebbe che un carrello è stato aggiornato, che un messaggio di chat è arrivato o che una validazione è fallita.

La navigazione da tastiera è un requisito trasversale (criterio WCAG 2.1.1, livello A). Ogni elemento interattivo deve essere raggiungibile con il tasto Tab, attivabile con Enter o Spazio, e l’ordine di tabulazione deve seguire la sequenza logica del contenuto. Il focus visibile (criterio 2.4.7, livello AA) deve essere sempre chiaramente distinguibile — le WCAG 2.2 rafforzano questo aspetto con il nuovo criterio Focus Not Obscured (2.4.11), che vieta che il focus venga nascosto da elementi sovrapposti come sticky header o cookie banner.

Accessibilità cognitiva: contenuti e navigazione

L’accessibilità cognitiva consiste nel progettare contenuti e interfacce comprensibili anche da persone con disabilità cognitive, disturbi dell’apprendimento (dislessia, ADHD), deficit di memoria o semplicemente da utenti in condizioni di stress, stanchezza o distrazione. Le WCAG 2.2 rafforzano questo aspetto con criteri dedicati come Consistent Help (3.2.6), Redundant Entry (3.3.7) e Accessible Authentication (3.3.8).

Il principio chiave è la prevedibilità. Un’interfaccia accessibile dal punto di vista cognitivo si comporta in modo coerente: la navigazione è nella stessa posizione su ogni pagina, le azioni simili producono risultati simili, e non si verificano cambiamenti di contesto inattesi (come l’apertura automatica di una nuova finestra o il submit di un form al cambio di selezione in un dropdown).

Le linee guida operative per la semplificazione dei contenuti includono:

• Linguaggio chiaro: frasi brevi (massimo 20-25 parole), vocabolario comune, paragrafi focalizzati su un singolo concetto. Quando un termine tecnico è necessario, fornire una definizione immediata
• Struttura visiva: uso di heading, liste, tabelle e spazi bianchi per organizzare l’informazione. Il muro di testo è il nemico dell’accessibilità cognitiva
• Istruzioni esplicite: non dare per scontato che l’utente sappia cosa fare. “Compila tutti i campi contrassegnati con asterisco (*) e premi Invia” è meglio di un form senza istruzioni
• Prevenzione e recupero degli errori: validazione in tempo reale con messaggi chiari (“La password deve contenere almeno 8 caratteri” invece di “Errore nel campo password”), possibilità di annullare azioni e conferma prima di operazioni irreversibili

Il criterio Accessible Authentication (3.3.8) merita un’attenzione specifica perché impatta direttamente l’esperienza di login. I CAPTCHA tradizionali, puzzle visivi, distorsioni di testo, quiz logici, rappresentano barriere significative per utenti con disabilità cognitive. Le WCAG 2.2 richiedono che l’autenticazione non dipenda da test di funzione cognitiva a meno che non sia disponibile almeno un metodo alternativo: login con passkey, autenticazione biometrica, link via email o password manager. L’obiettivo è eliminare la memorizzazione forzata come prerequisito per accedere a un servizio.

Le animazioni e i movimenti automatici richiedono controllo da parte dell’utente (criterio 2.3.3). Slider, caroselli e video in autoplay devono offrire la possibilità di pausa, stop o nascondimento. La direttiva prefers-reduced-motion nei CSS permette di rispettare le preferenze di sistema dell’utente, disabilitando o riducendo le animazioni per chi ne ha fatto richiesta a livello di sistema operativo.

Test di accessibilità con tool gratuiti

Il modo più efficace per testare l’accessibilità è combinare tool automatizzati gratuiti con verifiche manuali mirate: gli strumenti automatici rilevano circa il 30-40% dei problemi di accessibilità (quelli verificabili a livello di codice), mentre il restante 60-70% richiede valutazione umana, ad esempio la qualità del testo alternativo, la logica dell’ordine di lettura o la comprensibilità del linguaggio.

Lo studio di Boyalakuntla, Venigalla e Chimalakonda ha analizzato la copertura degli strumenti WCAG automatizzati, sviluppando WAccess, un tool open source capace di verificare 13 linee guida WCAG 2.0, 9 di WCAG 2.1 e 7 di WCAG 2.2. Applicato a 2.227 siti governativi indiani, ha rilevato circa 6,1 milioni di violazioni, confermando quanto il problema sia sistemico anche nei siti istituzionali.

Ecco i migliori tool gratuiti disponibili nel 2026, organizzati per tipologia d’uso:

Analisi rapide nel browser:

• WAVE (WebAIM): estensione per Chrome e Firefox che evidenzia errori, avvisi e feature di accessibilità direttamente sulla pagina. Visualizza la struttura degli heading, le etichette dei form, il testo alternativo e gli errori di contrasto con un’interfaccia visuale intuitiva
• Lighthouse (Google): integrato nei DevTools di Chrome (tab “Accessibility”), esegue un audit automatico e restituisce un punteggio 0-100 con elenco dettagliato delle violazioni, link alla documentazione e suggerimenti di fix. Disponibile anche da linea di comando e CI/CD
• axe DevTools (Deque): estensione browser con versione gratuita che identifica violazioni WCAG con zero falsi positivi. La versione gratuita copre un sottoinsieme di regole; la versione pro aggiunge remediation assistita dall’AI

Testing sistematico e CI/CD:

• Pa11y: tool open source da linea di comando che esegue test di accessibilità automatizzati su URL o liste di pagine. Integrabile in pipeline CI/CD per bloccare i deploy che introducono regressioni di accessibilità
• axe-core: il motore open source dietro axe DevTools, integrabile come libreria JavaScript in test automatizzati (Jest, Cypress, Playwright). Permette di scrivere test di accessibilità come parte della suite di test esistente
• Accessibility Insights (Microsoft): disponibile per Windows e come estensione browser, offre sia FastPass (scansione rapida) sia Assessment (valutazione guidata di tutti i criteri WCAG 2.2 AA)

Documenti PDF:

• PAC (PDF Accessibility Checker): tool gratuito e consolidato dal 2010 che verifica la conformità dei PDF agli standard PDF/UA e WCAG. Essenziale per aziende che pubblicano report, contratti o modulistica in formato PDF

Il flusso di lavoro raccomandato per un audit completo prevede tre fasi: scansione automatica con WAVE o axe per identificare i problemi evidenti, test manuale di navigazione da tastiera e con screen reader (NVDA su Windows o VoiceOver su Mac, entrambi gratuiti), e infine test con utenti reali con disabilità per validare l’usabilità effettiva.

AI e accessibilità: agenti AI accessibili

L’AI sta trasformando l’accessibilità in due direzioni: come strumento per migliorare l’accessibilità (generazione automatica di alt text, sottotitoli in tempo reale, navigazione vocale) e come nuova superficie che deve essere essa stessa accessibile (chatbot, assistenti vocali, agenti AI autonomi). Entrambe le direzioni presentano opportunità significative e rischi concreti.

Sul fronte dell’AI come strumento di accessibilità, i progressi più rilevanti riguardano:

• Generazione automatica di testo alternativo: modelli di computer vision generano descrizioni per immagini prive di alt text, riducendo una delle violazioni WCAG più comuni. La qualità è migliorata significativamente, ma richiede ancora revisione umana per contesti specifici
• Sottotitoli e trascrizioni in tempo reale: servizi come quelli integrati in Google Meet, Zoom e Teams offrono sottotitoli automatici con accuratezza crescente, rendendo i contenuti audio accessibili a persone sorde o ipoudenti
• Remediation assistita: tool come axe DevTools con AI auto-remediation suggeriscono e applicano fix direttamente nel codice, usando NLP per migliorare nomi di pulsanti e ruoli ARIA e prioritizzando le issue in base all’impatto sull’utente
• Navigazione assistita: agenti AI che interpretano le intenzioni dell’utente e navigano interfacce complesse per conto di persone con disabilità motorie o cognitive

L’altra faccia della medaglia è la necessità di rendere accessibili gli agenti AI stessi. I chatbot e gli assistenti virtuali integrati nei siti web devono rispettare le stesse WCAG di qualsiasi altro componente dell’interfaccia. I problemi più comuni includono:

• Widget chat non navigabili da tastiera: molti widget di chat si aprono con un click ma non gestiscono il focus, l’utente da tastiera non può raggiungere il campo di input o chiudere la finestra
• Contenuto dinamico non annunciato: le risposte del chatbot appaiono nel DOM ma senza live region ARIA, gli screen reader non le comunicano all’utente
• Limiti temporali: se il chatbot impone un timeout alla sessione, l’utente deve essere avvisato e avere la possibilità di estendere il tempo (criterio WCAG 2.2.1)
• Output solo visuale: grafici, card prodotto e elementi rich media mostrati dal chatbot senza equivalente testuale
• Widget con contrasti insufficienti: spesso i pulsanti vengono creati senza che la combinazione di colori superi le soglie AA

Un punto di attenzione emergente riguarda gli agenti AI autonomi che interagiscono con il web per conto dell’utente. Quando un agente media l’esperienza di un prodotto, l’accessibilità del comportamento dell’agente diventa importante quanto l’accessibilità dell’interfaccia sottostante.

Checklist WCAG 2.2: i passi essenziali per la conformità nel 2026

La conformità WCAG 2.2 livello AA si raggiunge attraverso un processo strutturato che combina interventi tecnici, organizzativi e culturali. Questa checklist riassume le azioni prioritarie per le aziende che devono adeguarsi all’European Accessibility Act nel 2026.

Fase 1 — Audit e gap analysis:

1. Esegui una scansione automatica: usa WAVE, Lighthouse o axe DevTools sulle pagine principali del sito (home, pagine prodotto, checkout, login, contatti). Documenta ogni violazione con il criterio WCAG corrispondente
2. Testa la navigazione da tastiera: naviga l’intero flusso utente principale usando solo Tab, Shift+Tab, Enter e Spazio. Verifica che il focus sia sempre visibile e che nessun elemento sia irraggiungibile
3. Verifica con screen reader: testa con NVDA (Windows, gratuito) o VoiceOver (Mac, integrato). Controlla che heading, link, pulsanti e form siano annunciati correttamente

Fase 2 — Remediation prioritizzata:

1. Correggi il contrasto: porta tutte le combinazioni testo/sfondo al rapporto 4.5:1 (3:1 per testo grande). Verifica anche il contrasto dei componenti UI (bordi, icone, indicatori di focus)
2. Aggiungi HTML semantico: sostituisci i <div> generici con tag semantici (<nav>, <main>, <article>). Correggi la gerarchia degli heading. Aggiungi lang al tag <html>
3. Completa le alternative testuali: ogni immagine informativa deve avere alt descrittivo. Le immagini decorative devono avere alt="". I video devono avere sottotitoli e, dove necessario, audiodescrizione
4. Rendi accessibili i form: ogni campo deve avere un <label> associato. I messaggi di errore devono essere specifici, collegati al campo via aria-describedby e annunciati tramite live region

Fase 3 — Conformità e monitoraggio:

1. Implementa i nuovi criteri WCAG 2.2: verifica Focus Not Obscured (gli sticky header non coprono il focus), Target Size (24px minimo o spaziatura adeguata), Accessible Authentication (alternativa ai CAPTCHA cognitivi)
2. Pubblica la dichiarazione di accessibilità: documento obbligatorio che dichiara il livello di conformità, elenca le eventuali non conformità note e indica le misure correttive pianificate con tempistiche
3. Integra i test nel workflow: aggiungi axe-core o Pa11y nella pipeline CI/CD per bloccare automaticamente i deploy che introducono nuove violazioni. Pianifica audit manuali trimestrali e test con utenti con disabilità almeno una volta l’anno

L’accessibilità non è un traguardo da raggiungere una volta: è un processo continuo. Ogni nuovo contenuto, funzionalità o redesign deve essere progettato, sviluppato e testato con i criteri WCAG 2.2 integrati nel workflow, non aggiunti a posteriori. Le aziende che adottano il design inclusivo nello sviluppo fin dalle prime fasi del progetto riducono drasticamente i costi di remediation e costruiscono prodotti migliori per tutti gli utenti.

È proprio con questo spirito di semplificazione che abbiamo approcciato lo sviluppo di Mimir AI Agents.

Per aiutare gli utenti a mantenere contrasti sufficienti senza complicare il lavoro di personalizzazione, abbiamo preso ispirazione dalle linee guida WCAG per la gestione dei colori del widget: la nostra tecnologia analizza il colore principale scelto per i vostri agenti e propone automaticamente per i pulsanti due combinazioni (una chiara e una scura) ottimizzate per garantire la leggibilità.

Se vuoi scoprire come un sistema di Agenti AI può aiutarti a rendere scalabile il tuo business, registrati subito alla piattaforma o richiedi una demo gratuita personalizzata per le tue esigenze.

Fonti

• Direttiva (UE) 2019/882 — European Accessibility Act
• D.Lgs. 82/2022 — Recepimento italiano dell’EAA
• WCAG 2.2 — Traduzione italiana ufficiale W3C
• Direttiva Web Accessibility (UE 2016/2102) — Commissione Europea
• EN 301 549 V4.1.0 — WebAccessibile.org
• Linee Guida AgID sull’accessibilità, AGID
• Vaughan, Ortiz Suarez (2026) — Studio contrasto colori su Common Crawl
• Boyalakuntla, Venigalla, Chimalakonda — WAccess: strumento audit WCAG