WCAG 2.3.1: Tre lampeggi o al di sotto della soglia

Cosa Significa Questa Regola

WCAG 2.3.1 — Tre lampeggi o al di sotto della soglia — è un criterio di successo di livello A sotto il principio Operable. Stabilisce che le pagine web non devono contenere alcun contenuto che lampeggi più di tre volte in un periodo di un secondo, a meno che quel contenuto lampeggiante non sia abbastanza piccolo o abbastanza tenue da rientrare al di sotto della soglia generale di lampeggio o della soglia di lampeggio rosso definite.

Un lampeggio è definito come una coppia di cambiamenti opposti nella luminanza relativa che può causare crisi epilettiche in persone suscettibili. In particolare, WCAG definisce due tipi di lampeggi pericolosi:

• Lampeggio generale: Una coppia di cambiamenti opposti in cui la luminanza più alta è almeno il 10% della luminanza relativa massima (0,80) e la differenza di luminanza è almeno il 10% del massimo. In pratica, questo significa contenuti che passano rapidamente da uno stato chiaro a uno scuro abbastanza velocemente da produrre un effetto stroboscopico.
• Lampeggio rosso: Una coppia di transizioni opposte che coinvolgono un colore rosso saturo. Questo è trattato con particolare attenzione perché i lampeggi rossi sono stati clinicamente associati a un rischio maggiore di scatenare crisi fotosensibili.

Il criterio si applica a tutti i contenuti web indipendentemente dal formato — animazioni HTML, transizioni CSS, effetti gestiti da JavaScript, video incorporati, GIF, animazioni SVG, scene WebGL, grafica renderizzata su canvas e widget pubblicitari di terze parti. Se un contenuto lampeggia a una frequenza superiore a tre lampeggi al secondo e non rientra al di sotto delle soglie di luminanza o di dimensione, non soddisfa questo criterio in modo incondizionato.

Eccezioni e soglie che consentono il superamento del criterio: WCAG 2.3.1 permette contenuti lampeggianti se soddisfano una delle seguenti condizioni:

• L’area combinata dei lampeggi che si verificano simultaneamente non copre più di 0,006 steradianti totali all’interno di qualsiasi campo visivo di 10 gradi sullo schermo (circa un rettangolo di 341 × 256 pixel alle distanze di visualizzazione tipiche, o approssimativamente 21.824 pixel quadrati su un display largo 1024 pixel visto a distanza di un braccio).
• Il lampeggio è al di sotto della soglia generale di lampeggio (il cambiamento di luminanza è inferiore al 10%) o al di sotto della soglia di lampeggio rosso (la componente di rosso saturo non cambia di più della soglia definita).

Un singolo evento di lampeggio con un contrasto di luminanza molto basso o un’area di schermo molto piccola può quindi essere consentito. Tuttavia, poiché queste soglie sono sfumate e richiedono strumenti di misurazione fotometrica per essere verificate con precisione, la maggior parte dei professionisti adotta l’approccio prudente di evitare semplicemente qualsiasi contenuto che lampeggi più di tre volte al secondo. Il contenuto che lampeggia esattamente tre volte al secondo (3 Hz) è al limite — il contenuto che supera i 3 Hz non è conforme indipendentemente dalla dimensione, a meno che le soglie di dimensione o luminanza non siano soddisfatte in modo definitivo.

Il criterio regola qualsiasi contenuto che viene renderizzato durante la normale interazione con la pagina. Non esenta contenuti nascosti dietro controlli attivati dall’utente se tali contenuti vengono riprodotti automaticamente al caricamento della pagina. Se un video inizia a riprodursi automaticamente e contiene sequenze lampeggianti che superano la soglia, la pagina non soddisfa questo criterio dal momento in cui viene caricata.

Perché È Importante

