WCAG 2.2.4: Interruzioni

Cosa Significa Questa Regola

WCAG 2.2.4: Interruzioni è un criterio di successo di livello AAA nell’ambito della Linea guida 2.2 (Tempo sufficiente). Stabilisce: «Le interruzioni possono essere rinviate o soppresse dall’utente, tranne le interruzioni che riguardano un’emergenza.» In termini pratici, ciò significa che qualsiasi contenuto, avviso, notifica, dialogo o aggiornamento che compare senza essere stato avviato direttamente dall’utente deve offrire a tale utente un meccanismo per rinviare o disabilitare l’interruzione — a meno che l’interruzione non comunichi una reale emergenza, come un allarme antincendio, un avviso medico che minaccia la vita o un guasto critico del sistema.

Un’interruzione, nel senso WCAG, è qualsiasi evento che si verifica indipendentemente dall’azione corrente dell’utente e distoglie l’attenzione da ciò che l’utente sta facendo. Questo include, ma non si limita a: notifiche “toast”, avvisi push, widget di chat che si aprono automaticamente, banner di stato che si aggiornano o cambiano, contenuti multimediali in riproduzione automatica, annunci in live region iniettati da JavaScript, finestre modali attivate da un timer e banner di consenso ai cookie che compaiono a sessione già avviata. Il criterio non vieta in assoluto questi pattern; richiede che agli utenti venga dato il controllo su di essi.

Una pagina supera il criterio 2.2.4 quando ogni interruzione non di emergenza dispone almeno di uno dei seguenti elementi: un’impostazione accessibile all’utente che disabilita l’interruzione prima che si verifichi, un meccanismo all’interno dell’interruzione stessa per chiuderla o rinviarla, oppure una preferenza globale a livello di sito che sopprime completamente tali interruzioni. Una pagina non supera il criterio quando le interruzioni compaiono automaticamente, non offrono alcun meccanismo di chiusura o rinvio e non riguardano un’emergenza. Ad esempio, un riquadro di chat dal vivo che si espande automaticamente dopo 10 secondi senza pulsante di chiusura, o un banner di notifica che scorre messaggi di marketing e non può essere fermato, non supererebbero il criterio.

L’unica eccezione definita esplicitamente riguarda le emergenze. Se un contenuto deve interrompere l’utente per comunicare un pericolo per la salute, la sicurezza o la vita — per esempio, un portale ospedaliero che invia un avviso critico sui farmaci — tale interruzione può ignorare le preferenze dell’utente. Questa eccezione è intenzionalmente ristretta; i messaggi di marketing di routine, gli avvisi di scadenza della sessione con ampio tempo residuo e gli aggiornamenti di stato a bassa priorità non rientrano nella categoria delle emergenze.

Poiché WCAG 2.2.4 è di livello AAA, non è richiesto per le dichiarazioni di conformità di base, ma rappresenta uno standard significativo per le organizzazioni impegnate nella piena inclusione. Si applica a tutti i contenuti web: applicazioni web desktop e mobile, single-page application che utilizzano notifiche gestite da JavaScript e progressive web app che sfruttano la Web Notifications API.

Perché È Importante

Le interruzioni inattese su una pagina web non sono semplicemente fastidiose — per molti utenti rappresentano un serio ostacolo al completamento dei compiti e, in alcuni casi, un rischio diretto per la salute.

Gli utenti con disabilità cognitive e legate all’attenzione — tra cui ADHD, lesioni cerebrali traumatiche, condizioni dello spettro autistico e demenza — si affidano fortemente a un ambiente stabile e prevedibile per mantenere la concentrazione. Una notifica improvvisa o un avviso animato può spezzare completamente la loro concentrazione, facendogli perdere il filo in un processo a più fasi, come la compilazione di una domanda di sussidio, la consultazione di una cartella clinica o la compilazione di una dichiarazione dei redditi. Per questi utenti, il tempo necessario per ri-orientarsi dopo un’interruzione può essere significativamente più lungo rispetto agli utenti neurotipici e, in alcuni casi, potrebbero non riuscire affatto a ritrovare il punto in cui si trovavano.

