WCAG 2.3.2: Drie flitsen

Wat Deze Regel Betekent

WCAG 2.3.2 Three Flashes is een succescriterium op niveau AAA onder het principe Bedienbaar. Het stelt dat webpagina’s niets mogen bevatten dat meer dan drie keer flitst in een periode van één seconde. In tegenstelling tot de tegenhanger op niveau AA (2.3.1 Three Flashes or Below Threshold) staat dit criterium geen uitzonderingen toe voor kleine flitsende gebieden of flitsen die onder de algemene flits- en rode-flitsdrempels vallen. De regel is absoluut: als content meer dan drie keer per seconde flitst, is het een fout, ongeacht grootte, kleur of contrast.

Een flits wordt door WCAG gedefinieerd als een paar tegengestelde veranderingen in relatieve luminantie die bij sommige mensen aanvallen kunnen veroorzaken. Praktischer gezien valt elke zichtbare aan-uit-knippering, stroboscoopachtige animatie, snel wisselende afbeeldingen of flikkerende video die meer dan drie volledige cycli per seconde voltooit, binnen de reikwijdte van deze regel. De term "three flashes" verwijst naar drie volledige oscillaties — wat betekent dat content die drie keer binnen één seconde afwisselt tussen een lichtere en donkerdere toestand hieronder valt.

De getroffen contenttypen zijn breed en omvatten geanimeerde GIF’s, CSS-animaties met @keyframes, door JavaScript aangestuurde DOM-updates die snel visueel schakelen veroorzaken, HTML5 Canvas-animaties, ingesloten videocontent, SVG-animaties en advertentienetwerken of widgets van derden die geanimeerde media insluiten. Zelfs subtiel geflikker in scrollende marquee-tekst of snel bijgewerkte datavisualisaties kan dit criterium activeren als de snelheid meer dan drie flitsen per seconde bedraagt.

Een pass onder 2.3.2 betekent dat de pagina helemaal geen flitsende content bevat die de drempel van drie flitsen per seconde overschrijdt. Een fail treedt op zodra enig deel van de pagina — ongeacht hoe klein het gebied is — meer dan drie keer flitst binnen een willekeurig tijdsvenster van één seconde. Er is geen uitzondering voor een veilige zone onder dit criterium, en dat is het verschil met 2.3.1. Een kleine knipperende cursor, een geanimeerde laadspinner of een snel wisselende advertentiebanner kunnen allemaal fouten vormen als ze flitsen met een frequentie boven 3 Hz.

Waarom Het Belangrijk Is

Fotosensitieve epilepsie treft wereldwijd ongeveer 1 op de 4.000 mensen, maar de totale populatie die vatbaar is voor een vorm van fotosensitieve neurologische reactie — waaronder fotosensitieve migraine, evenwichtsstoornissen en niet-epileptische fotosensitiviteit — is aanzienlijk groter. Voor deze mensen is blootstelling aan snel flitsende content op een scherm niet slechts een ergernis: het kan tonisch-clonische aanvallen, bewustzijnsverlies, letsel of in zeldzame gevallen de dood veroorzaken. In tegenstelling tot veel toegankelijkheidsbarrières die de gebruikerservaring verslechteren, vormt flitsende content een acuut veiligheidsrisico.

Neem een praktisch scenario: een Turkse nieuwssite plaatst een live ticker met een geanimeerd markeringseffect dat met 8 Hz pulseert om de aandacht op breaking news te vestigen. Een gebruiker met fotosensitieve epilepsie opent de pagina op zijn telefoon tijdens het woon-werkverkeer. Binnen enkele seconden veroorzaakt het snelle geflikker een focale aanval, waardoor de persoon zijn telefoon laat vallen en tijdelijk de controle over zijn spieren verliest. Hij had geen waarschuwing, geen manier om het effect vooraf uit te schakelen en geen uitweg. Dit scenario is volledig te voorkomen door flitssnelheden te beperken tot drie per seconde of minder — of door flitsende content volledig te elimineren, zoals 2.3.2 vereist.

Naast de neurologische veiligheidsdimensie komt naleving van dit criterium ook ten goede aan gebruikers met evenwichtsstoornissen (die duizeligheid, misselijkheid of desoriëntatie ervaren door beweging), gebruikers met migraine die worden getriggerd door visuele patronen, en gebruikers met aandachtsstoornissen die snel flitsende content onmogelijk kunnen negeren of omzeilen. Het verminderen of elimineren van flitsende content verbetert doorgaans ook de ervaren professionaliteit van de pagina en verlaagt het aantal afhakers, omdat veel gebruikers — met of zonder beperking — agressieve animaties irritant vinden.

