WCAG 2.3.2 : Trois clignotements

Ce que signifie cette règle

WCAG 2.3.2 Trois flashs est un critère de succès de niveau AAA relevant du principe « Utilisable ». Il stipule que les pages web ne doivent contenir aucun élément qui clignote plus de trois fois au cours d’une période d’une seconde. Contrairement à son équivalent de niveau AA (2.3.1 Trois flashs ou en dessous du seuil), ce critère ne prévoit aucune exception pour les petites zones clignotantes ou les flashs qui restent en dessous des seuils généraux de flash et de flash rouge. La règle est absolue : si un contenu clignote plus de trois fois par seconde, il échoue, quelle que soit sa taille, sa couleur ou son contraste.

Un flash est défini par les WCAG comme une paire de changements opposés de luminance relative pouvant provoquer des crises chez certaines personnes. Plus concrètement, tout clignotement visible de type marche/arrêt, animation de type stroboscopique, succession rapide d’images ou vidéo scintillante qui effectue plus de trois cycles complets par seconde entre dans le champ d’application de cette règle. L’expression « trois flashs » renvoie à trois oscillations complètes — ce qui signifie un contenu qui alterne entre un état plus clair et un état plus sombre trois fois en une seule seconde.

Les types de contenu concernés sont vastes et incluent les GIF animés, les animations CSS utilisant @keyframes, les mises à jour du DOM pilotées par JavaScript qui provoquent des basculements visuels rapides, les animations HTML5 Canvas, le contenu vidéo intégré, les animations SVG, ainsi que les réseaux publicitaires ou widgets tiers qui intègrent des médias animés. Même un scintillement subtil dans un texte défilant de type « marquee » ou dans des visualisations de données se mettant à jour rapidement peut déclencher ce critère si la fréquence dépasse trois flashs par seconde.

Un succès au titre de 2.3.2 signifie que la page ne contient aucun contenu clignotant dépassant le seuil de trois flashs par seconde. Un échec se produit dès qu’une partie quelconque de la page — quelle que soit la petitesse de la zone — clignote plus de trois fois au cours d’une fenêtre d’une seconde. Il n’existe aucune exception de « zone sûre » dans ce critère, ce qui le distingue de 2.3.1. Un minuscule curseur clignotant, un indicateur de chargement animé ou une bannière publicitaire qui défile rapidement peuvent tous constituer des échecs s’ils clignotent à des fréquences supérieures à 3 Hz.

Pourquoi c’est important

L’épilepsie photosensible touche environ 1 personne sur 4 000 dans le monde, mais la population totale susceptible de présenter une forme de réaction neurologique photosensible — y compris les migraines photosensibles, les troubles vestibulaires et la photosensibilité non épileptique — est nettement plus importante. Pour ces personnes, l’exposition à un contenu qui clignote rapidement à l’écran n’est pas un simple désagrément : elle peut déclencher des crises tonico-cloniques généralisées, une perte de conscience, des blessures ou, dans de rares cas, la mort. Contrairement à de nombreux obstacles d’accessibilité qui dégradent l’expérience utilisateur, le contenu clignotant représente un danger de sécurité aigu.

Considérons un scénario pratique : un site d’actualités turc intègre un bandeau d’actualités en direct avec un effet de surbrillance animé qui pulse à 8 Hz pour attirer l’attention sur les dernières nouvelles. Une personne atteinte d’épilepsie photosensible ouvre la page sur son téléphone pendant un trajet. En quelques secondes, le scintillement rapide déclenche une crise focale, amenant la personne à laisser tomber son téléphone et à perdre momentanément le contrôle musculaire. Elle n’avait aucun avertissement, aucun moyen de désactiver l’effet à l’avance et aucun recours. Ce scénario est entièrement évitable en limitant la fréquence des flashs à trois par seconde ou moins — ou en éliminant complètement le contenu clignotant, comme l’exige 2.3.2.

Au-delà de la dimension de sécurité neurologique, le respect de ce critère bénéficie également aux personnes souffrant de troubles vestibulaires (qui ressentent des vertiges, des nausées ou une désorientation liés au mouvement), aux personnes sujettes aux migraines déclenchées par des motifs visuels, et aux personnes ayant des troubles de l’attention qui trouvent le contenu clignotant rapide impossible à ignorer ou à contourner. Réduire ou éliminer le contenu clignotant tend également à améliorer la perception de professionnalisme de la page et à réduire les taux d’abandon, car de nombreux utilisateurs — en situation de handicap ou non — trouvent les animations agressives irritantes.

