WCAG 2.2.5: Nuova autenticazione

Cosa Significa Questa Regola

WCAG 2.2.5 Re-authenticating appartiene alla Linea guida 2.2 (Tempo sufficiente) ed è un requisito di Livello AAA. Il criterio afferma: «Quando una sessione autenticata scade, l’utente può continuare l’attività senza perdita di dati dopo essersi nuovamente autenticato.» In termini pratici, questo significa che se un utente è nel mezzo della compilazione di un modulo, del completamento di un acquisto, della composizione di un messaggio o di qualsiasi attività in più passaggi su una piattaforma autenticata e la sua sessione scade, deve poter effettuare nuovamente l’accesso e riprendere esattamente da dove aveva interrotto — con tutti i dati inseriti in precedenza preservati.

Questo criterio è strettamente correlato a WCAG 2.2.1 (Timing Adjustable, Livello A) e 2.2.4 (Interruptions, Livello AAA), ma affronta uno scenario specifico: il momento in cui viene superato il confine della sessione. Mentre 2.2.1 richiede di dare agli utenti tempo sufficiente o di permettere loro di estendere la sessione, 2.2.5 gestisce il caso di fallimento — cosa succede dopo che il tempo è trascorso. I due lavorano insieme: idealmente si estende la sessione e si preservano i dati se questa dovesse comunque scadere.

Un superamento di questo criterio richiede che la piattaforma preservi tutti i dati inseriti dall’utente — campi di testo, opzioni selezionate, allegati di file, checkbox, pulsanti di opzione e qualsiasi altro stato del modulo — attraverso un evento di ri-autenticazione. Dopo che l’utente ha effettuato nuovamente l’accesso, deve essere riportato allo stesso punto dell’attività che stava svolgendo, con i suoi dati intatti e il compito completabile senza ripetizioni.

Un fallimento si verifica quando un timeout di sessione causa uno dei seguenti casi: l’utente viene reindirizzato a una pagina di login e, dopo il login avvenuto con successo, viene mandato alla homepage invece che alla pagina in cui si trovava; i dati del modulo inseriti prima del timeout vengono persi e l’utente deve reinserire tutto; lo stato parzialmente completato di una procedura guidata multi-step viene azzerato; oppure l’utente viene semplicemente disconnesso senza alcun meccanismo per ri-autenticarsi e riprendere.

La specifica ufficiale WCAG non definisce una durata minima della sessione per questo criterio — si applica indipendentemente da quanto lungo o breve sia il periodo di timeout. Tuttavia, si noti che non è prevista alcuna eccezione per la perdita di dati dovuta a problemi di sicurezza; l’aspettativa è che le implementazioni trovino modi sicuri per preservare lo stato, come l’archiviazione della sessione lato server associata all’identità dell’utente, o token crittografati lato client che sopravvivono al flusso di ri-autenticazione.

Perché È Importante

I timeout di sessione che cancellano i dati creano un onere sproporzionatamente grave per le persone con disabilità. Molti utenti con disabilità richiedono molto più tempo per completare compiti digitali rispetto ai loro pari non disabili, e spesso non possono semplicemente “digitare più velocemente” o “aggirare” un timeout arbitrario.

Gli utenti che sono ciechi o ipovedenti navigano nei moduli usando screen reader, il che è intrinsecamente più lento della scansione visiva. Una persona cieca che compila un lungo modulo di richiesta di rimborso assicurativo può impiegare 20 o 30 minuti a navigare con attenzione campo per campo, solo per vedere il proprio lavoro cancellato quando scatta un timeout di sessione di 15 minuti. Deve quindi ricominciare da capo — senza alcuna garanzia che la stessa cosa non accada una seconda volta.

Le persone con disabilità motorie — come chi utilizza dispositivi di accesso a sensore, tecnologia di eye-tracking o bastoncini bocca — possono impiegare diverse volte più tempo della media per inserire testo e navigare nei moduli. Un utente con SLA o atrofia muscolare spinale può stare compilando un modulo medico critico e digitare solo pochi caratteri al minuto. I timeout di sessione che distruggono il loro lavoro non sono un semplice inconveniente; possono costituire una barriera completa al completamento di compiti essenziali.

Gli utenti con disabilità cognitive, inclusi quelli con dislessia, ADHD, lesioni cerebrali traumatiche o demenza, possono aver bisogno di rileggere le istruzioni più volte, fare pause per elaborare le informazioni o semplicemente procedere più lentamente attraverso processi in più passaggi. La ricerca mostra costantemente che questa popolazione è colpita in modo sproporzionato dalla pressione del tempo e dalla perdita di dati — entrambi fattori che aumentano il carico cognitivo del tentativo di ricominciare da zero.

