WCAG 1.3.1: Informazioni e relazioni

Cosa Significa Questa Regola

WCAG 1.3.1 — Info and Relationships è un criterio di Livello A sotto il principio Perceivable. Il suo requisito centrale è semplice ma di ampia portata: qualsiasi informazione o relazione comunicata visivamente deve essere espressa anche in un modo che le tecnologie assistive possano rilevare e trasmettere agli utenti. Se il tuo design utilizza segnali visivi — rientri per implicare un elenco, testo in grassetto per indicare un campo obbligatorio, colore per indicare un errore o dimensione per denotare un’intestazione — le stesse semantiche devono esistere nel codice sottostante.

Il criterio si applica a tre categorie di significato che i contenuti web trasmettono regolarmente attraverso la presentazione:

• Informazioni — fatti o dati comunicati nella pagina, come quali campi del modulo sono obbligatori o quali celle di una tabella condividono una relazione.
• Struttura — lo schema organizzativo del contenuto, come le gerarchie di intestazioni, gli elenchi ordinati o non ordinati e le tabelle di dati.
• Relazioni — associazioni tra elementi, come un’etichetta e il relativo input, un’intestazione di tabella e le sue celle di dati, o un termine e la sua definizione.

Una pagina soddisfa il criterio 1.3.1 quando ogni informazione strutturale o relazionale disponibile a un utente vedente è codificata in HTML semantico valido o esposta tramite un ruolo, una proprietà o uno stato ARIA corretto che le tecnologie assistive possono interpretare. Una pagina non lo soddisfa quando la struttura visiva esiste solo in CSS o immagini, o quando il markup ARIA contraddice o è assente dalla struttura DOM presentata.

Le eccezioni ufficiali sono minime. Il criterio non richiede che ogni decorazione visiva abbia un significato semantico — una formattazione puramente estetica come un bordo decorativo o un colore di sfondo non necessita di un equivalente programmatico. Tuttavia, qualsiasi formattazione che un utente potrebbe ragionevolmente interpretare come portatrice di significato (asterischi per indicare campi obbligatori, termini in grassetto in un glossario, passaggi numerati) deve avere una corrispondente espressione programmatica.

Perché È Importante

Informazioni e relazioni sono alla base di quasi ogni interazione che un utente ha con una pagina web. Quando tale struttura è racchiusa esclusivamente nella presentazione visiva, una parte significativa della popolazione è di fatto esclusa dalla comprensione del contenuto.

Gli utenti di screen reader — tipicamente persone cieche o ipovedenti — navigano le pagine interrogando l’albero di accessibilità, che è costruito da HTML semantico e ARIA. Quando uno sviluppatore usa un <div> stilizzato per sembrare un’intestazione invece di un vero <h2>, un utente di screen reader che salta tra le intestazioni con il tasto H lo salterà completamente. Potrebbe non trovare mai la sezione che introduce. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo vivono con qualche forma di compromissione visiva, e decine di milioni si affidano quotidianamente agli screen reader.

Gli utenti con disabilità cognitive traggono altrettanto beneficio da una struttura chiara. Intestazioni correttamente annidate, markup di elenco significativo e controlli di modulo etichettati riducono il carico cognitivo fornendo schemi prevedibili. Uno screen reader che annuncia "intestazione livello 2, Prodotti" seguita da "intestazione livello 3, Laptop" fornisce una mappa cognitiva della pagina. Un muro uniforme di testo stilizzato senza ancore strutturali è disorientante per tutti, ma soprattutto per gli utenti con difficoltà di attenzione o di memoria.

Gli utenti con disabilità motorie che si affidano alla navigazione da tastiera, all’accesso tramite switch o a software di controllo vocale dipendono anch’essi dalla struttura programmatica. Il software di controllo vocale come Dragon NaturallySpeaking genera bersagli cliccabili a partire da nomi accessibili derivati da etichette e ruoli — gli input di modulo senza etichette associate non possono essere presi di mira in modo affidabile tramite comandi vocali.

Considera uno scenario concreto: un portale pazienti di un ospedale mostra una tabella di appuntamenti imminenti. La tabella utilizza allineamento visivo e colore di sfondo per associare date e medici, ma gli elementi <th> non hanno attributi scope e le celle di dati non fanno riferimento alle intestazioni. Un utente cieco con uno screen reader sente valori di celle isolati — "9:00 AM", "Dr. Ayşe Kaya", "Cardiology" — senza alcun modo di sapere quale valore appartiene a quale colonna. Potrebbe interpretare male l’orario dell’appuntamento o presentarsi nel reparto sbagliato. Un uso corretto di scope='col' sulle intestazioni e degli attributi headers sulle celle avrebbe reso udibili le relazioni.

