WCAG 3.3.3: Suggerimento di errore

Cosa Significa Questa Regola

WCAG 3.3.3 Error Suggestion è un criterio di livello AA sotto il principio Comprensibile. Si basa direttamente sul 3.3.1 (Error Identification), che richiede che gli errori siano identificati in testo. Error Suggestion va oltre: quando un errore di input viene rilevato automaticamente, l’interfaccia deve anche suggerire come l’utente può correggerlo, a condizione che tale suggerimento non comprometta la sicurezza o lo scopo del contenuto.

La distinzione chiave qui è tra identificazione dell’errore e suggerimento dell’errore. Dire a un utente "La tua data di nascita non è valida" è identificazione. Dire a un utente "La tua data di nascita non è valida — inserisci una data nel formato GG/MM/AAAA" è un suggerimento. Entrambi sono richiesti dai rispettivi criteri, ma Error Suggestion richiede che, ove possibile, un’indicazione correttiva e azionabile accompagni il messaggio di errore.

Il criterio si applica ogni volta che un errore di input viene rilevato automaticamente — cioè quando la logica di validazione lato client o lato server determina che un valore inserito o inviato non soddisfa i criteri attesi. Si applica a tutti i controlli di form: campi di testo, select, checkbox, radio button, selettori di data, campi di caricamento file e qualsiasi componente interattivo che raccolga dati dell’utente.

Cosa è considerato conforme: Il messaggio di errore è presentato in testo (non solo tramite colore o icona), identifica chiaramente il campo in errore e fornisce indicazioni specifiche su come correggerlo. Per esempio: "La password deve essere di almeno 8 caratteri e includere una lettera maiuscola" invece di semplicemente "Password non valida." Il suggerimento deve apparire in prossimità del campo, essere associato a esso in modo programmatico (tramite aria-describedby o simili) ed essere percepibile dalle tecnologie assistive.

Cosa è considerato non conforme: Qualsiasi messaggio di errore che si limiti a dichiarare che si è verificato un errore senza spiegare cosa non va o come risolverlo. Messaggi generici come "Errore", "Input non valido" o "Campo obbligatorio" senza ulteriore contesto non soddisfano questo criterio. Errori comunicati solo tramite un bordo rosso o un’icona di avviso, senza testo descrittivo, non sono conformi.

Eccezioni definite: Il criterio include due eccezioni esplicite in cui un suggerimento non è richiesto. Primo, se fornire il suggerimento metterebbe a rischio la sicurezza — per esempio, in un form di login in cui spiegare esattamente perché una password non è stata accettata (password errata vs. nome utente errato) potrebbe agevolare attacchi di forza bruta. Secondo, se fornire il suggerimento comprometterebbe lo scopo del contenuto — per esempio, in un quiz educativo in cui rivelare la risposta corretta vanificherebbe l’obiettivo di valutazione. Queste eccezioni sono limitate e non dovrebbero essere usate per evitare il requisito nei contesti di form standard.

Perché È Importante

Error Suggestion esiste perché la compilazione di form è una delle attività cognitivamente più impegnative che gli utenti svolgono sul web, ed è anche una delle più consequenziali — errori nei form di checkout, nelle domande per benefici governativi, nei moduli di accettazione medica o nei portali bancari possono avere conseguenze reali per gli utenti che non riescono a capire cosa è andato storto o come rimediare.

Disabilità cognitive: Utenti con dislessia, ADHD, disturbi dell’apprendimento o alfabetizzazione limitata possono avere difficoltà a decodificare messaggi di errore vaghi e a collegarli allo specifico campo o formato richiesto. Senza un chiaro suggerimento correttivo, possono abbandonare completamente il form o inviare informazioni errate. Secondo l’Organizzazione Mondiale della Sanità, circa 1 persona su 6 a livello globale — oltre 1,3 miliardi — vive con qualche forma di disabilità, e le disabilità cognitive sono tra le categorie più diffuse ma meno accomodate.

Utenti ciechi e ipovedenti: Gli utenti di screen reader si affidano completamente alle descrizioni testuali per comprendere gli errori di validazione. Quando un messaggio di errore dice solo "Non valido" e non fornisce alcun suggerimento, l’utente non ha alcun modo per determinare cosa significhi "non valido" per quel campo. Non può dare un’occhiata a etichette adiacenti, testo segnaposto o indizi di formattazione visiva per dedurre il formato atteso. Un suggerimento chiaro, associato in modo programmatico all’input tramite aria-describedby, è l’unico canale di informazione affidabile.

Utenti con disabilità motorie: Gli utenti che si affidano a accesso a scansione, controllo vocale o dispositivi di input alternativi sperimentano uno sforzo fisico significativo quando compilano form. Dover tornare a un form dopo un invio fallito — senza capire cosa deve essere modificato — impone un costo sproporzionato. Suggerimenti chiari riducono l’onere di reinserimento e il numero di cicli di invio falliti.