Vanuit SEO- en prestatieperspectief vermindert het elimineren van zware animaties en snelle CSS-transities de belasting van CPU en GPU, wat de Core Web Vitals-scores zoals Total Blocking Time en Cumulative Layout Shift verbetert; beide zijn ranking-signalen van Google.

Gerelateerde Axe-core-regels

WCAG 2.3.2 vereist handmatige tests. Er is geen geautomatiseerde axe-core-regel die direct aan dit criterium is gekoppeld, en dat is bewust zo — dit is waarom geautomatiseerde tools overtredingen niet betrouwbaar kunnen detecteren:

• Handmatige test vereist — Detectie van flitssnelheid: Geautomatiseerde toegankelijkheidsscanners inspecteren de statische DOM en CSS op één enkel moment. Ze kunnen niet observeren hoe content zich gedraagt gedurende een volledige seconde aan animatie, de luminantie-oscillatiefrequentie van een video of geanimeerde GIF meten, of de framerate van een Canvas-animatie beoordelen. De flitssnelheid is een temporele eigenschap die realtime observatie vereist, waardoor deze fundamenteel buiten het bereik valt van statische analysetools zoals axe-core. Een menselijke tester — of gespecialiseerde fotosensitiviteitsanalysetools zoals de Photosensitive Epilepsy Analysis Tool (PEAT) — moet geanimeerde content in beweging beoordelen om te bepalen of deze de drempel van drie flitsen per seconde overschrijdt.
• Handmatige test vereist — Content van derden en ingesloten content: Advertenties, ingesloten video’s, socialmedia-widgets en iframes kunnen geanimeerde content injecteren die axe-core niet kan analyseren, omdat het binnen de same-origin policy-beperkingen van de browser opereert. Een tester moet alle ingesloten en externe content handmatig observeren tijdens het afspelen om de naleving te beoordelen.
• Handmatige test vereist — Door JavaScript aangestuurde animaties: Snel schakelen van CSS-klassen, het bijwerken van canvaspixels of het manipuleren van SVG-elementen via JavaScript met hoge frequentie kan flitseffecten produceren die onzichtbaar zijn in een statische DOM-snapshot. Testers moeten de pagina in een live browser uitvoeren, alle geanimeerde toestanden observeren en de flitscycli handmatig of met framerate-analysetools timen.

Hoe te Testen

1. Voer een geautomatiseerde scan uit als basislijn: Gebruik axe DevTools, Lighthouse of de ingebouwde audit van de Accsible-widget om eventuele gemarkeerde animatiegerelateerde problemen te identificeren. Hoewel geen enkele regel direct aan 2.3.2 is gekoppeld, kunnen deze tools gerelateerde waarschuwingen geven over CSS-animaties of ARIA live-regio’s die snel worden bijgewerkt. Noteer alle gemarkeerde items, maar begrijp dat een schone geautomatiseerde rapportage geen 2.3.2-naleving bevestigt.
2. Identificeer alle geanimeerde content handmatig: Laad de pagina in een browser en observeer deze minstens 30 seconden zonder interactie. Noteer elk element dat knippert, flitst, animeert of herhaaldelijk van visuele toestand verandert. Neem laadspinners, banners, hero-animaties, automatisch afspelende video’s, geanimeerde achtergronden en alle widgets van derden op. Maak een inventaris van deze elementen.
3. Gebruik de Photosensitive Epilepsy Analysis Tool (PEAT): Gebruik voor videocontent of schermopnames van animaties PEAT (een gratis tool van het Trace Research and Development Center) om het beeldmateriaal frame voor frame te analyseren. PEAT markeert alle sequenties die de flitsdrempels overschrijden en rapporteert zowel de algemene flitsdrempel als de rode-flitsdrempel. Een 2.3.2-fout is elke flits die meer dan drie keer per seconde voorkomt, ongeacht andere drempels.
4. Meet CSS- en JavaScript-animatiesnelheden: Open de DevTools van de browser (Chrome of Firefox) en gebruik het tabblad Performance om een sessie van 5 seconden op te nemen terwijl animaties worden afgespeeld. Inspecteer de flame graph op snel herhaalde paint- of layout-bewerkingen. U kunt ook het Animations-paneel in Chrome DevTools openen om actieve animaties en hun duur te zien — deel 1000 ms door de animatieduur om Hz te berekenen.
5. Test met NVDA + Firefox, VoiceOver + Safari en JAWS + Chrome: Schermlezersgebruikers zijn niet vrijgesteld van fotosensitiviteit. Start elke schermlezer en navigeer normaal naar de pagina. Als content die visueel flitst ook wordt gepresenteerd op een manier die snelle schermverversingen veroorzaakt (zoals een live-regio die elk frame van een teller aankondigt), documenteer dit. Visueel geflits blijft een overtreding, zelfs voor schermlezersgebruikers, omdat zij mogelijk enig functioneel zicht hebben.
6. Verifieer content van derden en ingesloten content: Scroll door alle iframes, ingesloten socialmediaberichten, advertentieposities en videospelers. Speel handmatig alle video’s af waarvoor autoplay is uitgeschakeld en let op snel geflikker. Controleer geanimeerde GIF’s door met de rechtermuisknop te klikken en framedata te inspecteren in een afbeeldingseditor of het Network-tabblad van de browser om de framerate te schatten.
7. Herhaal tests op verschillende apparaten en browsers: Sommige animaties draaien op mobiele apparaten met een andere snelheid dan op desktop door verschillen in hardwareversnelling. Test zowel in een desktopbrowser als op een mobiel apparaat (iOS Safari en Android Chrome) om consistente naleving te bevestigen.

