WCAG 2.3.1 : Trois flashs ou en dessous du seuil

Ce que signifie cette règle

WCAG 2.3.1 — Trois flashs ou en dessous du seuil — est un critère de succès de niveau A relevant du principe « Utilisable ». Il impose que les pages web ne contiennent aucun contenu qui clignote plus de trois fois au cours d’une période d’une seconde, sauf si ce contenu clignotant est suffisamment petit ou suffisamment peu lumineux pour être en dessous du seuil général de flash ou du seuil de flash rouge définis.

Un flash est défini comme une paire de changements opposés de luminance relative pouvant provoquer des crises chez les personnes sensibles. Plus précisément, les WCAG définissent deux types de flashs dangereux :

• Flash général : Une paire de changements opposés où la luminance la plus élevée est au moins de 10 % de la luminance relative maximale (0,80), et où la différence de luminance est d’au moins 10 % de la valeur maximale. En pratique, cela signifie un contenu qui alterne rapidement entre un état lumineux et un état sombre, suffisamment vite pour produire un effet stroboscopique.
• Flash rouge : Une paire de transitions opposées impliquant une couleur rouge saturée. Ce cas est traité avec une attention particulière, car les flashs rouges sont cliniquement associés à un risque plus élevé de déclencher des crises photosensibles.

Ce critère s’applique à tout contenu web, quel que soit son format — animations HTML, transitions CSS, effets pilotés par JavaScript, vidéos intégrées, GIF, animations SVG, scènes WebGL, graphiques rendus sur canvas et widgets publicitaires tiers. Si un contenu clignote à une fréquence dépassant trois flashs par seconde et ne se situe pas en dessous des seuils de luminance ou de taille, il échoue à ce critère sans exception.

Exceptions et seuils permettant au contenu d’être conforme : WCAG 2.3.1 autorise le contenu clignotant s’il répond à l’une des conditions suivantes :

• La zone combinée des flashs se produisant simultanément ne couvre pas plus de 0,006 stéradian au total dans tout champ visuel de 10 degrés à l’écran (soit approximativement un rectangle de 341 × 256 pixels à des distances de visionnage typiques, ou environ 21 824 pixels carrés sur un écran de 1024 pixels de large vu à bout de bras).
• Le flash est en dessous du seuil de flash général (variation de luminance inférieure à 10 %) ou en dessous du seuil de flash rouge (la composante rouge saturée ne varie pas au-delà du seuil défini).

Un événement comportant un seul flash avec un contraste de luminance très faible ou une zone d’écran très petite peut donc être acceptable. Cependant, comme ces seuils sont nuancés et nécessitent des outils de mesure photométrique pour être vérifiés précisément, la plupart des praticiens adoptent une approche prudente consistant simplement à éviter tout contenu qui clignote plus de trois fois par seconde. Un contenu qui clignote exactement trois fois par seconde (3 Hz) se situe à la limite — un contenu dépassant 3 Hz n’est pas conforme, quelle que soit sa taille, à moins que les seuils de taille ou de luminance ne soient clairement respectés.

Ce critère régit tout contenu rendu lors d’une interaction normale avec la page. Il n’exempte pas le contenu caché derrière des contrôles déclenchés par l’utilisateur si ce contenu se lance automatiquement au chargement de la page. Si une vidéo commence à se lire automatiquement et contient des séquences clignotantes dépassant le seuil, la page échoue à ce critère dès son chargement.

Pourquoi c’est important

L’épilepsie photosensible touche environ 1 personne sur 4 000 dans le monde — soit environ 3 % de l’ensemble de la population épileptique. Cependant, la sensibilité à la lumière clignotante ou vacillante rapidement dépasse le cadre de l’épilepsie clinique. De nombreuses personnes souffrant de migraines, de troubles vestibulaires, de troubles du spectre autistique ou de syndrome post-commotionnel peuvent ressentir un inconfort important, une désorientation, des nausées ou des douleurs face à des stimuli visuels clignotants rapides, même sans diagnostic de trouble convulsif.

