WCAG 2.4.6: Intestazioni ed etichette

Cosa Significa Questa Regola

WCAG 2.4.6 afferma: "Headings and labels describe topic or purpose." In sostanza, questo criterio richiede che qualsiasi intestazione (<h1> fino a <h6>) o etichetta (<label>, aria-label, aria-labelledby) presente in una pagina sia sufficientemente descrittiva da comunicare l’argomento del contenuto che introduce o lo scopo del controllo che identifica.

Questo criterio non richiede che intestazioni o etichette siano presenti — tale obbligo è coperto da altri criteri di successo come 1.3.1 (Info and Relationships) e 2.4.2 (Page Titled). Ciò che 2.4.6 disciplina è la qualità delle intestazioni e delle etichette già esistenti: quando ci sono, devono essere significative. Un’intestazione che recita "Section 1" o un’etichetta che recita "Field" non dice nulla di utile agli utenti sul contenuto che segue o sull’input che descrive. Al contrario, "Your Shipping Address" o "Monthly Budget Summary" orientano immediatamente gli utenti.

Le etichette in questo contesto includono non solo l’elemento HTML <label> associato ai controlli di un form, ma anche qualsiasi meccanismo di etichettatura programmatica: aria-label, aria-labelledby, l’attributo title quando usato come nome accessibile, e l’elemento legend per i fieldset. Qualsiasi di questi che sia esposto alle tecnologie assistive deve descrivere chiaramente lo scopo del controllo associato.

Si verifica un errore quando un’intestazione o un’etichetta è talmente generica, ambigua o poco informativa che l’utente non può determinare di cosa tratti la sezione o il controllo senza leggere il contesto circostante. Ad esempio, un form con tre campi di input tutti etichettati "Enter here" non soddisfa questo criterio, così come una pagina che utilizza intestazioni ripetute come "More Info" per ogni sottosezione. Allo stesso modo, un’intestazione tecnicamente presente nel DOM ma completamente fuorviante per l’utente — come etichettare una sezione del form di contatto con un’intestazione che dice "News and Updates" — costituisce anch’essa un errore.

Esiste un’importante eccezione ufficiale: WCAG 2.4.6 si applica solo quando intestazioni ed etichette vengono usate. Se una pagina non ha legittimamente intestazioni (per esempio, un documento molto breve con un solo argomento) o un controllo di form che non ha un’etichetta visibile o programmatica (che verrebbe rilevato invece da 1.3.1), 2.4.6 in sé non si applica. L’ambito del criterio riguarda strettamente la descrittività, non la presenza.

Perché È Importante

Intestazioni ed etichette descrittive avvantaggiano un pubblico sorprendentemente ampio, ma l’impatto è particolarmente forte per le persone con disabilità che si affidano alla struttura per navigare.

Gli utenti di screen reader — principalmente persone cieche o con grave ipovisione — navigano abitualmente le pagine saltando da un’intestazione all’altra usando tasti di scelta rapida (H in NVDA/JAWS, il Rotor in VoiceOver). Se le intestazioni sono vaghe o fuorvianti, questa strategia di navigazione si rompe completamente. Una persona cieca che accede a un portale di servizi governativi che usa "Section A", "Section B" e "Section C" come intestazioni deve leggere ogni parola di ogni sezione in sequenza per trovare ciò di cui ha bisogno, eliminando il vantaggio di efficienza che le intestazioni dovrebbero fornire. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno una qualche forma di deficit visivo, il che rappresenta una popolazione globale considerevole.

Le persone con disabilità cognitive, incluse quelle con disturbi dell’attenzione, deficit di memoria o disturbi dell’apprendimento, dipendono fortemente da etichette e intestazioni chiare e prevedibili per ridurre il carico cognitivo. Quando un campo di un form è etichettato solo "Name" su una pagina che raccoglie sia il nome dell’azienda sia il nome della persona di contatto, un utente con disabilità cognitive potrebbe non riuscire a risolvere l’ambiguità dal solo contesto, con conseguenti errori e frustrazione.

Gli utenti con disabilità motorie che si affidano a sistemi di accesso a scansione, software di eye-tracking o controllo vocale (come Dragon NaturallySpeaking) traggono beneficio da etichette descrittive perché possono attivare un campo specifico del form pronunciando il nome dell’etichetta. Se più campi condividono lo stesso testo di etichetta, il software di controllo vocale non può disambiguarli, costringendo l’utente a passaggi aggiuntivi fisicamente gravosi.