Oltre all’accessibilità, l’HTML strutturale ha un valore SEO significativo. I crawler dei motori di ricerca utilizzano le gerarchie di intestazioni per comprendere gli argomenti della pagina, il markup degli elenchi per identificare contenuti enumerati e le associazioni tra etichette e campi per comprendere lo scopo dei moduli. Una pagina che soddisfa il criterio 1.3.1 è quasi sempre una pagina che i motori di ricerca possono analizzare e indicizzare in modo più accurato.

Regole Axe-core Correlate

Le seguenti regole di axe-core corrispondono direttamente a violazioni di WCAG 1.3.1. Ogni regola prende di mira un aspetto specifico della struttura o delle relazioni programmatiche:

• aria-required-children — Verifica che gli elementi con determinati ruoli ARIA contengano i ruoli figli richiesti. Ad esempio, un role='list' deve contenere figli con role='listitem'. Senza la corretta struttura figlio, la relazione tra un contenitore e i suoi elementi è interrotta per le tecnologie assistive.
• aria-required-parent — L’inverso della precedente: verifica che gli elementi con ruoli che richiedono un contesto genitore specifico abbiano effettivamente quel genitore. Un role='listitem' che non si trova all’interno di un role='list' o di un <ul>/<ol> viene segnalato perché manca il contesto relazionale.
• aria-roles — Valida che tutti i valori dell’attributo role siano ruoli ARIA validi. Un ruolo non valido o scritto in modo errato (ad esempio, role='heading' invece di usare un elemento di intestazione, o un ruolo completamente inventato) significa che la tecnologia assistiva non riceve informazioni utili e può ignorare completamente l’elemento.
• definition-list — Verifica che gli elementi <dl> contengano solo figli consentiti: <dt>, <dd>, <div>, <script> e <template>. Inserire altri elementi come <p> direttamente all’interno di un <dl> invalida la struttura di relazione termine-definizione.
• dlitem — Verifica che gli elementi <dt> e <dd> siano usati solo all’interno di elementi <dl>. Usare questi elementi al di fuori del contesto genitore richiesto distrugge il significato semantico della coppia termine-definizione.
• heading-order — Segnala i livelli di intestazione che vengono saltati nella struttura del documento (ad esempio, passare da <h2> a <h4>). Pur non essendo sempre un errore rigoroso, saltare livelli fuorvia le tecnologie assistive sulla struttura gerarchica della pagina e confonde gli utenti che navigano tramite intestazioni.
• label — Verifica che ogni input di modulo abbia un’etichetta associata in modo programmatico, tramite <label for='...'>, aria-label, aria-labelledby o un elemento <label> che lo racchiude. Un input senza un’etichetta accessibile nega agli utenti ciechi e a quelli che usano il controllo vocale le informazioni necessarie per capire cosa inserire.
• list — Garantisce che gli elementi <ul> e <ol> contengano solo elementi <li> come figli diretti (oltre a <script> e <template>). Elementi figli non validi interrompono la struttura dell’elenco che gli screen reader usano per annunciare il numero di elementi e le posizioni.
• listitem — Verifica che gli elementi <li> siano usati solo all’interno di contenitori <ul>, <ol> o role='list'. Gli elementi di elenco orfani perdono completamente il loro significato semantico.
• scope-attr-valid — Valida che l’attributo scope sugli elementi <th> contenga solo i valori consentiti: col, row, colgroup o rowgroup. Un valore di scope non valido o assente in una tabella di dati complessa significa che gli screen reader non possono annunciare in modo affidabile quale intestazione si applica a una determinata cella di dati.
• td-headers-attr — Verifica che, quando le celle di dati usano l’attributo headers, ogni ID referenziato esista effettivamente nella stessa tabella e appartenga a una cella di intestazione. Riferimenti interrotti o mancanti recidono la relazione programmatica tra i dati e la loro intestazione descrittiva, lasciando gli utenti di screen reader senza contesto.

Nota che strumenti automatici come axe-core non possono rilevare ogni violazione del criterio 1.3.1. Ad esempio, uno sviluppatore potrebbe usare un <div> stilizzato visivamente con role='list' e figli correttamente strutturati con role='listitem' — axe lo considererà conforme — ma un tester umano potrebbe scoprire che il rientro visivo implica un sottoelenco annidato che non è rappresentato nella struttura ARIA. Ogni volta che la gerarchia visiva è complessa, l’ispezione manuale e i test con screen reader sono complementi essenziali alla scansione automatizzata.

Come Testare

