Introduzione
Quando si parla di accessibilità nei form HTML, la label è solo il punto di partenza. Un modulo ben progettato non deve limitarsi a dire “questo campo si chiama così”, ma deve anche aiutare l’utente a capire come compilare correttamente il campo, quali formati sono accettati e cosa succede in caso di errore.
In questo tutorial vedremo un aspetto molto pratico e spesso trascurato: come usare label, testo di aiuto e descrizioni collegate ai campi per migliorare l’accessibilità dei form. Questo approccio è utile per chi usa lettori di schermo, per chi naviga da tastiera e anche per chi compila il form da mobile o in condizioni di scarsa attenzione.
L’obiettivo è semplice: creare campi che non siano solo “etichette visibili”, ma interfacce comprensibili. Vedremo un esempio reale con un form di registrazione e useremo attributi come aria-describedby nel modo corretto, senza sostituire la label, ma completandola.
Codice completo
<form action="/registrazione" method="post">
<h2>Registrazione account</h2>
<div>
<label for="nome">Nome completo</label>
<input
type="text"
id="nome"
name="nome"
autocomplete="name"
aria-describedby="nome-help"
required
>
<p id="nome-help">Inserisci nome e cognome, ad esempio “Mario Rossi”.</p>
</div>
<div>
<label for="email">Email aziendale</label>
<input
type="email"
id="email"
name="email"
autocomplete="email"
aria-describedby="email-help"
required
>
<p id="email-help">Usa un indirizzo valido. Riceverai un link di conferma.</p>
</div>
<div>
<label for="password">Password</label>
<input
type="password"
id="password"
name="password"
aria-describedby="password-help"
required
>
<p id="password-help">Minimo 8 caratteri, con almeno una lettera maiuscola e un numero.</p>
</div>
<div>
<label for="privacy">
<input type="checkbox" id="privacy" name="privacy" required>
Accetto l’informativa sulla privacy
</label>
<p id="privacy-help">La tua accettazione è necessaria per completare la registrazione.</p>
</div>
<button type="submit">Crea account</button>
</form>Spiegazione
In questo esempio ogni campo ha una label chiara e un testo di supporto associato. La label dice che cosa è il campo, mentre il testo di aiuto spiega come compilarlo. Questa distinzione è fondamentale: se la label cerca di contenere troppe informazioni, il form diventa più difficile da leggere e da ascoltare con tecnologie assistive.
1. La label identifica il campo
La label deve essere breve, precisa e descrivere il contenuto del campo. Ad esempio:
- Nome completo è una label efficace perché indica chiaramente cosa inserire.
- Email aziendale è utile se il contesto richiede un indirizzo specifico.
- Password è sufficiente come nome del campo, mentre i requisiti vanno nel testo di supporto.
Il collegamento tra label e input avviene con for e id. Questo è essenziale per l’accessibilità e per la navigazione: cliccando sulla label, il focus va direttamente al campo corrispondente.
2. Il testo di aiuto aggiunge contesto
Il paragrafo con id, come nome-help o password-help, contiene una spiegazione utile ma non invasiva. Non deve ripetere la label, ma chiarire dettagli pratici:
- formato atteso;
- esempio di compilazione;
- vincoli tecnici o funzionali;
- informazioni sul motivo della richiesta.
Questo approccio è molto efficace nei form complessi, per esempio registrazioni, checkout o richieste di supporto.
3. aria-describedby collega il testo di supporto
L’attributo aria-describedby indica al browser e alle tecnologie assistive quale contenuto testuale descrive il campo. Quando un utente con screen reader si sposta sull’input, può ricevere sia il nome del campo sia la descrizione aggiuntiva.
È importante usare aria-describedby per descrizioni e aiuti, non per sostituire la label. La label resta il riferimento principale del campo. La descrizione è un’informazione supplementare.
4. Checkbox e label implicita
Nel caso della checkbox privacy abbiamo usato una label implicita: l’input è contenuto direttamente dentro la label. È una soluzione pratica e valida, soprattutto per checkbox e radio button. In questo caso, il testo “Accetto l’informativa sulla privacy” è associato in modo naturale al controllo.
Questa struttura migliora anche l’usabilità su touch screen, perché l’area cliccabile è più ampia.
5. Perché questo pattern è migliore di un placeholder
Un errore comune è usare il placeholder al posto della label o del testo di aiuto. Il placeholder però non è una soluzione accessibile completa: scompare quando l’utente scrive, può essere difficile da leggere e spesso non è letto in modo affidabile dai lettori di schermo come sostituto della label.
Meglio quindi seguire questo schema:
- label per identificare il campo;
- testo di aiuto per spiegare come compilarlo;
- placeholder solo se serve come esempio temporaneo, non come informazione essenziale.
Best practice
- Scrivi label brevi e specifiche: una label deve dire chiaramente cosa inserire, senza trasformarsi in una spiegazione lunga.
- Associa sempre la label al controllo: usa for e id oppure una label implicita quando ha senso.
- Usa aria-describedby per i testi di aiuto: è il modo corretto per collegare istruzioni, esempi e note aggiuntive.
- Non duplicare informazioni: se la label dice “Password”, il testo di aiuto deve aggiungere requisiti, non ripetere la stessa parola in modo inutile.
- Evita di mettere istruzioni solo nel placeholder: le informazioni importanti devono essere sempre visibili e persistenti.
- Rendi i messaggi utili anche fuori dal contesto visivo: pensa a chi usa screen reader, zoom elevato o navigazione da tastiera.
- Usa un linguaggio concreto: meglio “Inserisci nome e cognome” che “Compila correttamente il campo”.
- Se il campo è obbligatorio, dichiaralo chiaramente: non affidarti solo al colore o all’asterisco, ma comunica il vincolo in modo testuale.
Riepilogo
Le label sono fondamentali, ma da sole non bastano sempre. Un form accessibile deve aiutare l’utente a capire che cosa inserire e come farlo. Per questo è utile affiancare alla label un testo di supporto collegato con aria-describedby.
In pratica:
- la label identifica il campo;
- il testo di aiuto spiega regole, formato o contesto;
- il collegamento corretto migliora l’esperienza per tutti, non solo per chi usa tecnologie assistive.
Se progetti form più chiari fin dall’inizio, riduci errori, abbandoni e richieste di assistenza. È un vantaggio sia per l’accessibilità sia per la qualità dell’interfaccia.
Approfondisci con risorse ufficiali
- MDN Web Docs — documentazione su
<label>,<input>e attributi ARIA. - WAI-ARIA Authoring Practices — linee guida per l’uso corretto delle descrizioni accessibili.
- W3C HTML Standard — riferimento ufficiale per il comportamento dei controlli di form e delle label.
- W3C WAI — risorse pratiche sull’accessibilità dei form e sulla progettazione inclusiva.