Criteri di successo WCAG · Level A

WCAG 2.2.1: Tempo regolabile

WCAG 2.2.1 richiede che qualsiasi limite di tempo impostato dal contenuto possa essere disattivato, regolato o esteso dall’utente, garantendo che le persone che hanno bisogno di più tempo per interagire con i contenuti web non vengano escluse. Questo criterio di Livello A è essenziale per le persone con disabilità motorie, cognitive e visive.

Cosa Significa Questa Regola

WCAG 2.2.1 Timing Adjustable è un criterio di successo di Livello A sotto il Principio 2: Operabile. Stabilisce che, per ogni limite di tempo impostato dal contenuto, deve essere vera almeno una delle seguenti condizioni: l’utente può disattivare il limite di tempo prima di incontrarlo; l’utente può regolare il limite di tempo su un ampio intervallo (almeno dieci volte l’impostazione predefinita); oppure l’utente può estendere il limite di tempo con un’azione semplice — come premere un tasto o fare clic su un pulsante — prima che il tempo scada, ed è avvisato almeno 20 secondi in anticipo, con la possibilità di estendere almeno dieci volte.

In termini pratici, questo criterio si applica a qualsiasi interfaccia web che impone una scadenza di sessione, un carosello che avanza automaticamente con slide temporizzate, un modulo che si svuota o si invia automaticamente, un conto alla rovescia in una pagina di checkout, un lettore multimediale con sottotitoli temporizzati che non possono essere messi in pausa, o qualsiasi altro meccanismo che limiti il tempo a disposizione dell’utente per completare un’attività. Se la tua pagina o applicazione imposta un timer che, una volta scaduto, rimuove contenuti, disconnette l’utente o lo porta a un nuovo stato senza il suo consenso, devi offrire un modo per regolare o estendere tale limite.

Il criterio definisce anche tre importanti eccezioni che possono consentire il mantenimento di un limite di tempo senza i meccanismi di regolazione descritti sopra. Primo, l’eccezione in tempo reale: se il limite di tempo è una parte necessaria di un evento in tempo reale (come un’asta dal vivo o un esame online sincrono), la regolazione del tempo invaliderebbe l’attività stessa e nessuna alternativa è praticabile. Secondo, l’eccezione essenziale: se il limite di tempo è essenziale ed estenderlo invaliderebbe l’attività — per esempio, un test di abilità a tempo in cui lo scopo è misurare la velocità di risposta. Terzo, l’eccezione delle 20 ore: se il limite di tempo è superiore a 20 ore, l’onere per gli utenti è considerato minimo e non sono richiesti controlli di regolazione.

Un superamento si verifica quando un’interazione a tempo limitato fornisce un meccanismo chiaro — idealmente presentato prima che il limite venga incontrato — che consente all’utente di disabilitare, estendere o regolare il vincolo temporale. Un’infrazione si verifica quando il contenuto scade automaticamente, reindirizza, disconnette l’utente o avanza senza offrire nessuna delle tre opzioni di regolazione sopra, e nessuna delle tre eccezioni si applica.

Perché È Importante

I limiti di tempo colpiscono in modo sproporzionato le persone con disabilità. Gli utenti che si affidano ai lettori di schermo spesso navigano le pagine più lentamente rispetto agli utenti vedenti, perché ascoltano il contenuto in modo lineare e devono esplorare le interfacce non familiari in modo sequenziale. Gli utenti con disabilità motorie — inclusi coloro che utilizzano dispositivi di accesso a sensore, software di tracciamento oculare, bastoncini bocca o software di controllo vocale — possono impiegare molto più tempo per compilare un campo di un modulo, confermare un acquisto o passare alla fase successiva. Gli utenti con disabilità cognitive o dell’apprendimento, tra cui dislessia, disturbi dell’attenzione o deficit di memoria, possono aver bisogno di tempo aggiuntivo per leggere, comprendere e rispondere alle istruzioni. Anche le persone anziane necessitano comunemente di più tempo per le stesse attività e rappresentano una quota in rapida crescita della popolazione globale di internet.

