WCAG 2.2.3: Nessuna temporizzazione

Cosa Significa Questa Regola

WCAG 2.2.3 — No Timing si colloca al livello di conformità AAA nell’ambito della Linea guida 2.2: Tempo sufficiente. Il suo requisito è diretto: la temporizzazione non deve essere una parte essenziale di alcun evento o attività presentata all’utente. In altre parole, se i tuoi contenuti o le tue funzionalità prevedono un limite di tempo, una scadenza o un’interazione sensibile al tempo di qualsiasi tipo, tale dipendenza dal tempo deve poter essere rimossa oppure deve essere completamente irrilevante per il compito in questione — a meno che non si applichi una delle ristrette eccezioni previste.

Questo criterio va oltre il criterio di Livello A 2.2.1 (Timing Adjustable) e il criterio di Livello AA 2.2.2 (Pause, Stop, Hide). Mentre quei criteri precedenti consentono limiti di tempo regolabili o sospendibili, il 2.2.3 richiede che la temporizzazione semplicemente non esista come vincolo significativo. Un utente che impiega dieci secondi o dieci minuti per compilare un modulo, navigare in un menu o completare un flusso di lavoro deve arrivare allo stesso risultato di un utente che termina istantaneamente.

Cosa è considerato conforme: Contenuti in cui non esiste alcun limite di tempo, oppure in cui qualsiasi limite di tempo presente è puramente cosmetico e non incide sul risultato (per esempio, un’animazione che si ripete in loop ma non impedisce l’interazione). Contenuti che restano pienamente funzionali indipendentemente da quanto tempo impiega l’utente soddisfano questo criterio.

Cosa è considerato non conforme: Timeout di sessione che disconnettono gli utenti dopo inattività; quiz o valutazioni a tempo in cui il punteggio o il completamento dipendono dal finire entro una certa finestra; timer di scadenza del carrello che eliminano gli articoli; interfacce di offerta d’asta con conti alla rovescia che chiudono le offerte; campi per one-time password (OTP) che scadono; CAPTCHA con limiti di tempo; e qualsiasi elemento interattivo che diventa non disponibile o invia automaticamente in base al tempo trascorso.

Eccezioni ufficiali definite da WCAG: Il criterio esenta esplicitamente due categorie. Primo, le eccezioni in tempo reale — eventi in cui la temporizzazione è assolutamente intrinseca all’attività, come un’asta dal vivo, una trasmissione in diretta o un gioco multigiocatore in tempo reale. Secondo, le eccezioni essenziali — situazioni in cui rimuovere il limite di tempo altererebbe in modo fondamentale l’attività. Per esempio, un test di dattilografia veloce misura intrinsecamente la velocità, quindi la temporizzazione è essenziale. Tuttavia, sviluppatori e product owner devono essere rigorosi: comodità, vincoli tecnici preesistenti o preferenze di business non rientrano nella definizione di “essenziale”. La soglia è se l’attività perderebbe il suo significato o scopo principale senza il vincolo temporale.

È importante notare che i media sincronizzati — come un video preregistrato con sottotitoli — sono anch’essi esclusi, perché la temporizzazione nella riproduzione dei media è controllata dal lettore multimediale dell’utente e non impone un vincolo sulla capacità dell’utente di interagire con il resto della pagina.

Perché È Importante

I limiti di tempo sul web danneggiano in modo sproporzionato utenti con un’ampia gamma di disabilità. L’impatto non è astratto — per molti utenti, un’interfaccia a tempo è di fatto inaccessibile.

Utenti con disabilità motorie — inclusi coloro che usano dispositivi di accesso a sensore, bastoncini bocca, software di tracciamento oculare o altri metodi di input alternativi — operano a un ritmo fondamentalmente diverso rispetto agli utenti mouse-e-tastiera. Completare un modulo multi-step o navigare in un menu a tendina può richiedere molto più tempo. Un timeout di sessione o un carrello che scade automaticamente può cancellare in un istante minuti di lavoro attento e faticoso.

