Accessibilità web WCAG 2.2: perché conta e come iniziare

Le WCAG 2.2 (Web Content Accessibility Guidelines) sono lo standard internazionale per rendere i siti web utilizzabili da persone con disabilità visive, motorie, uditive o cognitive. Dal 2025 sono obbligatorie per i siti della Pubblica Amministrazione italiana e raccomandate per qualsiasi sito commerciale che voglia evitare rischi legali, massimizzare il pubblico raggiungibile e — non da ultimo — migliorare la SEO. Molte ottimizzazioni per l'accessibilità coincidono esattamente con le best practice SEO.

Circa il 15% della popolazione mondiale ha una forma di disabilità permanente o temporanea. In Italia, con una popolazione anziana superiore alla media europea (23% over 65), l'accessibilità riguarda milioni di potenziali clienti. Le disabilità temporanee (un braccio rotto, un ambiente troppo luminoso, l'uso dello smartphone in piena luce solare) ampiano ulteriormente questo pubblico.

Dal punto di vista business, un sito accessibile raggiunge un mercato più ampio, riduce il rischio legale (le cause per inaccessibilità sono in aumento in Europa), e migliora l'esperienza per tutti gli utenti — non solo per chi ha disabilità. Contrasto elevato, testi chiari, navigazione logica e target di click grandi aiutano chiunque, specialmente su mobile.

• Percepibile: i contenuti devono essere presentabili in modi diversi (testo alternativo per immagini, trascrizioni per audio, sottotitoli per video)
• Utilizzabile: l'interfaccia deve funzionare con tastiera senza mouse, con tempo sufficiente per leggere, senza contenuti che provocano crisi epilettiche
• Comprensibile: i contenuti e l'interfaccia devono essere chiari, prevedibili e fornire assistenza in caso di errori (es. nei form)
• Robusto: il codice deve essere compatibile con tecnologie assistive attuali e future come screen reader, display Braille, e switch access

• Contrasto colori: rapporto minimo 4,5:1 tra testo e sfondo per testo normale, 3:1 per testo grande (>18px). Verificare con WebAIM Contrast Checker gratuitamente
• Testo alternativo (alt) su tutte le immagini significative: descrizione concisa del contenuto o della funzione dell'immagine, non "foto 1" o il nome del file
• Struttura heading logica: H1 unico per pagina, H2 per sezioni principali, H3 per sottosezioni — non usate gli heading per "fare grande il testo"
• Focus visibile: chi naviga con Tab deve vedere dove si trova. Non rimuovere mai outline: focus con CSS (focus-visible) come alternativa moderna
• Form accessibili: ogni campo ha una label HTML associata (non solo placeholder), gli errori di validazione sono descritti chiaramente in testo, non solo con il colore rosso

WCAG 2.2, pubblicata nell'ottobre 2023, ha aggiunto 9 nuovi criteri di successo rispetto alla 2.1. I più importanti per i siti italiani: criterio 2.5.8 "Target Size" — i target di click devono essere almeno 24x24 pixel (importante per mobile, dove molti siti hanno pulsanti troppo piccoli), criterio 2.4.11 "Focus Not Obscured" — il componente in focus non deve essere completamente oscurato da altri elementi (es. header sticky), e criterio 3.3.7 "Redundant Entry" — gli utenti non devono reinserire le stesse informazioni già fornite nella stessa sessione.

Se avete un sito costruito prima del 2023, probabilmente non è conforme WCAG 2.2 anche se era conforme WCAG 2.1. Un audit tecnico di accessibilità permette di identificare tutti i gap e prioritizzare gli interventi. Nella nostra esperienza a Milano, i siti più vecchi hanno tipicamente 30-80 violazioni accessibilità, ma il 70% delle violazioni può essere risolto con 10-20 ore di intervento tecnico mirato.

Le ottimizzazioni per l'accessibilità migliorano anche la SEO in modo diretto. Testo alternativo alle immagini: Google non "vede" le immagini come le vede un umano, legge il testo alt — ottimizzarlo per le keyword è una pratica SEO riconosciuta. Struttura heading corretta: Google usa gli heading per capire la gerarchia del contenuto, esattamente come fa uno screen reader. Link con testo descrittivo (non "clicca qui"): migliorano l'accessibilità e aiutano Google a capire il contesto del link.

Gli strumenti automatici identificano il 30-40% delle violazioni di accessibilità: sono un punto di partenza, non una soluzione completa. Strumenti gratuiti: Lighthouse in Chrome DevTools (tab "Accessibilità"), axe DevTools come estensione browser (più dettagliato di Lighthouse), WAVE Web Accessibility Evaluation Tool (visualizzazione grafica dei problemi).

Per il restante 60% delle violazioni (problemi semantici, di flusso, di comprensibilità), serve testing manuale. Il metodo più accessibile: navigate il vostro sito usando solo la tastiera (Tab per muoversi, Invio per attivare, Shift+Tab per tornare indietro). Se riuscite a completare tutte le operazioni chiave (compilare un form, navigare il menu, trovare le informazioni principali) senza mouse, il sito ha una buona base di accessibilità da tastiera.

Next.js include avvisi in console durante lo sviluppo per problemi di accessibilità comuni, grazie all'integrazione con eslint-plugin-jsx-a11y. Lavorando in TypeScript con componenti React ben strutturati e librerie come Radix UI (componenti accessibili by design), è molto più semplice costruire interfacce WCAG-conformi rispetto a siti WordPress con Elementor, dove l'HTML generato automaticamente spesso non rispetta gli standard semantici.

Nella nostra pratica di realizzazione siti web con Next.js, includiamo l'accessibilità WCAG 2.2 livello AA come requisito di default — non come optional a pagamento. Questo significa: semantic HTML corretto (button per azioni, a per navigazione, h1-h6 in ordine logico), ARIA labels dove necessario, gestione del focus per modali e dropdown, colori verificati con contrast checker. Il costo aggiuntivo è marginale durante lo sviluppo; il costo di retrofitting su un sito già costruito è 5-10x superiore.

La Legge Stanca (L. 4/2004, aggiornata con D.Lgs. 106/2018) rende obbligatoria l'accessibilità per le PA italiane e per le aziende private con più di 50 dipendenti che forniscono servizi pubblici. L'European Accessibility Act (Direttiva 2019/882, recepita in Italia con D.Lgs. 82/2022) introduce obblighi progressivi per prodotti e servizi digitali destinati ai consumatori, con scadenza giugno 2025 per i servizi nuovi e giugno 2030 per quelli esistenti. Il rischio di sanzioni è reale: l'AGID (Agenzia per l'Italia Digitale) ha aumentato l'attività di vigilanza e le segnalazioni di utenti con disabilità sono in crescita.

Se volete iniziare a migliorare l'accessibilità del vostro sito senza un refactoring completo, il piano d'azione in 3 fasi è: 1) Audit automatico con axe DevTools e correzione delle violazioni critiche (missing alt text, contrasto insufficiente, label mancanti nei form) — 8-16 ore. 2) Test manuale con tastiera e correzione dei problemi di navigazione e focus — 4-8 ore. 3) Test con screen reader (NVDA per Windows gratuito, VoiceOver su Mac integrato) per verificare l'esperienza degli utenti non vedenti — 4-8 ore. Con 20-30 ore di lavoro tecnico mirato, la maggior parte dei siti raggiunge la conformità WCAG 2.2 livello A. Per il livello AA (quello richiesto per legge), potrebbero servire interventi più profondi. Contattateci per un audit gratuito della vostra situazione attuale.