Considera uno scenario concreto reale: una persona con paralisi cerebrale sta completando una prenotazione di volo sul sito web di una compagnia aerea turca. La sessione di checkout scade automaticamente dopo cinque minuti di inattività. L’utente, che digita lentamente con un dispositivo a puntatore sulla testa, ha inserito il proprio nome, numero di passaporto e dati di pagamento — e poi la pagina si ricarica, cancellando tutti i dati e riportandolo alla homepage. Non solo il suo sforzo è andato perso, ma la fiducia nel sito è scossa e potrebbe non riuscire a completare l’acquisto. Questo è una barriera diretta alla partecipazione paritaria al commercio digitale.

L’impatto è più ampio dei singoli utenti. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone nel mondo vivono con una qualche forma di disabilità significativa. Solo in Turchia, le statistiche ufficiali di TÜİK indicano che oltre 8,5 milioni di persone hanno una disabilità che influisce sulle attività quotidiane. Le interfacce a tempo limitato escludono una porzione misurabile della potenziale base utenti di qualsiasi applicazione web.

Oltre all’accessibilità, rimuovere limiti di tempo arbitrari o renderli regolabili avvantaggia anche gli utenti in ambienti a bassa larghezza di banda, gli utenti con funzionalità motoria temporaneamente compromessa (come un braccio rotto) e gli utenti che vengono semplicemente interrotti durante un’attività. I miglioramenti di usabilità sono ampi e possono ridurre i tassi di abbandono dei moduli, aumentare i tassi di conversione sui siti di e-commerce e ridurre i volumi di richieste all’assistenza clienti.

Regole Axe-core Correlate

WCAG 2.2.1 richiede test manuali. Gli strumenti automatici — inclusi axe-core, Lighthouse e motori simili — non possono rilevare in modo affidabile le violazioni relative al tempo perché i limiti di tempo sono spesso implementati nella logica di sessione lato server, in JavaScript che viene eseguito in modo asincrono o in integrazioni di terze parti. Lo strumento non ha modo di osservare che una pagina scadrà in cinque minuti, o che un carosello avanzerà senza input dell’utente, semplicemente ispezionando il DOM o eseguendo un’analisi statica. Le considerazioni seguenti spiegano cosa i tester devono valutare manualmente.

  • Timeout di sessione (manuale): I tester devono attendere o simulare un timeout di sessione per determinare se la pagina presenta un avviso anticipato, offre un’opzione di estensione e fornisce almeno 20 secondi all’utente per rispondere. Nessuna regola automatizzata può determinare la durata della sessione o se una finestra di avviso appare in tempo senza attendere effettivamente il timeout.
  • Caroselli e slider ad avanzamento automatico (manuale): I tester devono osservare se i caroselli avanzano automaticamente e, in tal caso, se è presente un controllo di pausa o stop raggiungibile tramite tastiera. Axe-core può rilevare alcuni attributi ARIA mancanti sui componenti del carosello, ma non può determinare se l’avanzamento temporizzato stesso sia regolabile.
  • Moduli che si inviano o si svuotano automaticamente (manuale): Se un modulo si invia o svuota il suo contenuto dopo un periodo di inattività, un tester deve identificare questo comportamento tramite osservazione o revisione del codice. Il solo DOM non rivela questo comportamento a uno scanner automatico.
  • Timer di conto alla rovescia nei flussi transazionali (manuale): Le pagine di checkout, i flussi di prenotazione biglietti e gli ambienti d’esame includono spesso timer di conto alla rovescia. Stabilire se questi timer siano essenziali (e quindi esenti) o se richiedano un meccanismo di estensione è una valutazione che richiede un esame umano sia dell’implementazione sia del contesto di business.

Come Testare

  1. Baseline di scansione automatizzata: Esegui axe DevTools o Lighthouse sulla pagina per identificare eventuali violazioni note relative ad ARIA o agli elementi interattivi che potrebbero aggravare i problemi di temporizzazione. Nota che questi strumenti non segnaleranno il limite di tempo in sé, ma aiutano a stabilire una baseline di altri problemi di accessibilità. In Chrome DevTools, apri il pannello Lighthouse, seleziona Accessibility ed esegui l’audit. In axe DevTools, attiva l’estensione del browser, fai clic su Analyze e rivedi i risultati — non apparirà alcuna regola specifica per il tempo, confermando che è necessario il test manuale.
  2. Identifica tutti i limiti di tempo: Esamina il sorgente JavaScript della pagina, le richieste di rete e la configurazione di sessione lato server per identificare ogni limite di tempo. Posizioni comuni includono le chiamate setTimeout e setInterval in JavaScript, le impostazioni di scadenza della sessione nei framework backend, i valori di scadenza dei cookie e le configurazioni di widget di terze parti come i processori di pagamento o i widget di chat.
  3. Testa l’avviso di timeout di sessione con NVDA + Firefox: Apri il sito in Firefox con NVDA in esecuzione. Naviga attraverso un modulo multi-step o una sezione autenticata. Attendi la finestra di avviso di sessione (o il timeout stesso se non appare alcun avviso). Verifica che NVDA annunci automaticamente l’avviso — idealmente tramite una live region — e che l’utente possa estendere la sessione premendo Invio o Barra spaziatrice su un pulsante a fuoco senza perdere i dati del modulo.
  4. Testa l’avviso di timeout di sessione con VoiceOver + Safari (macOS/iOS): Ripeti il test sopra su Safari con VoiceOver abilitato. Usa il rotor per navigare gli elementi interattivi e conferma che l’avviso di timeout venga annunciato e che il controllo di estensione sia raggiungibile entro la finestra di 20 secondi.
  5. Testa l’avviso di timeout di sessione con JAWS + Chrome: Ripeti con JAWS su Chrome. Conferma che il focus venga spostato sulla finestra di avviso, che JAWS legga il tempo rimanente e l’opzione di estensione e che l’attivazione del pulsante di estensione mantenga attiva la sessione senza richiedere il ricaricamento della pagina.
  6. Testa solo con tastiera (senza lettore di schermo): Disabilita il mouse e naviga esclusivamente con Tab, Shift+Tab, Invio e Barra spaziatrice. Conferma che qualsiasi finestra di avviso sia raggiungibile tramite tastiera, che il pulsante di estensione sia focalizzabile e che il focus venga restituito alla posizione corretta nel modulo dopo l’estensione della sessione.
  7. Testa la temporizzazione di caroselli e media: Identifica eventuali caroselli ad avanzamento automatico. Naviga fino al carosello usando Tab. Verifica che sia presente un pulsante di pausa o stop raggiungibile senza mouse. Attivalo e conferma che l’avanzamento si fermi. Se il carosello riprende dopo l’interazione dell’utente, conferma che non riprenda automaticamente.
  8. Verifica l’applicabilità delle eccezioni: Per ogni limite di tempo individuato, determina se si applica l’eccezione in tempo reale, essenziale o delle 20 ore. Documenta il tuo ragionamento. Se nessuna delle eccezioni si applica e non esiste alcun meccanismo di regolazione, registra questo come una violazione di WCAG 2.2.1.

Come Correggere

Timeout di Sessione Senza Avviso — Non Corretto

<!-- Session expires silently after 5 minutes; page reloads with no warning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Timeout di Sessione con Avviso ed Estensione — Corretto

<!-- Warn user 60 seconds before expiry; offer extension; announce via live region -->
<div
  id='session-warning'
  role='alertdialog'
  aria-modal='true'
  aria-labelledby='warning-title'
  aria-describedby='warning-desc'
  hidden
>
  <h2 id='warning-title'>Your session is about to expire</h2>
  <p id='warning-desc'>
    Your session will expire in <span id='countdown'>60</span> seconds.
    Select "Stay logged in" to continue your session.
  </p>
  <button id='extend-btn' type='button'>Stay logged in</button>
  <button id='logout-btn' type='button'>Log out now</button>
</div>

<script>
  var SESSION_DURATION = 300000; // 5 minutes
  var WARNING_BEFORE   = 60000;  // warn 60 seconds before
  var sessionTimer, warningTimer, countdownInterval;

  function startSessionTimer() {
    warningTimer = setTimeout(showWarning, SESSION_DURATION - WARNING_BEFORE);
    sessionTimer = setTimeout(expireSession, SESSION_DURATION);
  }

  function showWarning() {
    var dialog = document.getElementById('session-warning');
    dialog.hidden = false;
    document.getElementById('extend-btn').focus(); // move focus to dialog
    var seconds = 60;
    countdownInterval = setInterval(function() {
      seconds--;
      document.getElementById('countdown').textContent = seconds;
      if (seconds <= 0) clearInterval(countdownInterval);
    }, 1000);
  }

  function extendSession() {
    clearTimeout(sessionTimer);
    clearTimeout(warningTimer);
    clearInterval(countdownInterval);
    document.getElementById('session-warning').hidden = true;
    startSessionTimer();
    // Return focus to last active element
  }

  function expireSession() {
    window.location.href = '/session-expired';
  }

  document.getElementById('extend-btn').addEventListener('click', extendSession);
  document.getElementById('logout-btn').addEventListener('click', expireSession);
  startSessionTimer();
</script>

Carosello ad Avanzamento Automatico Senza Controlli — Non Corretto

<!-- Slides advance every 4 seconds; no pause control; no keyboard access -->
<div class='carousel'>
  <div class='slide active'>Slide 1 content</div>
  <div class='slide'>Slide 2 content</div>
  <div class='slide'>Slide 3 content</div>
</div>

Carosello ad Avanzamento Automatico con Controllo di Pausa — Corretto

<!-- Pause button stops auto-advance; button label updates to reflect state -->
<section aria-roledescription='carousel' aria-label='Featured announcements'>
  <div aria-live='off' aria-atomic='true'>
    <div class='slide active' role='group' aria-roledescription='slide' aria-label='Slide 1 of 3'>
      Slide 1 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 2 of 3'>
      Slide 2 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 3 of 3'>
      Slide 3 content
    </div>
  </div>
  <button id='carousel-pause' type='button' aria-pressed='false'>
    Pause slideshow
  </button>
</section>

<script>
  var paused = false;
  var btn = document.getElementById('carousel-pause');
  btn.addEventListener('click', function() {
    paused = !paused;
    btn.setAttribute('aria-pressed', paused.toString());
    btn.textContent = paused ? 'Play slideshow' : 'Pause slideshow';
    // toggle the carousel's auto-advance logic accordingly
  });
</script>

Countdown di Checkout Temporizzato Senza Estensione — Non Corretto

<!-- 10-minute checkout lock; no extension offered; not an essential exception -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer expires, cart is cleared silently -->

Countdown di Checkout Temporizzato con Opzione di Estensione — Corretto

<!-- Warn before expiry and offer a one-click extension -->
<p>
  Your items are reserved for:
  <span id='timer' aria-live='polite' aria-atomic='true'>10:00</span>
</p>
<div id='extend-notice' hidden role='alert'>
  <p>Your reservation expires in 2 minutes.</p>
  <button type='button' id='extend-checkout'>Give me more time</button>
</div>
<!--
  When timer reaches 2:00, reveal #extend-notice.
  Clicking the button resets the reservation timer via an API call.
  aria-live='alert' ensures screen readers announce the warning immediately.
-->

Errori Comuni

  • Mostrare un avviso di timeout senza gestione del focus da tastiera: La finestra di avviso appare visivamente ma il focus non viene mai spostato su di essa, quindi gli utenti che usano solo la tastiera e i lettori di schermo non scoprono mai di poter estendere la sessione prima che scada.
  • Fornire meno di 20 secondi per rispondere a un avviso di timeout: Mostrare un avviso “Sessione in scadenza” solo 10 secondi prima del logout non soddisfa il criterio, che richiede che siano disponibili almeno 20 secondi per l’azione di estensione.
  • Usare role='alert' su una finestra di timeout che richiede interazione: Il ruolo alert è per annunci di sola lettura; una finestra di dialogo che richiede input dell’utente dovrebbe usare role='alertdialog' con aria-modal='true' e aria-labelledby in modo che i lettori di schermo la trattino come una modale che richiede una risposta.
  • Invocare l’eccezione essenziale per un timer standard del carrello e-commerce: La prenotazione degli articoli in un carrello per 10 minuti è una comodità di business, non un’attività veramente essenziale in cui lo scopo è misurare la velocità. Applicare qui l’eccezione essenziale è scorretto; è richiesto un meccanismo di estensione.
  • Far avanzare automaticamente un carosello senza un pulsante di pausa visibile e raggiungibile da tastiera: Aggiungere un pulsante di pausa visibile solo al passaggio del mouse, o assente dall’ordine di Tab, non soddisfa il criterio. Il controllo deve essere raggiungibile senza un dispositivo di puntamento.
  • Reimpostare il contatore di timeout su qualsiasi movimento del mouse ma non sugli eventi da tastiera: JavaScript che estende il timer di inattività sugli eventi mousemove ma ignora keydown o focus farà scadere silenziosamente le sessioni per gli utenti che usano solo la tastiera e che stanno lavorando attivamente nella pagina.
  • Estendere la sessione tramite un ricaricamento completo della pagina: Quando un utente fa clic su “Rimani connesso”, ricaricare la pagina cancella qualsiasi dato che l’utente aveva inserito nei moduli. L’estensione dovrebbe avvenire tramite una chiamata API o un aggiornamento del cookie in background, preservando lo stato del DOM.
  • Usare valori di setTimeout che non sono configurabili o esposti all’utente: Codificare in modo rigido una durata di sessione di cinque minuti senza alcun controllo nell’interfaccia che consenta all’utente di scegliere una durata maggiore viola il criterio, a meno che non sia disponibile uno dei tre meccanismi di regolazione (disattivare, regolare o estendere).
  • Non testare il flusso di timeout con tecnologie assistive reali prima del rilascio: Gli sviluppatori che testano solo con il mouse potrebbero non accorgersi che la finestra di avviso è inaccessibile agli utenti dei lettori di schermo, perché i test visivi non rivelano i problemi di gestione del focus.
  • Dare per scontato che i widget incorporati di terze parti siano automaticamente conformi: I processori di pagamento, i widget di chat dal vivo e i motori di prenotazione incorporati tramite iframe o script spesso impongono propri limiti di tempo. La responsabilità della conformità WCAG dell’intera pagina — incluso il contenuto incorporato che controlli — ricade sul proprietario 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 requisiti obbligatori di accessibilità web allineati a WCAG 2.2 Livello AA per un’ampia gamma di soggetti pubblici e privati che gestiscono servizi digitali in Turchia. WCAG 2.2.1 Timing Adjustable è un criterio di Livello A, il che significa che si colloca al livello fondamentale della conformità — è tra i primi requisiti che i soggetti interessati devono soddisfare.

In base alla circolare, le istituzioni e agenzie pubbliche — inclusi ministeri, municipalità, università e imprese statali — sono tenute a raggiungere la piena conformità entro un anno dalla data di pubblicazione della circolare. I soggetti del settore privato coperti dal regolamento hanno una finestra di due anni per conformarsi. L’ambito del settore privato è esplicitamente ampio: copre piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali privati e fornitori di servizi sanitari, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società private di trasporto passeggeri e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE).

Per le organizzazioni in queste categorie, una violazione di WCAG 2.2.1 non è semplicemente una mancanza di best practice — è una non conformità legale che può attirare l’attenzione delle autorità di regolamentazione, reclami attraverso canali ufficiali e danni reputazionali. Considera i flussi di business specifici più suscettibili di generare questa violazione: un checkout e-commerce con una prenotazione del carrello a tempo, una sessione di online banking che scade silenziosamente mentre un cliente compila un modulo di pagamento, un sistema di prenotazione di appuntamenti ospedalieri che va in timeout prima che un utente con disabilità motoria possa completare la registrazione, o un portale self-service di un operatore di telecomunicazioni che disconnette automaticamente gli utenti da un flusso di gestione del contratto. Ciascuno di questi è uno scenario di possibile violazione all’interno di un tipo di ente esplicitamente nominato nella circolare.

Le organizzazioni dovrebbero trattare la conformità a WCAG 2.2.1 non come una casella tecnica da spuntare, ma come un requisito di design che deve essere affrontato a livello di architettura — nelle politiche di gestione delle sessioni, nei requisiti di approvvigionamento dei widget di terze parti e negli standard dei componenti UI — piuttosto che essere aggiunto a posteriori. I programmi di audit dovrebbero includere test manuali di tutte le interazioni temporizzate, non solo scansioni automatizzate, proprio perché gli strumenti automatici non possono rilevare questa classe di violazioni senza l’osservazione umana.