Utenti con disabilità cognitive, inclusa dislessia, ADHD, disturbi di elaborazione e lesioni cerebrali acquisite, possono aver bisogno di molto più tempo per leggere le istruzioni, comprendere le opzioni o comporre le risposte. Ricerche raccolte dalla Web Accessibility Initiative stimano che le disabilità cognitive e dell’apprendimento interessino in qualche forma circa il 15–20% della popolazione mondiale. Per questi utenti, un conto alla rovescia non è solo stressante — compromette attivamente l’elaborazione cognitiva necessaria per completare il compito.

Utenti di screen reader ciechi o con ipovisione navigano i contenuti in modo lineare e devono ascoltare o leggere gli elementi dell’interfaccia in sequenza. Comprendere la struttura e le opzioni su una pagina complessa richiede più tempo rispetto a un utente vedente che scorre visivamente. Un flusso di checkout a tempo che scade mentre un utente cieco sta rivedendo con attenzione il riepilogo dell’ordine è una barriera diretta al commercio.

Utenti con disturbi d’ansia possono scoprire che la sola presenza di un conto alla rovescia crea un carico cognitivo ed emotivo sufficiente a impedire il completamento del compito, anche se tecnicamente hanno abbastanza tempo. Rimuovere la temporizzazione come fattore elimina completamente questa barriera.

Uno scenario concreto nel mondo reale: Considera un portale di home banking che utilizza un timeout di inattività di cinque minuti combinato con un’OTP che scade in sessanta secondi. Un utente con il morbo di Parkinson che ha bisogno di tecnologie di input assistive per digitare, o un utente anziano non abituato a passare rapidamente da un’app all’altra, può trovare fisicamente impossibile ricevere l’SMS, cambiare applicazione, leggere il codice, tornare indietro e inserirlo entro il tempo previsto. Viene bloccato dal proprio conto — non per necessità di sicurezza, ma per un vincolo temporale arbitrario. Progettare l’OTP in modo che resti valida per un periodo più lungo (o eliminare la scadenza rigida a favore di un meccanismo di reinvio) risolve il problema senza compromettere la sicurezza.

Oltre all’accessibilità, rimuovere vincoli temporali non necessari migliora l’usabilità generale e riduce i tassi di abbandono. Un checkout e-commerce che non scade a metà del flusso trattiene più clienti, aumenta le conversioni e riduce il carico sul supporto — rendendo questo cambiamento positivo per il business oltre che un imperativo etico.

Regole Axe-core Correlate

WCAG 2.2.3 richiede test manuali. Nessuna regola automatizzata di axe-core mappa direttamente a questo criterio, e questa è una realtà architetturale importante da comprendere.

• Test manuale richiesto — Temporizzazione di sessione e interazioni: Gli strumenti automatizzati non possono rilevare se un’applicazione web impone un limite di tempo perché la logica di temporizzazione è implementata nella gestione di sessione lato server, nei timer JavaScript o nelle risposte delle API di back-end — nessuno dei quali è visibile in un’analisi statica del DOM. Uno strumento come axe-core ispeziona l’HTML renderizzato e l’albero di accessibilità; non può osservare che una richiesta fetch restituirà un 401 dopo cinque minuti di inattività, o che un setTimeout JavaScript reindirizzerà l’utente a una pagina di logout. Solo un tester umano che interagisce con l’applicazione lentamente e osserva cosa accade può determinare se esistono vincoli temporali e se influiscono sul completamento dei compiti.
• Test manuale richiesto — Scadenza di OTP e CAPTCHA: Le one-time password e le sfide di verifica a tempo compaiono nel DOM come normali campi di input. Il conto alla rovescia, se visibile, può essere un semplice nodo di testo o un elemento animato via CSS. Axe non può dedurre che inserire un valore in questo campo dopo novanta secondi porterà a uno stato di errore. Un tester deve deliberatamente attendere oltre la finestra di scadenza e tentare l’invio per confermare se la temporizzazione è applicata.
• Test manuale richiesto — Moduli che inviano o avanzano automaticamente: Alcune interfacce avanzano automaticamente allo step successivo o inviano un modulo dopo un periodo di inattività o dopo una durata prestabilita (per esempio, un sondaggio che passa alla domanda successiva dopo trenta secondi). Axe-core non segnalerà questo problema perché la struttura del DOM appare valida; il comportamento problematico si manifesta solo durante l’interazione reale nel tempo.
• Test manuale richiesto — Scadenza in contesti di commercio e prenotazione: Timer di prenotazione del carrello, blocchi di prenotazione di biglietti e blocchi di slot per appuntamenti sono implementati tramite logica lato server e si riflettono nell’interfaccia utente solo come un conto alla rovescia. Gli strumenti automatizzati vedono un numero che si aggiorna sullo schermo ma non possono determinare se, quando arriva a zero, provoca perdita di dati o negazione di accesso.

