Audit Accessibilità Sito Web: WCAG 2.2 nel Codice, non Overlay

Un audit accessibilità sito web serve a capire, criterio per criterio, dove il tuo sito o la tua web app non è utilizzabile da chi naviga con tastiera, screen reader, ingrandimento o contrasti elevati. Poi serve a correggere quei punti. Nel 2026 la domanda è diventata concreta: con l’European Accessibility Act in vigore e i controlli AgID in partenza, molte PMI italiane cercano una soluzione rapida. Spesso la trovano in un plugin che promette di sistemare tutto con una riga di JavaScript. Non funziona così. In questo articolo spiego come imposto io un audit WCAG 2.2 livello AA e perché le correzioni vanno fatte nel codice.

Gli obblighi generali, cioè chi è coinvolto e perché conviene, li ho già trattati in accessibilità del sito web: obblighi e vantaggi per le aziende. Qui parlo del lavoro tecnico.

Perché se ne parla adesso: controlli AgID e WCAG 2.2

In Italia l’European Accessibility Act è stato recepito con il D.Lgs. 82/2022 e AgID è l’autorità di vigilanza per i servizi digitali. Nel 2026 ha iniziato le verifiche sui soggetti privati, come riassume questo approfondimento di Sigmar. Tre punti mi sembrano i più rilevanti per chi ha un sito o una piattaforma:

• Le microimprese che forniscono servizi sono escluse dall’applicazione del decreto. Conviene comunque verificare la propria posizione con il consulente, perché la definizione di microimpresa ha soglie precise su dipendenti e fatturato.
• Gli overlay non garantiscono da soli la conformità. Le linee guida AgID lo dicono in modo esplicito, come riporta ForumPA.
• Il riferimento tecnico si sposta sulle WCAG 2.2 AA. La nuova versione della norma armonizzata EN 301 549 è attesa nel corso del 2026 e dovrebbe allinearsi a questa versione delle linee guida.

Tradotto: chi rientra negli obblighi deve avere un sito che funziona davvero con le tecnologie assistive. Un’icona di accessibilità nell’angolo della pagina non basta.

Perché un overlay non risolve il problema

Un overlay è uno script che si carica sopra il sito e prova a correggere al volo quello che trova: aggiunge attributi ARIA, cambia contrasti, offre un pannello per ingrandire il testo. I limiti sono strutturali:

• Non conosce il significato dei contenuti. Non sa che quell’immagine è il logo del partner o il grafico dei prezzi. Un testo alternativo generato in automatico raramente descrive quello che serve.
• Non ricostruisce la logica dei componenti. Un menu a tendina costruito con div e click del mouse resta difficile da usare con la tastiera. Per sistemarlo bisogna riscriverlo.
• Può entrare in conflitto con gli strumenti dell’utente. Chi usa uno screen reader ha già le sue impostazioni. Uno script che le sovrascrive rischia di peggiorare l’esperienza.
• Aggiunge peso e dipendenze esterne: un altro script di terze parti da caricare, spesso con implicazioni privacy da valutare.

Il problema nasce nel markup, nel CSS e nel JavaScript, e lì va corretto.

Come imposto un audit accessibilità WCAG 2.2 AA

Il metodo è lo stesso per un sito WordPress e per una web app. Cambia solo il numero di schermate e di flussi da verificare.

1. Scelta del campione

Non si controlla ogni URL, si controllano i modelli: home, pagina di servizio, articolo, scheda prodotto, form di contatto, carrello e checkout se c’è un e-commerce, login e area riservata. In una web app aggiungo i flussi principali, per esempio creare una prenotazione o emettere un documento. Se un modello è corretto, lo sono tutte le pagine che lo usano.

2. Test automatici

Passo le pagine con strumenti come axe-core e Lighthouse. Trovano in fretta contrasti insufficienti, immagini senza testo alternativo, campi senza etichetta, gerarchie di titoli saltate e attributi ARIA non validi. Coprono però solo una parte dei criteri WCAG. Un report automatico pulito non significa sito accessibile.

3. Test manuali

• Solo tastiera: ogni elemento interattivo si raggiunge con Tab, l’ordine è logico, il focus è sempre visibile, i modali si chiudono con Esc e non intrappolano il cursore.
• Screen reader: NVDA su Windows e VoiceOver su macOS e iOS. Verifico che i pulsanti si annuncino con un nome sensato e che errori e notifiche vengano letti.
• Zoom al 200% e al 400%: i contenuti devono riflettersi senza scroll orizzontale e senza testi tagliati.

4. I criteri nuovi delle WCAG 2.2

Sono quelli che più spesso non vengono controllati sui siti esistenti:

• Focus non oscurato (2.4.11): header fissi e banner cookie non devono coprire l’elemento su cui si trova il focus.
• Dimensione minima dei target (2.5.8): almeno 24×24 pixel CSS, oppure una spaziatura sufficiente. Icone social e pulsanti "chiudi" troppo piccoli sono il caso tipico.
• Movimenti di trascinamento (2.5.7): se un’interfaccia usa il drag-and-drop, come un calendario o una kanban, serve un’alternativa con click singolo.
• Autenticazione accessibile (3.3.8): niente login che obblighi a ricordare o trascrivere codici senza permettere incolla o gestore password.
• Inserimento ridondante (3.3.7) e aiuto coerente (3.2.6): non chiedere due volte lo stesso dato nello stesso flusso e tenere i contatti o l’assistenza sempre nella stessa posizione.

5. Report e priorità

Ogni problema finisce in una lista con criterio violato, pagina o componente, gravità e correzione proposta. Parto da quello che blocca i flussi: form non compilabili, checkout non raggiungibile da tastiera, CAPTCHA inaccessibili.

Correggere nel codice: WordPress su misura e web app

Su un WordPress con tema su misura, come quelli che realizzo e gestisco (per esempio lapidari.it e opticagheller.it), il vantaggio è che il markup lo controllo io. Una correzione a un componente del tema vale subito per tutto il sito, senza dipendere dall’aggiornamento di un page builder o di un tema commerciale. Ne ho parlato in sito vetrina professionale con tema WordPress su misura. Gli interventi tipici sono questi:

• struttura semantica con header, nav, main e footer, più un link "salta al contenuto";
• stili :focus-visible chiari e mai rimossi;
• campo "testo alternativo" reso obbligatorio nel flusso editoriale per le immagini che portano informazione;
• form con label collegate, messaggi di errore associati al campo e annunciati;
• plugin di terze parti, come slider, form builder e banner cookie, verificati uno per uno e sostituiti se non accessibili.

Nelle web app come apicco.app, indelio.eu o tandemops.app il lavoro si concentra sui componenti interattivi: tabelle ordinabili, modali, dropdown, date picker, notifiche. La regola che seguo è usare prima gli elementi HTML nativi (button, dialog, select) e ricorrere ad ARIA solo quando serve davvero. Le scelte di interfaccia che facilitano questo approccio le ho descritte nell’articolo sul design UX per web app aziendali.

Tenere il sito conforme nel tempo

Un audit fotografa il sito in un momento preciso. Dopo sei mesi di nuove pagine, plugin aggiornati e contenuti caricati da persone diverse, la situazione può essere cambiata. Per questo:

1. inserisco i controlli automatici con axe nella pipeline di test, così una regressione evidente blocca il rilascio (vedi testing automatizzato per web app);
2. ripeto un controllo manuale sui modelli principali a ogni modifica rilevante del design;
3. preparo e aggiorno le informazioni sull’accessibilità del servizio richieste dalla normativa, seguendo le indicazioni AgID;
4. do a chi gestisce i contenuti poche regole pratiche: titoli in ordine, testi dei link descrittivi, niente testo dentro le immagini.

Se stai preparando un e-commerce per il quarto trimestre, il momento giusto per l’audit è adesso, prima dei picchi di traffico. Correggere un checkout a dicembre è molto più rischioso.

FAQ sull’audit di accessibilità

Un plugin di accessibilità mi rende conforme?

No. AgID chiarisce che gli overlay non garantiscono da soli la conformità. Possono affiancare un sito già corretto, ma non sostituiscono le modifiche al codice.

Quanto dura un audit?

Dipende dal numero di modelli di pagina e di flussi. Un sito vetrina con pochi template richiede molto meno tempo di una web app con aree riservate e pagamenti. Prima di fare una stima guardo sempre il sito.

La mia azienda è obbligata?

Dipende da dimensione e tipo di servizio. Le microimprese che forniscono servizi sono escluse dal decreto. In caso di dubbio conviene una verifica con il consulente legale. Un sito accessibile resta comunque un sito più usabile per tutti.

Serve rifare il sito da zero?

Non per forza. Spesso bastano interventi mirati su tema e componenti. Il rifacimento conviene quando il sito poggia su un builder o un tema che genera markup difficile da correggere.

Parliamo del tuo sito o della tua web app

Sviluppo e gestisco siti WordPress su misura e web app full-stack, dal codice all’hosting. Posso fare l’audit, correggere i problemi alla fonte e mantenere il progetto nel tempo. Se vuoi capire a che punto è il tuo sito, contattami qui e partiamo da un’analisi concreta.