Controllo intestazioni WCAG

Che cos'è un controllore di intestazioni WCAG?

Un controllore di intestazioni WCAG verifica che gli elementi di intestazione su una pagina web (h1, h2, h3, h4, h5, h6) formino una gerarchia logica che i lettori di schermo e altre tecnologie assistive possono navigare. Le intestazioni sono il modo in cui gli utenti non vedenti e ipovedenti scansionano una pagina: usano una scorciatoia del lettore di schermo per saltare da intestazione a intestazione, costruendo un sommario mentale in pochi secondi. Se le intestazioni mancano, sono in ordine sbagliato o sono usate decorativamente, quella navigazione crolla. Il criterio di successo WCAG 2.2 1.3.1 (Informazioni e Relazioni) e 2.4.6 (Intestazioni ed Etichette) richiede che le intestazioni trasmettano correttamente la struttura.

Le regole sono semplici da enunciare e facili da violare. Dovrebbe esserci esattamente un h1 per pagina (il titolo della pagina). Ogni intestazione successiva dovrebbe essere al massimo un livello più profonda del suo genitore (un h2 può essere seguito da un altro h2 o da un h3, ma non direttamente da un h4). Le intestazioni non dovrebbero essere vuote. I livelli di intestazione dovrebbero descrivere la struttura del documento, non la dimensione visiva (non usare h4 solo perché vuoi un testo più piccolo). La maggior parte degli audit di accessibilità segnala i problemi di gerarchia delle intestazioni come la prima cosa da correggere perché sono comuni, facili da verificare e ad alto impatto per gli utenti di lettori di schermo.

Questo strumento analizza l'HTML che incolli (nessun caricamento, nessun round trip al server), percorre gli elementi di intestazione nell'ordine del documento e segnala i problemi: h1 mancante, h1 multipli, livelli saltati, intestazioni vuote e un outline della struttura della pagina. L'output è testo semplice che descrive ogni problema. Eseguilo su qualsiasi pagina durante lo sviluppo, prima del lancio o come parte di un ciclo regolare di audit di accessibilità. L'output è in linguaggio semplice, non un punteggio numerico; l'obiettivo è darti problemi specifici da correggere, non un voto di promozione da inseguire.

Cosa c'è dentro lo strumento

La parte superiore della pagina è una textarea dove incolli il tuo HTML. Puoi incollare un documento completo (DOCTYPE, html, head, body) o un frammento (solo il contenuto del body). Lo strumento estrae tutti gli elementi da h1 a h6 nell'ordine del documento usando un DOMParser standard del browser, quindi l'analisi corrisponde a ciò che farebbe un vero browser. La textarea gestisce input di qualsiasi dimensione; documenti molto grandi (decine di migliaia di righe) funzionano ma richiedono una frazione di secondo in più per l'analisi.

Clicca Controlla Intestazioni e i risultati appaiono sotto. La prima sezione è l'outline delle intestazioni: ogni intestazione in ordine, indentata per livello, così puoi leggere la struttura come un sommario. La seconda sezione è la lista dei problemi: ogni problema con la sua posizione specifica, cosa c'è di sbagliato e una breve spiegazione del perché conta. I problemi sono categorizzati per gravità: errori (devono essere corretti per la conformità WCAG) e avvertimenti (buona pratica ma non fallimenti rigorosi).

L'output rimane nel browser; nulla viene caricato. Puoi incollare lo stesso HTML molte volte con modifiche tra l'una e l'altra per iterare sulle correzioni. Lo strumento intenzionalmente non controlla nulla al di fuori della struttura delle intestazioni (non verifica il testo alt, il contrasto, l'ordine di focus, ARIA o qualsiasi altro criterio WCAG). Per quelli, usa questo strumento insieme a uno strumento di audit completo come axe DevTools, Lighthouse o WAVE.

Storia e contesto

Le intestazioni HTML fin dall'inizio (1991)

Tim Berners-Lee introdusse HTML nel 1991 con gli elementi da h1 a h6 come parte dei 18 tag originali. L'intento semantico originale era sempre la struttura del documento, non lo stile visivo. La gerarchia delle intestazioni del Web proviene da una tradizione molto più antica: i documenti stampati (libri, articoli, rapporti governativi) hanno usato livelli di sezione numerati per secoli per trasmettere la struttura. HTML ha ereditato direttamente quel modello. Nonostante 35 anni di semantica stabile, l'uso improprio delle intestazioni è uno dei bug di accessibilità più comuni sul web moderno perché i designer spesso applicano lo stile in base alle dimensioni visive prima e controllano la struttura dopo.