L’epilessia fotosensibile colpisce circa 1 persona su 4.000 a livello globale — circa il 3% della popolazione complessiva con epilessia. Tuttavia, la sensibilità alla luce che lampeggia o sfarfalla rapidamente è più ampia della sola epilessia clinica. Molte persone con disturbi emicranici, disfunzioni vestibolari, condizioni dello spettro autistico e sindrome post-commozione cerebrale possono sperimentare notevole disagio, disorientamento, nausea o dolore a causa di stimoli visivi che lampeggiano rapidamente, anche se non hanno una diagnosi di disturbo convulsivo.

Le implicazioni sono particolarmente gravi per questo criterio rispetto alla maggior parte degli altri requisiti di accessibilità. Un utente che si imbatte in testo alternativo mancante sperimenta esclusione e frustrazione. Un utente che incontra contenuti che scatenano una crisi fotosensibile può vivere un’emergenza medica — inclusa perdita di coscienza, lesioni dovute a cadute e, in casi rari ma documentati, esiti potenzialmente letali. L’Harding Flash and Pattern Analyzer, uno strumento di broadcast ampiamente utilizzato, è stato sviluppato specificamente per prevenire tali eventi in televisione, e il web presenta rischi analoghi.

Uno scenario concreto del mondo reale illustra bene il pericolo: si consideri un sito di notizie che riproduce automaticamente un video promozionale contenente una rapida sequenza di fotogrammi alternati chiari e scuri — un artefatto comune di alcuni tipi di compressione video o degli effetti del flash della fotocamera. Una persona con epilessia fotosensibile visita la homepage durante il tragitto mattutino su un dispositivo mobile. Senza alcun avviso e senza alcuna possibilità di disabilitare il contenuto, è esposta a una sequenza che scatena una crisi mentre utilizza i mezzi pubblici. Questo scenario non è ipotetico; si è verificato in contesti reali, incluso il famigerato episodio di Pokémon del 2007 che ha scatenato crisi in centinaia di spettatori in Giappone, e casi documentati che coinvolgono unità pubblicitarie basate sul web.

Oltre alla dimensione della sicurezza, la conformità a questo criterio ha anche implicazioni di usabilità per il pubblico generale. I contenuti che lampeggiano rapidamente creano una pessima esperienza di lettura, aumentano il carico cognitivo e sono considerati di disturbo e poco professionali nella maggior parte dei contesti di design. Eliminare tali contenuti migliora la concentrazione, riduce i tassi di abbandono e trasmette affidabilità — tutti fattori che contribuiscono positivamente a metriche SEO come il tempo di permanenza e i tassi di coinvolgimento. Inoltre, i crawler dei motori di ricerca tengono sempre più conto dei Core Web Vitals e dei segnali di esperienza utente nelle classifiche, e i siti con annunci o animazioni lampeggianti invasive possono essere penalizzati indirettamente.

Regole Axe-core Correlate

WCAG 2.3.1 richiede test manuali perché gli strumenti automatici non possono analizzare in modo affidabile le proprietà fotometriche dei contenuti dinamici in tempo reale. Nessuna regola automatizzata di axe-core mappa direttamente a questo criterio. Le ragioni di questo limite sono fondamentali per il funzionamento dell’automazione per l’accessibilità:

• Perché l’automazione fallisce in questo caso: Gli scanner automatici analizzano il DOM e il CSS statici in un determinato momento. Possono rilevare che esiste un’animazione o un elemento video, ma non possono misurare la frequenza effettiva dei lampeggi, i valori di luminanza di ogni fotogramma o l’area spaziale della regione lampeggiante così come percepita da un osservatore umano a una distanza di visualizzazione tipica. Determinare se un lampeggio supera la soglia di 3 Hz o la soglia di area di 0,006 steradianti richiede un’analisi fotometrica fotogramma per fotogramma — un compito che richiede strumenti dedicati come l’Harding Flash and Pattern Analyzer (HFPA), il Photosensitive Epilepsy Analysis Tool (PEAT) o la revisione manuale dei file sorgente delle animazioni.
• Video incorporati e contenuti di terze parti: Gran parte dei contenuti a rischio più elevato (annunci video in autoplay, widget di social media incorporati, librerie di animazione di terze parti) è caricata da domini esterni. Gli strumenti automatici in genere non possono accedere o analizzare i contenuti cross-origin a livello di fotogramma, rendendo impossibile valutare programmaticamente la frequenza dei lampeggi all’interno di tali risorse.
• Animazioni GIF e canvas: I file GIF animati e gli elementi canvas HTML5 renderizzano i loro fotogrammi di animazione al di fuori del normale albero di accessibilità. Sia axe-core che Lighthouse non hanno la capacità di decodificare il timing dei fotogrammi GIF o intercettare le chiamate di disegno del canvas per calcolare i cambiamenti di luminanza tra i fotogrammi.
• Animazioni CSS e JavaScript: Sebbene axe-core possa rilevare la presenza di proprietà CSS animation o transition, non può valutare se l’output visivo risultante in fase di esecuzione produca cambiamenti di luminanza che superano le soglie di lampeggio generale o rosso.

