Identificazione degli errori
Quando l'utente commette un errore in un modulo che viene rilevato automaticamente, l'errore deve essere identificato e descritto all'utente in forma testuale — non con il solo colore, non con la sola icona, non con il silenzio.
Cosa richiede
Se un campo di un modulo non è valido (formato errato, valore obbligatorio assente, valore fuori intervallo) e il sistema lo rileva automaticamente, l’errore deve essere comunicato all’utente con una descrizione testuale. Il testo deve indicare quale campo è sbagliato e cosa non va — non solo che «qualcosa» è andato storto.
Il criterio di successo non impone al sistema di rilevare ogni possibile errore; richiede che gli errori rilevati siano presentati all’utente come testo.
Come soddisfarlo
- Associare a ogni campo del modulo un messaggio di errore visibile che descriva il problema, posizionato vicino al campo o immediatamente sotto di esso.
- Fare riferimento al campo non valido per nome: «L’indirizzo e-mail deve contenere il simbolo @».
- Collegare il messaggio di errore all’input tramite
aria-describedbyaffinché gli screen reader lo annuncino al ricevimento del focus. - Usare
aria-invalid="true"sul campo non valido. - Per la validazione lato server, rendere visibile un elenco riepilogativo nella parte superiore del modulo, con ogni voce che rimanda al campo corrispondente.
- Annunciare i messaggi di validazione dinamici tramite una live region (
aria-live="polite"orole="alert") affinché gli screen reader comunichino l’errore senza che l’utente debba cercarlo.
Errori comuni
- Bordi rossi attorno ai campi non validi senza alcuna spiegazione testuale.
- Un banner generico con il testo «Modulo non valido» che non indica quali campi siano sbagliati.
- Messaggi di errore visibili solo in un tooltip che scompare alla perdita del focus.
- Validazione nativa del browser (
required,pattern) usata da sola — il palloncino del browser è inaffidabile con gli screen reader e scompare troppo velocemente. - Indicatori di errore a sola icona (punto esclamativo rosso) privi di nome accessibile.
Perché è importante
Questo è l’errore di supporto all’inserimento più frequentemente citato negli audit. Per gli utenti vedenti, un bordo rosso è quanto meno un indizio; per gli utenti di screen reader è come se non esistesse. Per gli utenti con disturbi della percezione dei colori, un bordo rosso da solo non viene percepito affatto. Quando un utente compila un lungo modulo e l’invio fallisce in silenzio, è probabile che abbandoni — e l’accessibilità è la ragione specifica per cui quell’utente ha fallito.
Abbinare il criterio 3.3.1 al 3.3.3 (Suggerimento per gli errori) e al 4.1.3 (Messaggi di stato) — insieme formano il moderno schema di gestione degli errori nei moduli.