Consideriamo uno scenario concreto reale: una persona con sclerosi multipla sta facendo domanda per un sussidio di invalidità governativo tramite il portale web di un’istituzione pubblica. La domanda ha 8 passaggi e richiede il caricamento di documenti medici, l’inserimento della storia lavorativa e la stesura di una dichiarazione personale. Arriva al 6° passaggio in 45 minuti, la sessione scade e tutti i dati inseriti vengono persi. Ora deve raccogliere di nuovo gli stessi documenti e ripetere l’intero processo, potenzialmente abbandonando del tutto la domanda. Questo non è un caso ipotetico — è un modello documentato ripetutamente nella ricerca e nei test di usabilità sull’accessibilità.

Oltre alla disabilità, la perdita di dati al timeout di sessione colpisce tutti gli utenti e ha impatti aziendali misurabili: carrelli abbandonati, registrazioni incomplete e contatti persi. Preservare lo stato della sessione è sia un imperativo di accessibilità sia una solida pratica di UX e di ottimizzazione delle conversioni. Secondo il Baymard Institute, l’abbandono dei moduli è un contributore principale ai tassi di abbandono del carrello nell’e-commerce, e la perdita imprevista di dati è uno dei motivi più citati per cui gli utenti non completano gli acquisti online.

Regole Axe-core Correlate

WCAG 2.2.5 richiede solo test manuali. Non esistono regole automatizzate di axe-core che possano rilevare in modo affidabile le violazioni di questo criterio. Quanto segue spiega perché gli strumenti automatici non sono sufficienti e cosa devono fare invece i tester umani:

• Non esiste alcuna regola automatica per la preservazione dello stato di sessione: Axe-core e motori di accessibilità automatizzati simili operano ispezionando il DOM corrente e valutando condizioni statiche o quasi statiche come i rapporti di contrasto dei colori, la correttezza degli attributi ARIA e la mancanza di testo alternativo. Non possono simulare il passare del tempo, attivare un evento di scadenza della sessione, inviare le credenziali di ri-autenticazione e poi verificare se i dati inseriti in precedenza sono stati ripristinati. Questa intera sequenza è un comportamento con stato e dipendente dal tempo che richiede l’osservazione da parte di un essere umano (o di un test end-to-end scriptato).
• Il rilevamento del timeout di sessione è fuori ambito per l’analisi statica: Anche se uno strumento automatico potesse rilevare che una pagina implementa un timeout di sessione (ad esempio leggendo un meta refresh o una chiamata JavaScript setTimeout), non può valutare cosa succede ai dati dell’utente dopo che il timeout scatta. Il comportamento di preservazione dei dati risiede nella logica di gestione della sessione lato server, non nella struttura del DOM che gli strumenti automatici analizzano.
• Complessità del flusso di ri-autenticazione: L’esperienza di ri-autenticazione può coinvolgere più pagine (modulo di login, prompt MFA, redirect) e il ripristino dello stato può dipendere da logica lato server, cookie, archiviazione locale o parametri URL. Nessuno strumento di ispezione del DOM di una singola pagina può tracciare questo flusso multi-pagina e multi-sistema.
• Perché il test manuale è essenziale: Un tester qualificato deve avviare manualmente un flusso autenticato, attendere deliberatamente la scadenza della sessione o provocarla, completare il processo di ri-autenticazione e poi verificare l’integrità dei dati. Questo è l’unico metodo affidabile per testare la conformità. Le scansioni automatiche possono essere usate come punto di partenza per segnalare problemi correlati (come la mancanza di meccanismi di avviso di sessione coperti da 2.2.1), ma non possono sostituire i test manuali per 2.2.5.

Come Testare

