WCAG 2.2.6: Timeout

Cosa Significa Questa Regola

WCAG 2.2.6 Timeouts (Livello AAA) richiede che gli utenti siano avvisati della durata di qualsiasi inattività che potrebbe causare la perdita di dati, a meno che i dati non vengano conservati per più di 20 ore di inattività dell’utente. In termini pratici, questo significa che se la tua applicazione o il tuo servizio web può perdere i dati di un utente — come l’inserimento in un modulo, un carrello, o una transazione in corso — perché l’utente è rimasto inattivo per un certo periodo di tempo, devi informare gli utenti esattamente di quanto tempo dispongono prima che quei dati vadano persi.

Il criterio si applica a qualsiasi situazione in cui un timeout comporta una perdita di dati. Esempi comuni includono la scadenza della sessione su portali bancari o governativi che cancella i dati dei moduli, carrelli che si svuotano dopo un periodo di inattività, procedure guidate o moduli multi-step che si resettano quando un cookie di sessione scade, e sistemi di test o prenotazione online che scartano risposte parziali. L’elemento chiave è la combinazione di inattività (non un limite di tempo rigido per completare un’attività, che è coperto da 2.2.1) e la conseguenza della perdita di dati.

Cosa è considerato conforme: Una pagina soddisfa il criterio 2.2.6 se informa chiaramente gli utenti all’inizio di una sessione — o prima che inizino a inserire dati — della specifica durata di inattività che comporterà la perdita di dati. In alternativa, una pagina è conforme se non può verificarsi alcuna perdita di dati indipendentemente da quanto a lungo l’utente rimanga inattivo (ad esempio, perché il server conserva tutti i dati dei moduli per più di 20 ore, o a tempo indeterminato). Mostrare un avviso solo dopo che la sessione è già scaduta non soddisfa il criterio.

Cosa è considerato non conforme: Una pagina non è conforme se perde silenziosamente i dati dell’utente dopo un periodo di inattività senza informare mai l’utente di questo rischio. Non è conforme neppure se esiste un avviso ma viene presentato solo al momento della perdita di dati (troppo tardi per intervenire), o se l’avviso è vago — ad esempio, affermando “la tua sessione potrebbe scadere” senza specificare la reale durata di inattività che attiva il timeout.

Eccezioni ufficiali: Il criterio esenta esplicitamente le situazioni in cui i dati sono conservati per più di 20 ore di inattività. La soglia di 20 ore è stata scelta per tenere conto degli utenti che iniziano un’attività in un giorno e la riprendono il giorno successivo. Se il tuo sistema memorizza in modo affidabile tutti i dati inseriti lato server per almeno 20 ore senza che sia richiesta alcuna azione da parte dell’utente, non sei tenuto a mostrare un avviso. Inoltre, questo criterio non si applica ai timeout essenziali per la sicurezza — ad esempio, un obbligo rigido previsto da legge o regolamento che impone la chiusura di una sessione dopo un periodo fisso indipendentemente dalle azioni dell’utente. In tali casi, il criterio incoraggia comunque la comunicazione, ma riconosce il vincolo legale.

Perché È Importante

I timeout senza un adeguato avviso colpiscono in modo sproporzionato le persone con disabilità cognitive, disabilità motorie e le persone cieche o ipovedenti. Utenti con disabilità cognitive come dislessia, ADHD o lesioni cerebrali traumatiche possono aver bisogno di molto più tempo per leggere le istruzioni, comporre testi o rivedere le informazioni prima di inviare un modulo. Se una sessione scade silenziosamente mentre stanno ancora lavorando, perdono tutto il loro lavoro e devono ricominciare da capo — un’esperienza profondamente scoraggiante che può portarli ad abbandonare completamente l’attività.

Le persone con disabilità motorie che si affidano a sistemi di accesso a scansione, dispositivi di eye-tracking o altri metodi di input alternativi interagiscono con le interfacce a un ritmo molto più lento rispetto a un utente con mouse. Completare un lungo modulo di richiesta di indennizzo assicurativo o una domanda governativa su più pagine può richiedere loro molto più tempo di quanto presupponga il timeout di sessione predefinito. Senza conoscere il conto alla rovescia, non hanno la possibilità di intervenire — ad esempio salvando i progressi o richiedendo una proroga — prima che i loro dati scompaiano.