Hoe te Herstellen

CSS Keyframe-animatie die te snel flitst — Onjuist

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

CSS Keyframe-animatie die te snel flitst — Juist

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

JavaScript DOM-toggle die snel geflikker veroorzaakt — Onjuist

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

JavaScript DOM-toggle die snel geflikker veroorzaakt — Juist

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

Geanimeerde GIF met hoge framerate — Onjuist

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

Geanimeerde GIF met hoge framerate — Juist

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

Veelvoorkomende Fouten

• Aannemen dat de "klein gebied"-uitzondering uit 2.3.1 van toepassing is op 2.3.2: WCAG 2.3.1 staat flitsende content toe die minder dan 25% van een visueel veld van 10 graden beslaat. WCAG 2.3.2 kent geen dergelijke uitzondering — een kleine knipperende cursor of een kleine laadpunt die meer dan drie keer per seconde flitst, is een volledige overtreding op AAA-niveau.
• CSS animation-duration instellen op waarden als 0.1s of 0.2s zonder de resulterende flitssnelheid te berekenen: Een animatie van 0.1s die tussen twee toestanden oscilleert, voltooit 10 cycli per seconde (10 Hz). Deel 1 door de duur in seconden om Hz te krijgen; zorg dat het resultaat 3 of lager is.
• Scripts van externe advertentienetwerken insluiten zonder het animatiegedrag te beoordelen: Advertentienetwerken leveren vaak geanimeerde creaties met hoge flitssnelheden, geoptimaliseerd voor doorklikratio’s, niet voor toegankelijkheid. Controleer altijd content van derden met PEAT of handmatige frame-inspectie voordat u deze uitrolt.
• Gebruik van setInterval of requestAnimationFrame-lussen om CSS-klassen snel te toggelen voor laad- of voortgangsindicatoren: Elke JavaScript-lus die de luminantie of zichtbaarheid van een element meer dan drie keer per seconde verandert, creëert een 2.3.2-overtreding, zelfs als het effect subtiel lijkt onder normale kijkomstandigheden.
• Geanimeerde SVG’s en Canvas-elementen niet testen: SVG-animaties met <animate> of SMIL, en Canvas-gebaseerde games of datavisualisaties, worden zelden getest met PEAT of framerate-tools, terwijl ze wel degelijk de flitsdrempel kunnen overschrijden.
• Uitsluitend vertrouwen op axe-core of Lighthouse om 2.3.2-naleving te bevestigen: Geautomatiseerde tools kunnen dit criterium niet detecteren. Een schone geautomatiseerde scan zegt niets over 2.3.2; alleen handmatige beoordeling en PEAT-analyse kunnen naleving bevestigen.
• prefers-reduced-motion behandelen als een volledige oplossing voor 2.3.2: Het respecteren van de prefers-reduced-motion-mediaquery is een best practice en nuttig voor veel gebruikers, maar het is een mechanisme waarbij de gebruiker zich actief moet aanmelden. WCAG 2.3.2 vereist dat content standaard veilig is, niet alleen wanneer de gebruiker een systeemvoorkeur heeft ingesteld. Gebruikers die deze instelling niet hebben geconfigureerd, blijven risico lopen.
• Flitssnelheidslimieten alleen toepassen op video, maar niet op CSS-, JavaScript- of GIF-animaties: Teams controleren soms videocontent met PEAT, maar negeren CSS keyframe-animaties en door JavaScript aangestuurde toggles. Alle animatietechnologieën moeten worden beoordeeld.
• Gebruik van background-image CSS-eigenschappen om geanimeerde GIF’s weer te geven: Geanimeerde GIF’s die als CSS-achtergrondafbeeldingen zijn ingesteld, zijn minder zichtbaar voor testers die een visuele scan uitvoeren en worden gemakkelijk over het hoofd gezien tijdens audits. Neem achtergrondafbeeldingen altijd op in uw animatie-inventaris.
• Niet opnieuw testen nadat A/B-tests of personalisatiewijzigingen nieuwe geanimeerde content injecteren: Marketing- en personalisatiesystemen kunnen dynamisch banners of overlays injecteren met animaties die nooit zijn beoordeeld op WCAG 2.3.2-naleving. Stel een beoordelingsstap in voor alle dynamisch ingespoten content.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Presidentiële Circulaire 2025/10 van Turkije, gepubliceerd in Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte web- en mobiele toegankelijkheidsnormen vast voor een brede reeks entiteiten die in Turkije actief zijn. De circulaire neemt WCAG 2.2 over als technisch referentiekader, waarbij naleving op niveau A en niveau AA in het algemeen verplicht is.