Poiché nessuna regola automatizzata intercetta questa violazione, l’intero onere della conformità ricade sulla revisione manuale del design, sull’analisi dei video prima della pubblicazione e sulla consapevolezza degli sviluppatori durante la fase di creazione dei contenuti. Questo rende essenziali, per una conformità sostenibile, i controlli di processo editoriali e di QA — non solo gli interventi tecnici.

Come Testare

1. Inventariare tutti i contenuti dinamici: Prima di qualsiasi test basato su strumenti, eseguire un audit della pagina per tutti i contenuti che si muovono, lampeggiano, sfarfallano o si animano. Questo include video in autoplay, GIF animate, animazioni CSS con keyframe, animazioni gestite da JavaScript, animazioni SVG, elementi canvas e widget di terze parti incorporati come unità pubblicitarie o embed di social media. Documentare ogni istanza con la sua origine e il relativo meccanismo di controllo.
2. Usare il Photosensitive Epilepsy Analysis Tool (PEAT): PEAT è uno strumento gratuito sviluppato dal Trace Research and Development Center, progettato specificamente per analizzare i contenuti video alla ricerca di pericoli di lampeggio secondo la specifica Harding. Registrare una cattura dello schermo della pagina web o dell’animazione in questione alla massima risoluzione, quindi importare il file video in PEAT. Lo strumento segnalerà se qualche sequenza supera la soglia generale di lampeggio o la soglia di lampeggio rosso e in quali timestamp.
3. Applicare l’Harding Flash and Pattern Analyzer per contenuti di qualità broadcast: Per i contenuti video che saranno incorporati da flussi di produzione (ad esempio siti di emittenti, organizzazioni di news), eseguire i file video sorgente tramite HFPA prima della pubblicazione. Questo è lo strumento di riferimento per il controllo pre-pubblicazione.
4. Osservazione manuale — il conteggio dei tre lampeggi: Per animazioni CSS, effetti JavaScript o file GIF per i quali l’analisi basata su strumenti è impraticabile, riprodurre l’animazione e provare a contare il numero di cicli completi chiaro-scuro-chiaro all’interno di un singolo secondo. Se si osservano tre o più cicli completi al secondo, è probabile che il contenuto non sia conforme. Utilizzare software di registrazione dello schermo con riproduzione fotogramma per fotogramma per aiutare in questo conteggio.
5. Controllare i contenuti video fotogramma per fotogramma: Aprire i file video in un editor video (come DaVinci Resolve, versione gratuita) che mostri dati a livello di fotogramma tramite waveform o istogramma. Scorrere le sezioni con rapidi cambiamenti visivi e verificare la presenza di pattern alternati di luminanza alta-bassa che si verificano più di tre volte al secondo. Prestare particolare attenzione alle sequenze che coinvolgono rosso saturo su sfondi scuri.
6. Testare con gli strumenti di sviluppo del browser per le animazioni CSS: In Chrome DevTools, aprire il pannello Animations (More Tools → Animations). Ispezionare le durate delle animazioni dichiarate e i cicli di iterazione. Un’animazione con una durata inferiore a 333 millisecondi che alterna stati ad alto contrasto a ogni iterazione supererà la soglia di 3 Hz. Calcolare: se un ciclo completo chiaro-scuro-chiaro si completa in meno di 333 ms, il contenuto non è conforme.
7. Valutare l’area spaziale per i casi al limite: Se un contenuto lampeggia a una frequenza superiore a 3 Hz ma appare molto piccolo sullo schermo, misurarne le dimensioni in pixel. Su un display largo 1024 pixel a distanza di visualizzazione normale (circa 57–60 cm), la soglia di area sicura è approssimativamente 21.824 pixel quadrati. Moltiplicare la larghezza e l’altezza della regione lampeggiante; se il risultato è inferiore a questa soglia, il contenuto può rientrare nell’eccezione di area sicura — ma documentare attentamente questa valutazione.
8. Testare i video in autoplay al caricamento della pagina: Disabilitare qualsiasi interazione con la pagina dopo il caricamento e osservare se qualche video o animazione inizia a riprodursi automaticamente. Se ciò accade, applicare immediatamente i test sopra al contenuto in autoplay, poiché l’utente non ha alcuna possibilità di intervenire prima dell’esposizione.