Gli utenti di screen reader affrontano anche una sfida amplificata: la navigazione in moduli complessi richiede più tempo quando ogni campo deve essere letto ad alta voce e confermato tramite tastiera. Una sessione che scade mentre un utente sta ancora lavorando metodicamente su un modulo lungo non è semplicemente scomoda — può rappresentare ore di lavoro perdute e una barriera significativa all’accesso a servizi essenziali.

Considera questo scenario reale: una persona con sclerosi multipla sta facendo domanda per un sussidio di invalidità tramite un portale governativo. Il modulo ha 12 sezioni e richiede il caricamento di documenti di supporto. La sessione scade dopo 15 minuti di inattività, ma l’utente si è fermato a metà della sezione 7 per recuperare un documento in un’altra stanza. Al ritorno, tutti i dati sono stati cancellati e deve ricominciare da capo — senza alcun preavviso che ciò sarebbe accaduto. Ai sensi del criterio 2.2.6, il portale sarebbe tenuto a informare l’utente fin dall’inizio che un’inattività superiore a 15 minuti comporterà la perdita dei dati, permettendogli di pianificare di conseguenza.

Oltre all’accessibilità, comunicare in modo proattivo il comportamento dei timeout migliora l’esperienza utente per tutti e riduce i tassi di abbandono nei flussi di conversione ad alto valore come checkout, registrazione e moduli di domanda. Inoltre, costruisce fiducia, poiché gli utenti non si ritrovano a chiedersi perché i loro dati siano scomparsi.

Regole Axe-core Correlate

WCAG 2.2.6 richiede test manuali. Non esiste una regola automatizzata di axe-core in grado di rilevare questa violazione, e capire il perché è importante sia per i tester che per gli sviluppatori.

• Test manuale richiesto — Comunicazione del timeout di sessione: Strumenti automatizzati come axe-core possono analizzare il DOM per la presenza o assenza di specifici elementi, attributi e pattern testuali, ma non possono determinare se un’applicazione web perderà i dati dell’utente dopo un periodo di inattività. Il comportamento del timeout è in genere governato dalla configurazione della sessione lato server (ad esempio, un TTL di sessione PHP o Node.js), e la comunicazione — se esiste — può apparire in un testo di onboarding, in una finestra modale, in una pagina di aiuto o persino in una sezione dei termini di servizio. Nessuna analisi statica del DOM può correlare in modo affidabile un testo informativo con il reale comportamento di timeout lato server. Uno strumento non può sapere se una frase come “Per la tua sicurezza, le sessioni scadono dopo 15 minuti” sia accurata, se si applichi ai dati della pagina corrente o se sia posizionata abbastanza presto nel percorso utente da essere effettivamente utile. Solo un tester umano che può interagire con l’applicazione, osservarne il comportamento nel tempo e valutare completezza e tempistica di eventuali comunicazioni può determinare la conformità.
• Test manuale richiesto — Verifica della conservazione dei dati: Axe-core non può neppure verificare l’eccezione delle 20 ore. Il fatto che i dati siano effettivamente memorizzati lato server per più di 20 ore — e quindi se sia necessaria o meno una comunicazione — dipende interamente dalla logica di backend, invisibile a uno strumento di scansione basato sul browser. I tester devono esaminare la configurazione del server, parlare con gli sviluppatori o testare empiricamente lasciando un modulo parzialmente compilato per un periodo prolungato e osservando se i dati persistono.

Come Eseguire i Test

