WCAG 3.3.7: Inserimento ridondante

Cosa Significa Questa Regola

WCAG 3.3.7 Redundant Entry è un criterio di successo di Livello A introdotto in WCAG 2.2. Stabilisce: «Le informazioni precedentemente inserite dall’utente o fornite all’utente, che devono essere inserite di nuovo nello stesso processo, sono o auto-compilate oppure disponibili per essere selezionate dall’utente.» In termini semplici, se un utente ha già digitato il proprio indirizzo email, indirizzo di spedizione, data di nascita o qualsiasi altra informazione durante una sessione, la tua interfaccia non deve costringerlo a digitarla di nuovo all’interno dello stesso processo o flusso.

Il criterio si applica in senso ampio a qualsiasi modulo multi-step, processo di checkout, procedura guidata di registrazione, flusso di prenotazione appuntamenti o sequenza simile in cui i dati raccolti in uno step possono essere necessari di nuovo in uno step successivo. I comportamenti interessati includono campi di testo, menu a discesa, checkbox, pulsanti di opzione (radio button) e qualsiasi altro controllo di modulo che raccolga dati forniti dall’utente. Quando la stessa informazione è richiesta di nuovo, deve essere o precompilata automaticamente usando il valore fornito in precedenza, oppure offerta come opzione selezionabile in modo che l’utente possa confermarla invece di reinserirla.

Un superamento di questo criterio si presenta così: un modulo di indirizzo di fatturazione precompilato con l’indirizzo di spedizione inserito dall’utente nella schermata precedente, oppure uno step di conferma che mostra l’indirizzo email inserito in precedenza in un campo di sola lettura. Un altro pattern conforme è una checkbox etichettata “Il mio indirizzo di fatturazione è uguale al mio indirizzo di spedizione” che, quando selezionata, copia automaticamente i valori. Un fallimento si presenta così: un flusso di registrazione multi-step che chiede l’indirizzo email allo step 1 e di nuovo allo step 3 senza precompilare il secondo campo, oppure un modulo di richiesta di rimborso assicurativo che chiede il nome del richiedente e il numero di polizza su più schermate separate senza alcun auto-fill.

WCAG 3.3.7 definisce due eccezioni ufficiali. La prima eccezione si applica quando reinserire l’informazione è essenziale per il processo — per esempio, un campo “Conferma la nuova password” chiede intenzionalmente agli utenti di digitare la stessa password due volte come protezione contro gli errori di digitazione, e questo è considerato un controllo di sicurezza essenziale. La seconda eccezione si applica quando le informazioni inserite in precedenza non sono più valide — ad esempio, se una sessione è scaduta o un prodotto è andato esaurito e l’utente deve riavviare un processo con dati aggiornati. Al di fuori di queste eccezioni, l’inserimento ridondante costituisce un mancato rispetto del criterio.

Perché È Importante

L’inserimento ridondante grava in modo sproporzionato sugli utenti le cui condizioni rendono la digitazione lenta, dolorosa, soggetta a errori o cognitivamente impegnativa. Comprendere chi è interessato aiuta sviluppatori e designer a capire perché questo criterio è più di una semplice funzionalità di comodità — è una vera e propria barriera per molte persone.

Utenti con disabilità motorie, come persone con tremori, lesioni al midollo spinale o condizioni come SLA o sclerosi multipla, possono fare affidamento su accesso a sensori (switch access), bastoncini bocca, software di tracciamento oculare o controllo vocale per inserire testo. Per questi utenti, digitare anche un breve indirizzo può richiedere diversi minuti e un notevole sforzo fisico. Essere costretti a ripetere quell’inserimento non è solo fastidioso — può causare dolore fisico o rendere il compito praticamente impossibile in una singola sessione.

Utenti con disabilità cognitive, tra cui dislessia, disturbi da deficit di attenzione, lesioni cerebrali traumatiche e condizioni correlate alla demenza, possono avere difficoltà a ricordare ciò che hanno inserito tre step prima. Trascrivere accuratamente le informazioni dalla memoria o da un documento cartaceo più volte aumenta notevolmente il tasso di errori e di abbandono. Secondo l’Organizzazione Mondiale della Sanità, oltre 1 miliardo di persone nel mondo vive con qualche forma di disabilità, e le disabilità cognitive rappresentano uno dei segmenti più grandi e meno serviti nella pianificazione dell’accessibilità.

Utenti con differenze agli arti superiori, inclusi coloro che sono nati con o hanno acquisito differenze agli arti, digitano molto più lentamente e possono usare dispositivi di input alternativi. Ogni singolo tasto richiesto in più moltiplica il carico su questi utenti.

Considera uno scenario reale: una persona con artrite reumatoide sta prenotando una visita medica tramite il portale online di un ospedale. Nella schermata 1 inserisce il proprio numero di identificazione nazionale, nome, data di nascita e numero di telefono di contatto. Nella schermata 3 il portale chiede di nuovo nome e data di nascita per confermare il record del paziente. Questa persona deve faticosamente ridigitare informazioni fornite solo due schermate prima, rischiando errori di digitazione che potrebbero far non corrispondere i record e subendo uno sforzo fisico non necessario. Una semplice precompilazione o auto-compilazione di quei campi eliminerebbe completamente la barriera.