Gli utenti di screen reader sono particolarmente colpiti dalle interruzioni dinamiche. Quando una live region o un avviso ARIA viene iniettato nel DOM, gli screen reader come NVDA, JAWS e VoiceOver sono progettati per annunciarlo immediatamente, interrompendo qualunque cosa la tecnologia assistiva stesse leggendo in quel momento. Se un utente sta ascoltando un lungo paragrafo di istruzioni importanti e una notifica di marketing “toast” viene attivata a metà frase, lo screen reader abbandona il paragrafo e annuncia la notifica. L’utente deve quindi tornare indietro, ritrovare il punto e rileggere — un processo molto più gravoso di quanto sembri per chi naviga solo tramite tastiera e audio.

Gli utenti con disturbi d’ansia e PTSD possono sperimentare reazioni fisiche di stress — aumento della frequenza cardiaca, perdita di concentrazione o panico — innescate da cambiamenti visivi o uditivi improvvisi e inattesi. L’imprevedibilità di un ambiente pieno di interruzioni incontrollate può rendere alcuni siti web praticamente inutilizzabili per queste persone.

Gli utenti con epilessia o disturbi vestibolari possono subire danni da alcuni tipi di interruzioni, in particolare quelle che comportano lampeggi o movimenti rapidi. Sebbene la Linea guida 2.3 affronti specificamente i rischi di crisi epilettiche, i banner di notifica animati e le notifiche video in riproduzione automatica che compaiono inaspettatamente si collocano all’intersezione di entrambi i criteri.

Consideriamo uno scenario concreto: un utente con ADHD sta usando un portale di home banking per trasferire denaro tra conti. Sta controllando con attenzione l’importo del trasferimento e il numero del conto di destinazione. Un avviso promozionale scorre dal bordo inferiore destro dello schermo, attivando un annuncio dello screen reader e un’animazione di ingresso. L’utente perde il filo, non riesce a trovare il pulsante di chiusura perché l’animazione ha distolto l’attenzione, e invia per errore l’importo sbagliato. Non si tratta di un caso limite ipotetico — è un esito prevedibile dell’ignorare questo criterio.

Al di là della disabilità, le interruzioni incontrollate danneggiano anche l’usabilità per tutti gli utenti, aumentano i tassi di abbandono (gli utenti semplicemente lasciano i siti che li bombardano) e possono ridurre le conversioni proprio sulle azioni che le interruzioni miravano a promuovere. Dal punto di vista SEO, alti tassi di abbandono e brevi durate di sessione sono correlati a segnali di ranking peggiori, il che significa che accessibilità e performance di business sono allineate in questo ambito.

Regole Axe-core Correlate

WCAG 2.2.4 richiede test manuali. Gli strumenti automatici, incluso axe-core, non possono rilevare in modo affidabile se un sito produce interruzioni incontrollabili, perché ciò richiederebbe che lo strumento: osservi tutti i contenuti dinamici iniettati durante una sessione utente, valuti se ogni iniezione è stata avviata dall’utente, verifichi se esiste un meccanismo di chiusura o rinvio e se è accessibile, e determini se il contenuto rientra nella categoria di emergenza. Si tratta di valutazioni contestuali e comportamentali che esulano dall’ambito dell’analisi statica del DOM.