Consideriamo uno scenario reale: una persona che usa uno screen reader visita una pagina di checkout di un sito di e-commerce. La pagina contiene tre sezioni di indirizzo — fatturazione, spedizione e indirizzo del destinatario del regalo — ma ogni sezione usa la stessa intestazione generica "Address" e ogni gruppo di campi usa le stesse etichette: "Street", "City", "Postal Code". Senza intestazioni ed etichette univoche e descrittive, l’utente dello screen reader non può determinare quale gruppo di campi stia compilando, aumentando drasticamente il rischio di errori nell’ordine e la probabilità di abbandonare completamente l’acquisto.

Oltre all’accessibilità, intestazioni descrittive forniscono un notevole valore SEO. I motori di ricerca usano la struttura delle intestazioni come un segnale forte per comprendere il contenuto della pagina e abbinarlo alle query degli utenti. Intestazioni significative aiutano i motori di ricerca a indicizzare le pagine in modo più accurato e possono migliorare i tassi di clic nei risultati di ricerca, dove le intestazioni vengono spesso mostrate come testo di anteprima. Questo allinea direttamente gli incentivi di business con i requisiti di accessibilità.

Regole Axe-core Correlate

WCAG 2.4.6 richiede test manuali perché nessuno strumento automatico può determinare in modo affidabile se un’intestazione o un’etichetta è descrittiva. La descrittività è un giudizio semantico e contestuale — un’intestazione che recita "Products" può essere perfettamente descrittiva in una pagina e completamente ambigua in un’altra. Gli scanner automatici possono rilevare la presenza o l’assenza di intestazioni ed etichette, ma non possono valutare se il testo di tali intestazioni ed etichette sia significativo senza l’interpretazione umana.

• Revisione manuale del testo delle intestazioni: Axe-core segnalerà intestazioni mancanti o nidificazione impropria (tramite regole come heading-order), ma non può segnalare un’intestazione che dice "Click Here" o "Untitled Section" come violazione di 2.4.6. Un tester umano deve leggere ogni intestazione isolatamente — come la incontrerebbe un utente di screen reader navigando per intestazioni — e valutare se comunichi l’argomento del contenuto sottostante.
• Revisione manuale del testo delle etichette dei form: La regola label di axe-core verifica che ogni input di un form abbia un’etichetta associata, ma non valuta se il testo di tale etichetta sia descrittivo. Un elemento label che contiene solo un carattere segnaposto, un’icona o una parola generica come "Input" supererà i controlli automatici pur non soddisfacendo 2.4.6. La revisione manuale richiede di leggere ogni etichetta e confermare che descriva accuratamente lo scopo del controllo associato.
• Revisione manuale dei valori di aria-label e aria-labelledby: Allo stesso modo, la famiglia di regole aria-label-is-accessible di axe-core conferma che le etichette ARIA siano sintatticamente valide e che gli elementi referenziati esistano, ma non valuta se il testo dell’etichetta sia semanticamente significativo o descrittivo dello scopo del controllo.
• Rilevamento di etichette duplicate: Sebbene alcuni strumenti possano segnalare testo di etichetta duplicato in una pagina, non possono determinare se la duplicazione sia intenzionale e appropriata (due campi con lo stesso scopo in righe diverse di una tabella) o un reale fallimento di descrittività in cui più controlli distinti condividono un’etichetta ambigua. È necessaria una revisione manuale per fare questa distinzione.

Come Eseguire i Test