Utenti non madrelingua e utenti anziani: Gli utenti che non sono fluenti nella lingua del form, o che hanno meno familiarità con le convenzioni del web, traggono anch’essi grande beneficio da suggerimenti correttivi espliciti. Un messaggio come "Inserisci il tuo numero di telefono senza spazi o trattini, ad es. 05321234567" elimina l’ambiguità per utenti che altrimenti potrebbero non riuscire mai a completare il form.

Scenario reale: Considera un cittadino turco che richiede un beneficio di assistenza sociale tramite un portale di e-government. La domanda richiede un TR Identity Number (TC Kimlik Numarası), un formato specifico di 11 cifre. Se l’utente inserisce 10 cifre e riceve solo il messaggio "TC Kimlik Numarası hatalı" (TC Identity Number is incorrect), un utente con disabilità cognitiva, un utente anziano o un utente di screen reader potrebbe non sapere se il numero è troppo corto, contiene un carattere non valido o ha un problema di formattazione. Aggiungere "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (TC Identity Number must be 11 digits, e.g., 12345678901) risolve immediatamente l’ambiguità e permette all’utente di autocorreggersi.

Benefici in termini di usabilità e conversione: Oltre all’accessibilità, l’abbandono dei form è un indicatore di business critico. La ricerca mostra costantemente che i messaggi di errore poco chiari sono tra le principali ragioni per cui gli utenti abbandonano i checkout di e-commerce e i flussi di registrazione. Suggerimenti di errore specifici e azionabili riducono i tassi di abbandono dei form e migliorano i tassi di completamento per tutti gli utenti — rendendo questo criterio un forte argomento di business oltre che un requisito di accessibilità.

Regole Axe-core Correlate

WCAG 3.3.3 richiede test manuali perché gli strumenti automatici non possono valutare la qualità o completezza del testo del messaggio di errore. Uno scanner automatico può rilevare che esiste un messaggio di errore e che è associato in modo programmatico a un campo del form, ma non può determinare se il messaggio fornisce effettivamente un suggerimento correttivo utile. Questo richiede un giudizio umano per valutare se il testo è specifico, azionabile e sufficiente a guidare l’utente verso un inserimento valido.

• Revisione manuale — qualità del contenuto del messaggio di errore: I tester devono attivare manualmente ogni condizione di validazione (inviare un campo obbligatorio vuoto, inserire dati nel formato sbagliato, superare i limiti di caratteri, ecc.) e valutare ogni messaggio di errore risultante. Il tester si chiede: questo messaggio dice all’utente non solo che si è verificato un errore, ma anche specificamente cosa deve fare per correggerlo? Se il messaggio è generico ("Non valido", "Errore", "Controlla questo campo"), non soddisfa il 3.3.3 indipendentemente dal fatto che sia esposto in modo programmatico.
• Revisione manuale — associazione programmatica: I tester devono verificare che il testo del suggerimento di errore sia collegato in modo programmatico al campo di input pertinente usando aria-describedby, regioni aria-live o associazione inline, in modo che gli screen reader lo annuncino senza richiedere ulteriore navigazione. Questo si sovrappone parzialmente a regole axe come label e aria-input-field-name, ma il testo del suggerimento in sé non è controllato da queste regole.
• Revisione manuale — validità dell’eccezione di sicurezza: I tester dovrebbero verificare che qualsiasi form che omette suggerimenti correttivi per motivi di sicurezza (ad es. form di login) rientri effettivamente nell’eccezione di sicurezza e che questa eccezione non venga usata per evitare il requisito su campi non sensibili.
• Parzialmente automatizzato — regola label: Sebbene la regola label di axe-core controlli che gli input dei form abbiano nomi accessibili, non verifica se i messaggi di errore forniscano suggerimenti correttivi. Può far emergere etichette mancanti che aggraverebbero il problema dei suggerimenti di errore, e la correzione dei problemi di etichettatura è un prerequisito per un’implementazione efficace di Error Suggestion.

Come Testare