1. Pre-analisi automatizzata: Esegui axe DevTools o Lighthouse sulla pagina che contiene il modulo, il flusso di checkout o un’altra interfaccia di inserimento dati. Sebbene nessuno dei due strumenti segnalerà direttamente una violazione del criterio 2.2.6, utilizza questo passaggio per identificare eventuali regioni ARIA live o componenti di dialogo legati al timeout che potrebbero far parte del meccanismo di avviso, e verifica che siano essi stessi accessibili (ruoli corretti, etichette, gestione del focus).
2. Identifica il comportamento del timeout: Parla con il team di sviluppo o esamina la configurazione lato server per determinare la durata del timeout di inattività per la sessione. Posizioni comuni includono i file di configurazione del server web, le impostazioni del middleware di sessione dell’applicazione e la documentazione del provider di autenticazione. Registra la durata esatta in minuti.
3. Verifica la comunicazione preventiva: Carica la pagina da zero e leggi tutti i contenuti presentati all’utente prima che inizi qualsiasi inserimento di dati. Cerca una dichiarazione chiara — nel corpo della pagina, in un paragrafo introduttivo, in un banner o in una modale — che specifichi l’esatta durata del timeout di inattività e indichi che i dati andranno persi se l’utente rimane inattivo per quel periodo. La comunicazione deve indicare esplicitamente la durata (ad esempio, “15 minuti”), non in modo vago (ad esempio, “per un breve periodo”).
4. Test con uno screen reader: Utilizzando NVDA con Firefox, VoiceOver con Safari o JAWS con Chrome, naviga la pagina dall’inizio. Conferma che qualsiasi comunicazione relativa al timeout sia raggiungibile e letta dallo screen reader senza che l’utente debba cercarla attivamente. Se la comunicazione è in un banner visivamente prominente, verifica che sia nell’ordine di lettura prima del primo campo del modulo.
5. Simula l’inattività: Inizia a compilare il modulo. Poi smetti di interagire con la pagina per una durata leggermente inferiore al periodo di timeout e osserva cosa accade. Ripeti quindi, aspettando fino a dopo la scadenza del timeout. Registra se i dati vengono persi, se viene visualizzato un avviso prima che si verifichi la perdita di dati e se tale avviso è stato comunicato prima dell’inizio della sessione.
6. Testa l’eccezione delle 20 ore: Se il team afferma che i dati sono conservati per più di 20 ore, verifica empiricamente compilando parzialmente un modulo, aspettando almeno 20 ore e tornando sulla pagina per confermare che i dati siano ancora presenti. In alternativa, esamina con il team di sviluppo la configurazione dell’archivio di sessione lato server.
7. Test di tastiera e focus: Se compare una finestra di dialogo o una notifica di avviso di timeout, verifica utilizzando la sola tastiera che riceva automaticamente il focus, che il suo contenuto sia completamente leggibile e che l’utente possa chiuderla o intervenire (ad esempio, estendere la sessione) senza usare il mouse.

Come Correggere

Sessione con perdita silenziosa di dati — Non corretto

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Sessione con perdita silenziosa di dati — Corretto

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Sessione di checkout con avviso vago — Non corretto

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Sessione di checkout con avviso vago — Corretto

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Dati conservati lato server per più di 20 ore — Corretto (si applica l’eccezione)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Errori Comuni