• Test manuale richiesto — Controllo delle interruzioni: I tester devono interagire manualmente con la pagina per un certo periodo di tempo per osservare se qualche aggiornamento di contenuto, notifica, dialogo o contenuto multimediale si avvia senza l’iniziativa dell’utente. Per ogni interruzione osservata, il tester deve verificare che esista un meccanismo accessibile per rinviarla o sopprimerla, che tale meccanismo sia a sua volta accessibile tramite tastiera e annunciato dallo screen reader, e che l’interruzione non si ripresenti dopo la chiusura senza che l’utente la riattivi.
• Test manuale richiesto — Valutazione delle live region: Le pagine che utilizzano aria-live, role='alert' o role='status' devono essere esaminate manualmente per determinare se gli annunci sono attivati da azioni dell’utente (accettabile) o da eventi basati sul tempo o su push dal server (potenzialmente non conformi). Uno strumento automatico può segnalare la presenza di live region ma non può determinare se producono interruzioni inattese durante una reale sessione utente.
• Test manuale richiesto — Uso della Notification API: Le applicazioni web che richiedono il permesso di inviare notifiche push a livello di browser devono offrire un meccanismo chiaro per consentire all’utente di gestire o sopprimere queste notifiche dall’interno dell’applicazione web stessa, senza fare affidamento esclusivamente sui controlli a livello di browser. Ciò richiede un’ispezione manuale del flusso di richiesta di permesso per le notifiche e della disponibilità di preferenze di notifica in-app.

Come Eseguire i Test

1. Esegui una scansione automatizzata come base. Apri la pagina in Chrome o Firefox ed esegui axe DevTools o Lighthouse. Sebbene nessuno dei due strumenti disponga di una regola dedicata per il criterio 2.2.4, la scansione automatizzata segnalerà problemi correlati: ruoli mancanti sui contenuti dinamici, live region configurate in modo errato e problemi di gestione del focus nei dialoghi. Prendi nota di eventuali regioni aria-live o elementi con role='alert' segnalati, poiché richiederanno un follow-up manuale.
2. Osserva passivamente la pagina per almeno due o tre minuti. Senza cliccare nulla, osserva e ascolta eventuali contenuti che cambiano, compaiono o si annunciano da soli. Usa uno screen reader in esecuzione in background (NVDA con Firefox o VoiceOver con Safari su macOS) e ascolta eventuali annunci non attivati da una tua azione. Annota ogni interruzione, il momento in cui avviene e il suo contenuto.
3. Testa i flussi interattivi che comunemente attivano notifiche. Accedi all’applicazione, se applicabile, naviga verso un modulo o un processo a più fasi e inizia a compilarlo lentamente. Annota eventuali interruzioni che si verificano: avvisi di scadenza della sessione, inviti alla chat, banner promozionali, aggiornamenti di avanzamento o richieste di iscrizione. Per ciascuna, prova a chiuderla o rinviarla usando solo la tastiera (Tab, Esc, Invio, Barra spaziatrice). Verifica che il focus ritorni in una posizione logica dopo la chiusura.
4. Testa con NVDA e Firefox. Attiva NVDA, apri Firefox e naviga nella pagina. Ascolta con attenzione eventuali output vocali che interrompono la lettura corrente. Se viene attivata una notifica automatica, prova a chiuderla usando i controlli da tastiera e verifica che NVDA annunci la conferma di chiusura o che il focus ritorni in modo appropriato.
5. Testa con JAWS e Chrome. Ripeti i test di osservazione passiva e dei flussi interattivi usando JAWS con Chrome. JAWS e NVDA gestiscono le live region in modo diverso, quindi è importante testarli entrambi per assicurarsi che le interruzioni vengano annunciate in modo coerente e che i meccanismi di chiusura funzionino con entrambi gli screen reader.
6. Testa con VoiceOver e Safari su iOS. Su un dispositivo mobile o simulatore, usa VoiceOver con Safari per navigare nella pagina. Scorri tra i contenuti e osserva se si verificano interruzioni. Metti alla prova il meccanismo di chiusura usando i gesti touch (doppio tap per attivare) e verifica che il focus ritorni in una posizione significativa.
7. Verifica la presenza di un’impostazione per le preferenze di notifica. Cerca un profilo utente, un pannello impostazioni o una sezione di preferenze di accessibilità all’interno dell’applicazione. Verifica che esista un controllo per sopprimere o configurare globalmente le notifiche e testa che l’attivazione di questa impostazione impedisca effettivamente il verificarsi di interruzioni durante una sessione successiva.
8. Esamina il codice JavaScript o l’attività di rete. Negli strumenti di sviluppo del browser, osserva le schede Network e Console durante la sessione. Cerca connessioni WebSocket, intervalli di polling o chiamate setTimeout/setInterval che iniettano contenuti nel DOM. Ciascuno di questi è una potenziale fonte di interruzioni e dovrebbe essere tracciato per assicurarsi che sia implementato un controllo da parte dell’utente.

