Scrivere HTML semantico non è solo una buona pratica per i motori di ricerca. È, innanzitutto, una questione di inclusione: milioni di persone con disabilità visive utilizzano ogni giorno software chiamati screen reader per navigare il web. Inoltre, le linee guida internazionali WCAG — Web Content Accessibility Guidelines — richiedono una struttura HTML semantica come prerequisito fondamentale per la conformità ai livelli A e AA.
In questa guida, quindi, ci concentriamo su un angolo specifico: come l’HTML semantico aiuta le persone con disabilità visive, come funzionano concretamente gli screen reader e cosa devi fare per rendere il tuo codice davvero accessibile. Non si tratta di teoria astratta: ogni punto ha un impatto reale sull’esperienza di navigazione di milioni di utenti.
Per una reference completa dei tag semantici HTML5 con esempi di codice, puoi consultare la guida completa ai tag semantici HTML5.
Come gli Screen Reader Leggono l’HTML Semantico
Gli screen reader sono software che convertono il contenuto visivo di una pagina web in audio o output Braille. I più diffusi sono NVDA e JAWS su Windows, e VoiceOver su macOS e iOS. Tuttavia, non leggono semplicemente il testo dall’alto verso il basso. Al contrario, usano la struttura semantica dell’HTML per costruire una mappa di navigazione interattiva.
Il documento come mappa di navigazione
Quando un utente apre una pagina con NVDA o JAWS, il software analizza innanzitutto i tag semantici presenti e costruisce una lista di punti di navigazione rapida. In particolare:
- I titoli h1, h2, h3 diventano navigabili con un singolo tasto — l’utente può saltare da titolo a titolo senza ascoltare tutto il testo intermedio
- Il tag nav viene annunciato come “regione di navigazione”
- Il tag main viene annunciato come “regione principale del documento”
- Il tag aside viene annunciato come “regione complementare”
- Il tag footer viene annunciato come “piè di pagina del documento”
In sintesi, un utente con screen reader può premere un singolo tasto per saltare direttamente al main, bypassando completamente header e navigazione. Questo è possibile solo se quei tag semantici esistono nel codice.
Prima e dopo: l’impatto concreto sul codice
Considera questo esempio senza tag semantici:
html
<!-- Senza semantica: lo screen reader legge tutto linearmente -->
<div class="header">
<div class="logo">Il mio sito</div>
<div class="nav">Home | Blog | Contatti</div>
</div>
<div class="content">
<div class="title">Come usare Flexbox</div>
<div class="text">Contenuto dell'articolo...</div>
</div>
<div class="sidebar">Articoli correlati...</div>
<div class="footer">Copyright 2026</div>In questo caso, lo screen reader legge tutto dall’alto verso il basso senza possibilità di navigazione rapida. L’utente è quindi costretto ad ascoltare header e navigazione ogni volta che apre una nuova pagina. Inoltre, non sa distinguere il contenuto principale dalla sidebar: entrambi sono semplici div anonimi.
Ora, invece, lo stesso layout con i tag semantici corretti:
html
<!-- Con semantica: navigazione immediata per l'utente -->
<header>
<a href="/" aria-label="Home - Il mio sito">Il mio sito</a>
<nav aria-label="Navigazione principale">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/blog">Blog</a></li>
<li><a href="/contatti">Contatti</a></li>
</ul>
</nav>
</header>
<main id="contenuto-principale">
<article>
<h1>Come usare Flexbox</h1>
<p>Contenuto dell'articolo...</p>
</article>
</main>
<aside aria-label="Articoli correlati">
<h2>Continua a leggere</h2>
</aside>
<footer>
<p>Copyright 2026</p>
</footer>Con questa struttura, NVDA annuncia “intestazione, banner” quando incontra header, e “regione principale” quando raggiunge main. L’utente può saltare direttamente al contenuto con un tasto, ignorare la sidebar perché è identificata come “complementare” e navigare tra i titoli dell’articolo senza ascoltare tutto il testo. La differenza in termini di usabilità è radicale.
VoiceOver e il rotor
VoiceOver su iOS e macOS introduce inoltre il concetto di “rotor”: un controllo gestuale che permette di filtrare la navigazione per tipo di elemento. In particolare, l’utente può scegliere di navigare solo tra i titoli, solo tra i link, solo tra le regioni semantiche della pagina. Questo meccanismo funziona, tuttavia, solo se il codice HTML usa i tag corretti. Senza nav, main e article, il rotor rimane sostanzialmente vuoto e la navigazione torna ad essere lineare dall’alto verso il basso.
ARIA Roles e HTML Semantico: Quando Usarli Insieme
ARIA — Accessible Rich Internet Applications — è un insieme di attributi che aggiungono informazioni semantiche agli elementi HTML. Tuttavia, c’è una regola fondamentale da ricordare: non usare ARIA se esiste già un tag HTML semantico equivalente.
La regola d’oro dell’ARIA
Le specifiche W3C sono esplicite: “No ARIA is better than bad ARIA”. In altre parole, aggiungere ARIA in modo errato è peggio che non usarlo affatto, perché può confondere gli screen reader e creare esperienze di navigazione incoerenti.
Considera questi esempi di uso ridondante da evitare:
html
<!-- Ridondante: il tag nav già comunica il role navigation -->
<nav role="navigation">...</nav>
<!-- Ridondante: il tag button ha già il role implicito -->
<button role="button">Invia</button>
<!-- Ridondante: main ha già il role main -->
<main role="main">...</main>In tutti questi casi, il role ARIA è superfluo. Il tag semantico lo comunica già nativamente al browser e agli screen reader.
Quando ARIA è invece necessario
Esistono tuttavia situazioni in cui ARIA è indispensabile. In particolare, i componenti interattivi complessi — quelli che non hanno un equivalente HTML nativo — richiedono ARIA per essere accessibili. Ad esempio, un tab panel personalizzato:
html
<!-- Tab panel custom: ARIA è necessario -->
<div role="tablist" aria-label="Sezioni dell'articolo">
<button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
Introduzione
</button>
<button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2">
Esempi
</button>
</div>
<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
Contenuto introduzione...
</div>
<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
Contenuto esempi...
</div>Oppure un modal dialog:
html
<!-- Modal dialog: ARIA è necessario -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
<h2 id="modal-title">Conferma eliminazione</h2>
<p>Sei sicuro di voler eliminare questo elemento?</p>
<button>Conferma</button>
<button>Annulla</button>
</div>In sintesi: usa prima i tag semantici HTML5. Aggiungi ARIA solo dove i tag nativi non arrivano, e sempre seguendo le specifiche W3C per non peggiorare l’esperienza degli utenti con screen reader.
Checklist Accessibilità HTML: 8 Regole Pratiche
Di seguito trovi le 8 regole concrete da applicare a qualsiasi progetto HTML. Ogni regola ha un impatto diretto sull’esperienza degli utenti con disabilità visive.
1. Usa sempre un solo h1 per pagina Il tag h1 deve contenere il titolo principale con la keyword primaria. Tutti gli heading successivi seguono la gerarchia: h2 per le sezioni principali, h3 per i sottoparagrafi. Non saltare livelli — passare da h2 a h4 confonde gli screen reader, che si aspettano una struttura gerarchica coerente. VoiceOver e NVDA usano questa gerarchia per costruire il sommario navigabile della pagina.
2. Aggiungi main e lo skip link Lo skip link permette agli utenti da tastiera di saltare direttamente al contenuto principale, bypassando header e navigazione. È il primo elemento della pagina e deve essere visibile quando riceve il focus:
html
<a href="#contenuto-principale" class="skip-link">Salta al contenuto</a>
<main id="contenuto-principale">...</main>Senza skip link, un utente che naviga solo con la tastiera deve premere Tab decine di volte per raggiungere il contenuto ad ogni cambio di pagina.
3. Ogni nav deve avere un aria-label Se hai più elementi nav nella pagina — menu principale, breadcrumb, paginazione — distinguili con aria-label. In caso contrario, JAWS e NVDA annunciano semplicemente “regione di navigazione” senza specificare quale, e l’utente non sa dove si trova:
html
<nav aria-label="Navigazione principale">...</nav>
<nav aria-label="Breadcrumb">...</nav>
<nav aria-label="Paginazione">...</nav>4. Le immagini decorative usano alt vuoto Le immagini puramente decorative — separatori, sfondi, icone senza significato — devono avere un attributo alt vuoto. In questo modo gli screen reader le ignorano completamente, invece di leggere il nome del file o interrompere il flusso di lettura:
html
<!-- Immagine decorativa: screen reader la salta -->
<img src="decorazione.svg" alt="">
<!-- Immagine informativa: screen reader legge l'alt -->
<img src="schema-html5.webp" alt="Schema della struttura semantica HTML5">5. I link devono descrivere la destinazione Evita anchor text generici come “clicca qui”, “leggi di più” o “scopri”. Gli utenti con screen reader spesso navigano la pagina saltando di link in link — ascoltano solo il testo del link, senza il contesto circostante. Un link generico non comunica nulla:
html
<!-- Non accessibile -->
<a href="/guida-html">Leggi di più</a>
<!-- Accessibile -->
<a href="/guida-html">Leggi la guida completa ai tag semantici HTML5</a>6. Usa button per le azioni e a per la navigazione Questa distinzione è fondamentale per la navigazione da tastiera. Il tag button è attivabile con Spazio e Invio, il tag a solo con Invio. Inoltre, gli screen reader annunciano i due elementi in modo diverso — “collegamento” per a, “pulsante” per button. Invertirli crea aspettative sbagliate nell’utente:
html
<!-- Azione (apre modal, invia form): usa button -->
<button type="button">Apri il menu</button>
<!-- Navigazione (va a un URL): usa a -->
<a href="/contatti">Vai alla pagina contatti</a>7. I form richiedono label associati Ogni campo di input deve avere una label associata tramite gli attributi for e id. Senza label, lo screen reader annuncia solo il tipo di campo — “campo di testo” — senza dire all’utente cosa deve inserire. Questo rende i form praticamente inutilizzabili:
html
<!-- Senza label: lo screen reader annuncia solo "campo di testo" -->
<input type="email" name="email" placeholder="La tua email">
<!-- Con label: lo screen reader annuncia "Indirizzo email, campo di testo" -->
<label for="email">Indirizzo email</label>
<input type="email" id="email" name="email" required>8. Usa table solo per dati tabulari, mai per il layout Le tabelle usate per il layout creano una struttura confusa per gli screen reader, che leggono il contenuto cella per cella. Per il layout usa CSS Flexbox o Grid. Quando usi tabelle per dati reali, aggiungi sempre caption e th con attributo scope:
html
<table>
<caption>Confronto tra i principali screen reader</caption>
<thead>
<tr>
<th scope="col">Software</th>
<th scope="col">Sistema operativo</th>
<th scope="col">Gratuito</th>
</tr>
</thead>
<tbody>
<tr>
<td>NVDA</td><td>Windows</td><td>Sì</td>
</tr>
<tr>
<td>JAWS</td><td>Windows</td><td>No</td>
</tr>
<tr>
<td>VoiceOver</td><td>macOS / iOS</td><td>Sì</td>
</tr>
</tbody>
</table>Conclusione
L’HTML semantico e l’accessibilità non sono due argomenti separati: sono, in realtà, due facce della stessa medaglia. Scrivere codice con i tag giusti significa, quindi, costruire pagine che funzionano per tutti — con o senza disabilità visive, con o senza mouse, su qualsiasi dispositivo e con qualsiasi tecnologia assistiva.
Applica la checklist a un tuo progetto esistente: spesso bastano pochi interventi mirati — aggiungere main, distinguere i nav con aria-label, correggere i link generici — per migliorare significativamente l’accessibilità del codice senza riscrivere nulla da zero.
Articoli correlati in questa guida:
