WCAG 2.3.2: Tre lampeggi

Cosa Significa Questa Regola

WCAG 2.3.2 Tre Lampi è un criterio di successo di livello AAA sotto il principio Operable. Stabilisce che le pagine web non devono contenere nulla che lampeggi più di tre volte in un periodo di un secondo. A differenza del corrispondente criterio di livello AA (2.3.1 Tre Lampi o Sotto la Soglia), questo criterio non consente alcuna eccezione per piccole aree lampeggianti o lampi che rientrano al di sotto delle soglie generali di lampo e di lampo rosso. La regola è assoluta: se un contenuto lampeggia più di tre volte al secondo, non è conforme, indipendentemente da dimensione, colore o contrasto.

Un lampo è definito da WCAG come una coppia di cambiamenti opposti nella luminanza relativa che può causare crisi epilettiche in alcune persone. Più praticamente, qualsiasi lampeggio visibile acceso-spento, animazione tipo strobo, immagini che si susseguono rapidamente o video tremolanti che completano più di tre cicli completi al secondo rientra nell’ambito di questa regola. Il termine "tre lampi" si riferisce a tre oscillazioni complete — cioè contenuti che alternano uno stato più chiaro e uno più scuro tre volte entro un singolo secondo.

I tipi di contenuto interessati sono ampi e includono GIF animate, animazioni CSS che utilizzano @keyframes, aggiornamenti del DOM guidati da JavaScript che causano un rapido alternarsi visivo, animazioni HTML5 Canvas, contenuti video incorporati, animazioni SVG e reti pubblicitarie o widget di terze parti che incorporano media animati. Anche un tremolio sottile in un testo a scorrimento tipo marquee o in visualizzazioni di dati che si aggiornano rapidamente può attivare questo criterio se la frequenza supera tre lampi al secondo.

Un pass ai sensi del 2.3.2 significa che la pagina non contiene alcun contenuto lampeggiante che superi la soglia di tre lampi al secondo. Un fail si verifica ogni volta che qualsiasi porzione della pagina — indipendentemente da quanto piccola sia l’area — lampeggia più di tre volte in qualsiasi intervallo di un secondo. Non esiste alcuna eccezione di area sicura in questo criterio, ed è questo che lo distingue dal 2.3.1. Un piccolo cursore lampeggiante, uno spinner di caricamento animato o un banner pubblicitario che cicla rapidamente potrebbero tutti costituire violazioni se lampeggiano a frequenze superiori a 3 Hz.

Perché È Importante

L’epilessia fotosensibile colpisce circa 1 persona su 4.000 a livello globale, ma la popolazione totale suscettibile a qualche forma di risposta neurologica fotosensibile — incluse emicranie fotosensibili, disturbi vestibolari e fotosensibilità non epilettica — è significativamente più ampia. Per queste persone, l’esposizione a contenuti che lampeggiano rapidamente su uno schermo non è un semplice fastidio: può scatenare crisi epilettiche generalizzate, perdita di coscienza, lesioni o, in rari casi, la morte. A differenza di molte barriere di accessibilità che degradano l’esperienza utente, i contenuti lampeggianti rappresentano un rischio di sicurezza acuto.

Consideriamo uno scenario pratico: un sito di notizie turco incorpora un ticker in tempo reale con un effetto di evidenziazione animato che pulsa a 8 Hz per attirare l’attenzione sulle notizie dell’ultima ora. Una persona con epilessia fotosensibile apre la pagina sul proprio telefono mentre è in viaggio. Nel giro di pochi secondi, il rapido tremolio scatena una crisi focale, facendo cadere il telefono alla persona e causandole una momentanea perdita di controllo muscolare. Non aveva alcun avvertimento, nessun modo per disabilitare l’effetto in anticipo e nessun rimedio. Questo scenario è completamente prevenibile limitando la frequenza dei lampi a tre al secondo o meno — o eliminando del tutto i contenuti lampeggianti, come richiede il 2.3.2.

Oltre alla dimensione della sicurezza neurologica, il rispetto di questo criterio avvantaggia anche le persone con disturbi vestibolari (che sperimentano vertigini, nausea o disorientamento a causa del movimento), le persone con emicranie scatenate da pattern visivi e le persone con disturbi dell’attenzione che trovano impossibile ignorare o aggirare contenuti che lampeggiano rapidamente. Ridurre o eliminare i contenuti lampeggianti tende anche a migliorare la percezione di professionalità della pagina e a ridurre i tassi di abbandono, poiché molte persone — con disabilità o meno — trovano irritanti le animazioni aggressive.

Da una prospettiva SEO e di performance, eliminare animazioni pesanti e transizioni CSS rapide riduce il carico su CPU e GPU, migliorando metriche Core Web Vitals come il Total Blocking Time e il Cumulative Layout Shift, entrambe segnali di ranking per Google.

Regole Axe-core Correlate

WCAG 2.3.2 richiede test manuali. Nessuna regola automatizzata di axe-core mappa direttamente a questo criterio, e ciò è intenzionale — ecco perché gli strumenti automatici non possono rilevare in modo affidabile le violazioni:

• Test manuale richiesto — Rilevamento della frequenza dei lampi: Gli scanner di accessibilità automatizzati ispezionano il DOM e il CSS statici in un singolo istante. Non possono osservare come si comporta il contenuto nell’arco di un secondo di riproduzione dell’animazione, misurare la frequenza di oscillazione della luminanza di un video o di una GIF animata, o valutare il frame rate di un’animazione Canvas. La frequenza dei lampi è una proprietà temporale che richiede osservazione in tempo reale, rendendola fondamentalmente al di là della portata di strumenti di analisi statica come axe-core. Un tester umano — o strumenti specializzati per l’analisi della fotosensibilità come il Photosensitive Epilepsy Analysis Tool (PEAT) — deve esaminare i contenuti animati in movimento per determinare se superano la soglia di tre lampi al secondo.
• Test manuale richiesto — Contenuti di terze parti e incorporati: Pubblicità, video incorporati, widget di social media e iframe possono iniettare contenuti animati che axe-core non può analizzare, poiché opera entro i vincoli della same-origin policy del browser. Un tester deve osservare manualmente tutti i contenuti incorporati e di terze parti durante la riproduzione per valutarne la conformità.
• Test manuale richiesto — Animazioni guidate da JavaScript: L’alternanza rapida di classi CSS, l’aggiornamento di pixel su canvas o la manipolazione di elementi SVG tramite JavaScript ad alta frequenza possono produrre effetti lampeggianti invisibili a uno snapshot statico del DOM. I tester devono eseguire la pagina in un browser reale, osservare tutti gli stati animati e misurare i cicli di lampo manualmente o con strumenti di analisi del frame rate.

Come Testare

1. Esegui una scansione automatizzata come base: Usa axe DevTools, Lighthouse o l’audit integrato del widget Accsible per identificare eventuali problemi relativi alle animazioni segnalati. Sebbene nessuna regola mappi direttamente al 2.3.2, questi strumenti possono far emergere avvisi correlati su animazioni CSS o regioni ARIA live che si aggiornano rapidamente. Prendi nota degli elementi segnalati, ma tieni presente che un report automatico pulito non conferma la conformità al 2.3.2.
2. Identifica manualmente tutti i contenuti animati: Carica la pagina in un browser e osservala per almeno 30 secondi senza interagire. Annota ogni elemento che lampeggia, sfarfalla, si anima o cambia ripetutamente stato visivo. Includi spinner di caricamento, banner, animazioni hero, video in autoplay, sfondi animati e qualsiasi widget di terze parti. Crea un inventario di questi elementi.
3. Usa il Photosensitive Epilepsy Analysis Tool (PEAT): Per contenuti video o registrazioni dello schermo di animazioni, utilizza PEAT (uno strumento gratuito del Trace Research and Development Center) per analizzare il filmato fotogramma per fotogramma. PEAT segnalerà qualsiasi sequenza che superi le soglie di lampo e riporterà sia la soglia generale di lampo sia la soglia di lampo rosso. Una violazione del 2.3.2 è qualsiasi lampo che superi tre al secondo indipendentemente dalle altre soglie.
4. Misura le frequenze delle animazioni CSS e JavaScript: Apri gli strumenti di sviluppo del browser (Chrome o Firefox) e utilizza la scheda Performance per registrare una sessione di 5 secondi mentre le animazioni sono in esecuzione. Ispeziona il flame graph per operazioni di paint o layout che si ripetono rapidamente. Puoi anche aprire il pannello Animations in Chrome DevTools per vedere le animazioni in esecuzione e le loro durate — dividi 1000 ms per la durata dell’animazione per calcolare gli Hz.
5. Testa con NVDA + Firefox, VoiceOver + Safari e JAWS + Chrome: Le persone che usano screen reader non sono esenti dalla fotosensibilità. Avvia ciascuno screen reader e naviga normalmente nella pagina. Se un contenuto che lampeggia visivamente è presentato anche in modo da causare aggiornamenti rapidi dello schermo (come una live region che annuncia ogni frame di un contatore), documentalo. Il lampeggio visivo rimane una violazione anche per le persone che usano screen reader perché possono avere una certa visione funzionale.
6. Verifica i contenuti di terze parti e incorporati: Scorri tutti gli iframe, i post di social media incorporati, gli spazi pubblicitari e i player video. Riproduci manualmente qualsiasi video con autoplay disabilitato e osserva l’eventuale tremolio rapido. Controlla le GIF animate facendo clic con il tasto destro e ispezionando i dati dei frame in un editor di immagini o nella scheda Network del browser per stimarne il frame rate.
7. Ripeti i test su dispositivi e browser diversi: Alcune animazioni vengono eseguite a velocità diverse su mobile rispetto al desktop a causa delle differenze di accelerazione hardware. Esegui i test sia su un browser desktop sia su un dispositivo mobile (Safari su iOS e Chrome su Android) per confermare una conformità coerente.