1. Baseline di scansione automatizzata: Esegui axe DevTools o Lighthouse sulla pagina che contiene il form. Prendi nota di eventuali violazioni esistenti relative a etichette dei form, ruoli ARIA o identificazione degli errori (3.3.1). Queste devono essere risolte per prime, poiché sono prerequisiti per un suggerimento di errore efficace. Le scansioni automatiche non segnaleranno suggerimenti mancanti — stabiliscono solo la baseline strutturale.
2. Attiva ogni condizione di validazione: Per ogni campo del form, attiva deliberatamente ogni possibile stato di errore: invia un campo obbligatorio vuoto, inserisci dati in un formato errato (formato data sbagliato, email non valida, password troppo corta, valore non numerico in un campo numerico) e supera eventuali limiti di caratteri. Documenta ogni messaggio di errore che appare.
3. Valuta la qualità del suggerimento: Per ogni messaggio di errore, chiediti: (a) Identifica lo specifico campo? (b) Spiega cosa non va? (c) Fornisce indicazioni azionabili su come correggere l’inserimento? Un messaggio che risponde a tutte e tre le domande soddisfa il 3.3.3. Un messaggio che risponde solo alla (a) soddisfa il 3.3.1 ma non il 3.3.3.
4. Test con screen reader NVDA + Firefox: Naviga al form usando Tab. Inserisci un valore non valido. Invia o sposta il focus altrove. Ascolta cosa annuncia NVDA. Verifica che il testo del suggerimento di errore venga letto automaticamente (tramite una regione aria-live o la gestione del focus sull’errore) senza richiedere che l’utente lo cerchi manualmente.
5. Test con screen reader VoiceOver + Safari (macOS/iOS): Esegui gli stessi passaggi. Usa VO+Freccia destra per leggere il campo e la sua descrizione associata. Conferma che il testo del suggerimento venga annunciato come parte della descrizione accessibile del campo, non solo come testo vicino che potrebbe essere saltato.
6. Test con screen reader JAWS + Chrome: Dopo aver inviato un form con errori, conferma che JAWS legga il suggerimento di errore tramite la gestione del focus (focus spostato al riepilogo degli errori) o tramite aggiornamenti di una regione aria-live. Usa il cursore virtuale di JAWS per navigare al campo e conferma che il suggerimento faccia parte della descrizione del campo.
7. Navigazione solo da tastiera: Senza screen reader, naviga nel form usando solo Tab, Shift+Tab ed Enter. Verifica che i suggerimenti di errore siano visibili nel viewport, non nascosti fuori dallo schermo o coperti da altri elementi, quando il campo riceve il focus dopo un invio fallito.
8. Verifica delle eccezioni di sicurezza: Per i form di login e autenticazione, conferma che l’omissione di suggerimenti specifici sia intenzionale e documentata, e che l’eccezione di sicurezza sia limitata al minimo numero necessario di campi.

Come Correggere

Messaggio di errore generico — Non corretto

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Messaggio di errore generico — Corretto

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Validazione password senza indicazioni sul formato — Non corretto

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Validazione password senza indicazioni sul formato — Corretto

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Campo data con errore di formato ambiguo — Non corretto

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Campo data con errore di formato ambiguo — Corretto

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Form con più campi e riepilogo errori lato server — Non corretto

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Form con più campi e riepilogo errori lato server — Corretto

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Errori Comuni

• Usare il placeholder come sostituto dei suggerimenti di errore: Il testo segnaposto scompare non appena l’utente inizia a digitare e non viene annunciato in modo affidabile dagli screen reader come errore. Non fare mai affidamento solo sul testo segnaposto per comunicare quale formato è richiesto dopo che si è verificato un errore.
• Mostrare i messaggi di errore solo in una notifica toast che scompare dopo pochi secondi: Le notifiche transitorie non sono percepibili da tutti gli utenti — gli utenti di screen reader possono perdere l’annuncio e il messaggio scompare prima che un lettore lento possa elaborarlo. I suggerimenti di errore devono persistere finché l’errore non è corretto.
• Usare aria-invalid='true' senza che aria-describedby punti al testo del suggerimento: Impostare aria-invalid segnala che un campo contiene un errore, ma senza che aria-describedby colleghi l’elemento del suggerimento, gli screen reader non leggeranno il testo del suggerimento quando il campo riceve il focus.
• Fornire il suggerimento solo nel design visivo (ad es. un tooltip al passaggio del mouse) e non nel DOM: I tooltip visibili solo al passaggio del mouse sono inaccessibili agli utenti da tastiera e agli utenti di screen reader. Il testo del suggerimento deve essere presente nel DOM e associato in modo programmatico al campo.
• Usare solo colore o icone per indicare quale campo ha un errore: Un bordo rosso o un’icona di avviso non costituisce un suggerimento di errore. Il suggerimento deve essere una descrizione testuale che spiega l’azione correttiva, non un indicatore visivo.
• Scrivere suggerimenti che identificano il problema ma non la soluzione: "La tua password è troppo corta" identifica l’errore ma non suggerisce una correzione. "La tua password deve essere di almeno 8 caratteri" fornisce l’indicazione correttiva necessaria. Entrambe le parti sono richieste per la conformità al 3.3.3.
• Applicare l’eccezione di sicurezza in modo troppo esteso: L’eccezione di sicurezza si applica in modo limitato a situazioni in cui fornire un suggerimento comprometterebbe realmente la sicurezza — tipicamente limitato ai campi di autenticazione. Non si applica ai campi standard del form come nomi, indirizzi o numeri di telefono, per i quali gli errori generici non sono giustificati.
• Posizionare il suggerimento di errore dopo il pulsante di invio o lontano dal campo: I suggerimenti di errore devono essere visivamente e programmaticamente vicini al campo che descrivono. Posizionare tutti gli errori in fondo a un form lungo, senza includere anche suggerimenti inline presso ciascun campo, costringe gli utenti a fare continui cambi di contesto e a ricordare quale suggerimento si applica a quale campo.
• Non spostare il focus sul riepilogo degli errori dopo un invio lato server fallito: Quando una pagina viene ricaricata dopo un invio fallito, il focus in genere torna all’inizio della pagina. Senza una gestione programmatica del focus verso il riepilogo degli errori o verso il primo campo in errore, gli utenti di screen reader devono navigare l’intera pagina per scoprire cosa è andato storto.
• Usare un linguaggio vago come "Controlla il tuo input" o "Qualcosa è andato storto": Questi messaggi non forniscono alcuna informazione su cosa non va o come risolverlo. Ogni suggerimento di errore deve essere specifico per il campo e per la specifica regola di validazione che è stata violata.

