Accessibilità Web

Aggiornato aprile 2026 · 12 min di lettura

Un sito accessibile funziona per tutti: utenti con disabilità visive o motorie, persone anziane, chi usa una connessione lenta o uno schermo piccolo. In Italia e in Europa, per i siti delle pubbliche amministrazioni è anche un obbligo di legge. Ma anche per i siti privati, l’accessibilità migliora la SEO, riduce i contenziosi legali e allarga il pubblico raggiungibile.

Le WCAG 2.1: i quattro principi

Le Web Content Accessibility Guidelines del W3C organizzano i requisiti intorno a quattro principi fondamentali, spesso abbreviati come POUR:

Il livello AA è lo standard richiesto dalla normativa europea (EN 301 549) e dalla maggior parte dei capitolati pubblici italiani. Il livello AAA è più restrittivo e non è richiesto per conformità, ma alcune sue linee guida sono utili da conoscere.

HTML semantico come base

Il 70% dei problemi di accessibilità si risolve scrivendo HTML semantico corretto. Gli screen reader navigano il documento attraverso i landmark ARIA impliciti degli elementi HTML5:

<header>        → role="banner"
<nav>           → role="navigation"
<main>          → role="main"
<aside>         → role="complementary"
<footer>        → role="contentinfo"

Usare un <div> dove servirebbe un <button> è uno degli errori più comuni: il <div> non riceve il focus da tastiera, non comunica il suo ruolo agli screen reader, non risponde a Invio o Spazio. La stessa logica vale per <h1>...<h6>: la gerarchia dei titoli è la struttura di navigazione principale per chi usa uno screen reader.

Testo alternativo per le immagini

L’attributo alt non va mai omesso. Ma va anche compilato in modo sensato:

ARIA: quando usarlo

WAI-ARIA aggiunge semantica agli elementi HTML quando quella nativa non basta. La prima regola di ARIA è: non usarlo se esiste un elemento HTML nativo equivalente. Un <button> è sempre meglio di un <div role="button">.

I casi d’uso più comuni:

Contrasto e colori

WCAG 2.1 AA richiede un rapporto di contrasto minimo di 4.5:1 per il testo normale e 3:1 per il testo grande (18pt o 14pt grassetto). Non affidarsi mai al solo colore per trasmettere un’informazione: un messaggio di errore in rosso senza icona o testo esplicativo non è accessibile per gli utenti daltonici.

Strumenti utili per verificare il contrasto: WebAIM Contrast Checker, il devtools di Chrome/Firefox (sezione Accessibilità nell’inspector degli elementi).

Form e messaggi di errore

Ogni campo di un form deve avere un <label> associato tramite for/id, non solo un placeholder. Il placeholder sparisce alla digitazione e non è sufficiente come etichetta. I messaggi di errore vanno collegati al campo tramite aria-describedby e devono spiegare cosa correggere, non solo che c’è un errore:

<label for="email">Email</label>
<input id="email" type="email" aria-describedby="email-err">
<span id="email-err" role="alert">
  Inserisci un indirizzo email valido (es. [email protected])
</span>

Navigazione da tastiera

Tutta la funzionalità di un sito deve essere raggiungibile e utilizzabile con la sola tastiera (Tab, Invio, Spazio, Frecce). Verificare:

Un skip link all’inizio della pagina (“Vai al contenuto principale”) evita che gli utenti da tastiera debbano attraversare l’intera navigazione a ogni pagina.

Testing pratico

Nessuno strumento automatico rileva più del 30-40% dei problemi di accessibilità. Il testing manuale è indispensabile:

Normativa italiana ed europea

Per i siti della pubblica amministrazione, la Direttiva UE 2016/2102 e il D.Lgs. 106/2018 impongono:

Per i siti privati non esiste un obbligo generico di accessibilità, ma la Legge Stanca (L. 4/2004) si applica alle aziende con più di 15 dipendenti che offrono servizi al pubblico.