• Mostrare l’avviso di timeout solo all’interno della console del browser o in una voce di log del server invisibile agli utenti finali — l’avviso deve essere presentato nell’interfaccia utente, in una posizione che l’utente incontrerà prima che si verifichi la perdita di dati.
• Collocare la comunicazione in un footer, in un’informativa sulla privacy o in una pagina di termini di servizio che gli utenti difficilmente leggeranno prima di iniziare a inserire dati, invece che direttamente sul modulo o immediatamente prima di esso.
• Utilizzare una finestra modale per avvisare gli utenti di una scadenza imminente della sessione ma non spostare il focus della tastiera sulla modale — gli utenti che usano la tastiera o uno screen reader potrebbero non accorgersi mai che l’avviso è apparso.
• Indicare la durata di una sessione (ad esempio, “la tua sessione dura 30 minuti”) invece di un timeout di inattività (ad esempio, “dopo 15 minuti di inattività, i tuoi dati andranno persi”) — sono concetti diversi, e solo la perdita di dati innescata dall’inattività è regolata dal criterio 2.2.6.
• Dare per scontato che, poiché esiste una finestra modale di avviso di timeout per gli utenti vedenti, il criterio sia soddisfatto — se la modale non è accessibile tramite tastiera, non ha un nome accessibile o non è annunciata tramite regioni ARIA live o gestione del focus, gli utenti di screen reader non riceveranno l’avviso.
• Impostare il timeout di sessione lato server a 25 ore e concludere che non è necessaria alcuna comunicazione, senza verificare che lo stato lato browser o a livello di applicazione (ad esempio, uno store Redux o il localStorage) non venga cancellato prima — il timeout effettivo è quello del meccanismo che perde i dati per primo.
• Comunicare la durata del timeout in un tooltip attivato solo al passaggio del mouse — gli utenti che si affidano alla navigazione da tastiera o ai dispositivi touch potrebbero non vedere mai la comunicazione.
• Affidarsi a un avviso generico del CMS o del framework che dice “session expired” visualizzato dopo che la perdita di dati si è già verificata, invece di informare proattivamente gli utenti prima che inizino a inserire dati.
• Non tenere conto degli utenti che aprono il modulo in una scheda in background: se il timer di sessione continua mentre la scheda è inattiva, i dati possono andare persi prima che l’utente abbia avuto la possibilità di interagire con il modulo. Ciò è particolarmente problematico sui browser mobili che sospendono in modo aggressivo le schede in background.
• Omettere l’avviso nelle versioni mobile o nei contesti di progressive web app (PWA) pur mostrandolo nella versione desktop, creando un’esperienza incoerente che non soddisfa il criterio 2.2.6 per una parte significativa degli utenti.

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 vincolanti in materia di accessibilità web per un’ampia gamma di soggetti pubblici e privati che operano in Turchia. La circolare impone la conformità a WCAG 2.2 come standard tecnico, richiedendo ai soggetti interessati di raggiungere almeno la conformità di Livello AA. WCAG 2.2.6 Timeouts è un criterio di Livello AAA e pertanto non è direttamente imposto dai requisiti di base della circolare. Tuttavia, l’ambito e le finalità della circolare creano forti motivazioni pratiche affinché i soggetti interessati perseguano la conformità AAA per criteri come il 2.2.6.

I soggetti coperti dalla Circolare Presidenziale 2025/10 includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, operatori di telecomunicazioni con più di 200.000 abbonati, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Molti di questi settori gestiscono portali online che coinvolgono esattamente i tipi di flussi di inserimento dati che il criterio 2.2.6 è progettato per proteggere: richieste di prestiti, moduli di accettazione dei pazienti, sistemi di prenotazione di biglietti, domande di iscrizione e richieste di sussidi governativi.

Per banche e piattaforme di e-commerce in particolare, i timeout di sessione sono una misura di sicurezza di routine, e l’interazione tra requisiti di sicurezza e obblighi di accessibilità è direttamente rilevante. Sebbene una banca possa avere l’obbligo normativo di terminare le sessioni inattive dopo un periodo fisso, l’implementazione del criterio WCAG 2.2.6 comunicando in anticipo la durata del timeout non è in conflitto con tale requisito di sicurezza — lo integra. Gli utenti vengono messi a conoscenza del vincolo senza che la banca debba indebolire la propria postura di sicurezza delle sessioni.

I fornitori di servizi sanitari e gli ospedali coperti dalla circolare gestiscono alcuni dei compiti di inserimento dati più critici immaginabili — moduli di anamnesi, richieste di pre-autorizzazione e sistemi di prenotazione di appuntamenti. I pazienti con disabilità cognitive o motorie che perdono i loro dati a metà modulo in questi contesti affrontano non solo frustrazione ma anche potenziali ritardi nel ricevere cure. L’implementazione del criterio 2.2.6 in questi ambienti è un’espressione diretta del mandato di servizio inclusivo che è alla base della circolare.

Sebbene il Livello AAA non sia richiesto per legge, raggiungerlo per criteri come il 2.2.6 — che richiedono uno sforzo di implementazione relativamente basso (aggiungere una singola comunicazione accurata a un modulo) pur offrendo un beneficio significativo a gruppi di utenti vulnerabili — rappresenta una pratica di accessibilità di livello eccellente. Le organizzazioni che desiderano dimostrare il proprio impegno per l’inclusione digitale nel mercato turco, o che prevedono una regolamentazione più stringente in futuro, traggono grande vantaggio dal trattare il criterio 2.2.6 come un obiettivo pratico di implementazione piuttosto che come un’aspirazione opzionale.