1. Esegui prima una scansione automatizzata: Usa axe DevTools (estensione del browser) o Lighthouse in Chrome DevTools per identificare eventuali problemi strutturali di intestazioni o etichette che gli strumenti automatici possono rilevare, come etichette mancanti, livelli di intestazione saltati o elementi di intestazione vuoti. Sebbene questi non siano violazioni dirette di 2.4.6, indicano aree da esaminare più attentamente durante la revisione manuale. Annota ogni intestazione e controllo etichettato segnalato o identificato nel report.
2. Estrai l’elenco delle intestazioni: Usa un’estensione del browser come HeadingsMap (disponibile per Firefox e Chrome) o lo strumento WAVE per generare un elenco piatto di tutte le intestazioni della pagina, prive del contenuto circostante. Leggi questo elenco come se fosse un indice. Chiediti: un utente potrebbe comprendere la struttura e gli argomenti principali di questa pagina dalle sole intestazioni, senza leggere il testo del corpo? Se un’intestazione è ambigua o poco informativa presa isolatamente, si tratta di un errore rispetto a 2.4.6.
3. Testa con NVDA e Firefox: Apri la pagina e premi H per navigare da un’intestazione all’altra. Ascolta l’annuncio di ogni intestazione e valuta se descrive il contenuto che segue. Poi premi F per scorrere i campi del form e ascolta l’etichetta annunciata per ogni input. Registra qualsiasi intestazione o etichetta che non descriva chiaramente il proprio argomento o scopo.
4. Testa con VoiceOver e Safari (macOS/iOS): Usa il Web Rotor (VO+U) per aprire l’elenco delle Intestazioni e l’elenco dei Controlli del form. Naviga in ciascun elenco e valuta la descrittività di ogni voce indipendentemente dal contesto della pagina. Su iOS, usa uno swipe con tre dita per navigare per intestazioni nel Rotor.
5. Testa con JAWS e Chrome: Premi H per navigare tra le intestazioni e usa la Forms Mode (F) per spostarti tra i controlli del form. Usa la finestra List of Headings di JAWS (Insert+F6) per visualizzare tutte le intestazioni in un elenco piatto, che replica il modo in cui un utente di screen reader scandirebbe la struttura della pagina.
6. Valuta le etichette dei form in isolamento: Per ogni controllo di form, copri o ignora tutto il contesto circostante e leggi solo l’etichetta programmatica (testo dell’etichetta visibile, aria-label o elemento target di aria-labelledby). Conferma che la sola etichetta sia sufficiente per capire quali informazioni inserire o quale azione esegua il controllo.
7. Verifica la presenza di testo di intestazione o etichetta duplicato: Cerca nella pagina testo di intestazione ripetuto (ad esempio, più intestazioni "Read More" o più sezioni "Learn More"). Se lo stesso testo viene usato per intestazioni o etichette che si riferiscono a argomenti o controlli diversi, si tratta di una violazione di 2.4.6.

Come Correggere

Intestazioni di Sezione Generiche — Errato

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Intestazioni di Sezione Generiche — Corretto

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Etichette di Form Ambigue — Errato

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Etichette di Form Ambigue — Corretto

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Etichetta ARIA Non Descrittiva su Pulsante Icona — Errato

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Etichetta ARIA Non Descrittiva su Pulsante Icona — Corretto

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Intestazioni o Link "Read More" Ripetuti — Errato

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Intestazioni o Link "Read More" Ripetuti — Corretto

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Errori Comuni