Du point de vue du référencement et des performances, l’élimination des animations lourdes et des transitions CSS rapides réduit la charge CPU et GPU, améliorant les indicateurs Core Web Vitals tels que le temps de blocage total (Total Blocking Time) et le décalage cumulatif de mise en page (Cumulative Layout Shift), qui sont tous deux des signaux de classement pour Google.

Règles Axe-core associées

WCAG 2.3.2 nécessite des tests manuels. Aucune règle axe-core automatisée ne correspond directement à ce critère, et c’est intentionnel — voici pourquoi les outils automatisés ne peuvent pas détecter de manière fiable les violations :

• Tests manuels requis — Détection de la fréquence des flashs : Les analyseurs d’accessibilité automatisés inspectent le DOM et le CSS statiques à un instant donné. Ils ne peuvent pas observer le comportement du contenu sur une seconde entière de lecture d’animation, mesurer la fréquence d’oscillation de luminance d’une vidéo ou d’un GIF animé, ni évaluer la fréquence d’images d’une animation Canvas. La fréquence des flashs est une propriété temporelle qui nécessite une observation en temps réel, ce qui la rend fondamentalement hors de portée des outils d’analyse statique comme axe-core. Un testeur humain — ou des outils spécialisés d’analyse de photosensibilité tels que le Photosensitive Epilepsy Analysis Tool (PEAT) — doit examiner le contenu animé en mouvement pour déterminer s’il dépasse le seuil de trois flashs par seconde.
• Tests manuels requis — Contenu tiers et intégré : Les publicités, les vidéos intégrées, les widgets de réseaux sociaux et les iframes peuvent injecter du contenu animé qu’axe-core ne peut pas analyser, car il fonctionne dans les contraintes de la politique de même origine du navigateur. Un testeur doit observer manuellement tout le contenu intégré et tiers pendant la lecture pour évaluer la conformité.
• Tests manuels requis — Animations pilotées par JavaScript : Le basculement rapide de classes CSS, la mise à jour de pixels de canvas ou la manipulation d’éléments SVG via JavaScript à haute fréquence peuvent produire des effets de clignotement invisibles sur un instantané DOM statique. Les testeurs doivent exécuter la page dans un navigateur en conditions réelles, observer tous les états animés et chronométrer les cycles de flash manuellement ou à l’aide d’outils d’analyse de fréquence d’images.

Comment tester

1. Exécuter une analyse automatisée comme base : Utilisez axe DevTools, Lighthouse ou l’audit intégré du widget Accsible pour identifier les problèmes liés aux animations signalés. Bien qu’aucune règle ne corresponde directement à 2.3.2, ces outils peuvent faire remonter des avertissements liés aux animations CSS ou aux régions ARIA live qui se mettent à jour rapidement. Notez tous les éléments signalés, mais gardez à l’esprit qu’un rapport automatisé vierge ne confirme pas la conformité à 2.3.2.
2. Identifier manuellement tout le contenu animé : Chargez la page dans un navigateur et observez-la pendant au moins 30 secondes sans interagir. Notez chaque élément qui clignote, flash, s’anime ou change d’état visuel de manière répétée. Incluez les indicateurs de chargement, bannières, animations de héros, vidéos en lecture automatique, arrière-plans animés et tout widget tiers. Créez un inventaire de ces éléments.
3. Utiliser le Photosensitive Epilepsy Analysis Tool (PEAT) : Pour le contenu vidéo ou les enregistrements d’écran d’animations, utilisez PEAT (un outil gratuit du Trace Research and Development Center) pour analyser les séquences image par image. PEAT signalera toute séquence dépassant les seuils de flash et indiquera à la fois le seuil de flash général et le seuil de flash rouge. Un échec 2.3.2 correspond à tout flash dépassant trois par seconde, quels que soient les autres seuils.
4. Mesurer les fréquences des animations CSS et JavaScript : Ouvrez les DevTools du navigateur (Chrome ou Firefox) et utilisez l’onglet Performance pour enregistrer une session de 5 secondes pendant la lecture des animations. Inspectez le « flame graph » pour repérer les opérations de rendu ou de mise en page qui se répètent rapidement. Vous pouvez également ouvrir le panneau Animations dans Chrome DevTools pour voir les animations en cours et leurs durées — divisez 1000 ms par la durée de l’animation pour calculer la fréquence en Hz.
5. Tester avec NVDA + Firefox, VoiceOver + Safari et JAWS + Chrome : Les utilisateurs de lecteurs d’écran ne sont pas exemptés de photosensibilité. Lancez chaque lecteur d’écran et naviguez normalement sur la page. Si un contenu qui clignote visuellement est également présenté d’une manière qui provoque des rafraîchissements rapides de l’écran (par exemple une région live annonçant chaque image d’un compteur), documentez-le. Le clignotement visuel reste une violation même pour les utilisateurs de lecteurs d’écran, car ils peuvent disposer d’une vision fonctionnelle.
6. Vérifier le contenu tiers et intégré : Faites défiler tous les iframes, publications de réseaux sociaux intégrées, emplacements publicitaires et lecteurs vidéo. Lancez manuellement toute vidéo dont la lecture automatique est désactivée et observez la présence de scintillements rapides. Vérifiez les GIF animés en cliquant avec le bouton droit et en inspectant les données de trame dans un éditeur d’images ou dans l’onglet Réseau du navigateur pour estimer la fréquence d’images.
7. Répéter les tests sur différents appareils et navigateurs : Certaines animations s’exécutent à des vitesses différentes sur mobile et sur ordinateur de bureau en raison des différences d’accélération matérielle. Testez à la fois sur un navigateur de bureau et sur un appareil mobile (Safari iOS et Chrome Android) pour confirmer une conformité cohérente.