Les enjeux sont particulièrement élevés pour ce critère par rapport à la plupart des autres exigences d’accessibilité. Un utilisateur confronté à l’absence de texte alternatif subit une exclusion et de la frustration. Un utilisateur confronté à un contenu déclenchant une crise photosensible peut vivre une urgence médicale — incluant une perte de conscience, des blessures dues à une chute et, dans de rares cas documentés, des conséquences potentiellement mortelles. Le Harding Flash and Pattern Analyzer, un outil de diffusion largement utilisé, a été développé précisément pour prévenir de tels événements à la télévision, et le web présente des risques analogues.

Un scénario concret illustre bien le danger : imaginez un site d’actualités qui lance automatiquement une vidéo promotionnelle contenant une séquence rapide d’images alternant clair et sombre — un artefact courant de certains types de compression vidéo ou d’effets de flash d’appareil photo. Une personne atteinte d’épilepsie photosensible visite la page d’accueil pendant son trajet matinal sur un appareil mobile. Sans avertissement et sans possibilité de désactiver le contenu, elle est exposée à une séquence qui déclenche une crise alors qu’elle se trouve dans les transports en commun. Ce scénario n’est pas hypothétique ; il s’est produit dans des contextes réels, notamment lors du célèbre incident de l’épisode Pokémon de 2007 qui a déclenché des crises chez des centaines de téléspectateurs au Japon, ainsi que dans des cas documentés impliquant des unités publicitaires basées sur le web.

Au-delà de la dimension de sécurité, le respect de ce critère a également des implications en matière d’ergonomie pour le grand public. Un contenu clignotant rapidement crée une mauvaise expérience de lecture, augmente la charge cognitive et est considéré comme perturbateur et non professionnel dans la plupart des contextes de design. Éliminer ce type de contenu améliore la concentration, réduit les taux de rebond et renforce la confiance — autant de facteurs qui contribuent positivement à des indicateurs SEO tels que le temps passé sur la page et les taux d’engagement. De plus, les robots d’indexation des moteurs de recherche prennent de plus en plus en compte les Core Web Vitals et les signaux d’expérience utilisateur dans leurs classements, et les sites comportant des publicités ou animations clignotantes intrusives peuvent être pénalisés indirectement.

Règles axe-core associées

WCAG 2.3.1 nécessite des tests manuels, car les outils automatisés ne peuvent pas analyser de manière fiable les propriétés photométriques d’un contenu dynamique en temps réel. Aucune règle automatisée axe-core ne correspond directement à ce critère. Les raisons de cette limitation tiennent à la manière dont fonctionne l’automatisation en accessibilité :

• Pourquoi l’automatisation échoue ici : Les analyseurs automatisés examinent le DOM et le CSS statiques à un instant donné. Ils peuvent détecter l’existence d’une animation ou d’un élément vidéo, mais ils ne peuvent pas mesurer la fréquence réelle des flashs, les valeurs de luminance à chaque image, ni la zone spatiale de la région clignotante telle qu’elle est perçue par un utilisateur à une distance de visionnage typique. Déterminer si un flash dépasse le seuil de 3 Hz ou le seuil de 0,006 stéradian nécessite une analyse photométrique image par image — une tâche qui requiert des outils dédiés tels que le Harding Flash and Pattern Analyzer (HFPA), le Photosensitive Epilepsy Analysis Tool (PEAT) ou un examen manuel des fichiers source d’animation.
• Vidéos intégrées et contenu tiers : Une grande partie du contenu le plus risqué (publicités vidéo en lecture automatique, widgets de réseaux sociaux intégrés, bibliothèques d’animation tierces) est chargée depuis des domaines externes. Les outils automatisés ne peuvent généralement pas accéder au contenu cross-origin ni l’analyser image par image, ce qui rend impossible l’évaluation programmée de la fréquence des flashs dans ces ressources.
• Animations GIF et canvas : Les fichiers GIF animés et les éléments canvas HTML5 rendent leurs images d’animation en dehors de l’arbre d’accessibilité normal. Axe-core et Lighthouse n’ont pas la capacité de décoder le minutage des images GIF ni d’intercepter les appels de dessin canvas pour calculer les variations de luminance entre les images.
• Animations CSS et JavaScript : Bien qu’axe-core puisse détecter la présence de propriétés CSS animation ou transition, il ne peut pas évaluer si le rendu visuel à l’exécution produit des variations de luminance dépassant les seuils de flash général ou de flash rouge.

