WCAG 3.3.6: Prevenzione degli errori (tutti)

Cosa Significa Questa Regola

WCAG 3.3.6 — Prevenzione degli errori (Tutti) è un criterio di successo di livello AAA sotto il principio Comprensibile. Estende i requisiti di 3.3.4 (Prevenzione degli errori: legali, finanziari, dati) per coprire tutte le pagine che richiedono all’utente di inviare informazioni, indipendentemente dal fatto che tale invio comporti impegni legali, transazioni finanziarie o dati personali identificabili.

Alla base, il criterio richiede che, per qualsiasi pagina web in cui un utente invia informazioni, sia soddisfatta almeno una delle seguenti tre condizioni:

• Reversibile: Gli invii sono reversibili dopo il fatto. L’utente può annullare, cancellare o ritirare un’azione entro un lasso di tempo ragionevole. Ad esempio, un messaggio inviato può essere richiamato, oppure un modulo inviato può essere annullato da una coda di conferma.
• Verificato: I dati inseriti dall’utente vengono controllati per errori di input prima dell’invio finale e all’utente viene data l’opportunità di correggere tali errori. Ciò implica validazione in linea, riepiloghi pre-invio o flussi di revisione passo dopo passo.
• Confermato: È fornito un meccanismo per rivedere, confermare e correggere le informazioni prima che l’invio sia finalizzato. Questo può essere una schermata di revisione, una finestra di conferma o una procedura guidata multi-step con un passaggio finale di revisione.

La distinzione chiave tra 3.3.4 e 3.3.6 è l’ambito. Il criterio 3.3.4 si applica solo ad accordi legali, transazioni finanziarie, risposte a test e cancellazioni di dati controllati dall’utente. Il criterio 3.3.6 estende questo a ogni pagina che richiede qualsiasi forma di invio di input da parte dell’utente — inclusi moduli di contatto, iscrizioni a newsletter, sezioni di commenti, risposte a sondaggi, aggiornamenti del profilo, impostazioni di ricerca e qualsiasi altro inserimento di dati controllato dall’utente.

Cosa è considerato conforme: Un modulo è conforme se implementa in modo coerente almeno uno dei tre meccanismi sopra. Una pagina di conferma prima dell’invio finale, una schermata di riepilogo con un’opzione "Modifica", la validazione lato client o lato server con opportunità di correzione degli errori, o una finestra di annullamento chiaramente comunicata soddisfano tutti il criterio.

Cosa è considerato non conforme: Un modulo a singolo passaggio che invia i dati immediatamente al clic del pulsante senza validazione, senza schermata di revisione e senza meccanismo di annullamento non soddisfa questo criterio. Allo stesso modo, un modulo che valida ma non offre l’opportunità di correggere gli errori prima di un nuovo invio non è conforme.

Le specifiche WCAG non richiedono tutti e tre i meccanismi simultaneamente — è sufficiente soddisfarne uno. Tuttavia, combinare due o tre meccanismi fornisce una difesa in profondità e serve una gamma più ampia di utenti e contesti.

Perché È Importante

La prevenzione degli errori non è semplicemente una comodità di usabilità — è un requisito fondamentale di accessibilità per gli utenti che affrontano un rischio elevato di errori di input a causa di disabilità o menomazioni situazionali.

Disabilità cognitive e dell’apprendimento: Utenti con dislessia, ADHD o deficit di memoria commettono frequentemente errori di battitura, scambiano cifre o perdono il filo in moduli complessi con molti campi. Senza un meccanismo di revisione, un indirizzo email digitato male in un modulo di contatto può significare una risposta mancata, o un indirizzo inserito in modo errato in un modulo di consegna può causare pacchi smarriti. Questi non sono casi limite — secondo l’Organizzazione Mondiale della Sanità, circa 1 miliardo di persone nel mondo vive con qualche forma di condizione cognitiva o neurologica che influisce sul funzionamento quotidiano.