Oltre all’accessibilità, eliminare l’inserimento ridondante migliora i tassi di conversione, riduce l’abbandono dei moduli e diminuisce i ticket di supporto causati da errori di inserimento dati — offrendo un valore aziendale misurabile insieme a un design inclusivo.

Regole Axe-core Correlate

WCAG 3.3.7 è un criterio che richiede test manuali. Attualmente non esiste alcuna regola automatizzata di axe-core che possa rilevare in modo affidabile violazioni di inserimento ridondante, perché gli strumenti automatici non possono comprendere la relazione semantica tra i dati inseriti in più step o pagine in un processo dinamico. Non hanno consapevolezza di quali informazioni siano state raccolte in uno step precedente, quali informazioni siano richieste nello step corrente o se queste due informazioni siano logicamente identiche. Solo un tester umano che percorre l’intero flusso può osservare e valutare se gli stessi dati vengono richiesti due volte senza precompilazione.

• Test manuale richiesto (nuovo in WCAG 2.2): axe-core e altri scanner automatici di accessibilità analizzano il DOM di uno stato di pagina alla volta. Non possono tracciare i valori inseriti dall’utente attraverso più caricamenti di pagina o step di un modulo, non possono confrontare le etichette dei campi tra gli step per identificare duplicazioni semantiche e non possono valutare se un meccanismo di precompilazione funzioni correttamente. I tester devono percorrere manualmente i processi multi-step, registrare quali dati inseriscono in ogni step e verificare in ogni step successivo se i dati forniti in precedenza siano auto-compilati o selezionabili. Qualsiasi strumento che affermi di rilevare automaticamente violazioni del criterio 3.3.7 produrrebbe un tasso di falsi negativi estremamente elevato e non dovrebbe essere considerato l’unico metodo di test.

Come Testare

1. Scansione automatizzata come punto di partenza: Esegui axe DevTools, Lighthouse o l’auditor Accsible su ogni singolo step del tuo processo multi-step. Sebbene questi strumenti non segnaleranno direttamente violazioni del criterio 3.3.7, evidenzieranno problemi correlati come attributi autocomplete mancanti, campi di modulo senza etichetta e altri fallimenti dei criteri 3.3.x che spesso co-occorrono. Documenta ogni campo di modulo che trovi in ogni step.
2. Mappa dei requisiti di dati tra gli step: Prima del test manuale, crea una semplice tabella o foglio di calcolo che elenchi ogni step del processo e tutti i campi dati che raccoglie. Quindi identifica qualsiasi etichetta di campo o tipo di dato che compaia in più di uno step. Questo esercizio di mappatura fa emergere potenziali violazioni ancora prima di aprire il browser.
3. Percorso manuale — desktop: Usando un mouse e una tastiera standard, completa l’intero processo multi-step (ad esempio, checkout, registrazione, invio di una richiesta). Inserisci valori realistici in ogni campo. Quando arrivi a uno step che nella tua mappa risulta avere un campo duplicato, verifica se il campo è precompilato con il valore inserito in precedenza o se è disponibile un’opzione selezionabile che presenti il valore inserito in precedenza. Se nessuna delle due condizioni è soddisfatta, registra un fallimento. Ripeti questo test con uno screen reader (NVDA con Firefox, JAWS con Chrome, VoiceOver con Safari) per confermare che i valori precompilati siano annunciati correttamente e che i controlli di selezione per i valori inseriti in precedenza siano raggiungibili tramite tastiera.
4. Percorso manuale — mobile: Completa lo stesso flusso su iOS (VoiceOver + Safari) e Android (TalkBack + Chrome). Presta attenzione al fatto che le funzionalità native di autocomplete o autofill non vengano disattivate dall’applicazione, cosa che potrebbe creare involontariamente barriere di inserimento ridondante anche se lo sviluppatore intendeva usare l’autocomplete come aiuto.
5. Test delle eccezioni: Identifica eventuali campi che chiedono intenzionalmente un inserimento duplicato (ad esempio, conferma password, reinserisci email). Verifica che rientrino nei controlli essenziali di sicurezza o validazione previsti dall’eccezione WCAG e che non siano semplicemente campi ridondanti che dovrebbero essere rimossi o precompilati.
6. Test con autocomplete disattivato: Alcuni utenti disattivano l’autocomplete del browser per motivi di privacy. Verifica se il meccanismo di precompilazione dell’applicazione (lato server o basato su JavaScript) funzioni ancora correttamente quando l’autocomplete del browser è disattivato, assicurando che il criterio sia soddisfatto indipendentemente dal comportamento del browser.

Come Correggere

Checkout multi-step — stesso indirizzo richiesto su due schermate — Non corretto

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Checkout multi-step — stesso indirizzo richiesto su due schermate — Corretto

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Procedura guidata di registrazione che chiede l’email due volte senza giustificazione — Non corretto

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Procedura guidata di registrazione — email precompilata dai dati di sessione — Corretto

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Prenotazione appuntamento — dati del paziente richiesti di nuovo nello step di riepilogo — Non corretto

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Prenotazione appuntamento — data di nascita mostrata come conferma in sola lettura — Corretto

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Errori Comuni