1. Identificare i flussi autenticati con moduli o processi in più passaggi. Iniziare mappando tutte le aree del sito che richiedono autenticazione e che comportano l’inserimento di dati da parte dell’utente — flussi di checkout, editor di profilo, moduli di domanda, sistemi di prenotazione, interfacce di messaggistica e dashboard amministrative. Queste sono le aree a più alto rischio di fallimenti rispetto a 2.2.5.
2. Determinare la durata del timeout di sessione. Verificare la configurazione del server, le impostazioni dell’applicazione o consultare il team di sviluppo per sapere quando le sessioni scadono. In alternativa, avviare una sessione e attendere finché non si viene disconnessi automaticamente. Annotare la durata. I timeout comuni vanno da 15 minuti a 2 ore.
3. Iniziare un’attività e inserire una quantità significativa di dati. Effettuare il login e iniziare a compilare un modulo rappresentativo — ad esempio, un flusso di registrazione o di acquisto con molti campi. Inserire testo nei campi di testo, effettuare selezioni e procedere attraverso eventuali passaggi della procedura guidata. Non inviare il modulo.
4. Attivare la scadenza della sessione. Attendere che si verifichi il timeout naturale oppure — se si dispone di accesso da sviluppatore — far scadere artificialmente la sessione invalidando il cookie di sessione negli strumenti di sviluppo del browser (scheda Application > Cookies > eliminare il cookie di sessione), o facendo scadere direttamente la sessione lato server.
5. Osservare il prompt di ri-autenticazione. Verificare se il sito invita a ri-autenticarsi (superamento) o semplicemente reindirizza a una pagina di login senza preavviso (un problema di usabilità correlato, sebbene 2.2.5 si concentri sulla preservazione dei dati, non sull’avviso in sé). Tentare di effettuare nuovamente il login.
6. Verificare la preservazione dei dati dopo il login. Dopo essersi ri-autenticati con successo, osservare dove si viene reindirizzati e se i dati inseriti in precedenza sono intatti. Se si viene mandati alla homepage e/o i dati del modulo sono scomparsi, si tratta di un fallimento rispetto a 2.2.5.
7. Testare con tecnologie assistive. Ripetere la sequenza di test sopra descritta usando NVDA con Firefox, JAWS con Chrome e VoiceOver con Safari per assicurarsi che il prompt di ri-autenticazione sia accessibile agli utenti di screen reader e che lo stato della pagina ripristinata sia annunciato correttamente. Un utente vedente potrebbe riconoscere visivamente i dati ripristinati; un utente di screen reader ha bisogno che il focus sia posizionato correttamente e che il contenuto ripristinato sia nell’ordine di lettura.
8. Testare la navigazione tramite sola tastiera. Assicurarsi che l’intero processo di ri-autenticazione — dall’avviso di scadenza della sessione all’accesso nuovamente effettuato fino al ritorno al compito preservato — sia completabile usando solo la tastiera, senza richiedere il mouse.
9. Testare con simulazioni di timeout estesi. Se possibile, ridurre il timeout di sessione a 1–2 minuti in un ambiente di sviluppo ed eseguire test completi del percorso utente per rendere il ciclo di test più rapido e ripetibile.

Come Correggere

Modulo di Login Semplice con Timeout di Sessione — Errato

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Modulo di Login Semplice con Timeout di Sessione — Corretto

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Procedura Guidata Multi-Step che Perde i Progressi — Errato

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Procedura Guidata Multi-Step che Perde i Progressi — Corretto

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Avviso di Scadenza della Sessione Senza Preservazione dei Dati — Errato

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Avviso di Scadenza della Sessione Senza Preservazione dei Dati — Corretto

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Errori Comuni