Come Correggere

Widget di chat che si apre automaticamente — Non corretto

<!-- Chat widget opens automatically after 10 seconds with no close button -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

Widget di chat che si apre automaticamente — Corretto

<!-- Chat widget includes a dismiss button and respects a user preference -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Dismiss button allows user to postpone the interruption -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Check whether the user has previously dismissed the chat offer
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Move focus into the dialog so screen reader users are aware of it
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Suppress for the remainder of the session
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Return focus to the element the user was on before the interruption
    document.getElementById('main-content').focus();
  });
</script>

Notifica “toast” di marketing incontrollabile — Non corretto

<!-- Toast fires every 30 seconds, no way to stop it -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

Notifica “toast” di marketing incontrollabile — Corretto

<!-- Toast fires once, includes a dismiss control, and respects a preference -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Dismiss button suppresses future promos in this session -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Only show once, and only if the user has not opted out
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Suppress all future promotional interruptions permanently
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

Modal di timeout di sessione senza controllo da parte dell’utente — Non corretto

<!-- Modal fires automatically, traps focus with no postpone option -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

Modal di timeout di sessione senza controllo da parte dell’utente — Corretto

<!-- Modal provides both a continue option and a postpone option,
     and announces itself clearly to screen readers -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Postpone option gives the user meaningful control -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

Errori Comuni

• Usare role='alert' per messaggi promozionali o a bassa priorità. Il ruolo alert segnala urgenza agli screen reader e provoca un’interruzione immediata della lettura. I messaggi di marketing, i suggerimenti e gli annunci di nuove funzionalità dovrebbero invece usare role='status' o aria-live='polite', che annunciano il contenuto solo dopo che lo screen reader ha terminato l’output corrente.
• Fornire un pulsante di chiusura visibile solo al passaggio del mouse o al focus, rendendolo praticamente inaccessibile. Se il meccanismo di chiusura richiede che l’utente passi con il mouse per renderlo visibile, gli utenti che usano solo la tastiera e gli utenti di screen reader non possono vederlo o raggiungerlo. Il pulsante di chiusura deve essere sempre visibile o, almeno, sempre raggiungibile tramite l’ordine di tabulazione della tastiera.
• Restituire il focus a document.body dopo aver chiuso una notifica. Quando una notifica o un dialogo viene chiuso, il focus deve tornare a un elemento significativo e contestualmente appropriato — in genere l’elemento con cui l’utente stava interagendo prima che l’interruzione comparisse. Spostare il focus su body costringe gli utenti di screen reader a ri-navigare l’intera pagina.
• Attivare più regioni aria-live simultaneamente. Quando diverse live region si aggiornano nello stesso momento, gli screen reader accodano o scartano gli annunci in modo imprevedibile. Ogni interruzione dovrebbe essere gestita con attenzione, in modo che venga attivata una sola live region alla volta e che gli aggiornamenti siano raggruppati quando possibile.
• Considerare sufficiente il prompt nativo del browser per il permesso delle notifiche. La finestra di permesso del browser per la Web Notifications API opera a livello di sistema operativo, non a livello di applicazione. WCAG 2.2.4 richiede che gli utenti possano gestire le notifiche dall’interno dell’applicazione web stessa, non solo bloccando il sito a livello di browser.
• Reimpostare una notifica chiusa a ogni caricamento di pagina. Se un utente chiude una notifica e questa riappare la volta successiva che visita la stessa pagina o un’altra pagina del sito, l’azione di chiusura è stata priva di significato. Le preferenze dovrebbero persistere almeno per la durata della sessione usando sessionStorage, o in modo permanente usando localStorage o una preferenza lato server.
• Usare setInterval per far scorrere banner o suggerimenti senza un controllo di pausa. I contenuti a rotazione che si aggiornano con un timer costituiscono un’interruzione. Se il contenuto cambia mentre un utente di screen reader lo sta leggendo, l’annuncio ricomincerà da capo. Queste giostre di contenuti e banner rotanti richiedono un controllo di riproduzione/pausa e non devono scorrere all’infinito senza il consenso dell’utente.
• Iniettare una notifica nel DOM in una posizione che provoca salti di scorrimento inattesi. Se un banner di notifica viene iniettato nella parte superiore della pagina e la pagina si sposta verso il basso, gli utenti perdono la posizione di lettura visiva. Le notifiche dovrebbero essere iniettate in modo da non influire sul layout del contenuto che l’utente sta visualizzando, in genere usando un posizionamento fisso o assoluto.
• Supporre che un breve timer di chiusura automatica soddisfi il criterio. Un “toast” che scompare dopo cinque secondi non offre agli utenti un controllo significativo — molti utenti non riescono a leggere, elaborare o rispondere a un contenuto così rapidamente, in particolare quelli con disabilità cognitive o che usano screen reader. Fornire solo un timer di chiusura automatica senza un pulsante di chiusura controllato dall’utente non è conforme.
• Non testare il comportamento delle interruzioni quando sono attive le preferenze di riduzione del movimento o di notifica del sistema operativo o del browser. Alcuni utenti impostano preferenze a livello di sistema operativo per ridurre il movimento o sopprimere le notifiche. Questi segnali dovrebbero essere rispettati dall’applicazione, e gli sviluppatori dovrebbero testare con la media query prefers-reduced-motion: reduce attiva per assicurarsi che le interruzioni animate siano soppresse in modo appropriato.

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 vincolante per l’accessibilità web per un’ampia gamma di organizzazioni che operano in Turchia. La circolare adotta WCAG 2.2 come standard tecnico di riferimento e impone la conformità per i soggetti coperti. Le tipologie di entità esplicitamente incluse nella circolare comprendono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e organizzazioni di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio autorizzate, aziende di trasporto privato e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE).

