Form accessibili: label, errori, focus e tastiera (guida pratica per dev e PMI)

Quasi ogni sito ha almeno un form: contatti, iscrizione newsletter, checkout, login, richiesta preventivo. Sono anche il punto in cui l'accessibilità si rompe più spesso, perché basta un placeholder al posto della label, un errore comunicato solo col colore rosso o un campo senza name per rendere il modulo inutilizzabile a chi usa screen reader, tastiera o tecnologie assistive.

Questa guida raccoglie i quattro pilastri WCAG 2.2 che fanno la differenza su un form: label, gestione degli errori, focus e navigazione da tastiera. Alla fine trovi come verificare i tuoi form in pochi minuti con lo scanner LEXABLE.

1. Label associate: il campo deve avere un nome vero

Il primo criterio WCAG che salta su un form è il 3.3.2 Labels or Instructions: ogni campo deve avere un'etichetta visibile e programmaticamente associata. Il placeholder non è una label: sparisce quando l'utente scrive e spesso non viene letto dagli screen reader.

Le tre regole pratiche:

• Usa sempre <label for="id-campo"> collegata all'id dell'input.
• Se la label deve essere nascosta visivamente, usa una classe di visually hidden (non display:none), così resta leggibile dalle tecnologie assistive.
• Per i campi required, indica l'obbligatorietà sia con testo/attributo required sia con aria-required="true" quando serve.

Esempio corretto

<label for="email">Email</label><input id="email" type="email" name="email" required>

Da evitare

<input type="email" placeholder="La tua email">: nessuna label, nessun nome accessibile.

2. Errori: spiegarli con testo, non solo col colore

Il criterio 3.3.1 Error Identification chiede che gli errori siano identificati in modo chiaro e descritti all'utente. Il criterio 3.3.3 Error Suggestion aggiunge che, quando possibile, vada suggerita la correzione.

Errori tipici che troviamo nei form aziendali:

• campo bordato di rosso senza messaggio testuale;
• messaggio generico in cima alla pagina (“Ci sono errori”), senza indicare quali campi;
• testo di errore non collegato al campo tramite aria-describedby;
• conferma di invio che non viene annunciata allo screen reader.

Una struttura robusta prevede: <input aria-describedby="err-email" aria-invalid="true"> e subito sotto <p id="err-email">Inserisci un indirizzo email valido, es. nome@dominio.it</p>. In questo modo il messaggio è visibile, leggibile e associato al campo giusto.

3. Focus visibile e ordine logico

Il criterio 2.4.7 Focus Visible (e il nuovo 2.4.11 Focus Not Obscured in WCAG 2.2) richiede che l'elemento attivo sia sempre riconoscibile. Troppi CSS aziendali contengono outline: none per “estetica”: è una delle violazioni più semplici da correggere e più impattanti.

• Ripristina un :focus-visible con outline ad alto contrasto (minimo 3:1 rispetto allo sfondo).
• Evita che header sticky, cookie banner o modali coprano il campo attivo: è esattamente ciò che il criterio 2.4.11 vuole prevenire.
• L'ordine di tabulazione deve seguire l'ordine visivo: evita tabindex positivi.

4. Uso completo da tastiera

Il criterio 2.1.1 Keyboard chiede che tutte le funzionalità siano raggiungibili senza mouse. Sui form significa:

1. tutti i campi raggiungibili con Tab in ordine logico;
2. select, checkbox, radio e date picker attivabili con Spazio, Invio e frecce;
3. nessun widget custom (es. dropdown fatti in div) che non gestisca gli eventi da tastiera;
4. il pulsante di invio raggiungibile e attivabile con Invio.

Un test rapido: prova a compilare e inviare il form usando solo la tastiera, poi ripeti con uno screen reader (NVDA o VoiceOver). Le frizioni emergono in pochi secondi.

Come LEXABLE ti aiuta a controllare i form

Correggere un form è fattibile; il problema è accorgersi che è rotto, e farlo su tutte le pagine che lo contengono (contatti, checkout, area riservata). Lo scanner WCAG 2.2 di LEXABLE analizza un URL e restituisce un report con i problemi rilevati automaticamente, incluse le criticità più frequenti sui form: label mancanti, input senza nome accessibile, contrasto del focus, uso improprio di placeholder.

Puoi partire con una scansione gratuita di una pagina per vedere subito lo stato dei tuoi moduli. Se gestisci più template o più siti, il monitoraggio continuo e il widget di accessibilità installabile con uno snippet JS ti aiutano a tenere sotto controllo anche le pagine che cambi spesso.

Ricorda: lo scanner è un alleato operativo, non una certificazione legale. La verifica manuale con tastiera e screen reader resta indispensabile per i casi che nessun tool può valutare fino in fondo.

In sintesi

• Label sempre associate, mai solo placeholder.
• Errori descritti con testo e collegati al campo.
• Focus visibile e mai coperto da banner o modali.
• Form interamente utilizzabili da tastiera.

Se vuoi trasformare questi quattro punti in una routine di controllo, crea un account e inizia a monitorare i tuoi form: registrati su LEXABLE e porta l'accessibilità dei tuoi moduli a un livello verificabile.