Come Correggere

GIF in autoplay con lampeggio rapido — Non corretto

<!-- An animated GIF that cycles between a bright yellow and black frame
     at approximately 10 times per second, far exceeding the 3 Hz threshold -->
<img src='attention-flash.gif' alt='Special offer alert' width='600' height='300'>

GIF in autoplay con lampeggio rapido — Corretto

<!-- Replace the flashing GIF with a static image and use a subtle CSS
     animation that does not alter luminance rapidly. The animation here
     uses a gentle scale pulse at a rate well below 3 Hz (one cycle per 2 seconds). -->
<img src='attention-static.png'
     alt='Special offer alert'
     class='pulse-attention'
     width='600'
     height='300'>

<style>
  @keyframes gentlePulse {
    0%, 100% { transform: scale(1); }
    50% { transform: scale(1.03); }
  }
  .pulse-attention {
    animation: gentlePulse 2s ease-in-out infinite;
  }
</style>

Animazione CSS con keyframe che lampeggia tra colori ad alto contrasto — Non corretto

<!-- A CSS animation that alternates a banner between white and black
     with a 100ms total duration, producing 10 flashes per second -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 0.1s linear infinite;
  }
</style>

Animazione CSS con keyframe che lampeggia tra colori ad alto contrasto — Corretto

<!-- Slowing the animation duration to 1 second per full cycle means
     the luminance alternates once per second (1 Hz), well below the 3 Hz limit.
     Alternatively, use prefers-reduced-motion to disable animation entirely
     for users who have opted into reduced motion at the OS level. -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 1s linear infinite;
  }

  @media (prefers-reduced-motion: reduce) {
    .flash-banner {
      animation: none;
      background-color: #1a1a8c;
      color: #ffffff;
    }
  }
</style>

Video incorporato in autoplay con sequenze di lampeggio — Non corretto

<!-- Auto-playing video with no controls, no PEAT analysis performed,
     and no mechanism for the user to stop or pause before exposure -->
<video src='promo.mp4' autoplay loop muted width='800' height='450'></video>

Video incorporato in autoplay con sequenze di lampeggio — Corretto

<!-- Best practice: provide controls so users can pause immediately,
     add a poster frame so no video plays without interaction,
     or use preload='none' to prevent auto-loading. If autoplay is
     genuinely required by business logic, the video MUST have been
     screened with PEAT or HFPA and confirmed free of flash hazards. -->
<video
  src='promo-screened.mp4'
  controls
  muted
  preload='metadata'
  poster='promo-poster.jpg'
  width='800'
  height='450'>
  <track kind='captions' src='promo-captions.vtt' srclang='tr' label='Türkçe'>
</video>
<p>Bu video flaş analizi aracıyla (PEAT) incelenmiş ve güvenli bulunmuştur.</p>

Errori Comuni

