Nome, ruolo, valore

Cosa richiede

Ogni elemento interattivo della pagina — pulsanti, link, campi modulo, schede, slider, widget personalizzati — deve esporre tre informazioni alle tecnologie assistive:

• Nome — come si chiama questo controllo? («Invia», «Chiudi finestra di dialogo», «Volume»)
• Ruolo — che tipo di controllo è? (pulsante, link, casella di spunta, scheda, slider)
• Valore / stato — per i componenti che lo prevedono: è premuto, espanso, selezionato? Qual è il valore corrente?

L’esposizione deve essere programmatica — definita nel DOM, non dipinta con CSS. I lettori di schermo, i display braille, i software di controllo vocale e gli scanner switch leggono tutti l’albero di accessibilità, non i pixel.

Come soddisfarlo

• Usa l’elemento HTML nativo ogni volta che ne esiste uno. <button> include già il ruolo corretto, il focus, la gestione della tastiera e un nome accessibile derivato dal testo contenuto — senza costi aggiuntivi.
• Per i pulsanti con sola icona, aggiungi aria-label (o testo nascosto visivamente). <button aria-label="Chiudi">×</button>.
• Per gli input di un modulo, associa un <label for> all’id dell’input, oppure racchiudi l’input dentro il <label>. Il testo segnaposto non è un’etichetta.
• Quando devi costruire un widget personalizzato con <div> e <span>, aggiungi role="…", gestisci tabindex, gestisci Invio e Spazio, e rifletti lo stato con aria-pressed, aria-expanded, aria-checked, aria-selected, aria-valuenow.
• Esegui il rendering della pagina nell’inspector dell’albero di accessibilità del browser (Chrome DevTools → Elementi → Accessibilità) e leggi ogni controllo: ciascuno dovrebbe annunciarsi come nome + ruolo + stato.

Errori comuni

• <div onclick="…"> stilizzato come pulsante — nessun ruolo, nessuna tastiera, nessun nome. I lettori di schermo lo saltano. Il controllo vocale non può dire «clicca Salva».
• <div role="button"> senza tabindex="0", senza gestore Invio/Spazio — sembra accessibile, ma non lo è.
• Pulsanti con sola icona (<button><svg /></button>) privi di aria-label, aria-labelledby o testo nascosto visivamente. Annunciati semplicemente come «pulsante».
• Menu a discesa personalizzati costruiti con <div> e JavaScript, privi di role="combobox", aria-expanded, aria-controls e dei ruoli listbox/option sottostanti.
• Pulsanti di attivazione/disattivazione (silenzia, preferiti, segui) che cambiano stato visivamente ma non aggiornano mai aria-pressed. Gli utenti vedenti percepiscono il cambiamento; gli utenti di lettori di schermo non sentono alcuna differenza.
• Input di modulo con un’etichetta visiva posta accanto, ma senza collegamento for/id o <label> avvolgente.
• Caselle di spunta personalizzate disegnate con <svg> e un input nativo nascosto che non riflette mai :checked nell’interfaccia visibile — lo stato del lettore di schermo e quello visivo divergono.

Perché è importante

Questo è il criterio di successo più citato nella specifica. Quasi ogni segnalazione del tipo «questo sito è inutilizzabile con un lettore di schermo» riconduce a una violazione del 4.1.2 — di solito un <div> che si spaccia per pulsante, o un pulsante icona senza nome. È anche il punto in cui si manifesta il costo della costruzione di widget personalizzati: ogni controllo HTML nativo supera già il 4.1.2; ogni widget <div> costruito a mano deve guadagnarselo riga per riga. L’audit più rapido del 4.1.2 è navigare la pagina con la tastiera e un lettore di schermo e ascoltare — qualsiasi cosa si annunci come «vuoto» o semplicemente «pulsante» è un problema.