Comment corriger

Animation CSS keyframes clignotant trop vite — Incorrect

<!-- Un badge qui clignote pour attirer l’attention, effectuant 8 cycles par seconde -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — dépasse largement 3 par seconde */
  }
</style>
<span class='alert-badge'>NEW</span>

Animation CSS keyframes clignotant trop vite — Correct

<!-- Animation ralentie pour effectuer moins de 3 cycles par seconde -->
<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 — bien en dessous du seuil de 3 Hz */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Mieux encore : supprimer complètement l’animation et utiliser un badge statique à fort contraste -->

Basculement DOM JavaScript provoquant un scintillement rapide — Incorrect

<!-- Le script bascule la visibilité 10 fois par seconde pour simuler un effet stroboscopique -->
<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); /* Se déclenche toutes les 100 ms = 10 flashs par seconde -- risque sérieux de crise */
</script>

Basculement DOM JavaScript provoquant un scintillement rapide — Correct

<!-- Suppression complète du basculement rapide ; transmettre le changement d’état via du texte ou une icône à la place -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- Si une animation est réellement nécessaire, maintenez-la bien en dessous de 3 Hz et privilégiez
     les transitions d’opacité/couleur plutôt que des changements de luminance à fort contraste -->

GIF animé avec fréquence d’images élevée — Incorrect

<!-- Une publicité GIF animée qui fait défiler les images à 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- Le délai interne entre les images du GIF est fixé à 10 ms par image, créant un scintillement rapide -->

GIF animé avec fréquence d’images élevée — Correct

<!-- Remplacez le GIF animé par une image statique, ou réexportez le GIF
     avec un délai minimal de 334 ms par image (3 fps ou moins) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- Si le mouvement doit être conservé, utilisez une animation CSS avec prise en charge de prefers-reduced-motion -->
<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>

Erreurs courantes