I lettori di schermo imparano a navigare per intestazione (dal 1996 in poi)

JAWS (Job Access With Speech) è stato rilasciato da Henter-Joyce nel 1989 e ha aggiunto la navigazione per intestazione delle pagine web quando il Web è diventato popolare alla fine degli anni 1990. Premere il tasto H in JAWS salta all'intestazione successiva; i tasti numerati da 1 a 6 saltano a quel livello specifico di intestazione. Ogni lettore di schermo principale da allora (NVDA nel 2006, VoiceOver nel 2005, TalkBack su Android) ha copiato questa scorciatoia. Il sondaggio annuale Screen Reader User Survey di WebAIM rileva costantemente che il 67 al 70 percento degli utenti di lettori di schermo navigano per intestazioni come metodo principale per comprendere una pagina. Una gerarchia di intestazioni rotta non è quindi un problema cosmetico.

WCAG 1.0 e l'ascesa degli standard di accessibilità (1999)

Le Web Content Accessibility Guidelines 1.0 sono state pubblicate da W3C nel maggio 1999, il primo standard internazionale per l'accessibilità Web. WCAG 1.0 richiedeva esplicitamente che le intestazioni fossero usate per la struttura del documento (Checkpoint 3.5). WCAG 2.0 (2008) ha rifinito questo nel criterio di successo 1.3.1 (Informazioni e Relazioni, Livello A) e 2.4.6 (Intestazioni ed Etichette, Livello AA). WCAG 2.1 (2018) e 2.2 (2023) hanno mantenuto questi criteri invariati perché il requisito sottostante è solido. La maggior parte delle leggi sull'accessibilità nel mondo (ADA negli USA, EAA in Europa, AODA in Ontario) ora cita WCAG 2.1 AA come la base legale.

Sezionamento HTML5 e l'outline del documento (2014)

HTML5 (Raccomandazione W3C 2014) ha introdotto elementi di sezionamento (article, section, nav, aside) e un algoritmo di outline che doveva derivare la gerarchia delle intestazioni dalla profondità di nidificazione. L'algoritmo non è mai stato implementato in alcun browser o lettore di schermo ed è stato formalmente deprecato nel 2022. La guida pratica è: usare livelli di intestazione espliciti (da h1 a h6) e trattare gli elementi di sezionamento come raggruppamento semantico, non come sostituto della profondità di intestazione. Lo HTML Living Standard ora afferma chiaramente che i livelli di intestazione devono essere impostati esplicitamente.

Ruoli ARIA e aria-level (dal 2014 in poi)

WAI-ARIA 1.1 (Raccomandazione W3C 2017) fornisce role="heading" con aria-level="N" come modo alternativo per marcare le intestazioni, utile quando non puoi usare gli elementi nativi h1-h6 (per esempio, in un componente framework che deve rendere diversi livelli di intestazione in contesti diversi). I lettori di schermo trattano role="heading" in modo identico all'elemento nativo. La migliore pratica è usare elementi nativi dove possibile; usa ARIA solo quando la semantica nativa non è disponibile. Questo strumento controlla sia gli elementi di intestazione nativi sia gli elementi con role="heading".

Cause di accessibilità e il caso aziendale (dal 2017 in poi)

Domino's Pizza v. Robles (Corte Suprema degli USA 2019) ha stabilito che l'Americans with Disabilities Act (ADA, 1990) si applica ai siti web commerciali. Centinaia di cause simili sono seguite ogni anno (oltre 4.000 cause web ADA depositate solo nel 2024). L'European Accessibility Act (EAA, in vigore da giugno 2025) rende l'accessibilità equivalente a WCAG un requisito legale per la maggior parte dei siti web rivolti ai consumatori in tutta l'UE. La struttura delle intestazioni fallita è uno dei problemi più facili da identificare e documentare per i querelanti, il che rende i controlli di base sulle intestazioni un passo di conformità ad alta leva.

Flussi pratici

Controllo pre lancio su nuove pagine e modelli