Comme aucune règle automatisée ne détecte cette violation, l’ensemble de la responsabilité de conformité repose sur la revue manuelle du design, l’analyse vidéo avant publication et la sensibilisation des développeurs lors de la phase de création de contenu. Cela rend les processus éditoriaux et de QA — et pas seulement la remédiation technique — essentiels pour une conformité durable.

Comment tester

1. Recenser tout le contenu dynamique : Avant tout test basé sur des outils, auditez la page pour repérer tout contenu qui se déplace, clignote, clignote rapidement ou s’anime. Cela inclut les vidéos en lecture automatique, les GIF animés, les animations CSS keyframe, les animations pilotées par JavaScript, les animations SVG, les éléments canvas et les widgets tiers intégrés tels que les unités publicitaires ou les intégrations de réseaux sociaux. Documentez chaque instance avec sa source et son mécanisme de contrôle.
2. Utiliser le Photosensitive Epilepsy Analysis Tool (PEAT) : PEAT est un outil gratuit développé par le Trace Research and Development Center, conçu spécifiquement pour analyser les contenus vidéo à la recherche de risques de flash selon la spécification Harding. Enregistrez une capture d’écran de la page web ou de l’animation concernée en pleine résolution, puis importez le fichier vidéo dans PEAT. L’outil indiquera si une séquence dépasse le seuil de flash général ou le seuil de flash rouge, et à quels instants.
3. Utiliser le Harding Flash and Pattern Analyzer pour les contenus de qualité broadcast : Pour les contenus vidéo qui seront intégrés à partir de flux de production (par exemple, sites de diffuseurs, organisations de presse), faites passer les fichiers vidéo source dans le HFPA avant publication. Il s’agit de l’outil de référence pour le contrôle avant diffusion.
4. Observation manuelle — le comptage des trois flashs : Pour les animations CSS, les effets JavaScript ou les fichiers GIF pour lesquels une analyse par outil est peu pratique, lisez l’animation et essayez de compter le nombre de cycles complets clair-sombre-clair en une seconde. Si vous observez trois cycles complets ou plus par seconde, le contenu est probablement non conforme. Utilisez un logiciel d’enregistrement d’écran avec lecture image par image pour faciliter ce comptage.
5. Vérifier le contenu vidéo image par image : Ouvrez les fichiers vidéo dans un éditeur vidéo (tel que DaVinci Resolve, version gratuite) qui affiche des données de forme d’onde ou d’histogramme au niveau de l’image. Parcourez les sections à changements visuels rapides et recherchez des motifs alternant luminance élevée et faible se produisant plus de trois fois par seconde. Portez une attention particulière aux séquences impliquant du rouge saturé sur des arrière-plans sombres.
6. Tester avec les outils de développement du navigateur pour les animations CSS : Dans Chrome DevTools, ouvrez le panneau Animations (More Tools → Animations). Inspectez les durées d’animation déclarées et les cycles d’itération. Une animation d’une durée inférieure à 333 millisecondes qui alterne entre des états à fort contraste à chaque itération dépassera le seuil de 3 Hz. Calculez : si un cycle complet clair-sombre-clair se termine en moins de 333 ms, le contenu n’est pas conforme.
7. Évaluer la zone spatiale pour les cas limites : Si un contenu clignote à une fréquence supérieure à 3 Hz mais semble très petit à l’écran, mesurez ses dimensions en pixels. Sur un écran de 1024 pixels de large à une distance de visionnage normale (environ 57–60 cm), le seuil de zone sûre est d’environ 21 824 pixels carrés. Multipliez la largeur et la hauteur de la zone clignotante ; si le résultat est inférieur à ce seuil, le contenu peut relever de l’exception de zone sûre — mais documentez soigneusement cette évaluation.
8. Tester les vidéos en lecture automatique au chargement de la page : Désactivez toute interaction avec la page après son chargement et observez si une vidéo ou une animation commence à se lire automatiquement. Si c’est le cas, appliquez immédiatement les tests ci-dessus au contenu en lecture automatique, car l’utilisateur n’a aucune possibilité d’intervenir avant l’exposition.

Comment corriger

GIF en lecture automatique avec flash rapide — Incorrect

<!-- 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 en lecture automatique avec flash rapide — Correct

<!-- 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>

Animation CSS keyframe clignotant entre des couleurs à fort contraste — Incorrect