• Supposer que l’exception de « petite zone » de 2.3.1 s’applique à 2.3.2 : WCAG 2.3.1 autorise le contenu clignotant qui occupe moins de 25 % d’un champ visuel de 10 degrés. WCAG 2.3.2 ne comporte aucune exception de ce type — un minuscule curseur clignotant ou un petit point de chargement qui clignote plus de trois fois par seconde constitue une violation complète au niveau AAA.
• Définir animation-duration en CSS à des valeurs comme 0.1s ou 0.2s sans calculer la fréquence de flash résultante : Une animation de 0.1 s qui oscille entre deux états effectue 10 cycles par seconde (10 Hz). Divisez 1 par la durée en secondes pour obtenir la fréquence en Hz ; assurez-vous que le résultat est de 3 ou moins.
• Intégrer des scripts publicitaires tiers sans examiner le comportement des animations : Les réseaux publicitaires diffusent fréquemment des créations animées avec des fréquences de flash élevées, optimisées pour le taux de clics, pas pour l’accessibilité. Auditez toujours le contenu tiers à l’aide de PEAT ou d’une inspection manuelle des trames avant le déploiement.
• Utiliser des boucles setInterval ou requestAnimationFrame pour basculer rapidement des classes CSS pour des indicateurs de chargement ou de progression : Toute boucle JavaScript qui modifie la luminance ou la visibilité d’un élément plus de trois fois par seconde crée une violation de 2.3.2, même si l’effet semble subtil dans des conditions de visionnage normales.
• Ne pas tester les SVG animés et les éléments Canvas : Les animations SVG utilisant <animate> ou SMIL, ainsi que les jeux ou visualisations de données basés sur Canvas, sont rarement testés avec PEAT ou des outils de mesure de fréquence d’images, alors qu’ils sont parfaitement capables de dépasser le seuil de flash.
• Se fier uniquement à axe-core ou Lighthouse pour confirmer la conformité à 2.3.2 : Les outils automatisés ne peuvent pas détecter ce critère. Un résultat d’analyse automatisée sans erreur ne signifie rien pour 2.3.2 ; seuls un examen manuel et une analyse avec PEAT peuvent confirmer la conformité.
• Considérer prefers-reduced-motion comme une solution complète pour 2.3.2 : Respecter la media query prefers-reduced-motion est une bonne pratique et utile pour de nombreux utilisateurs, mais il s’agit d’un mécanisme d’activation par l’utilisateur. WCAG 2.3.2 exige que le contenu soit sûr par défaut, et pas seulement lorsque l’utilisateur a défini une préférence système. Les utilisateurs qui n’ont pas configuré ce paramètre restent exposés au risque.
• Appliquer des limites de fréquence de flash uniquement à la vidéo mais pas aux animations CSS, JavaScript ou GIF : Les équipes auditent parfois le contenu vidéo avec PEAT mais négligent les animations CSS keyframes et les basculements pilotés par JavaScript. Toutes les technologies d’animation doivent être évaluées.
• Utiliser des propriétés CSS background-image pour afficher des GIF animés : Les GIF animés définis comme images d’arrière-plan CSS sont moins visibles pour les testeurs lors d’un examen visuel et sont faciles à négliger pendant les audits. Incluez toujours les images d’arrière-plan dans votre inventaire d’animations.
• Ne pas refaire de tests après que des changements d’A/B testing ou de personnalisation ont injecté un nouveau contenu animé : Les systèmes de marketing et de personnalisation peuvent injecter dynamiquement des bannières ou des superpositions avec des animations qui n’ont jamais été examinées pour la conformité à WCAG 2.3.2. Mettez en place un point de contrôle de revue pour tout contenu injecté dynamiquement.

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 normes obligatoires d’accessibilité web et mobile pour un large éventail d’entités opérant en Turquie. La circulaire adopte WCAG 2.2 comme cadre de référence technique, avec une conformité obligatoire généralement requise aux niveaux A et AA.

WCAG 2.3.2 est un critère de niveau AAA et n’est donc pas légalement obligatoire au titre de la circulaire pour la plupart des entités concernées. Toutefois, son objet — la prévention de contenu susceptible de déclencher des crises — recoupe directement l’obligation générale de diligence et les principes de non-discrimination qui sous-tendent la réglementation. Les types d’entités suivants sont couverts par la circulaire et devraient considérer 2.3.2 comme une obligation de bonne pratique forte, même lorsqu’il n’est pas strictement requis : plateformes de commerce électronique, institutions publiques et agences gouvernementales, banques et institutions financières, hôpitaux et prestataires de soins de santé, entreprises de télécommunications comptant 200 000 abonnés ou plus, agences de voyage, entreprises de transport privé et écoles privées autorisées par le Ministry of National Education (MoNE).

Pour les institutions publiques et les prestataires de soins de santé en particulier, les enjeux éthiques de 2.3.2 sont particulièrement élevés. Un portail de santé gouvernemental ou une page d’information patient d’hôpital qui déclenche une crise chez un visiteur photosensible représenterait à la fois un échec de sécurité et une crise de réputation. Bien que la circulaire n’impose pas explicitement la conformité au niveau AAA, les organisations qui cherchent à démontrer une accessibilité de premier plan — que ce soit pour l’éligibilité aux marchés publics, la confiance du public ou des partenariats commerciaux internationaux — devraient mettre en œuvre 2.3.2 en plus de leurs obligations obligatoires de niveaux A et AA.

Les organisations qui fournissent des services au marché de l’Union européenne doivent également noter que l’European Accessibility Act (EAA), entré en application en juin 2025, renvoie à la norme EN 301 549, qui renvoie à son tour aux WCAG. Les entreprises turques exportant des produits ou services numériques vers les États membres de l’UE peuvent être confrontées à des exigences plus strictes par ce biais. La mise en œuvre proactive de 2.3.2 positionne favorablement les organisations turques pour la conformité tant nationale que transfrontalière.

D’un point de vue pratique de mise en œuvre, le SDK du widget de surcouche Accsible peut aider les organisations concernées en offrant aux utilisateurs la possibilité de mettre en pause ou d’arrêter toutes les animations sur une page, ce qui contribue à réduire le risque de photosensibilité pour les utilisateurs conscients de leur condition. Toutefois, ce contrôle déclenché par l’utilisateur est une mesure complémentaire, et non un substitut à la suppression ou au ralentissement du contenu clignotant à la source, comme l’exige 2.3.2.