1. Scansione automatizzata con axe DevTools o Lighthouse: Installa l’estensione browser axe DevTools (Chrome o Firefox). Apri la pagina da testare, apri DevTools, vai alla scheda axe ed esegui una scansione dell’intera pagina. Filtra i risultati per il tag wcag131 o rivedi tutti i problemi etichettati sotto "Info and Relationships". Cerca in particolare violazioni delle undici regole axe elencate sopra. In Lighthouse (pannello Audits di Chrome DevTools), esegui un audit di accessibilità e controlla la categoria "Accessibility" per errori relativi all’ordine delle intestazioni, alle etichette e agli elenchi. Annota tutti gli elementi segnalati e i loro selettori DOM per la correzione.
2. Revisione manuale della struttura delle intestazioni: Usa l’estensione browser HeadingsMap o il pannello "Headings" in axe DevTools per visualizzare la struttura completa delle intestazioni della pagina. Verifica che la struttura sia logica e gerarchica — dovrebbe leggere come un indice ben strutturato. Conferma che nessun livello di intestazione sia saltato e che il testo delle intestazioni sia significativo e non solo stile visivo applicato a elementi che non sono intestazioni.
3. Verifica delle etichette dei moduli: Spostati con il tasto Tab attraverso ogni elemento interattivo del modulo nella pagina. Per ogni input, select e textarea, conferma che sia presente un’etichetta visibile e che sia associata in modo programmatico (controlla l’elemento in DevTools e cerca una coppia for/id corrispondente, o un aria-label/aria-labelledby). Usa l’albero di accessibilità in Chrome DevTools (pannello Elements → scheda Accessibility) per confermare il nome accessibile calcolato per ciascun controllo.
4. Test con screen reader usando NVDA + Firefox: Avvia NVDA e apri la pagina in Firefox. Premi H per scorrere le intestazioni e verifica che i livelli di intestazione annunciati corrispondano alla gerarchia visiva. Premi F per spostarti tra i campi del modulo e conferma che l’etichetta di ciascun campo venga annunciata. Premi T per navigare tra le tabelle e spostati con le frecce tra le celle, ascoltando gli annunci delle intestazioni. Premi L per scorrere gli elenchi e conferma che venga annunciato il numero di elementi.
5. Test con screen reader usando VoiceOver + Safari (macOS/iOS): Abilita VoiceOver (Cmd+F5 su macOS). Apri il Rotor (Ctrl+Option+U) e ispeziona Intestazioni, Link, Controlli modulo e Tabelle. Conferma che tutti gli elementi strutturali compaiano nel Rotor e che i nomi annunciati siano significativi e accurati.
6. Test con screen reader usando JAWS + Chrome: Apri JAWS e la pagina in Chrome. Usa l’elenco delle intestazioni di JAWS (Insert+F6) per rivedere la struttura delle intestazioni. Usa Insert+F5 per i campi del modulo per verificare le associazioni delle etichette. Naviga nelle tabelle con i tasti freccia e conferma che JAWS annunci le intestazioni di colonna e di riga per ogni cella di dati.
7. Verifica delle relazioni nelle intestazioni delle tabelle: Identifica tutte le tabelle di dati nella pagina. Per le tabelle semplici, verifica che gli elementi <th> abbiano attributi scope appropriati. Per le tabelle complesse con intestazioni multilivello, verifica che le celle di dati usino l’attributo headers che fa riferimento ai corretti valori id. Traccia visivamente ogni cella fino alle sue logiche intestazioni di riga e colonna, quindi conferma che lo stesso percorso sia rappresentato nel codice.

Come Correggere

Intestazioni visive implementate come div stilizzati — Non corretto

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Intestazioni visive implementate come div stilizzati — Corretto

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Campo di input senza etichetta associata — Non corretto

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Campo di input senza etichetta associata — Corretto

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Tabella di dati senza attributi scope — Non corretto

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Tabella di dati senza attributi scope — Corretto

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Elementi di elenco usati fuori da un contenitore di elenco — Non corretto

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Elementi di elenco usati fuori da un contenitore di elenco — Corretto

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Errori Comuni

