Accessibilità Web (a11y): Guida per Sviluppatori alla Conformità WCAG

L'accessibilità web — spesso indicata con il numeronimo a11y — non è solo una scelta etica, ma una necessità tecnica. Progettare siti accessibili significa garantire che chiunque, indipendentemente da limitazioni fisiche, sensoriali o cognitive, possa navigare e interagire con i contenuti digitali. In un mondo dove oltre un miliardo di persone convive con una disabilità, l'accessibilità è diventata un requisito legale fondamentale (si pensi all'European Accessibility Act o alla Legge Stanca in Italia).

In questa guida analizzeremo i passaggi tecnici fondamentali per allinearsi agli standard WCAG 2.1, migliorando non solo l'inclusività ma anche il posizionamento SEO e l'esperienza utente globale.

I Livelli di Conformità WCAG 2.1

Le Web Content Accessibility Guidelines (WCAG) sono lo standard internazionale definito dal W3C. Si articolano su tre livelli di severità:

• Livello A — Il requisito minimo. Riguarda le barriere più gravi che impediscono totalmente l'accesso ai contenuti (es. mancanza di testi alternativi per le immagini).
• Livello AA — Lo standard di riferimento per la maggior parte delle aziende e delle normative europee. Include requisiti sul contrasto cromatico (4.5:1) e una navigazione coerente.
• Livello AAA — Il massimo livello di accessibilità. Richiede un contrasto elevato (7:1), interpretazione nella lingua dei segni e descrizioni audio estese. Spesso difficile da applicare a interi portali complessi.

Puntare al Livello AA è la strategia migliore per garantire conformità legale e una navigazione fluida per la stragrande maggioranza degli utenti.

L'importanza dell'HTML Semantico

Il modo più efficace (ed economico) per rendere un sito accessibile è scrivere HTML semantico. Gli screen reader e le tecnologie assistive si basano sulla struttura del DOM per spiegare all'utente cosa sta guardando.

<div class="header">
  <div class="nav">
    <div class="link" onclick="home()">Home</div>
    <div class="link" onclick="prodotti()">Prodotti</div>
  </div>
</div>
<div class="content">
  <div class="titolo">I nostri servizi</div>
  <div class="paragrafo">Dettagli qui...</div>
</div>

<header>
  <nav aria-label="Navigazione principale">
    <ul>
      <li><a href="/it/">Home</a></li>
      <li><a href="/it/prodotti">Prodotti</a></li>
    </ul>
  </nav>
</header>
<main>
  <h1>I nostri servizi</h1>
  <p>Dettagli qui...</p>
</main>

Elementi chiave da utilizzare sempre:

• <header>, <footer>, <main>, <nav> — Definiscono le macro-aree della pagina.
• <h1>-<h6> — Gerarchia dei titoli (mai saltare i livelli).
• <button> — Per azioni interattive (non usare div con click event).
• <a> — Solo per collegamenti ipertestuali.
• <form> e <label> — Indispensabili per l'accessibilità dei campi input.

Attributi ARIA: Colmare i Vuoti

L'acronimo ARIA (Accessible Rich Internet Applications) indica attributi che aggiungono contesto dove l'HTML standard non arriva. Regola d'oro: Se puoi usare un elemento HTML nativo, non usare ARIA.

Pattern Comuni

<!-- Etichettare un elemento senza testo visibile -->
<button aria-label="Chiudi menu" onclick="close()">
  <svg>...</svg>
</button>

<!-- Regioni Live: avvisa lo screen reader di un cambiamento -->
<div aria-live="polite">
  Prodotto aggiunto al carrello correttamente.
</div>

<!-- Stati di espansione per menu a tendina -->
<button aria-expanded="false" aria-controls="sub-menu">
  Opzioni
</button>
<ul id="sub-menu" hidden>...</ul>

Errori da evitare con ARIA

• Ruoli ridondanti: Non scrivere <nav role="navigation">, l'elemento nav lo implica già.
• Mancanza di gestione tastiera: Se simuli un bottone con un div usando role="button", devi anche gestire gli eventi "Enter" e "Space" via JavaScript.
• Abuso di aria-hidden: Non nascondere contenuti importanti alle tecnologie assistive se sono visibili agli altri utenti.

Navigazione da Tastiera (Keyboard-Only)

Molti utenti con disabilità motorie o visive navigano esclusivamente tramite tastiera. Il sito deve essere completamente esplorabile senza mouse.

Requisiti Tecnici

1. Ordine di tabulazione logico: Segui l'ordine naturale del DOM. Evita valori positivi di tabindex.
2. Focus visibile: Non rimuovere mai l'outline (outline: none) senza fornire un'alternativa visibile ed evidente.
3. Skip Links: Inserisci un link "Salta al contenuto" come primo elemento della pagina per bypassare header e menu ripetitivi.

<style>
.skip-link {
  position: absolute;
  left: -9999px;
  background: #2563eb;
  color: white;
  padding: 10px;
}
.skip-link:focus {
  left: 0;
  top: 0;
}
</style>

<a href="#main" class="skip-link">Salta al contenuto principale</a>

Contrasto Colore e Design Visivo

Il basso contrasto è l'errore più frequente rilevato dagli strumenti automatici. Le WCAG 2.1 richiedono:

• Testo normale: Rapporto minimo di 4.5:1.
• Testo grande o grassetto: Rapporto minimo di 3:1.
• Icone e componenti UI: Rapporto minimo di 3:1 rispetto ai colori circostanti.

Un consiglio fondamentale: non usare solo il colore per trasmettere informazioni. Ad esempio, un errore in un form deve essere segnalato da un testo o un'icona, non solo dal bordo rosso del campo.

Accessibilità delle Immagini: Il Testo Alt

L'attributo alt è obbligatorio. Se un'immagine è informativa, descrivila brevemente. Se è puramente decorativa, usa alt="" per indicare agli screen reader di ignorarla.

<!-- Immagine informativa -->
<img src="grafico-vendite.png" alt="Grafico a barre: vendite in crescita del 20% nel 2024">

<!-- Immagine decorativa -->
<img src="pattern-sfondo.svg" alt="">

<!-- Immagine in un link -->
<a href="/it/download-pdf">
  <img src="icona-download.png" alt="Scarica il report in PDF">
</a>

Moduli e Form Accessibili

I form sono il punto più critico per l'interazione. Ogni input deve avere un'etichetta associata in modo programmatico.

1. Usa <label for="id-input"> per collegare il testo al campo.
2. Indica i campi obbligatori con aria-required="true".
3. Associa messaggi di errore tramite aria-describedby.
4. Usa role="alert" per messaggi di errore dinamici.

Focus Management nelle SPA (React, Vue, Angular)

Nelle Single Page Applications, il cambio di pagina non ricarica il browser. Lo screen reader potrebbe non accorgersi del cambio di rotta. È necessario spostare il focus sul nuovo titolo <h1> o usare un aria-live per annunciare il cambio di pagina.

Strumenti di Test

Il test dell'accessibilità deve essere un mix tra automazione e verifica manuale:

• Axe DevTools: Estensione browser eccellente per trovare bug strutturali.
• Lighthouse: Integrato in Chrome, fornisce un punteggio rapido di accessibilità.
• Navigazione manuale: Prova a usare il tuo sito solo con il tasto TAB.
• Screen Reader: Testa con NVDA (Windows) o VoiceOver (macOS) per capire l'esperienza reale degli utenti non vedenti.

Checklist Rapida

Per iniziare subito, verifica questi 5 punti sul tuo sito:

• L'attributo lang è presente nel tag <html>?
• Tutte le immagini hanno un attributo alt?
• Il contrasto del testo è leggibile ovunque?
• Puoi raggiungere tutti i link usando solo la tastiera?
• Tutti i form hanno etichette (label) associate?