Prima che qualsiasi nuova pagina o modello venga distribuito, esegui l'HTML attraverso questo controllore. I problemi di struttura delle intestazioni sono i bug di accessibilità più facili da introdurre (specialmente nel contenuto guidato da CMS dove gli editor scelgono i livelli di intestazione in base alla dimensione visiva) e i più facili da correggere. Catturarli prima del lancio è molto più economico che dopo, quando le correzioni richiedono coordinamento con i proprietari del contenuto. Per le agenzie, costruisci questo controllo nella checklist di QA; per i team interni, eseguilo come parte del code review o prima di unire al main.

Audit di un sito esistente per la conformità all'accessibilità

Per un audit di accessibilità (pre contenzioso, conformità EAA, requisito contrattuale), esamina le pagine più trafficate ed esegui l'HTML di ciascuna attraverso questo controllore. Documenta i risultati: quali pagine hanno problemi di intestazione, di che tipo, come correggerli. Combina con axe DevTools o Lighthouse per gli altri criteri WCAG. I risultati sulla struttura delle intestazioni sono solitamente i più facili da rimediare e formano una solida sezione di vittorie rapide nel rapporto di audit.

Formazione degli editor CMS e templating

Il contenuto guidato da CMS (WordPress, Drupal, Contentful, Sanity) spesso dà agli editor un menu a tendina di intestazioni con opzioni da H1 a H6. Gli editor che non conoscono le regole scelgono i livelli in base alla dimensione visiva. Mostra questo controllore agli editor così possono vedere cosa producono le loro scelte di intestazione. Per i template, esegui l'output renderizzato attraverso il controllore dopo ogni cambio di design per confermare che le scelte di intestazione dell'editor producano ancora una gerarchia valida. Esistono molti plugin CMS che avvertono gli editor al momento della scrittura; questo strumento serve il passo di verifica.

Validare modelli email e newsletter HTML

Le email HTML lette dai lettori di schermo dovrebbero seguire la stessa gerarchia di intestazioni delle pagine web. Esegui l'HTML del tuo modello email attraverso questo controllore prima di inviarlo a una grande lista. Problemi comuni dei modelli email: h1 multipli (quando ogni sezione ha il proprio titolo), h1 mancante (quando il layout inizia direttamente con h2) e h4 decorativi usati puramente per intestazioni piccole. Correggi questi prima di inviare; gli utenti di tecnologia assistiva nella tua lista lo noteranno.

Validare le conversioni da PDF a HTML

Quando converti PDF in HTML per accessibilità (così possono essere letti dai lettori di schermo con navigazione per intestazione), il convertitore deve mappare i tag di struttura PDF ai livelli di intestazione HTML. Il risultato è spesso rotto: i PDF senza tag corretti producono HTML piatto senza intestazioni affatto, e anche i PDF taggati a volte producono output tutto h1 o tutto h2. Esegui l'HTML convertito attraverso questo controllore per individuare il problema prima di pubblicare la pagina convertita.

Onboarding di nuovi sviluppatori e designer

Gli sviluppatori frontend junior e i designer beneficiano del vedere esempi concreti di gerarchie di intestazioni rotte e l'esperienza risultante con il lettore di schermo. Abbina questo strumento a una demo del lettore di schermo (NVDA su Windows è gratuito, VoiceOver su Mac è integrato) per mostrare come le intestazioni guidano la navigazione del lettore di schermo. La connessione tra regole astratte di intestazione ed esperienza utente concreta è spesso ciò che fa rimanere la lezione.

Insidie comuni

Scegliere il livello di intestazione in base alla dimensione visiva

L'errore più comune: usare un h4 perché vuoi un testo più piccolo, o saltare da h2 a h4 perché non c'è un h3 dimensionato correttamente nel design. I livelli di intestazione sono strutturali, non visivi; usa CSS per controllare la dimensione e usa il livello che corrisponde alla gerarchia del documento. Se il tuo design system non ha uno stile visivo per ogni livello necessario, aggiungine uno (o sovrascrivilo con nomi di classe) invece di scegliere il livello sbagliato.

Più h1 per pagina

Una pagina dovrebbe avere esattamente un h1 che rappresenta il titolo della pagina. Bug comuni: un logo del sito avvolto in h1 più un titolo dell'articolo anche in h1 (due h1), una homepage con ogni sezione hero che usa h1 (h1 multipli), o nessun h1 affatto perché il layout inizia con h2. La correzione è strutturale: scegli il contenuto più importante sulla pagina come singolo h1 e retrocedi tutto il resto a h2 o sotto. Strumenti come axe e Lighthouse avvertono su h1 multipli per questo motivo.

Livelli di intestazione saltati