Relazione con le Normative di Accessibilità della Turchia

Il panorama dell’accessibilità in Turchia è avanzato significativamente con la Circolare Presidenziale 2025/10, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025. Questa circolare stabilisce requisiti obbligatori di accessibilità web e mobile allineati a WCAG 2.2, con conformità di livello AA richiesta per le entità che desiderano ottenere l’Erişilebilirlik Logosu (Logo di Accessibilità) rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Error Suggestion, in quanto criterio di livello AA, rientra nell’ambito di questo requisito obbligatorio. Qualsiasi entità soggetta che gestisca form — per registrazione, pagamento, richieste di servizi o gestione account — deve garantire che i propri messaggi di errore non si limitino a identificare gli errori ma forniscano suggerimenti correttivi azionabili, come descritto in questo criterio.

Le entità coperte dalla Circolare Presidenziale 2025/10 coprono un’ampia gamma di settori. Istituzioni pubbliche e agenzie governative sono tenute a conformarsi, il che significa che tutti i portali di e-government (ad es. servizi e-Devlet, portali municipali, sistemi di richiesta di benefici) devono fornire implementazioni conformi di suggerimenti di errore. Considerato che molti servizi governativi richiedono ai cittadini di inviare dati personali complessi — numeri di identità, codici di indirizzo, numeri fiscali — suggerimenti di errore chiari sono particolarmente critici in questo contesto.

Banche e istituzioni finanziarie sono incluse, comprese le piattaforme di online banking, i form di registrazione di conti di investimento e i portali di richiesta di prestiti. Questi form raccolgono regolarmente dati sensibili e con formati molto precisi, e l’assenza di suggerimenti correttivi crea barriere reali per i clienti con disabilità e potenziali rischi legali.

Ospedali e fornitori di servizi sanitari devono anch’essi conformarsi, includendo i sistemi di registrazione dei pazienti, i form di prenotazione appuntamenti e i portali per le richieste di rimborso assicurativo. I form medici spesso prevedono requisiti di campo complessi (codici di diagnosi, numeri di polizza assicurativa, formati di data precisi), rendendo i suggerimenti di errore chiari particolarmente importanti per pazienti anziani e con disabilità cognitive.

Le società di telecomunicazioni con 200.000 o più abbonati sono incluse, comprendendo i portali clienti dei principali operatori, i form di registrazione SIM e le interfacce di gestione account. Le piattaforme di e-commerce — inclusi i flussi di checkout e di registrazione account — devono conformarsi, rendendo Error Suggestion direttamente rilevante per i form di gestione di prodotti e carrelli che sono centrali per le loro operazioni di business.

Agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE) rientrano anch’esse nell’ambito. I form di prenotazione, le domande di iscrizione e le interfacce di pagamento gestiti da queste entità devono soddisfare gli standard di livello AA, incluso il 3.3.3.

Da una prospettiva pratica di conformità, le organizzazioni che perseguono l’Erişilebilirlik Logosu dovrebbero considerare WCAG 3.3.3 come un punto chiave di audit durante qualsiasi valutazione di accessibilità. È richiesto il test manuale di tutti i flussi di validazione dei form — inclusi sia gli stati di errore lato client che lato server — e dovrebbe essere mantenuta documentazione sulla motivazione delle eccezioni di sicurezza per qualsiasi campo in cui i suggerimenti correttivi siano intenzionalmente omessi. Il mancato rispetto dei requisiti di livello AA, incluso Error Suggestion, impedirà l’assegnazione del logo e può esporre le entità soggette a conseguenze amministrative ai sensi della circolare.