Informazioni e relazioni

Cosa richiede

Tutto ciò che si percepisce a colpo d’occhio — che questo testo grande e in grassetto è un’intestazione, che queste righe formano una tabella di dati, che questo gruppo di campi è l’«indirizzo di fatturazione», che l’asterisco indica un campo obbligatorio — deve essere presente anche nel codice sottostante. I lettori di schermo, i software di controllo vocale e i motori di ridisposizione vedono solo il markup. Se una relazione è puramente visiva (un font più grande, un bordo più spesso, un rientro), le tecnologie assistive non percepiscono nulla.

Come soddisfarlo

• Utilizzare veri elementi di intestazione (<h1> fino a <h6>) in un ordine gerarchico logico — mai un <div> stilizzato per simulare un’intestazione.
• Marcare gli elenchi con <ul>, <ol> e <li> — non paragrafi separati da interruzioni di riga o caratteri bullet.
• Usare <table> con <th scope="col"> / <th scope="row"> per le tabelle di dati, con <caption> che descrive lo scopo della tabella.
• Ogni campo di modulo deve avere un’etichetta programmatica: <label for="...">, aria-labelledby o aria-label. Il testo segnaposto non è un’etichetta.
• Raggruppare i campi di modulo correlati in <fieldset> con <legend>, oppure usare role="group" con aria-labelledby per i widget personalizzati.
• Per figure e didascalie, utilizzare <figure> e <figcaption>. Per le coppie definizione-termine, usare <dl> / <dt> / <dd>.
• Indicare i campi obbligatori sia visivamente (asterisco) sia programmaticamente (aria-required="true" o l’attributo required).

Errori comuni

• <div class="heading-1"> al posto di <h1> — visivamente corretto, annunciato come nulla dai lettori di schermo.
• Tabelle di layout usate per colonne visive, o tabelle di dati costruite con griglie di <div> senza celle <th>.
• Campi di modulo con solo il testo segnaposto come etichetta — l’etichetta scompare al focus e i lettori di schermo potrebbero non annunciarla.
• Punti elenco simulati con <p>•&nbsp;Voce</p> invece del markup di lista appropriato.
• Asterischi per i campi obbligatori mostrati in rosso via CSS, senza attributo aria-required o required.
• Pulsanti radio raggruppati visivamente senza <fieldset> / <legend>, che lascia agli utenti di lettori di schermo opzioni fluttuanti prive della domanda di riferimento.
• Tabelle di dati in cui la riga di intestazione è in grassetto ma usa <td> invece di <th>.

Perché è importante

Il criterio 1.3.1 è il SC più citato nelle verifiche WCAG dopo 1.1.1 e 1.4.3. Ogni pagina generata da un CMS, ogni landing page marketing, ogni widget di modulo personalizzato tende a non soddisfare almeno una parte di questo criterio. La soluzione è quasi sempre l’HTML semantico, non ARIA — quando si ricorre a role="heading" per riparare un <div> che avrebbe dovuto essere <h2>, il problema è già a monte.