Andare da h2 direttamente a h4 rompe l'outline del documento. Gli utenti di lettori di schermo che si spostano da intestazione a intestazione si aspettano che ogni h4 sia nidificato sotto un h3, e l'h3 mancante confonde la struttura. La correzione è inserire il livello intermedio mancante o retrocedere l'h4 a h3. La causa più comune è copiare il design da un mockup dove la gerarchia visiva usa tre dimensioni ma il design system usa quattro livelli di intestazione; ricontrolla dopo ogni aggiornamento del componente.

Intestazioni vuote

Un h2 senza contenuto testuale (spesso perché un widget JavaScript ha rimosso il testo ma mantenuto l'elemento) appare nella lista delle intestazioni del lettore di schermo come un'intestazione senza etichetta, il che è confuso e inutile. O popola l'intestazione con testo, o rimuovi completamente l'elemento di intestazione. Questo è comune nelle app a pagina singola dove gli elementi segnaposto sono renderizzati prima del caricamento dei dati; rendi l'intestazione solo quando c'è contenuto da metterci.

Intestazioni dentro wrapper non semantici

Un'intestazione avvolta in un div con role="presentation" o aria-hidden="true" viene rimossa dall'albero dell'accessibilità, il che può nascondere un'intestazione altrimenti corretta dai lettori di schermo. Verifica gli elementi genitori di ogni intestazione per assicurarti che non rimuovano l'intestazione dall'albero dell'accessibilità. Anche CSS display:none e visibility:hidden rimuovono l'intestazione; usali solo intenzionalmente e mai su contenuto che dovrebbe essere visibile al lettore di schermo.

Usare ARIA quando l'HTML nativo basterebbe

Aggiungere role="heading" aria-level="2" a un div invece di usare un elemento h2 funziona per l'accessibilità ma è complessità inutile. Gli elementi nativi h1-h6 ottengono semantica di intestazione gratuitamente, vengono renderizzati correttamente negli stili predefiniti del browser e sopravvivono ai bug dei lettori di schermo meglio degli override ARIA. La prima regola di ARIA (secondo le WAI-ARIA Authoring Practices) è: non usare ARIA quando l'HTML nativo fornisce la stessa semantica. Usa elementi di intestazione nativi a meno che un vincolo del framework forzi davvero ARIA.

Privacy e gestione dei dati

L'HTML che incolli rimane nel tuo browser durante tutto il controllo. Il DOMParser che estrae le intestazioni gira in JavaScript sulla tua macchina; i risultati vengono renderizzati nella pagina sotto la textarea. Non c'è passo di upload, nessuna elaborazione remota e nessuna telemetria su quale HTML hai incollato. Questo conta perché l'HTML che vuoi controllare di più (template pre lancio, siti client sotto NDA, pagine admin interne) è esattamente ciò che non dovresti incollare in un validatore SaaS di terze parti.

Una volta caricata la pagina, lo strumento funziona offline. Puoi disconnetterti da internet, incollare HTML, eseguire il controllo e rivedere i risultati senza che il tuo markup tocchi mai un'altra macchina. La maggior parte dei controllori di accessibilità cloud (PowerMapper, Tenon, Site Improve) richiede di caricare l'URL della pagina o l'HTML; per pagine confidenziali quella è precisamente la modalità di fallimento da evitare.

Quando non usare questo strumento

Per audit WCAG completi (usa uno strumento completo)

La struttura delle intestazioni è uno di decine di criteri WCAG. Per un audit completo, usa axe DevTools (estensione gratuita Chrome/Firefox di Deque), Lighthouse (integrato in Chrome), WAVE (lo strumento gratuito di WebAIM), o una soluzione a pagamento come Tenon o PowerMapper. Questi controllano il contrasto dei colori, il testo alt, l'uso di ARIA, le etichette dei moduli, l'ordine di focus e molti altri. Esegui questo strumento accanto, non al posto, di quelli completi.

Per contenuto dinamico (testa il DOM renderizzato)

Se le tue intestazioni sono generate da JavaScript (React, Vue, Svelte, Angular), la sorgente HTML statica non contiene le intestazioni finali. Devi incollare il DOM renderizzato dopo che JavaScript è girato. Usa il DevTools del browser: apri la pagina, apri DevTools, scheda Elements, fai clic destro sul body o main, Copia outerHTML, poi incolla quello in questo controllore. Oppure usa un'estensione del browser che cammina direttamente sul DOM live.

Per pipeline automatizzate CI/CD (usa una libreria Node)

Se vuoi che i controlli di intestazione vengano eseguiti automaticamente su ogni commit o pull request, integra axe-core, Pa11y o jest-axe nella tua suite di test. Eseguono controlli di intestazione (e molti altri controlli WCAG) headless in CI. Questo strumento browser è per uso interattivo durante lo sviluppo e la revisione, non per l'automazione. Entrambi hanno il loro posto; usa lo strumento browser per audit one shot e la libreria CI per validazione continua.

Per l'accessibilità di documenti PDF o Word

I PDF e i documenti Word hanno i propri sistemi di tagging dell'accessibilità (PDF/UA, gli stili di intestazione di Word). Non usano intestazioni HTML, quindi questo strumento non si applica. Per l'accessibilità PDF, usa l'Accessibility Checker di Adobe Acrobat Pro o PAC 2024 (gratuito, focalizzato su PDF/UA). Per Word, usa l'Accessibility Checker integrato (scheda Review). Converti prima in HTML se vuoi usare questo strumento, ma la conversione stessa può introdurre problemi di intestazione.

Altre domande

È mai accettabile saltare un livello di intestazione?

Non nel contenuto del documento dritto. WCAG 2.2 SC 1.3.1 implica che le intestazioni dovrebbero formare una sequenza gerarchica. Il caso comune in cui sembra un salto è l'outline della pagina che inizia con h1 poi h2 all'interno dell'area di contenuto principale, mentre una barra laterale o navigazione ha anche h2; va bene perché entrambi sono fratelli sotto l'h1 della pagina. La regola effettiva è: non saltare livelli all'interno di un flusso di contenuto contiguo. Il controllore segnala solo i salti veri.

E se il mio framework supporta solo un livello di intestazione?

Alcune librerie di componenti rendono le intestazioni a un livello fisso (sempre h2, indipendentemente dalla nidificazione). La correzione è esporre una prop di livello sul componente di intestazione (h2, h3, ecc.) e fare in modo che i genitori passino il valore appropriato. Framework come React lo fanno comunemente; se il tuo no, aggiungi un aria-level sul componente e usa role="heading" come workaround temporaneo finché non puoi refactorizzare. A lungo termine, ogni componente di intestazione riutilizzabile dovrebbe accettare una prop di livello.

Lo strumento controlla i ruoli ARIA come role="heading"?

Sì. Qualsiasi elemento con role="heading" e un attributo aria-level valido (da 1 a 6) è trattato come un'intestazione al livello indicato. Gli elementi nativi h1-h6 sono sempre preferiti, ma le intestazioni marcate ARIA sono altrettanto valide per i lettori di schermo e vengono controllate insieme a quelle native.

Quanto è importante la gerarchia delle intestazioni rispetto ad altri criteri WCAG?

Molto. Il sondaggio annuale Screen Reader User Survey di WebAIM rileva costantemente che il 67-70% degli utenti di lettori di schermo navigano per intestazioni come modo principale per comprendere una pagina. Intestazioni cattive bloccano effettivamente uno dei principali metodi di navigazione per l'accessibilità. Nell'analisi annuale WebAIM Million di WebAIM, i problemi di intestazione sono tra i primi cinque fallimenti di accessibilità più comuni sul web. La combinazione di alto impatto sull'utente e facile rilevamento li rende una priorità assoluta.

Ogni pagina dovrebbe avere un h1?

Sì, con rare eccezioni. Ogni documento HTML completo dovrebbe avere esattamente un h1 che rappresenta il titolo della pagina. L'eccezione sono i frammenti che vengono esplicitamente inseriti in una pagina più grande (una firma email, un widget incorporato in un'altra pagina); la pagina ospite fornisce l'h1 e il frammento inizia con h2 o inferiore. Per pagine autonome, h1 mancante è un chiaro fallimento di accessibilità.

Posso fidarmi di questo strumento per audit di conformità legale?

Per la struttura specifica delle intestazioni, sì: le regole sono precise e lo strumento le implementa accuratamente. Per la conformità WCAG complessiva, nessuno strumento automatizzato singolo è sufficiente; il test manuale con tecnologia assistiva, la revisione di esperti e il test utente con utenti disabili sono richiesti per audit di qualità legale. Usa questo strumento come uno di diversi input per il tuo audit, non come unica fonte di verità per la conformità.