Disabilità motorie: Utenti con tremori, limitato controllo motorio fine, o che si affidano a sistemi di accesso a interruttore o software di input vocale, spesso attivano l’invio dei moduli accidentalmente o inseriscono caratteri indesiderati. Una persona con il morbo di Parkinson che compila un modulo complesso con un’interfaccia a interruttore può inviare involontariamente un modulo incompleto o errato. Senza reversibilità o passaggi di conferma, questi errori diventano permanenti.

Utenti di screen reader: Utenti ciechi che navigano con JAWS, NVDA o VoiceOver potrebbero non avere la stessa visione d’insieme visiva di un modulo completato di cui godono gli utenti vedenti prima dell’invio. Una schermata di conferma o un riepilogo letto ad alta voce da uno screen reader offre a questi utenti un’ultima possibilità di verificare i propri dati prima che siano inviati in modo irreversibile.

Bassa alfabetizzazione digitale e popolazioni anziane: Gli adulti più anziani e gli utenti nuovi alle interfacce digitali sono particolarmente vulnerabili agli invii accidentali. Un passaggio di conferma con riepiloghi in linguaggio semplice fornisce una rete di sicurezza che riduce drasticamente i costi di supporto e la frustrazione degli utenti.

Scenario reale: Si consideri un portale di e-government turco in cui un cittadino compila un lungo modulo burocratico per registrare un’attività. Se il cittadino omette accidentalmente un campo obbligatorio o inserisce il proprio numero di identificazione fiscale in modo errato e il modulo viene inviato immediatamente senza un passaggio di revisione, potrebbe non rendersi conto dell’errore fino a ricevere una notifica formale di rifiuto giorni dopo. Una semplice schermata di conferma che mostra tutti i dati inseriti prima dell’invio finale avrebbe prevenuto completamente questo problema.

Benefici per SEO e usabilità: Le pagine che implementano una prevenzione degli errori solida tendono ad avere tassi di abbandono dei moduli più bassi, tassi di conversione più alti e punteggi di soddisfazione degli utenti migliori. I motori di ricerca tengono sempre più conto dei segnali di esperienza utente nei ranking, e le pagine con alti tassi di rimbalzo dovuti a errori nei moduli soffrono indirettamente in termini di visibilità organica.

Regole Axe-core Correlate

WCAG 3.3.6 richiede test manuali perché nessuno strumento automatico può determinare se un determinato flusso di invio di un modulo soddisfa i requisiti di reversibilità, controllo degli errori o conferma di questo criterio. Gli scanner di accessibilità automatici come axe-core possono verificare la presenza di singoli attributi ARIA, etichette e messaggi di errore, ma non possono valutare la logica complessiva del flusso di invio, l’esistenza di un passaggio di conferma o se un meccanismo di annullamento è effettivamente funzionale. Il criterio riguarda fondamentalmente il design dell’interazione e il flusso dell’esperienza utente — non il markup statico.

• Non esiste una regola axe-core dedicata per 3.3.6. Axe-core e motori simili testano singoli elementi del DOM rispetto a specifici requisiti di attributo o ruolo. Determinare se un modulo multipagina include un passaggio di revisione prima dell’invio finale richiede la comprensione del flusso di navigazione dell’applicazione e del comportamento lato server — informazioni a cui gli strumenti di analisi statica non possono accedere. Un tester umano deve percorrere l’intero percorso di invio per valutare la conformità.
• Regole correlate che supportano la qualità complessiva dei moduli (sebbene non specificamente 3.3.6): Regole come label (ogni input ha un’etichetta associata), aria-required-attr (gli attributi ARIA obbligatori sono presenti) e form-field-multiple-labels (gli input non hanno etichette in conflitto) contribuiscono alle fondamenta di moduli accessibili. Assicurarsi che queste siano superate è un prerequisito per una prevenzione degli errori significativa, ma superarle non garantisce la conformità a 3.3.6.
• Perché l’automazione non è sufficiente: Una scansione automatica di una pagina di checkout può confermare che tutti i campi di input hanno etichette e che i messaggi di errore sono associati in modo programmatico agli input. Ma non può determinare se cliccando su "Invia" l’utente viene portato a una schermata di revisione, se esiste un’opzione "Annulla" o se il sistema invia un’email di conferma con un link di cancellazione. Si tratta di questioni di comportamento e di processo che solo una valutazione umana può risolvere.