WCAG 2.3.2 is een criterium op niveau AAA en is daarom niet wettelijk verplicht onder de circulaire voor de meeste betrokken entiteiten. De inhoud ervan — het voorkomen van content die aanvallen kan uitlokken — raakt echter direct aan de algemene zorgplicht en de non-discriminatiebeginselen die ten grondslag liggen aan de regelgeving. De volgende typen entiteiten vallen onder de circulaire en zouden 2.3.2 als een sterke best-practiceverplichting moeten behandelen, zelfs wanneer het niet strikt vereist is: e-commerceplatforms, publieke instellingen en overheidsinstanties, banken en financiële instellingen, ziekenhuizen en zorgaanbieders, telecombedrijven met 200.000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE).

Voor publieke instellingen en zorgaanbieders zijn de ethische belangen van 2.3.2 in het bijzonder groot. Een overheidsgezondheidsportaal of een patiënteninformatiesite van een ziekenhuis die bij een fotosensitieve bezoeker een aanval uitlokt, zou zowel een veiligheidsfalen als een reputatieschade betekenen. Hoewel de circulaire AAA-naleving niet expliciet verplicht stelt, zouden organisaties die best-in-class toegankelijkheid willen aantonen — of dat nu is voor aanbestedingsgeschiktheid, publiek vertrouwen of internationale zakelijke partnerschappen — 2.3.2 moeten implementeren naast hun verplichte A- en AA-verplichtingen.

Organisaties die diensten leveren aan de markt van de Europese Unie moeten er ook rekening mee houden dat de European Accessibility Act (EAA), die in juni 2025 van toepassing werd, verwijst naar EN 301 549, dat op zijn beurt naar WCAG verwijst. Turkse bedrijven die digitale producten of diensten exporteren naar EU-lidstaten kunnen via dat kanaal met strengere eisen te maken krijgen. Proactieve implementatie van 2.3.2 positioneert Turkse organisaties goed voor zowel binnenlandse als grensoverschrijdende naleving.

Vanuit praktisch implementatieperspectief kan de Accsible overlay widget SDK betrokken organisaties helpen door gebruikers de optie te bieden om alle animaties op een pagina te pauzeren of te stoppen, wat het fotosensitiviteitsrisico vermindert voor gebruikers die zich bewust zijn van hun aandoening. Deze door de gebruiker geactiveerde controle is echter een aanvullende maatregel, geen vervanging voor het verwijderen of vertragen van flitsende content aan de bron, zoals 2.3.2 vereist.