Come Testare

1. Scansione automatizzata di base: Esegui axe DevTools o Lighthouse sulla pagina per identificare eventuali violazioni di temporizzazione di livello inferiore correlate (come quelle coperte da 2.2.1 o 2.2.2) che possano indirizzarti verso aree che richiedono un’ispezione manuale più approfondita. Sebbene nessuna regola di axe testi direttamente il 2.2.3, i risultati relativi ad avvisi sui limiti di tempo o all’auto-refresh possono guidare l’ambito del tuo audit manuale. In Lighthouse, esamina la sezione “Accessibility” per eventuali segnalazioni legate al tempo.
2. Inventaria tutte le funzionalità dipendenti dal tempo: Prima di testare, cataloga sistematicamente ogni funzionalità dell’applicazione che potrebbe coinvolgere la temporizzazione. Questo include: gestione della sessione e timeout di inattività; campi OTP e codici di verifica; blocchi del carrello o delle prenotazioni; quiz, valutazioni o sondaggi a tempo; interfacce di asta o offerta; CAPTCHA; meccanismi di salvataggio automatico con finestre di invio; e qualsiasi conto alla rovescia o timer di avanzamento visibile.
3. Testa il comportamento del timeout di sessione: Apri l’applicazione e inizia un compito che si articola in più passaggi (per esempio, compilare un modulo multipagina o completare un checkout). Non interagire per un periodo superiore alla finestra di timeout sospetta. Poi prova a continuare. Osserva se i tuoi progressi sono preservati, se ricevi un avviso e la possibilità di estendere la sessione, oppure se vieni disconnesso o perdi i dati. Per essere conforme è necessario che o non esista alcun timeout, o il timeout sia puramente precauzionale e i dati siano preservati al momento della riautenticazione, oppure che l’utente riceva un adeguato avviso e controllo.
4. Testa la scadenza di OTP e codici: Attiva un flusso di OTP o codice di verifica. Attendi oltre il tempo di scadenza dichiarato del codice (o più a lungo se non è mostrato alcun tempo). Prova a inserire il codice. Se il sistema lo rifiuta esclusivamente a causa del tempo, si tratta di una violazione del 2.2.3. Nota: un meccanismo di “reinvia” da solo non risolve il 2.2.3 — la scadenza del codice originale impone comunque una temporizzazione.
5. Test con screen reader (NVDA + Firefox): Usando NVDA con Firefox, naviga in qualsiasi interfaccia a tempo usando solo la tastiera e lo screen reader. Nota quanto tempo richiede ogni passaggio con l’overhead di navigazione tramite tecnologia assistiva. Procedi deliberatamente a un ritmo lento — fermati per ascoltare tutte le istruzioni, esplora tutte le opzioni tramite cursore virtuale — quindi prova a inviare o procedere. Verifica che la navigazione lenta non attivi un timeout o una perdita di stato.
6. Test con screen reader (VoiceOver + Safari su macOS): Ripeti lo stesso test di navigazione lenta usando VoiceOver su macOS con Safari. Presta particolare attenzione ai timer di conto alla rovescia dinamici: VoiceOver annuncia il tempo rimanente in modo da creare urgenza, e l’interfaccia fallisce quando il tempo scade?
7. Test con screen reader (JAWS + Chrome): Usando JAWS con Chrome, testa gli stessi flussi. Gli utenti JAWS rappresentano una parte significativa degli utenti professionali di screen reader; i problemi di temporizzazione che colpiscono gli utenti NVDA in genere colpiranno allo stesso modo gli utenti JAWS.
8. Verifica la legittimità delle eccezioni: Per qualsiasi temporizzazione che il team di sviluppo dichiara “essenziale” o “in tempo reale”, documenta la giustificazione e valuta se la temporizzazione è davvero intrinseca allo scopo dell’attività, oppure se potrebbe essere allentata, estesa o rimossa senza cambiare la natura fondamentale del compito.