Come Testare

1. Esegui una scansione automatica come base: Usa axe DevTools, Lighthouse o la modalità di audit integrata del widget Accsible per analizzare tutte le pagine contenenti moduli. Sebbene questi strumenti non segnaleranno direttamente violazioni di 3.3.6, stabiliscono una base identificando etichette mancanti, messaggi di errore assenti o feedback di validazione associato in modo improprio. Risolvi tutti i problemi rilevati automaticamente prima di procedere ai test manuali.
2. Identifica tutti i moduli di invio sul sito: Crea un inventario completo di ogni pagina che accetta e invia input dell’utente — moduli di contatto, moduli di registrazione, moduli di login, moduli per le preferenze di ricerca, pagine di aggiornamento del profilo, sezioni di commenti, iscrizioni a newsletter e qualsiasi procedura guidata multi-step. Ognuno deve essere testato in modo indipendente.
3. Testa il percorso ideale con errori intenzionali: Su ogni modulo, inserisci intenzionalmente dati errati, incompleti o malformati (ad esempio, un indirizzo email non valido, un numero di telefono con lettere, campi obbligatori lasciati vuoti). Invia il modulo e osserva: la pagina impedisce l’invio e fornisce messaggi di errore? I messaggi di errore sono associati ai campi corretti? L’utente ha un’opportunità chiara di correggere e reinviare?
4. Testa la presenza di meccanismi di conferma o revisione: Per i moduli che superano la validazione, completa il modulo con dati validi e invia. Osserva se compare una schermata di conferma, una finestra di riepilogo o un passaggio di revisione prima che i dati siano irrevocabilmente inviati. Verifica che il passaggio di revisione consenta all’utente di tornare indietro e modificare le voci.
5. Testa la reversibilità dopo l’invio: Dopo un invio riuscito, verifica se esiste un meccanismo di cancellazione, annullamento o ritiro. Questo potrebbe essere un link "Annulla invio" in un’email di conferma, una schermata di gestione della coda in un’area di amministrazione o una notifica in-app con un’azione di annullamento. Verifica che il meccanismo funzioni e sia chiaramente comunicato agli utenti.
6. Test con screen reader usando NVDA + Firefox: Naviga fino a ciascun modulo usando NVDA e Firefox. Spostati tra tutti i campi con il tasto Tab, inserisci i dati e invia il modulo. Verifica che i messaggi di errore vengano annunciati quando compaiono, che la schermata di revisione (se presente) sia completamente leggibile nell’ordine del documento e che tutti i controlli interattivi (pulsanti di modifica, conferma, annullamento) sulla schermata di conferma siano accessibili da tastiera e correttamente etichettati.
7. Test con screen reader usando VoiceOver + Safari (macOS/iOS): Ripeti il processo sopra usando VoiceOver su Safari. Presta particolare attenzione agli aggiornamenti dinamici dei contenuti — se gli errori di validazione compaiono dinamicamente tramite JavaScript senza ricaricare la pagina, conferma che siano esposti tramite regioni live (aria-live) in modo che VoiceOver li annunci senza richiedere all’utente di esplorare manualmente la pagina.
8. Test solo tastiera: Senza mouse, naviga attraverso l’intero flusso di invio del modulo usando solo i tasti Tab, Shift+Tab, Invio e Barra spaziatrice. Conferma che ogni elemento interattivo — inclusi i pulsanti di modifica, indietro, conferma e annullamento sulle schermate di revisione — sia raggiungibile e utilizzabile senza un dispositivo di puntamento.