WCAG 2.2.4: Interruzioni è un criterio di livello AAA, il che significa che non rientra tra i requisiti di conformità di base previsti dalla Circolare Presidenziale 2025/10 per la maggior parte dei soggetti coperti. Le organizzazioni che raggiungono e dichiarano la conformità ai livelli A e AA sono considerate legalmente conformi ai requisiti minimi della circolare. Tuttavia, i criteri di livello AAA come il 2.2.4 hanno un peso pratico e reputazionale significativo nel contesto del mercato turco.

Diverse delle tipologie di entità coperte — in particolare ospedali, banche e istituzioni pubbliche — servono popolazioni di utenti con tassi elevati di condizioni cognitive e neurologiche, disturbi d’ansia e difficoltà di attenzione legate all’età avanzata. Per queste organizzazioni, le interruzioni incontrollate nelle interfacce digitali rappresentano non solo un fallimento in termini di accessibilità, ma anche un potenziale rischio per la sicurezza dei pazienti o per danni finanziari. Un portale pazienti ospedaliero che attiva promemoria sui farmaci o notifiche di appuntamenti incontrollabili durante un flusso critico di compilazione di un modulo, o un’applicazione bancaria che mostra banner promozionali non sopprimibili durante la revisione di una transazione, crea danni concreti per gli utenti di questi gruppi.

Per le organizzazioni in Turchia che intendono dimostrare leadership nell’accessibilità digitale — in particolare quelle che perseguono dichiarazioni volontarie di conformità a WCAG 2.2 di livello AAA, che rispondono a requisiti di accessibilità negli appalti pubblici o che mirano a mercati europei in cui l’European Accessibility Act (EAA) stabilisce uno standard più elevato — l’implementazione del criterio 2.2.4 rappresenta un elemento di differenziazione significativo. L’SDK di overlay Accsible supporta le organizzazioni nel soddisfare questi standard più elevati fornendo funzionalità configurabili di gestione delle notifiche, persistenza delle preferenze utente e comportamenti dei widget attenti all’accessibilità, in linea sia con le aspettative normative turche sia con le migliori pratiche internazionali.