• Usare solo le proprietà CSS font-size e font-weight per creare l’aspetto visivo delle intestazioni su elementi <div> o <span>, senza aggiungere mai role='heading' e aria-level o senza convertirli in veri elementi <h1>–<h6> — gli screen reader non possono riconoscerli come intestazioni navigabili.
• Usare il testo del placeholder come unica etichetta per gli input dei moduli, il che fa sì che l’etichetta scompaia non appena l’utente inizia a digitare, lasciando il campo senza etichetta per tutta la durata dell’inserimento — associa sempre gli input a un elemento <label> persistente.
• Contrassegnare i campi obbligatori con un asterisco rosso (*) spiegato solo in una legenda visiva in cima al modulo, senza aggiungere aria-required='true' o includere "required" nell’etichetta programmatica, così che gli utenti di screen reader ricevano la stessa informazione.
• Applicare list-style: none tramite CSS a un <ul> senza capire che alcuni screen reader (in particolare Safari + VoiceOver) potrebbero smettere di annunciare l’elemento come elenco — se la semantica dell’elenco è significativa, aggiungi esplicitamente role='list' per preservarla.
• Saltare livelli di intestazione — ad esempio, inserire un <h4> direttamente dopo un <h2> perché il designer voleva un testo più piccolo — invece di usare il livello di intestazione corretto e controllare l’aspetto visivo tramite CSS.
• Costruire tabelle di dati complesse con celle unite (colspan/rowspan) senza aggiungere l’attributo headers alle celle di dati, lasciando gli utenti di screen reader incapaci di determinare quale intestazione governa una cella unita ambigua.
• Usare elementi <table> per scopi di layout e poi aggiungere role='presentation' in modo incoerente — alcune celle contengono ancora intestazioni che vengono annunciate fuori contesto, confondendo gli utenti che non possono vedere che la tabella è puramente decorativa.
• Racchiudere una coppia <dt>/<dd> all’interno di un <p> o <div> che è figlio diretto di un <dl> senza capire che in HTML5 solo i wrapper <div> sono consentiti all’interno di <dl> e che mescolare altri elementi a blocco distrugge la struttura dell’elenco di definizioni.
• Aggiungere aria-labelledby a un input che fa riferimento a un ID inesistente nel DOM, o che fa riferimento all’ID di un elemento non testuale — il nome accessibile calcolato diventa vuoto e l’input è di fatto senza etichetta per le tecnologie assistive.
• Dare per scontato che, poiché una pagina appare corretta visivamente e ottiene un punteggio Lighthouse superiore a 90, sia conforme al criterio 1.3.1 — gli strumenti automatici non possono rilevare ogni violazione strutturale, come relazioni di annidamento visivo che non sono riflesse nella gerarchia dei ruoli ARIA, rendendo obbligatorie la verifica manuale e quella con screen reader.

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à web allineati a WCAG 2.2 per un’ampia gamma di soggetti che operano in Turchia. WCAG 1.3.1 è un criterio di Livello A, il che significa che si colloca al livello fondamentale di conformità — il livello minimo accettabile di accessibilità — ed è quindi pienamente obbligatorio per tutti i soggetti coperti dalla circolare.

La circolare definisce due tempistiche di conformità. Le istituzioni pubbliche — inclusi gli organi di governo centrale, i comuni, le università statali e gli ospedali pubblici — devono raggiungere la piena conformità al Livello A entro un anno dall’entrata in vigore della circolare. I soggetti del settore privato coperti dal regolamento hanno una finestra di due anni per conformarsi. Tuttavia, l’obbligo non è facoltativo per nessuno dei due gruppi: la mancata conformità espone i soggetti interessati a controlli regolatori e a potenziali azioni esecutive.

I soggetti del settore privato esplicitamente coperti dalla circolare includono piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari privati, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio autorizzate, società di trasporto private e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE). Qualsiasi di questi soggetti che gestisca un sito web rivolto al pubblico o un’applicazione web mobile deve garantire che il criterio 1.3.1 sia soddisfatto in tutte le proprie proprietà digitali.

Ai fini della conformità pratica, il criterio 1.3.1 è uno dei più incisivi tra quelli di Livello A perché governa la struttura fondamentale della pagina. Un sito di e-commerce turco le cui pagine di categoria prodotto usano elementi <div> stilizzati per le intestazioni, i cui campi del modulo di checkout non hanno associazioni con etichette o il cui riepilogo d’ordine è una tabella non strutturata senza attributi scope non soddisferebbe in modo completo il criterio 1.3.1. La correzione non è solo un obbligo legale — migliora direttamente l’esperienza per le stime 700,000 o più persone cieche e ipovedenti in Turchia che si affidano alle tecnologie assistive per fare acquisti, operare con le banche, accedere all’assistenza sanitaria e interagire con i servizi governativi online.

Alle organizzazioni che intendono dimostrare la conformità si consiglia di condurre sia scansioni automatizzate con axe-core sia audit manuali con screen reader che coprano l’intera gamma dei loro contenuti digitali. L’accessibilità strutturale — la base che il criterio 1.3.1 impone — dovrebbe essere integrata nei design system e nelle librerie di componenti, in modo che la conformità sia mantenuta man mano che i contenuti vengono creati e aggiornati, piuttosto che essere trattata come un esercizio di correzione una tantum.