<!-- 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>

Animation CSS keyframe clignotant entre des couleurs à fort contraste — Correct

<!-- 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>

Vidéo intégrée en lecture automatique avec séquences de flash — Incorrect

<!-- 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>

Vidéo intégrée en lecture automatique avec séquences de flash — Correct

<!-- 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>

Erreurs courantes

• Supposer que les fichiers GIF sont sûrs par défaut : De nombreux développeurs pensent que, parce que les GIF animés sont un format ancien, ils sont intrinsèquement inoffensifs. En réalité, les GIF peuvent alterner entre des images à des fréquences dépassant 3 Hz, et le format n’impose aucune limite technique au taux d’images. Chaque GIF comportant des images à fort contraste alterné doit être minuté et évalué.
• Ignorer les scripts publicitaires tiers : Les réseaux de publicité display diffusent fréquemment des créations contenant des animations clignotantes. Les éditeurs qui intègrent des tags publicitaires sans examiner le contenu créatif restent responsables de toute violation de WCAG 2.3.1 que ces publicités produisent sur leurs pages. Mettez en place des politiques de revue des créations publicitaires et des exigences contractuelles avec les réseaux publicitaires.
• Confondre WCAG 2.3.1 avec WCAG 2.2.2 (Mettre en pause, Arrêter, Masquer) : Certaines équipes traitent le symptôme en ajoutant un bouton de pause (ce qui satisfait 2.2.2) mais ne s’attaquent pas au taux de flash sous-jacent (qui viole 2.3.1). Les deux critères sont indépendants : un contrôle de pause ne rend pas rétroactivement conforme un contenu qui a déjà commencé à clignoter, car l’utilisateur est exposé avant de pouvoir interagir.
• Ne pas prendre en compte séparément le seuil de flash rouge : Les développeurs qui connaissent le seuil général de 3 Hz négligent parfois le seuil distinct de flash rouge. Un contenu impliquant des alternances rapides de rouge saturé peut déclencher des crises photosensibles même à des fréquences légèrement inférieures à 3 Hz chez certaines personnes. Les animations en rouge saturé doivent être examinées avec une attention particulière.
• Ignorer le contenu chargé dans des iframes : Les pages qui intègrent du contenu tiers via des éléments <iframe> — y compris des widgets de réseaux sociaux, des outils de chat en direct ou des tableaux de bord intégrés — sont responsables de l’accessibilité de ce contenu tel qu’il est rendu sur leur page. Les risques de flash dans une iframe sont tout aussi dangereux que ceux du document principal.
• Omettre d’implémenter la media query prefers-reduced-motion : Même lorsque les animations de base sont en dessous du seuil de 3 Hz, ne pas implémenter @media (prefers-reduced-motion: reduce) signifie que les utilisateurs ayant indiqué une préférence de réduction des mouvements au niveau du système d’exploitation ne bénéficient d’aucune adaptation. Bien que cela soit principalement couvert par WCAG 2.3.3 au niveau AAA, inclure cette media query est une pratique peu coûteuse et à fort impact qui démontre un engagement en matière d’accessibilité et réduit les risques.
• Utiliser JavaScript setInterval ou requestAnimationFrame sans limitation de fréquence : Les animations pilotées par setInterval(fn, 50) se déclenchent toutes les 50 millisecondes, produisant 20 cycles par seconde — bien au-delà de la limite de 3 Hz. Les développeurs doivent calculer explicitement la durée d’intervalle nécessaire pour rester à un changement au plus toutes les 333 ms pour toute animation modifiant la luminance.
• Ne pas filtrer les contenus vidéo avant publication : De nombreuses organisations disposent d’un flux de publication incluant une QA visuelle et une vérification des droits d’auteur, mais sans étape de détection des risques de flash. Sans intégrer PEAT ou HFPA dans le pipeline de prépublication, les risques de photosensibilité dans les contenus vidéo peuvent passer inaperçus jusqu’à ce qu’ils causent un dommage.
• Considérer l’exception de taille comme facile à exploiter : Certains développeurs découvrent l’exception de zone sûre de 0,006 stéradian et tentent de l’utiliser pour justifier le maintien d’effets de flash dangereux en les rendant petits. En pratique, calculer avec précision si un contenu se situe en dessous du seuil nécessite de connaître la distance de visionnage de l’utilisateur et la résolution de l’écran — des variables que le développeur ne contrôle pas. S’appuyer sur l’exception de taille sans mesure photométrique est risqué et juridiquement précaire.
• Ne pas documenter les évaluations des risques de flash : Les organisations qui testent les contenus vidéo ou d’animation pour les risques de flash omettent souvent de conserver les traces de ces évaluations. En cas de plainte d’utilisateur ou d’audit réglementaire, des preuves documentées montrant que des contrôles PEAT ou HFPA ont été effectués et que le contenu a été jugé conforme sont essentielles pour démontrer la diligence raisonnable.