• Usare intestazioni posizionali o ordinali come "Step 1", "Step 2", "Section A" senza alcun testo descrittivo: queste intestazioni indicano all’utente solo dove si trova in una sequenza, non di cosa tratti la sezione. Combina sempre gli indicatori di sequenza con un sintagma nominale descrittivo, ad esempio "Step 2: Verify Your Email Address".
• Dare a tutte le card o ai componenti articolo in una pagina di elenco lo stesso testo di intestazione (ad esempio, ogni scheda prodotto ha un <h3> che dice solo "Product"): ogni intestazione di card deve identificare in modo univoco quello specifico prodotto, post del blog o elemento.
• Usare il testo segnaposto come etichetta accessibile per un input di form (affidandosi all’attributo placeholder invece di un elemento <label> o di aria-label): i placeholder scompaiono all’inserimento e non vengono annunciati in modo affidabile da tutti gli screen reader come nomi accessibili. Anche quando esiste un placeholder, è necessaria un’etichetta descrittiva separata.
• Scrivere un aria-label che si limita a ripetere il tipo di elemento invece del suo scopo, come aria-label='input' su un campo di testo o aria-label='button' su un pulsante: l’etichetta deve descrivere cosa fa il controllo o quale valore raccoglie, non che tipo di elemento sia.
• Usare il testo di tooltip o l’attributo title come unica etichetta per un controllo di form e presumere che ciò soddisfi 2.4.6: le etichette basate su title sono spesso inaccessibili agli utenti che usano solo la tastiera e non vengono annunciate in modo coerente dagli screen reader. Affidati invece a elementi <label> visibili o a aria-label.
• Etichettare i campi di ricerca con il solo "Search" in una pagina in cui esistono più ambiti di ricerca (ad esempio, ricerca su tutto il sito e ricerca all’interno di una tabella di dati): quando due controlli eseguono ricerche diverse, ciascuna etichetta deve specificare l’ambito, come "Search all products" e "Search within order history".
• Applicare la stessa intestazione a una finestra modale e all’intestazione principale della pagina: le intestazioni delle modali dovrebbero descrivere il compito specifico o il contenuto della finestra di dialogo (ad esempio, "Confirm Your Cancellation") invece di ereditare il titolo della pagina, che sarebbe fonte di confusione per gli utenti di screen reader che navigano all’interno della modale.
• Omettere un <legend> descrittivo per gruppi di pulsanti di opzione o checkbox pur fornendo etichette per le singole opzioni: il <legend> fornisce un contesto essenziale che rende significativa ogni etichetta individuale. "Yes" e "No" come etichette di opzione isolate sono poco informative senza una legend come "Do you agree to the terms and conditions?".
• Troncare il testo dell’intestazione nel DOM per motivi di design visivo (ad esempio, un’intestazione che contiene solo un’icona o una singola parola perché il testo completo è in elementi visivi adiacenti): l’intestazione programmatica deve essere completamente descrittiva perché gli utenti di screen reader la ascoltano senza vedere il layout visivo circostante.
• Presumere che, poiché un’etichetta è visibile agli utenti vedenti, sia quindi sufficientemente descrittiva per tutti: un’etichetta che si basa sulla posizione spaziale (ad esempio, un’intestazione di colonna in una griglia personalizzata in cui il significato dell’etichetta dipende dal vedere la sua relazione con le celle circostanti) può essere visivamente chiara ma non trasmettere le stesse informazioni a livello programmatico. Verifica sempre che il solo nome accessibile sia sufficiente.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce obblighi vincolanti in materia di accessibilità digitale per un’ampia gamma di soggetti pubblici e privati che operano in Turchia. La Circolare fa esplicito riferimento a WCAG 2.1 Livello AA come standard tecnico per la conformità, e i requisiti di Livello AA secondo WCAG 2.2 — che è retrocompatibile con WCAG 2.1 a livello AA — sono fortemente incoraggiati e richiesti per i soggetti che intendono ottenere il Logo di Accessibilità (Erişilebilirlik Logosu) ufficiale rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 è un criterio di Livello AA, il che significa che rientra pienamente nell’ambito di ciò che i soggetti interessati devono affrontare per raggiungere la piena conformità. I seguenti tipi di soggetti sono coperti dalla Circolare Presidenziale: istituzioni pubbliche e agenzie governative; piattaforme di e-commerce; banche e istituzioni finanziarie; ospedali e fornitori di servizi sanitari; operatori di telecomunicazioni con 200.000 o più abbonati; agenzie di viaggio; aziende di trasporto private; e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (Millî Eğitim Bakanlığı).

Per questi soggetti, non fornire intestazioni ed etichette descrittive comporta un rischio normativo concreto. Un portale governativo con intestazioni di sezione vaghe ostacola l’accesso ai servizi pubblici da parte dei cittadini con disabilità, in conflitto diretto con l’obiettivo dichiarato della Circolare di garantire pari accesso. Un sito di e-commerce con etichette ambigue nei form del flusso di checkout può impedire alle persone con disabilità visive o cognitive di completare gli acquisti, costituendo una barriera alla partecipazione economica che la Circolare mira a eliminare.

I soggetti che intendono ottenere l’Erişilebilirlik Logosu devono dimostrare la conformità tramite una verifica di accessibilità, e 2.4.6 è tra i criteri che i valutatori esamineranno manualmente. Poiché questo criterio richiede un giudizio umano — gli strumenti automatici non possono valutare la descrittività — le organizzazioni dovrebbero includere una revisione manuale strutturata di tutte le intestazioni e le etichette dei form come parte standard del loro processo di audit di accessibilità. Integrare questa revisione nei flussi di lavoro di gestione dei contenuti e nei design system, invece di trattarla come un’attività di audit una tantum, è la strategia più efficace per mantenere la conformità nel tempo man mano che i contenuti cambiano.