• Costruire moduli multi-step come pagine indipendenti senza uno stato di sessione condiviso, così da non avere alcun meccanismo per portare avanti i valori inseriti negli step precedenti — l’errore architetturale più fondamentale che porta a fallimenti del criterio 3.3.7.
• Fornire una checkbox “uguale all’indirizzo di spedizione” ma senza popolare effettivamente i campi di fatturazione quando è selezionata, costringendo gli utenti a digitare comunque manualmente i dettagli dell’indirizzo anche dopo aver indicato che dovrebbero coincidere.
• Precompilare i campi al caricamento della pagina ma poi svuotarli in caso di errore di validazione, così che un utente che commette un errore in uno step successivo debba reinserire tutti i dati forniti in precedenza quando torna per correggerlo.
• Archiviare i dati di sessione in modo non sicuro e scegliere di disattivarli invece di risolvere il problema di sicurezza, con il risultato di un’esperienza di precompilazione interrotta che tecnicamente costituisce un fallimento del criterio 3.3.7.
• Usare l’eccezione della conferma password come giustificazione per far reinserire agli utenti gli indirizzi email, quando la conferma dell’email non è un controllo di sicurezza essenziale e non rientra nell’eccezione WCAG.
• Non trasmettere i valori riportati tramite campi nascosti nei moduli renderizzati lato server, causando la perdita dei valori precompilati quando un utente naviga avanti e indietro tra gli step usando i pulsanti di cronologia del browser.
• Fare affidamento esclusivamente sull’autofill del browser per soddisfare questo criterio, senza implementare una precompilazione a livello di applicazione — gli utenti che disattivano l’autofill per motivi di privacy non hanno quindi alcun percorso conforme attraverso il processo.
• Precompilare un campo ma impostarlo come disabled invece che readonly, il che fa sì che il valore venga escluso dall’invio del modulo nella maggior parte dei browser, interrompendo il processo e potenzialmente costringendo a un reinserimento.
• Non testare l’intero flusso end-to-end con utenti che usano software di input vocale come Dragon NaturallySpeaking, dove i campi ridondanti possono richiedere di ripetere più volte lo stesso comando di dettatura vocale, un carico significativo che è facile trascurare nei test degli sviluppatori.
• Considerare questo criterio applicabile solo ai campi di indirizzo, quando si applica in egual misura a qualsiasi dato ripetuto, inclusi nomi, numeri di telefono, numeri di identificazione nazionale, numeri di polizza, date e qualsiasi altra informazione fornita dall’utente richiesta più di una volta nello stesso processo.

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, impone la conformità all’accessibilità web per un’ampia gamma di soggetti pubblici e privati che operano in Turchia. WCAG 3.3.7 Redundant Entry è un criterio di Livello A in WCAG 2.2, e la conformità di Livello A è la base obbligatoria prevista da questa circolare. Ciò significa che qualsiasi soggetto interessato che gestisca un sito web, un’applicazione web o un servizio digitale non deve richiedere agli utenti di reinserire informazioni che hanno già fornito all’interno dello stesso processo — senza eccezioni — pena la non conformità.

La circolare stabilisce una tempistica di implementazione graduale: le istituzioni pubbliche devono raggiungere la conformità entro un anno dalla pubblicazione della circolare, mentre i soggetti del settore privato nelle categorie interessate hanno due anni per adeguarsi.

I tipi di soggetti coperti dalla circolare sono numerosi e includono piattaforme e marketplace di e-commerce, tutte le istituzioni pubbliche e le agenzie governative, banche e fornitori di servizi finanziari, ospedali e portali sanitari (sia pubblici che privati), 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). Per tutti questi soggetti, i processi digitali multi-step — flussi di checkout sui siti di e-commerce, registrazione dei pazienti sui portali ospedalieri, apertura di conti sulle piattaforme bancarie, moduli di iscrizione sui siti delle scuole — devono essere verificati e corretti per eliminare qualsiasi caso di inserimento ridondante.

In pratica, questa normativa colloca la conformità al criterio WCAG 3.3.7 al centro delle attività di approvvigionamento, prodotto e legali nell’economia digitale turca. Ad esempio, una piattaforma di e-commerce turca che gestisce un checkout multi-step che chiede un indirizzo di consegna in una schermata e un indirizzo di fatturazione nella successiva senza offrire un’opzione di precompilazione o copia è in violazione diretta sia di WCAG 2.2 Livello A sia della Circolare Presidenziale. Allo stesso modo, il portale di prenotazione appuntamenti di un ospedale statale che chiede ai pazienti di reinserire il numero di identità o la data di nascita su più schermate non è conforme. Le organizzazioni soggette alla circolare dovrebbero dare priorità a una verifica end-to-end di tutti i processi multi-step come parte della loro roadmap di conformità, trattando l’eliminazione dell’inserimento ridondante come un’attività di ingegneria obbligatoria, non come un miglioramento opzionale.