Sito accessibile: i 10 errori che trovo più spesso negli audit, e come si correggono nel codice

Gli elenchi degli «errori di accessibilità più comuni» si somigliano tutti: contrasto, testo alternativo, etichette. Sono corretti, ma descrivono i sintomi. Negli audit che faccio, gli errori che bloccano davvero gli utenti stanno quasi sempre nei componenti interattivi e nel modo in cui il codice comunica stato e struttura alle tecnologie assistive. Ecco i dieci che trovo più spesso, con il criterio WCAG coinvolto e la correzione.

1. Elementi interattivi che non sono elementi interattivi

div e span con un gestore di clic al posto di button e a. Non ricevono il focus, non rispondono a Invio e Spazio, non hanno ruolo. Criteri 2.1.1 e 4.1.2. La correzione non è aggiungere tabindex e role="button", ma usare l'elemento nativo, che porta con sé tutto il comportamento corretto.

2. ARIA usato per decorare

aria-label su elementi che hanno già testo visibile diverso, role="menu" su una normale navigazione, aria-hidden="true" su contenuti che si possono raggiungere con il focus. ARIA scorretto è peggio di nessun ARIA: comunica informazioni false. Regola pratica: prima l'HTML semantico, ARIA solo per ciò che l'HTML non sa esprimere.

3. Modali senza gestione del focus

All'apertura il focus resta sotto la modale, con Tab si esce verso la pagina, Esc non chiude, alla chiusura il focus si perde in cima al documento. Criteri 2.4.3 e 2.1.2. Oggi l'elemento dialog con showModal() risolve gran parte del problema in modo nativo: rende inerte il resto della pagina e gestisce Esc. Resta da riportare il focus sull'elemento che l'ha aperta.

4. Focus invisibile o coperto

outline: none senza alternativa, oppure focus visibile ma nascosto sotto un'intestazione fissa o un banner dei cookie. Criteri 2.4.7 e 2.4.11. Si usa :focus-visible con uno stile netto e coerente su tutti i componenti, e scroll-margin-top pari all'altezza dell'intestazione fissa.

5. Contrasto dei componenti, non solo del testo

Il contrasto del testo viene controllato quasi sempre. Quello dei bordi dei campi, delle icone senza testo, degli indicatori di stato e degli anelli di focus quasi mai. Criterio 1.4.11, soglia 3:1. È l'errore più frequente nei design minimalisti con campi grigio chiaro su bianco.

6. Moduli: etichette, istruzioni ed errori

Placeholder usati come etichetta (spariscono durante la digitazione), errori segnalati solo con il colore rosso, messaggi non collegati al campo. Criteri 1.3.1, 3.3.1, 3.3.2. Ogni campo ha una label associata, le istruzioni sono collegate con aria-describedby, l'errore è testuale, collegato al campo e annunciato, e autocomplete è valorizzato sui dati personali.

7. Contenuti dinamici non annunciati

Risultati di ricerca aggiornati, carrello che cambia, messaggio di conferma dopo l'invio: chi usa un lettore di schermo non se ne accorge. Criterio 4.1.3. Serve una regione aria-live (o role="status") presente nel DOM fin dall'inizio, in cui si inserisce il messaggio. Aggiunta al momento, spesso non viene letta.

8. Struttura dei titoli scelta per l'aspetto

Un h4 perché «è più piccolo», titoli saltati, testo in grassetto al posto di un titolo. Chi naviga per titoli con il lettore di schermo trova una mappa sbagliata. Criterio 1.3.1. La gerarchia segue la struttura del contenuto, l'aspetto si gestisce con il CSS.

9. Testi alternativi meccanici

Immagini con alt uguale al nome del file, immagini decorative descritte, immagini informative (grafici, schemi) con un alt generico. Criterio 1.1.1. Le decorative hanno alt="", le informative descrivono l'informazione, non l'aspetto. Su un CMS il campo alt va reso obbligatorio dove serve.

10. Movimento e animazioni senza alternativa

Caroselli automatici senza pausa, animazioni di comparsa su tutto, effetti parallasse. Criteri 2.2.2 e 2.3.3. I caroselli hanno controlli di pausa; le animazioni rispettano la preferenza prefers-reduced-motion e si riducono o si spengono.

Correggere nel componente, non nella pagina

Quasi tutti questi errori si ripetono identici su ogni pagina, perché nascono da un componente. Correggerli pagina per pagina non finisce mai; correggerli nel componente li elimina ovunque in un colpo. È anche il motivo per cui un sistema di componenti coerente rende l'accessibilità molto più economica da mantenere. Il quadro normativo è in Accessibilità web: cosa chiede la normativa.

Una verifica rapida in un'ora

Prima di un audit completo, questo protocollo dà un quadro realistico:

1. Solo tastiera su home, una pagina interna e il modulo principale: si raggiunge tutto? Il focus si vede sempre? Le modali si chiudono con Esc?
2. Zoom al 200% e al 400%: il contenuto si riorganizza senza scorrimento orizzontale e senza testi tagliati?
3. Analisi automatica con axe o Lighthouse sui template principali, nei due temi se il sito ne ha più di uno.
4. Navigazione per titoli con un lettore di schermo: la struttura racconta la pagina?
5. Invio del modulo con errori: gli errori sono annunciati, testuali e collegati ai campi?
6. Riduzione del movimento attivata nel sistema: le animazioni si fermano?

Se in un'ora emergono problemi in tre di questi punti, il sito ha bisogno di un lavoro sui componenti, non di correzioni sparse.

Come la vedo io

Quando costruisco un sito parto da qui: elementi nativi, stati di focus disegnati insieme al resto, animazioni che si spengono per chi ha chiesto meno movimento. In questo sito, per esempio, tutte le animazioni di comparsa e le scene in movimento rispettano prefers-reduced-motion, e il tema chiaro e scuro è costruito su variabili di colore, così i contrasti si controllano in un punto solo.

Il problema dei siti fatti con builder e plugin di origini diverse è che ogni componente porta i suoi errori, e non hai il controllo del codice per correggerli. Lì l'accessibilità diventa una battaglia contro gli strumenti invece che una proprietà del sito.

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 verifiche manuali da tastiera e lettore di schermo, e correggo gli errori nei componenti, dove nascono.

Se vuoi sapere quali di questi errori ha il tuo sito, scrivimi: in una chiacchierata di circa 20 minuti scegliamo da dove partire. Il servizio è in Accessibilità web: audit e correzioni WCAG.