Come Correggere

Modulo di contatto senza validazione o revisione — Non corretto

<!-- Non conforme a 3.3.6: invia immediatamente senza validazione, senza revisione, senza annullamento -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Modulo di contatto con validazione e passaggio di conferma — Corretto

<!-- Passaggio 1: modulo con validazione lato client prima dell'invio -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Il pulsante di revisione attiva un riepilogo di conferma prima dell'invio finale -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Passaggio 2: schermata di conferma/revisione (mostrata dopo il superamento della validazione) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- L'opzione di modifica soddisfa il requisito di 'reversibile/correggibile prima del commit finale' -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Procedura guidata multi-step senza passaggio di riepilogo — Non corretto

<!-- Non conforme a 3.3.6: il passaggio finale invia direttamente senza consentire all'utente di rivedere i passaggi precedenti -->
<form action='/register' method='post'>
  <!-- Passaggio 3 di 3 — nessuna possibilità di rivedere i passaggi 1 e 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Procedura guidata multi-step con passaggio finale di revisione — Corretto

<!-- Passaggio 4 di 4: riepilogo di revisione prima dell'invio finale -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Invio finale solo dopo che l'utente ha rivisto tutti i dati -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Modulo con invio immediato e senza annullamento — Non corretto

<!-- Non conforme a 3.3.6: elimina il commento immediatamente senza annullamento o conferma -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Azione distruttiva con finestra di dialogo di conferma — Corretto

<!-- Conforme a 3.3.6: l'utente deve confermare prima che l'azione distruttiva venga eseguita -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Errori Comuni

• Implementare la validazione ma non renderla disponibile agli screen reader: Mostrare i messaggi di errore visivamente tramite cambi di colore CSS o icone senza associarli all’input usando aria-describedby o inserirli in una regione aria-live significa che gli utenti ciechi non sentiranno mai l’errore — il modulo sembra essere stato inviato correttamente pur rimanendo in realtà incompleto.
• Considerare la conformità a 3.3.4 sufficiente per il livello AAA: I team spesso implementano la prevenzione degli errori solo per i moduli finanziari o legali (soddisfacendo 3.3.4) e presumono che tutti i moduli siano coperti. Il criterio 3.3.6 richiede le stesse protezioni per ogni modulo sul sito, incluse iscrizioni a newsletter, commenti e aggiornamenti del profilo.
• Fornire una schermata di conferma che è di sola lettura senza percorso di modifica: Una pagina di revisione che mostra i dati inviati ma offre solo un pulsante "Conferma" — senza modo di tornare indietro e correggere gli errori — non soddisfa pienamente lo spirito del criterio e lascia gli utenti senza possibilità di intervento se notano un errore durante la revisione.
• Usare window.confirm() come unico meccanismo di conferma: Le finestre di dialogo di conferma native del browser non sono accessibili a tutti gli utenti e non possono essere stilizzate o strutturate per chiarezza. Inoltre, si comportano in modo incoerente tra le diverse tecnologie assistive. Usa invece un elemento <dialog> appropriato con gli attributi ARIA corretti.
• Reimpostare l’intero modulo in caso di errore di validazione invece di preservare le voci valide: Quando un utente invia un modulo con 10 campi e un solo errore e il modulo cancella tutti i campi, l’utente deve reinserire tutti i dati. Ciò è particolarmente gravoso per gli utenti con disabilità motorie o affaticamento cognitivo. Preserva sempre i dati validi e concentra l’attenzione solo sui campi errati.
• Posizionare i messaggi di riepilogo degli errori fuori dalla viewport o dall’ordine di focus della tastiera: Un banner di riepilogo degli errori inserito nella parte superiore della pagina dopo un invio non riuscito non serve agli utenti che sono focalizzati a metà modulo. Usa aria-live='assertive' sul contenitore del riepilogo e sposta il focus su di esso in modo programmatico in caso di invio non riuscito.
• Contrassegnare i pulsanti di conferma con etichette vaghe come "OK" o "Yes": Su una schermata di revisione, i pulsanti devono comunicare chiaramente cosa accadrà. "Confirm and Send Message" è inequivocabile; "OK" non lo è — soprattutto per gli utenti di screen reader che potrebbero non avere a disposizione il contesto visivo circostante.
• Presumere che la sola validazione lato server soddisfi il criterio: Se la validazione lato client è assente, ogni invio richiede un round-trip completo al server prima che l’utente venga a conoscenza di un errore. Gli utenti con connessioni lente o che perdono la rete durante l’invio possono trovarsi in uno stato incerto senza un chiaro feedback di errore.
• Non testare il meccanismo di reversibilità in condizioni realistiche: I team a volte implementano un’opzione di "annullamento" in un’email di conferma ma non testano mai se il link di annullamento è accessibile, se funziona dopo la scadenza della finestra temporale o se il link è utilizzabile dagli screen reader. Un meccanismo di annullamento inaccessibile non soddisfa il criterio.
• Non gestire i casi limite di auto-fill nelle schermate di revisione: Quando l’auto-fill del browser o del password manager compila i campi del modulo, i valori visualizzati in una schermata di revisione potrebbero non corrispondere a quelli effettivamente inviati se lo script JavaScript che popola la revisione preleva i dati dal DOM prima che l’auto-fill sia completato. Recupera sempre i valori immediatamente prima di renderizzare la schermata di revisione, non al caricamento iniziale della pagina.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce obblighi di accessibilità digitale obbligatori per un’ampia gamma di entità che operano in Turchia. La circolare richiede alle organizzazioni interessate di conformarsi a WCAG 2.2 a livello AA come base. Le entità esplicitamente coperte includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio autorizzate, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