• Dare per scontato che i file GIF siano sicuri per impostazione predefinita: Molti sviluppatori credono che, poiché le GIF animate sono un formato legacy, siano intrinsecamente innocue. In realtà, le GIF possono alternare i fotogrammi a frequenze che superano i 3 Hz e il formato non impone alcun limite tecnico al frame rate. Ogni GIF con fotogrammi alternati ad alto contrasto deve essere temporizzata e valutata.
• Trascurare gli script pubblicitari di terze parti: Le reti di advertising display servono spesso creatività che contengono animazioni lampeggianti o sfarfallanti. I publisher che incorporano tag pubblicitari senza rivedere i contenuti creativi sono comunque responsabili di qualsiasi violazione di WCAG 2.3.1 che tali annunci producono sulle loro pagine. Implementare politiche di revisione delle creatività pubblicitarie e requisiti contrattuali con le reti pubblicitarie.
• Confondere WCAG 2.3.1 con WCAG 2.2.2 (Pausa, Stop, Nascondi): Alcuni team affrontano il sintomo aggiungendo un pulsante di pausa (che soddisfa 2.2.2) ma non affrontano la frequenza di lampeggio sottostante (che viola 2.3.1). I due criteri sono indipendenti: un controllo di pausa non rende retroattivamente conforme, rispetto a 2.3.1, un contenuto che ha già iniziato a lampeggiare, perché l’utente è esposto prima di poter interagire.
• Non considerare separatamente la soglia di lampeggio rosso: Gli sviluppatori che conoscono la soglia generale di 3 Hz talvolta trascurano la soglia separata per il lampeggio rosso. I contenuti che coinvolgono valori di rosso saturo che si alternano rapidamente possono scatenare crisi fotosensibili anche a frequenze leggermente inferiori a 3 Hz in alcune persone. Le animazioni con rosso saturo dovrebbero essere esaminate con particolare attenzione.
• Ignorare i contenuti caricati in iframe: Le pagine che incorporano contenuti di terze parti tramite elementi <iframe> — inclusi widget di social media, strumenti di live chat o dashboard incorporati — sono responsabili dell’accessibilità di tali contenuti così come vengono renderizzati sulla loro pagina. I pericoli di lampeggio all’interno di un iframe sono tanto pericolosi quanto quelli nel documento principale.
• Saltare l’implementazione della media query prefers-reduced-motion: Anche quando le animazioni di base sono al di sotto della soglia di 3 Hz, non implementare @media (prefers-reduced-motion: reduce) significa che gli utenti che hanno indicato a livello di sistema operativo una preferenza per una riduzione del movimento non ricevono alcuna accomodazione. Sebbene questo sia affrontato principalmente da WCAG 2.3.3 a livello AAA, includere la media query è una pratica a basso costo e ad alto impatto che dimostra impegno per l’accessibilità e riduce il rischio.
• Usare JavaScript setInterval o requestAnimationFrame senza limitare la frequenza: Le animazioni gestite da setInterval(fn, 50) vengono eseguite ogni 50 millisecondi, producendo 20 cicli al secondo — ben oltre il limite di 3 Hz. Gli sviluppatori devono calcolare esplicitamente la durata dell’intervallo necessaria per rimanere a una modifica ogni 333 ms o meno per qualsiasi animazione che alteri la luminanza.
• Non sottoporre a screening i contenuti video prima della pubblicazione: Molte organizzazioni hanno un flusso di pubblicazione che include QA visivo e revisione del copyright ma non una fase di controllo dei pericoli di lampeggio. Senza integrare PEAT o HFPA nella pipeline di pre-pubblicazione, i pericoli legati alla fotosensibilità nei contenuti video possono passare inosservati fino a quando non causano danni.
• Considerare l’eccezione di dimensione come facile da sfruttare: Alcuni sviluppatori vengono a conoscenza dell’eccezione di area sicura di 0,006 steradianti e tentano di usarla per giustificare il mantenimento di effetti di lampeggio pericolosi riducendone le dimensioni. In pratica, calcolare con precisione se un contenuto rientra nella soglia richiede la conoscenza della distanza di visualizzazione dell’utente e della risoluzione del display — variabili che lo sviluppatore non può controllare. Fare affidamento sull’eccezione di dimensione senza misurazioni fotometriche è rischioso e giuridicamente precario.
• Non documentare le valutazioni dei pericoli di lampeggio: Le organizzazioni che testano video o contenuti animati per i pericoli di lampeggio spesso non conservano i registri di tali valutazioni. In caso di reclamo da parte di un utente o di audit regolatorio, prove documentate che lo screening con PEAT o HFPA è stato effettuato e che il contenuto è stato ritenuto conforme sono essenziali per dimostrare la dovuta diligenza.

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 e mobile allineati a WCAG 2.2. WCAG 2.3.1, in quanto criterio di successo di livello A, rientra nell’ambito della conformità obbligatoria per tutte le entità interessate.