• Reindirizzare alla homepage dopo la ri-autenticazione invece che alla pagina originale: Il modello di fallimento più comune. Dopo il login, l’applicazione manda l’utente a /dashboard o / invece che all’URL in cui si trovava quando la sessione è scaduta, costringendolo a tornare manualmente al proprio compito — e i suoi dati sono già spariti.
• Archiviare lo stato del modulo solo in memoria JavaScript o nello stato dei componenti React/Vue: Lo stato del framework lato client non sopravvive a un ricaricamento della pagina attivato da un redirect al login dovuto alla scadenza della sessione. Lo stato deve essere preservato lato server o in un meccanismo di archiviazione (ad es. localStorage) che venga ripristinato in modo affidabile al ritorno.
• Salvare un “return URL” ma non i dati del modulo: Alcune implementazioni memorizzano l’URL a cui reindirizzare dopo il login ma non salvano i valori effettivi dei campi del modulo. L’utente arriva alla pagina corretta ma con i campi vuoti, il che viola comunque 2.2.5.
• Salvataggio automatico in sessionStorage che viene cancellato alla chiusura della scheda: Se la scadenza della sessione fa sì che la scheda del browser navighi altrove (ad es. redirect al login), sessionStorage viene cancellato. Usare localStorage con uno spazio dei nomi associato all’utente, o preferibilmente un salvataggio bozza lato server.
• Non testare con campi di caricamento file: I campi file non possono essere pre-popolati tramite HTML per motivi di sicurezza. Se un modulo include un caricamento di file completato prima della scadenza della sessione, il riferimento al file viene perso. Le applicazioni devono gestire questo caso archiviando i riferimenti ai file caricati lato server e mostrando all’utente che il file è ancora allegato.
• Cancellare i dati della bozza salvata immediatamente alla ri-autenticazione: Alcune implementazioni eliminano la bozza non appena l’utente effettua il login, prima di verificare che l’utente abbia effettivamente visto e confermato i dati ripristinati. La bozza dovrebbe essere preservata finché il compito non è esplicitamente completato o annullato.
• Non annunciare i dati ripristinati agli utenti di screen reader: Dopo la ri-autenticazione e il redirect, gli utenti di screen reader hanno bisogno di una regione aria-live o di un annuncio con focus che confermi che i loro dati sono stati ripristinati e che possono continuare da dove avevano interrotto. Senza questo, potrebbero non sapere che il loro lavoro è stato salvato.
• Trattare le sessioni basate su AJAX in modo diverso dalle sessioni basate su pagina: Le single-page application che usano autenticazione basata su token (ad es. scadenza JWT) spesso fanno fallire silenziosamente le chiamate API quando il token scade senza dare all’utente la possibilità di ri-autenticarsi e riprendere. Il meccanismo di ri-autenticazione deve essere altrettanto robusto per le architetture SPA.
• Usare <meta http-equiv='refresh'> per forzare il logout senza salvataggio preventivo dei dati: Un meta refresh che scatta al timeout reindirizza immediatamente l’utente senza alcuna preservazione dello stato lato server, rendendo impossibile il recupero dei dati. La gestione della sessione deve essere gestita a livello di applicazione con una corretta persistenza dello stato.
• Supporre che sessioni brevi eliminino la necessità di questo criterio: Anche un timeout di sessione di 5 minuti può colpire una persona che digita lentamente, un utente con disabilità cognitiva che rilegge le istruzioni o qualcuno interrotto da un caregiver. La durata del timeout non cambia l’obbligo di preservare i dati attraverso la ri-autenticazione.

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 il quadro nazionale per l’accessibilità digitale e fa riferimento a WCAG 2.2 come standard tecnico di base. La circolare impone la conformità a un’ampia gamma di soggetti che operano in Turchia, tra cui istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e fornitori privati di assistenza sanitaria, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società di trasporto private e istituti di istruzione privati autorizzati dal Ministero dell’Istruzione Nazionale (MoNE).

WCAG 2.2.5 Re-authenticating è un criterio di Livello AAA, il che significa che non rientra tra i requisiti minimi legalmente obbligatori ai sensi della Circolare (che mira alla conformità di Livello A e AA). Tuttavia, le organizzazioni che desiderano dimostrare leadership in materia di accessibilità, servire popolazioni di utenti diversificate, incluse le persone con disabilità, o posizionarsi come fornitori di servizi digitali di eccellenza dovrebbero considerare i criteri di Livello AAA — in particolare quelli con un impatto pratico così rilevante come il 2.2.5 — come obiettivi aspirazionali degni di essere perseguiti.

Alcune categorie di soggetti coperti hanno motivazioni particolarmente forti per implementare il 2.2.5. Le banche e le piattaforme finanziarie richiedono spesso agli utenti di compilare lunghi moduli per richieste di prestito, apertura di conti o prodotti di investimento, e i loro timeout di sessione brevi dettati dalla sicurezza creano una tensione diretta con gli obblighi di preservazione dei dati. Gli ospedali e i portali sanitari espongono i pazienti alla perdita di dati durante compiti critici come la prenotazione di appuntamenti o la compilazione di questionari sanitari, che possono avere conseguenze reali sulla continuità delle cure. Le istituzioni pubbliche che gestiscono servizi di e-government — come la dichiarazione dei redditi, le richieste di permessi o le domande di sussidi — servono cittadini con disabilità che possono aver bisogno di tempo prolungato per completare moduli governativi complessi.

Anche laddove la conformità al Livello AAA non sia legalmente richiesta, le organizzazioni turche dovrebbero essere consapevoli che i regolatori, le organizzazioni della società civile e i difensori dei diritti delle persone con disabilità stanno esaminando sempre più da vicino la qualità e la completezza delle implementazioni di accessibilità digitale. Documentare la conformità a criteri di Livello AAA come il 2.2.5 rafforza la dichiarazione di accessibilità di un’organizzazione, riduce il rischio di contenzioso e dimostra un impegno genuino verso il design inclusivo oltre la mera conformità minima. Per i soggetti con portata internazionale, in particolare quelli che operano nei mercati UE insieme alla Turchia, i criteri di Livello AAA possono intersecarsi con i requisiti previsti dall’European Accessibility Act (EAA) e dalle relative implementazioni nazionali.