Come Correggere

Animazione CSS Keyframe che Lampeggia Troppo Velocemente — Non Corretto

<!-- A badge that flashes to draw attention, completing 8 cycles per second -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — far exceeds 3 per second */
  }
</style>
<span class='alert-badge'>NEW</span>

Animazione CSS Keyframe che Lampeggia Troppo Velocemente — Corretto

<!-- Animation slowed to complete fewer than 3 cycles per second -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.4s infinite; /* ~2.5 Hz — safely below the 3 Hz threshold */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Better still: remove the animation entirely and use a static high-contrast badge -->

Toggle del DOM con JavaScript che Causa Tremolio Rapido — Non Corretto

<!-- Script toggles visibility 10 times per second to simulate a strobe effect -->
<div id='strobe-element' style='width:200px;height:200px;background:white;'></div>
<script>
  setInterval(function() {
    var el = document.getElementById('strobe-element');
    el.style.background = el.style.background === 'white' ? 'black' : 'white';
  }, 100); /* Fires every 100ms = 10 flashes per second -- a serious seizure risk */
</script>

Toggle del DOM con JavaScript che Causa Tremolio Rapido — Corretto

<!-- Removed the rapid toggle entirely; convey state change through text or icon instead -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- If animation is genuinely needed, keep it well under 3 Hz and prefer opacity/color
     transitions over high-contrast luminance switches -->

GIF Animata con Frame Rate Elevato — Non Corretto

<!-- An animated GIF advertisement that cycles through frames at 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- The GIF's internal frame delay is set to 10ms per frame, creating rapid flicker -->

GIF Animata con Frame Rate Elevato — Corretto

<!-- Replace the animated GIF with a static image, or re-export the GIF
     with a minimum frame delay of 334ms per frame (3 fps or slower) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- If motion must be preserved, use a CSS animation with prefers-reduced-motion support -->
<picture>
  <source srcset='promo-static.png' media='(prefers-reduced-motion: reduce)'>
  <img src='promo-slow.gif' alt='Special offer — 50% off this weekend only'>
</picture>

Errori Comuni