La circolare definisce una tempistica di conformità graduale: le istituzioni e agenzie pubbliche devono raggiungere la piena conformità di livello A entro un anno dalla data di entrata in vigore della circolare, mentre le entità del settore privato coperte dal regolamento hanno due anni per conformarsi. Data la natura critica per la sicurezza di WCAG 2.3.1 — che è direttamente correlata al rischio di scatenare emergenze mediche negli utenti — la non conformità a questo particolare criterio comporta un’esposizione reputazionale e legale maggiore, anche rispetto ad altri requisiti di livello A.

I seguenti tipi di entità sono esplicitamente coperti dalla Circolare Presidenziale 2025/10 e devono quindi conformarsi a WCAG 2.3.1:

• Istituzioni pubbliche e agenzie governative: Tutti gli organi di governo centrali e locali, ministeri, municipalità e organizzazioni affiliate allo Stato che gestiscono siti web o applicazioni mobili rivolti al pubblico.
• Piattaforme di e-commerce: Operatori di vendita al dettaglio online e marketplace che forniscono beni o servizi ai consumatori tramite piattaforme digitali, indipendentemente dal settore.
• Banche e istituzioni finanziarie: Tutte le banche autorizzate, banche partecipative, società di investimento e operatori fintech che forniscono servizi bancari o finanziari digitali.
• Ospedali e fornitori di servizi sanitari: Ospedali pubblici e privati, policlinici e reti sanitarie che offrono servizi digitali rivolti ai pazienti, inclusa la prenotazione di appuntamenti e i portali paziente.
• Società di telecomunicazioni con 200.000 o più abbonati: I principali operatori di rete mobile e fornitori di servizi Internet che soddisfano la soglia di abbonati, inclusi i loro portali self-service e le applicazioni mobili.
• Agenzie di viaggio: Agenzie di viaggio e turismo autorizzate che offrono servizi di prenotazione, riservazione o informazione online.
• Società di trasporto private: Compagnie aeree, operatori di autobus interurbani, operatori di traghetti e altri fornitori di trasporto privato con piattaforme digitali rivolte ai consumatori.
• Scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE): Istituzioni educative private con autorizzazione MoNE che gestiscono siti web o piattaforme di apprendimento digitale.

Per le entità coperte, la conformità a WCAG 2.3.1 richiede non solo un audit una tantum ma un impegno operativo continuo. Poiché i pericoli di lampeggio vengono introdotti più comunemente tramite contenuti dinamici — caricamenti video, animazioni di marketing, pubblicità di terze parti — le organizzazioni devono integrare il controllo dei pericoli di lampeggio nei loro flussi di lavoro di pubblicazione dei contenuti, non solo nell’audit iniziale del sito. L’uso di strumenti come PEAT per lo screening dei video prima della pubblicazione, combinato con la formazione degli sviluppatori sui limiti di frequenza sicura delle animazioni e sull’implementazione CSS di prefers-reduced-motion, rappresenta lo standard minimo di diligenza operativa atteso dalle entità coperte dalla circolare. Le organizzazioni che si affidano a sistemi di gestione dei contenuti o di advertising di terze parti devono inoltre garantire disposizioni contrattuali che richiedano la conformità a WCAG 2.3.1 da parte dei loro fornitori, poiché l’obbligo normativo ricade sull’entità che gestisce il servizio digitale rivolto al pubblico.