Introduzione
Quando si parla di accessibilità dei form HTML, l’attenzione si concentra spesso sugli elementi <input>. Tuttavia, un modulo può contenere anche menu a tendina, aree di testo, campi per date, caricamento di file e caselle di ricerca. Tutti questi controlli devono avere un’etichetta chiara e correttamente associata.
Un’etichetta ben progettata permette agli utenti di capire che cosa inserire, indipendentemente dal dispositivo o dalla tecnologia assistiva utilizzata. Un lettore di schermo, per esempio, annuncia il nome del campo quando questo riceve il focus. Se la label manca o non è collegata, l’utente potrebbe sentire soltanto “casella di modifica” o “menu”, senza sapere quale informazione fornire.
In questo tutorial vedremo come usare le label con elementi diversi dal semplice input testuale. L’obiettivo è costruire un modulo realistico per raccogliere una richiesta di assistenza, mantenendo una struttura semantica, navigabile da tastiera e comprensibile.
Codice completo
<form action="/assistenza" method="post" enctype="multipart/form-data">
<h2>Richiedi assistenza</h2>
<p>
I campi contrassegnati con <strong>*</strong> sono obbligatori.
</p>
<div>
<label for="categoria">Categoria della richiesta *</label>
<select id="categoria" name="categoria" required>
<option value="">Seleziona una categoria</option>
<option value="account">Account e accesso</option>
<option value="pagamento">Pagamenti e fatturazione</option>
<option value="tecnico">Problema tecnico</option>
</select>
</div>
<div>
<label for="descrizione">Descrivi il problema *</label>
<textarea
id="descrizione"
name="descrizione"
rows="6"
required></textarea>
</div>
<div>
<label for="data-preferita">Data preferita per il ricontatto</label>
<input
type="date"
id="data-preferita"
name="data-preferita">
</div>
<div>
<label for="allegato">Allega uno screenshot, se necessario</label>
<input
type="file"
id="allegato"
name="allegato"
accept="image/png, image/jpeg, application/pdf">
</div>
<div>
<label for="email">Indirizzo email per la risposta *</label>
<input
type="email"
id="email"
name="email"
autocomplete="email"
required>
</div>
<button type="submit">Invia richiesta</button>
</form>Spiegazione
Label e menu select
L’elemento <select> deve avere una label che spieghi il significato del menu. Il collegamento viene creato usando un valore identico tra l’attributo for della label e l’attributo id del select:
<label for="categoria">Categoria della richiesta</label>
<select id="categoria" name="categoria">
...
</select>Il testo della prima <option> funziona come istruzione iniziale, ma non sostituisce la label. La label identifica il controllo; l’opzione indica invece quale valore scegliere. Per un campo obbligatorio è utile usare un’opzione iniziale con value="", così il browser può verificare che l’utente abbia effettuato una scelta reale.
Label e textarea
Una <textarea> non dovrebbe essere identificata soltanto tramite un testo segnaposto. Il placeholder scompare quando l’utente inizia a scrivere e non rappresenta una vera etichetta accessibile.
<label for="descrizione">Descrivi il problema</label>
<textarea id="descrizione" name="descrizione"></textarea>È preferibile lasciare la textarea vuota e posizionare le istruzioni nella label o in un testo separato. In questo modo il nome del campo rimane disponibile anche dopo l’inserimento del contenuto.
Campi data e file
Anche i controlli specializzati, come type="date" e type="file", richiedono una label. Il browser può mostrare un’interfaccia diversa in base al sistema operativo, ma il collegamento semantico resta valido in ogni ambiente.
L’attributo accept limita i tipi di file suggeriti all’utente, ma non sostituisce una descrizione comprensibile. La label dovrebbe chiarire che cosa allegare e, quando necessario, quali formati sono accettati.
La differenza tra name e id
L’attributo id serve soprattutto a collegare la label al controllo e deve essere univoco nella pagina. L’attributo name identifica invece il dato inviato al server. In un form corretto, entrambi sono normalmente presenti, ma svolgono ruoli differenti.
Best practice
- Usa una label visibile per ogni controllo che richiede un’informazione dall’utente.
- Assicurati che ogni valore di
forcorrisponda a un soloidesistente. - Scrivi label specifiche: “Descrivi il problema” è più utile di “Messaggio”.
- Non usare il placeholder come unica etichetta del campo.
- Inserisci
requiredsolo sui campi realmente obbligatori. - Indica chiaramente il significato dell’asterisco e non affidarti esclusivamente al colore.
- Usa
autocompleteper dati comuni, come l’indirizzo email, così da velocizzare la compilazione. - Non nascondere la label con tecniche visive che la rendano indisponibile alle tecnologie assistive.
- Controlla il modulo usando soltanto la tastiera: il focus deve raggiungere ogni campo in un ordine logico.
- Verifica il risultato con un lettore di schermo e con gli strumenti di analisi del browser.
Riepilogo
Le label non sono limitate ai campi di testo: devono accompagnare anche select, textarea, date picker, upload di file e altri controlli del modulo. Il collegamento esplicito tramite for e id rende il rapporto tra descrizione e controllo riconoscibile da browser e tecnologie assistive.
Una buona label deve essere visibile, concisa e descrittiva. Placeholder, attributi tecnici e icone possono completare l’interfaccia, ma non devono sostituire l’etichetta. Partire da HTML semantico e da associazioni corrette consente di creare form più comprensibili per tutti gli utenti.