WCAG 3.3.6 è un criterio di livello AAA e pertanto non è un requisito legale diretto ai sensi della Circolare 2025/10. Tuttavia, la sua importanza nel contesto normativo turco non dovrebbe essere sottovalutata. Diversi dei tipi di entità coperte — in particolare banche, piattaforme di e-commerce e fornitori di servizi sanitari — gestiscono moduli transazionali ad alto rischio in cui la prevenzione degli errori non è semplicemente una best practice ma una necessità legale ed etica. Un modulo di bonifico online di una banca turca, un sistema di prenotazione appuntamenti di un portale sanitario o un flusso di checkout di e-commerce che manca di passaggi di conferma o meccanismi di correzione degli errori potrebbero non violare 3.3.6 in senso giuridicamente applicabile, ma creano un rischio significativo di danno per gli utenti con disabilità ed espongono l’organizzazione a rischi reputazionali e operativi.

Inoltre, la circolare segnala una chiara traiettoria verso un aumento dei requisiti di accessibilità nel tempo, in linea con il quadro dell’European Accessibility Act (EAA) con cui la Turchia si sta allineando. Le organizzazioni che implementano oggi criteri di livello AAA come 3.3.6 sono proattivamente posizionate per futuri irrigidimenti normativi e dimostrano un impegno per il design inclusivo che va oltre la conformità minima. Per entità come ospedali privati e istituzioni finanziarie che servono popolazioni anziane o utenti con disabilità cognitive e motorie in percentuali sproporzionatamente elevate, implementare 3.3.6 su tutti i moduli è una solida decisione di gestione del rischio indipendentemente dal suo status legale. L’SDK di overlay di Accsible può aiutare a mettere in evidenza i messaggi di errore, rafforzare gli stati di validazione e fornire prompt di conferma supplementari come livello di protezione avanzata per le organizzazioni turche che mirano a essere leader in materia di accessibilità.