Lien avec la réglementation d’accessibilité de la Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires d’accessibilité web et mobile alignées sur WCAG 2.2. WCAG 2.3.1, en tant que critère de succès de niveau A, relève du champ de la conformité obligatoire pour toutes les entités concernées.

La circulaire définit un calendrier de conformité progressif : les institutions et organismes publics doivent atteindre une conformité complète de niveau A dans l’année suivant la date d’entrée en vigueur de la circulaire, tandis que les entités du secteur privé couvertes par la réglementation disposent de deux ans pour se mettre en conformité. Étant donné la nature critique de sécurité de WCAG 2.3.1 — qui est directement liée au risque de déclencher des urgences médicales chez les utilisateurs — le non-respect de ce critère particulier entraîne un risque accru en termes de réputation et de responsabilité juridique, même par rapport à d’autres exigences de niveau A.

Les types d’entités suivants sont explicitement couverts par la circulaire présidentielle 2025/10 et doivent donc se conformer à WCAG 2.3.1 :

• Institutions publiques et organismes gouvernementaux : Tous les organismes gouvernementaux centraux et locaux, ministères, municipalités et organisations affiliées à l’État exploitant des sites web ou des applications mobiles destinés au public.
• Plateformes de commerce électronique : Opérateurs de vente en ligne et de places de marché fournissant des biens ou des services aux consommateurs via des plateformes numériques, quel que soit le secteur.
• Banques et institutions financières : Toutes les banques agréées, banques participatives, sociétés d’investissement et opérateurs fintech fournissant des services bancaires ou financiers numériques.
• Hôpitaux et prestataires de soins de santé : Hôpitaux publics et privés, polycliniques et réseaux de soins offrant des services numériques destinés aux patients, y compris la prise de rendez-vous et les portails patients.
• Entreprises de télécommunications comptant 200 000 abonnés ou plus : Principaux opérateurs de réseaux mobiles et fournisseurs d’accès à Internet atteignant ce seuil d’abonnés, y compris leurs portails en libre-service et leurs applications mobiles.
• Agences de voyage : Agences de voyage et de tourisme agréées proposant des services de réservation, de réservation en ligne ou d’information.
• Entreprises de transport privé : Compagnies aériennes, opérateurs de bus interurbains, compagnies de ferry et autres prestataires de transport privé disposant de plateformes numériques destinées aux consommateurs.
• Écoles privées autorisées par le ministère de l’Éducation nationale (MoNE) : Établissements d’enseignement privés disposant de l’autorisation du MoNE et exploitant des sites web ou des plateformes d’apprentissage numérique.

Pour les entités couvertes, la conformité à WCAG 2.3.1 nécessite non seulement un audit ponctuel, mais aussi un engagement opérationnel continu. Comme les risques de flash sont le plus souvent introduits par du contenu dynamique — mises en ligne de vidéos, animations marketing, publicités tierces — les organisations doivent intégrer le contrôle des risques de flash dans leurs flux de publication de contenu, et pas seulement dans leur audit initial de site. L’utilisation d’outils tels que PEAT pour le contrôle des vidéos avant publication, combinée à la formation des développeurs sur les limites de fréquence d’animation sûres et sur l’implémentation CSS de prefers-reduced-motion, représente le niveau minimal de diligence opérationnelle attendu des entités couvertes par la circulaire. Les organisations qui s’appuient sur des systèmes de gestion de contenu ou des systèmes publicitaires tiers doivent également prévoir des clauses contractuelles exigeant la conformité à WCAG 2.3.1 de la part de leurs fournisseurs, car l’obligation réglementaire incombe à l’entité qui exploite le service numérique destiné au public.