Come Correggere

Timeout di Sessione — Non Corretto

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Timeout di Sessione — Corretto

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Campo OTP con Scadenza — Non Corretto

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Campo OTP con Scadenza — Corretto

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Quiz a Tempo — Non Corretto

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Quiz a Tempo — Corretto

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Errori Comuni

• Presumere che la sicurezza della sessione richieda un timeout rigido: Molti team implementano timeout di inattività brevi citando requisiti di sicurezza, ma la maggior parte degli standard di sicurezza (inclusi PCI-DSS e OWASP) consente l’estensione della sessione controllata dall’utente. Un logout rigido senza avviso o possibilità di estensione è un problema di accessibilità, non una necessità di sicurezza.
• Mostrare un conto alla rovescia senza fornire un modo per fermarlo o estenderlo: Aggiungere una regione aria-live a un conto alla rovescia lo rende peggiore per gli utenti di screen reader — annuncia ogni secondo — senza risolvere il problema di temporizzazione sottostante. La correzione consiste nel rimuovere il vincolo, non nell’annunciarlo in modo più accessibile.
• Considerare “reinvia codice” come soluzione alla scadenza dell’OTP: Fornire un pulsante di reinvio consente agli utenti di ottenere un nuovo codice ma non affronta il fatto che il codice originale è scaduto a causa della temporizzazione. Il limite di tempo è ancora presente. La correzione corretta è estendere la finestra di validità per eliminare la pressione temporale.
• Avanzare automaticamente i passaggi di un carosello o wizard dopo inattività: Moduli multi-step o wizard che procedono automaticamente allo step successivo dopo un tempo prestabilito impongono un vincolo temporale. Gli utenti che stanno leggendo le istruzioni o valutando la loro risposta vengono penalizzati. I passaggi devono avanzare solo su azione esplicita dell’utente.
• Timer del carrello che eliminano gli articoli senza preservarli: I timer di prenotazione nell’e-commerce (“Il tuo carrello scade in 15 minuti”) violano il 2.2.3 quando gli articoli vengono persi in modo permanente alla scadenza invece di essere semplicemente rilasciati dalla prenotazione. Come minimo, gli articoli dovrebbero essere salvati in una lista dei desideri o la sessione dovrebbe essere ripristinabile.
• Applicare l’“eccezione in tempo reale” in modo troppo estensivo: Etichettare un’interfaccia come “in tempo reale” per giustificare vincoli temporali quando non è realmente live. Una replica preregistrata di un’asta, un’interfaccia di offerta statica o un quiz che semplicemente assomiglia a un game show non rientrano nell’eccezione in tempo reale.
• Ignorare la temporizzazione nelle risposte delle API di back-end: I team correggono i timer front-end ma trascurano che l’API stessa rifiuta le richieste effettuate dopo una certa finestra. L’utente non vede alcun conto alla rovescia ma il suo invio fallisce silenziosamente. La gestione della sessione lato back-end deve essere allineata con l’esperienza front-end.
• Usare setTimeout per il logout automatico senza salvare lo stato del modulo: Quando un logout automatico è inevitabile (per esempio, a causa di requisiti normativi), non salvare i dati del modulo dell’utente prima del reindirizzamento significa che tutto il lavoro viene perso. Come minimo, lo stato di bozza dovrebbe essere salvato e ripristinato dopo la riautenticazione.
• Confondere la conformità a 2.2.1 con la conformità a 2.2.3: Fornire un controllo per “disattivare, regolare o estendere” (come richiesto da 2.2.1 Livello A) non soddisfa il 2.2.3. Il Livello AAA richiede che la temporizzazione non sia essenziale — non solo gestibile. Un limite di tempo con un’estensione generosa è comunque un limite di tempo.
• Trascurare la temporizzazione nei componenti incorporati di terze parti: Widget di chat incorporati, processori di pagamento, SDK di verifica dell’identità e servizi di mappe possono introdurre propri vincoli temporali. L’origine di terze parti non esenta questi elementi dall’applicabilità delle WCAG quando sono integrati nella tua interfaccia.

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 un quadro nazionale per l’accessibilità web che fa riferimento a WCAG 2.2 come base tecnica. La Circolare impone la conformità a un’ampia gamma di entità che gestiscono servizi digitali in Turchia.