• Dare per scontato che l’eccezione di "piccola area" del 2.3.1 si applichi al 2.3.2: WCAG 2.3.1 consente contenuti lampeggianti che occupano meno del 25% di un campo visivo di 10 gradi. WCAG 2.3.2 non prevede alcuna eccezione di questo tipo — un piccolo cursore lampeggiante o un piccolo punto di caricamento che lampeggia più di tre volte al secondo è una violazione completa a livello AAA.
• Impostare la proprietà CSS animation-duration su valori come 0.1s o 0.2s senza calcolare la frequenza di lampo risultante: Un’animazione di 0.1s che oscilla tra due stati completa 10 cicli al secondo (10 Hz). Dividi 1 per la durata in secondi per ottenere gli Hz; assicurati che il risultato sia 3 o inferiore.
• Incorporare script pubblicitari di terze parti senza esaminarne il comportamento delle animazioni: Le reti pubblicitarie servono frequentemente creatività animate con frequenze di lampo elevate ottimizzate per il click-through, non per l’accessibilità. Verifica sempre i contenuti di terze parti utilizzando PEAT o un’ispezione manuale dei frame prima della messa in produzione.
• Usare loop setInterval o requestAnimationFrame per alternare rapidamente classi CSS per indicatori di caricamento o di avanzamento: Qualsiasi loop JavaScript che cambia la luminanza o la visibilità di un elemento più di tre volte al secondo crea una violazione del 2.3.2, anche se l’effetto sembra sottile in condizioni di visualizzazione normali.
• Non testare SVG animati ed elementi Canvas: Le animazioni SVG che utilizzano <animate> o SMIL, e i giochi o le visualizzazioni di dati basati su Canvas, vengono raramente testati con PEAT o strumenti di analisi del frame rate, eppure sono pienamente in grado di superare la soglia di lampo.
• Fare affidamento esclusivamente su axe-core o Lighthouse per confermare la conformità al 2.3.2: Gli strumenti automatici non possono rilevare questo criterio. Un risultato pulito di una scansione automatizzata non significa nulla per il 2.3.2; solo la revisione manuale e l’analisi con PEAT possono confermare la conformità.
• Trattare prefers-reduced-motion come una soluzione completa per il 2.3.2: Rispettare la media query prefers-reduced-motion è una best practice ed è utile per molte persone, ma è un meccanismo basato su un’opzione impostata dall’utente. WCAG 2.3.2 richiede che i contenuti siano sicuri per impostazione predefinita, non solo quando l’utente ha configurato una preferenza di sistema. Le persone che non hanno configurato questa impostazione restano a rischio.
• Applicare limiti alla frequenza dei lampi solo ai video ma non alle animazioni CSS, JavaScript o GIF: I team talvolta verificano i contenuti video con PEAT ma trascurano le animazioni CSS keyframe e i toggle guidati da JavaScript. Tutte le tecnologie di animazione devono essere valutate.
• Usare proprietà CSS background-image per visualizzare GIF animate: Le GIF animate impostate come immagini di sfondo CSS sono meno visibili alle persone che eseguono una scansione visiva e sono facili da trascurare durante gli audit. Includi sempre le immagini di sfondo nel tuo inventario delle animazioni.
• Non ripetere i test dopo che test A/B o modifiche di personalizzazione hanno iniettato nuovi contenuti animati: I sistemi di marketing e personalizzazione possono iniettare dinamicamente banner o overlay con animazioni che non sono mai stati esaminati per la conformità al WCAG 2.3.2. Stabilisci un controllo di revisione per qualsiasi contenuto iniettato dinamicamente.

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 standard obbligatori di accessibilità web e mobile per un’ampia gamma di soggetti che operano in Turchia. La circolare adotta WCAG 2.2 come quadro di riferimento tecnico, con conformità obbligatoria generalmente richiesta ai livelli A e AA.

WCAG 2.3.2 è un criterio di livello AAA e pertanto non è giuridicamente obbligatorio ai sensi della circolare per la maggior parte dei soggetti interessati. Tuttavia, il suo oggetto — la prevenzione di contenuti che possono scatenare crisi epilettiche — si interseca direttamente con il dovere generale di diligenza e con i principi di non discriminazione che sono alla base della regolamentazione. I seguenti tipi di soggetti sono coperti dalla circolare e dovrebbero considerare il 2.3.2 come un forte obbligo di best practice anche quando non è strettamente richiesto: piattaforme di e-commerce, istituzioni pubbliche e agenzie governative, banche e istituzioni finanziarie, 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).

Per le istituzioni pubbliche e i fornitori di servizi sanitari in particolare, le implicazioni etiche del 2.3.2 sono particolarmente rilevanti. Un portale sanitario governativo o una pagina di informazioni per pazienti di un ospedale che scatena una crisi epilettica in una persona fotosensibile rappresenterebbe sia un fallimento in termini di sicurezza sia una crisi reputazionale. Sebbene la circolare non imponga esplicitamente la conformità al livello AAA, le organizzazioni che desiderano dimostrare un’accessibilità di livello eccellente — sia per l’idoneità agli appalti, sia per la fiducia del pubblico, sia per partnership commerciali internazionali — dovrebbero implementare il 2.3.2 insieme ai loro obblighi obbligatori di livello A e AA.

Le organizzazioni che forniscono servizi al mercato dell’Unione Europea dovrebbero inoltre notare che l’European Accessibility Act (EAA), entrato in applicazione nel giugno 2025, fa riferimento alla norma EN 301 549, che a sua volta fa riferimento a WCAG. Le aziende turche che esportano prodotti o servizi digitali verso gli Stati membri dell’UE possono affrontare requisiti più severi attraverso tale canale. L’implementazione proattiva del 2.3.2 posiziona favorevolmente le organizzazioni turche sia per la conformità interna sia per quella transfrontaliera.

Da un punto di vista pratico di implementazione, l’SDK del widget overlay Accsible può assistere le organizzazioni interessate fornendo alle persone la possibilità di mettere in pausa o interrompere tutte le animazioni su una pagina, contribuendo a ridurre il rischio di fotosensibilità per chi è consapevole della propria condizione. Tuttavia, questo controllo attivato dall’utente è una misura supplementare, non un sostituto della rimozione o del rallentamento dei contenuti lampeggianti alla fonte, come richiede il 2.3.2.