Accessibilità web: cosa chiede la normativa e come si imposta un lavoro serio

Dal 28 giugno 2025 l'accessibilità web non è più solo una buona pratica per molti siti privati: l'European Accessibility Act, recepito in Italia, la rende un requisito per una serie di servizi digitali rivolti ai consumatori, a partire dall'e-commerce. Le definizioni di base si trovano ovunque. Qui mi concentro su cosa comporta davvero dal punto di vista tecnico e su come si imposta un lavoro che regga a una verifica.

Il quadro normativo, con prudenza

Non sono un avvocato e il perimetro esatto va verificato con un consulente. Il quadro tecnico, però, è chiaro.

• Pubblica amministrazione: obblighi in vigore da anni, con dichiarazione di accessibilità e meccanismo di segnalazione.
• European Accessibility Act (direttiva 2019/882): si applica a prodotti e servizi indicati dalla direttiva, tra cui commercio elettronico verso consumatori, servizi bancari, trasporti, e-book, comunicazioni elettroniche. Le microimprese che forniscono servizi sono esentate.
• Norma tecnica di riferimento: la EN 301 549, che per il web rimanda alle WCAG 2.1 livello AA.

Il punto pratico: per chi è coinvolto, non basta «fare del proprio meglio». Serve conformità a criteri verificabili, documentata, e mantenuta nel tempo.

Cosa chiedono davvero le WCAG

Il livello AA comprende una cinquantina di criteri di successo. Quelli che nella mia esperienza fanno fallire più spesso un audit:

• 1.4.3 e 1.4.11 – contrasto di testo e di componenti non testuali (bordi dei campi, icone, stati del focus);
• 2.1.1 – tastiera: tutto deve essere utilizzabile senza mouse, compresi menu, modali, slider e caroselli;
• 2.4.7 e 2.4.11 – focus visibile e non nascosto da intestazioni fisse o banner;
• 4.1.2 – nome, ruolo, valore: ogni controllo personalizzato deve esporre cosa è e in che stato si trova;
• 3.3.1 e 3.3.3 – errori nei moduli identificati e spiegati;
• 1.3.1 – informazioni e relazioni: struttura dei titoli, liste, tabelle e associazione tra etichette e campi nel codice, non solo nell'aspetto.

Le WCAG 2.2 aggiungono criteri come la dimensione minima dei bersagli e l'autenticazione senza test cognitivi. Progettare già su 2.2 costa poco e anticipa la prossima revisione della norma.

Dove nascono i problemi

L'accessibilità si decide in tre punti, e correggerla a valle costa sempre di più.

• Nel design: palette con contrasti insufficienti, stati di focus non disegnati, informazioni affidate solo al colore, bersagli piccoli su mobile.
• Nei componenti: menu a tendina, modali, schede e caroselli costruiti con div cliccabili invece che con elementi nativi, senza gestione del focus e senza attributi ARIA corretti. Un componente sbagliato replica l'errore su ogni pagina.
• Nei contenuti: testi alternativi assenti o ridondanti, titoli scelti per l'aspetto, link «clicca qui», PDF non taggati.

Per l'elenco dettagliato degli errori ricorrenti c'è Sito accessibile: i 10 errori più comuni.

Perché gli overlay non sono una soluzione

I widget che aggiungono un pulsante «accessibilità» con contrasto alto, ingrandimento e lettura vocale promettono conformità con una riga di codice. Non funziona così: non modificano la semantica, non aggiungono nomi accessibili corretti, non sistemano la gestione del focus né i moduli. Gli utenti di lettori di schermo hanno già strumenti propri, spesso migliori, e un overlay può interferire con questi. Diverse associazioni di persone con disabilità ne sconsigliano esplicitamente l'uso.

Come imposto un audit che regge

1. Campione rappresentativo: non tutte le pagine, ma tutti i template e tutti i flussi critici (registrazione, checkout, moduli di contatto, area riservata).
2. Verifica automatica con axe o strumenti equivalenti: trova una parte dei problemi, quella meccanica.
3. Verifica manuale da tastiera su ogni flusso, con attenzione a ordine e visibilità del focus, trappole, modali.
4. Verifica con lettori di schermo (VoiceOver, NVDA) su componenti e moduli.
5. Verifica di zoom e reflow a 400% e con spaziatura del testo aumentata.
6. Report per criterio WCAG, con priorità: prima ciò che blocca un compito, poi il resto.
7. Correzione nei componenti, così che il fix si propaghi su tutto il sito.
8. Dichiarazione di accessibilità e procedura di verifica sulle nuove pagine.

Mantenerla nel tempo

L'accessibilità si degrada a ogni nuovo contenuto e a ogni nuovo componente. Le misure che funzionano sono di processo: controlli automatici nella pipeline di pubblicazione, una checklist per chi scrive i contenuti, una verifica manuale a ogni nuovo template, e un canale per le segnalazioni degli utenti.

Come la vedo io

L'accessibilità, per me, è prima di tutto una questione di qualità del codice. Se i componenti sono costruiti con elementi nativi, gestiscono il focus e rispettano preferenze come la riduzione del movimento, buona parte dei criteri è soddisfatta senza sforzi aggiuntivi. È quello che cerco di fare nei miei progetti: componenti scritti una volta sola, con gli stati di focus e di errore già pensati, riutilizzati ovunque.

Il problema dei siti costruiti per accumulo, con builder e plugin di provenienze diverse, è che ogni pezzo ha la sua idea di accessibilità e non c'è un punto unico in cui correggere. Lì l'audit diventa una lista infinita. Su un sistema di componenti coerente, invece, una correzione vale per tutto il sito.

Infine, considero l'accessibilità un buon indicatore della qualità complessiva di un sito: quando è curata, di solito lo sono anche struttura, prestazioni e manutenibilità.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Faccio audit WCAG con strumenti automatici, verifiche da tastiera e lettori di schermo, e correggo i problemi dove nascono, nei componenti. Non rilascio certificazioni: consegno un report per criterio e il lavoro fatto. Per il perimetro legale conviene affiancare un consulente.

Se devi capire a che punto è il tuo sito, scrivimi: in una chiacchierata di circa 20 minuti definiamo il campione da verificare e le priorità. Il servizio è in Accessibilità web: audit e correzioni WCAG.