Moduli accessibili: etichette, suggerimenti ed errori

Sei criteri di successo per i moduli

Le WCAG 2.2 sono l’attuale raccomandazione del W3C per i contenuti web accessibili. Per i testi di un modulo contano soprattutto sei dei loro criteri di successo:

• 1.3.1 Informazioni e correlazioni (livello A): ciò che mostra il layout, per esempio quale etichetta appartiene a quale campo, è disponibile anche nel codice o nel testo.
• 1.3.5 Identificare lo scopo degli input (livello AA): i campi che chiedono informazioni sull’utente, come nome o email, espongono il loro scopo nel codice.
• 3.3.1 Identificazione di errori (livello A): se un errore di inserimento viene rilevato automaticamente, il campo viene indicato e l’errore descritto a testo.
• 3.3.2 Etichette o istruzioni (livello A): ci sono etichette o istruzioni quando un contenuto richiede un input dell’utente.
• 3.3.3 Suggerimenti per gli errori (livello AA): se un errore viene rilevato e si conosce una correzione, questa viene suggerita, a meno che ciò metta a rischio la sicurezza o lo scopo del contenuto.
• 4.1.2 Nome, ruolo, valore (livello A): ogni controllo ha un nome e un ruolo che il software può leggere.

Ogni campo ha bisogno di un’etichetta visibile

Un’etichetta dice cosa va nel campo e resta visibile mentre l’utente scrive. In HTML collega l’elemento label al campo: l’attributo for dell’etichetta ha esattamente lo stesso valore dell’id del campo. Gli screen reader leggono così l’etichetta insieme al campo, e un clic sull’etichetta porta il cursore nel campo. Un pulsante prende l’etichetta dal suo testo, e 'Invia messaggio' dice di più di 'Invia'. Le etichette stanno di solito a destra di pulsanti di opzione e caselle di controllo, e a sinistra o sopra gli altri campi; le etichette sopra i campi occupano meno spazio in larghezza.

Un placeholder non è un’etichetta

Il testo grigio in un campo vuoto sembra un’etichetta, ma non lo è. Il W3C indica i problemi:

• Sparisce appena si inizia a scrivere, quindi è più difficile controllare i dati prima dell’invio.
• I browser lo mostrano spesso in un colore chiaro con troppo poco contrasto.
• Gli screen reader non lo trattano come un’etichetta, e il supporto varia.

Usa un placeholder al massimo per un esempio e metti tutto ciò che è importante nell’etichetta o in un suggerimento.

Suggerimenti e campi obbligatori

• Metti le regole in un suggerimento: il formato della data, la lunghezza di un codice cliente, i requisiti di una password. In HTML puoi collegare il suggerimento con aria-describedby, così gli screen reader lo leggono dopo l’etichetta.
• Indica quali campi sono obbligatori e quali facoltativi. Se usi un asterisco, spiegalo una volta all’inizio del modulo.
• Metti le istruzioni per l’intero modulo prima del modulo, per esempio su un limite di tempo.
• Tieni i suggerimenti brevi. Troppe istruzioni rendono un modulo più difficile, non più facile.

Raggruppa i campi correlati

Pulsanti di opzione e caselle di controllo che vanno insieme si raggruppano con l’elemento fieldset, e l’elemento legend dà un nome al gruppo, per esempio 'Come preferisci essere contattato?'. Il W3C dice che i gruppi di pulsanti di opzione andrebbero sempre raggruppati così. Tieni breve la legend, perché alcuni screen reader la leggono con ogni campo. I gruppi aiutano anche con campi che hanno la stessa etichetta, come la via nell’indirizzo di spedizione e in quello di fatturazione.

autocomplete: lascia che il browser aiuti

Per i campi che chiedono informazioni sull’utente, il criterio 1.3.5 chiede che il loro scopo si possa determinare nel codice. Le WCAG 2.2 hanno un elenco di questi scopi, basato sulla sezione autofill della specifica HTML, come name, given-name, family-name, email, tel, street-address e postal-code. In HTML li imposti con l’attributo autocomplete, per esempio autocomplete="email". I browser possono così compilare i valori salvati, e si scrive meno. I campi che non riguardano l’utente non hanno bisogno di uno scopo.

Messaggi di errore che aiutano

Un messaggio di errore ha tre compiti: indicare il campo, dire cosa non va e dire come correggerlo. Il criterio 3.3.1 chiede i primi due, a testo, quindi un bordo rosso o un’icona da soli non bastano. Il 3.3.3 chiede la correzione quando è nota.

• Mostra il messaggio accanto al campo e collegalo con aria-describedby, così gli screen reader lo leggono insieme al campo.
• Dopo l’invio mostra un elenco di tutti gli errori in alto, prima del modulo, sotto un’intestazione chiara. Ogni voce indica il campo, il problema e la correzione, e rimanda al campo con un link.
• Aggiorna anche il titolo della pagina, per esempio '2 errori – Modulo di contatto', e sposta il focus sul primo campo con un errore.
• Conserva ciò che l’utente ha già inserito. È un nostro consiglio, non una regola WCAG: dover riscrivere tutto dopo un solo errore fa rinunciare le persone.

Controlla il tuo modulo con Do4U

Lo strumento Testi del modulo controlla i testi di un modulo web. Incolli l’HTML del modulo o indichi l’indirizzo della pagina, e puoi aggiungere i messaggi di errore che il tuo modulo mostra. Il codice legge ogni campo: la sua etichetta e da dove proviene, suggerimenti, placeholder, campi obbligatori, valori autocomplete e gruppi di pulsanti di opzione o caselle di controllo. Trova problemi come un campo senza etichetta, un placeholder come unica etichetta, campi obbligatori che il testo non menziona, valori autocomplete mancanti e messaggi di errore vaghi, ciascuno con il suo criterio di successo. L’IA propone un’etichetta chiara, un breve suggerimento e un messaggio di errore che indica il campo e dice come correggere l’inserimento. Il codice controlla ogni proposta e crea dal tuo modulo una bozza HTML migliorata.

Do4U trova indicazioni e crea una bozza, tu controlli e decidi. Lo strumento controlla il markup, non i tuoi stili, gli script o l’uso con la tastiera, e non ti dice se il tuo modulo è accessibile. Prova il modulo migliorato con la tastiera e con uno screen reader.