Le tipologie di entità coperte includono istituzioni pubbliche e organismi governativi, piattaforme di e-commerce, banche e servizi finanziari, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Queste organizzazioni sono tenute a rispettare gli standard di accessibilità definiti o richiamati dalla Circolare quando forniscono servizi digitali al pubblico.

WCAG 2.2.3 — No Timing è un criterio di Livello AAA, e la Circolare Presidenziale 2025/10, come lo standard europeo EN 301 549 a cui si allinea, impone la conformità ai Livelli A e AA come minimo legale. La conformità al Livello AAA non è un obbligo legale diretto in questo quadro. Tuttavia, raggiungere il Livello AAA — e in particolare implementare il 2.2.3 — è riconosciuto come indicatore di un livello di maturità nell’accessibilità di eccellenza e dimostra un reale impegno verso un design inclusivo che va oltre le soglie legali minime.

Per alcune tipologie di entità coperte, in particolare banche e servizi finanziari che operano sotto la supervisione del BDDK e piattaforme di e-commerce con alti volumi di transazioni, vincoli temporali come scadenza delle OTP, gestione della sessione e timer nei flussi di checkout sono funzionalità pervasive. Anche quando il 2.2.3 non è richiesto per legge, non affrontare le barriere di temporizzazione in questi flussi crea un reale rischio di discriminazione — soprattutto man mano che i meccanismi di applicazione dell’accessibilità in Turchia maturano e le procedure di reclamo diventano più consolidate.

Le istituzioni pubbliche e i fornitori di servizi sanitari che servono utenti con disabilità, utenti anziani e utenti con bassa alfabetizzazione digitale hanno una motivazione etica particolarmente forte per eliminare completamente i vincoli temporali. Rimuovere i limiti di tempo dai servizi digitali della pubblica amministrazione e dai portali sanitari è in linea con gli obiettivi più ampi di inclusione dell’e-government turco e riduce il rischio di future esposizioni regolatorie man mano che l’adozione del Livello AAA negli appalti del settore pubblico diventa più comune.

Le organizzazioni che desiderano posizionare i propri prodotti digitali come pienamente inclusivi — sia per leadership sul mercato interno, sia per l’accesso ai mercati internazionali, sia per vantaggi negli appalti in contesti dell’Unione Europea (dove si applicano EN 301 549 e l’European Accessibility Act) — dovrebbero considerare la conformità a WCAG 2.2.3 come un investimento strategico piuttosto che un miglioramento opzionale.