WCAG 2.3.2: Drei Blitze

Was diese Regel bedeutet

WCAG 2.3.2 Drei Blitze ist ein Erfolgskriterium der Stufe AAA unter dem Prinzip „Bedienbar“. Es besagt, dass Webseiten nichts enthalten dürfen, das mehr als dreimal innerhalb eines Zeitraums von einer Sekunde aufblitzt. Anders als das entsprechende Kriterium der Stufe AA (2.3.1 Drei Blitze oder unterhalb des Schwellenwerts) erlaubt dieses Kriterium keine Ausnahmen für kleine blinkende Bereiche oder Blitze, die unterhalb des allgemeinen Blitz- und Rotblitz-Schwellenwerts liegen. Die Regel ist absolut: Wenn Inhalte mehr als dreimal pro Sekunde blitzen, ist dies ein Verstoß – unabhängig von Größe, Farbe oder Kontrast.

Ein Blitz wird von WCAG als ein Paar entgegengesetzter Änderungen der relativen Leuchtdichte definiert, die bei manchen Menschen Anfälle auslösen können. Praktischer ausgedrückt: Jegliches sichtbare Ein-Aus-Blinken, stroboskopartige Animationen, schnell wechselnde Bilder oder flackernde Videos, die mehr als drei vollständige Zyklen pro Sekunde durchlaufen, fallen in den Geltungsbereich dieser Regel. Der Begriff „drei Blitze“ bezieht sich auf drei vollständige Schwingungen – das bedeutet Inhalte, die innerhalb einer Sekunde dreimal zwischen einem helleren und einem dunkleren Zustand wechseln.

Die betroffenen Inhaltstypen sind breit gefächert und umfassen animierte GIFs, CSS-Animationen mit @keyframes, JavaScript-gesteuerte DOM-Updates, die schnelles visuelles Umschalten verursachen, HTML5-Canvas-Animationen, eingebettete Videoinhalte, SVG-Animationen sowie Drittanbieter-Werbenetzwerke oder Widgets, die animierte Medien einbetten. Selbst subtiles Flackern in scrollendem Lauftext oder sich schnell aktualisierenden Datenvisualisierungen kann dieses Kriterium auslösen, wenn die Rate mehr als drei Blitze pro Sekunde überschreitet.

Ein Bestehen nach 2.3.2 bedeutet, dass die Seite keinerlei blinkende Inhalte enthält, die den Schwellenwert von drei Blitzen pro Sekunde überschreiten. Ein Fehlschlag tritt immer dann ein, wenn irgendein Teil der Seite – unabhängig davon, wie klein der Bereich ist – mehr als dreimal innerhalb eines beliebigen Ein-Sekunden-Fensters aufblitzt. Es gibt keine Ausnahme für „sichere Bereiche“ in diesem Kriterium, was es von 2.3.1 unterscheidet. Ein winziger blinkender Cursor, ein animierter Ladeindikator oder ein sich schnell wechselndes Werbebanner können alle Verstöße darstellen, wenn sie mit Frequenzen über 3 Hz blinken.

Warum es wichtig ist

Fotosensitive Epilepsie betrifft weltweit etwa 1 von 4.000 Menschen, aber die Gesamtzahl der Personen, die für irgendeine Form fotosensitiver neurologischer Reaktion anfällig sind – einschließlich fotosensitiver Migräne, vestibulärer Störungen und nicht-epileptischer Fotosensitivität – ist deutlich größer. Für diese Personen ist die Exposition gegenüber schnell blinkenden Inhalten auf einem Bildschirm nicht nur eine Belästigung: Sie kann generalisierte tonisch-klonische Anfälle, Bewusstlosigkeit, Verletzungen oder in seltenen Fällen den Tod auslösen. Anders als viele Barrieren der Barrierefreiheit, die die Nutzererfahrung verschlechtern, stellt blinkender Inhalt eine akute Sicherheitsgefahr dar.

Betrachten Sie ein praktisches Szenario: Eine türkische Nachrichtenwebsite bettet einen Live-Ticker mit einem animierten Hervorhebungseffekt ein, der mit 8 Hz pulsiert, um auf Eilmeldungen aufmerksam zu machen. Eine Nutzerin oder ein Nutzer mit fotosensitiver Epilepsie öffnet die Seite auf dem Handy während der Fahrt. Innerhalb von Sekunden löst das schnelle Flackern einen fokalen Anfall aus, wodurch die Person das Telefon fallen lässt und kurzzeitig die Muskelkontrolle verliert. Es gab keine Warnung, keine Möglichkeit, den Effekt im Voraus zu deaktivieren, und keinen Ausweg. Dieses Szenario ist vollständig vermeidbar, indem die Blitzrate auf drei pro Sekunde oder weniger begrenzt wird – oder indem blinkende Inhalte vollständig entfernt werden, wie es 2.3.2 verlangt.

Über die neurologische Sicherheitsdimension hinaus kommt die Einhaltung dieses Kriteriums auch Nutzerinnen und Nutzern mit vestibulären Störungen zugute (die Schwindel, Übelkeit oder Desorientierung durch Bewegung erleben), Nutzerinnen und Nutzern mit durch visuelle Muster ausgelösten Migränen sowie Personen mit Aufmerksamkeitsstörungen, die schnell blinkende Inhalte nicht ignorieren oder umgehen können. Die Reduzierung oder Beseitigung blinkender Inhalte verbessert zudem häufig die wahrgenommene Professionalität einer Seite und senkt die Abbruchraten, da viele Nutzerinnen und Nutzer – ob mit Behinderung oder ohne – aggressive Animationen als störend empfinden.

Aus SEO- und Performance-Perspektive reduziert die Beseitigung schwerer Animationen und schneller CSS-Übergänge die CPU- und GPU-Last und verbessert Core-Web-Vitals-Werte wie Total Blocking Time und Cumulative Layout Shift, die beide Google-Ranking-Signale sind.

Verwandte Axe-core-Regeln

WCAG 2.3.2 erfordert manuelle Tests. Keine automatisierte axe-core-Regel lässt sich direkt diesem Kriterium zuordnen, und das ist beabsichtigt – hier ist der Grund, warum automatisierte Tools Verstöße nicht zuverlässig erkennen können:

• Manuelle Tests erforderlich – Erkennung der Blitzrate: Automatisierte Barrierefreiheits-Scanner untersuchen das statische DOM und CSS zu einem einzigen Zeitpunkt. Sie können nicht beobachten, wie sich Inhalte über eine volle Sekunde der Animationswiedergabe verhalten, die Frequenz der Leuchtdichte-Schwingungen eines Videos oder eines animierten GIF messen oder die Bildrate einer Canvas-Animation bewerten. Die Blitzrate ist eine zeitliche Eigenschaft, die eine Beobachtung in Echtzeit erfordert und damit grundsätzlich außerhalb der Möglichkeiten statischer Analysetools wie axe-core liegt. Eine menschliche Testerin oder ein menschlicher Tester – oder spezialisierte Tools zur Analyse von Fotosensitivität wie das Photosensitive Epilepsy Analysis Tool (PEAT) – müssen animierte Inhalte in Bewegung prüfen, um festzustellen, ob sie den Schwellenwert von drei Blitzen pro Sekunde überschreiten.
• Manuelle Tests erforderlich – Drittanbieter- und eingebettete Inhalte: Werbeanzeigen, eingebettete Videos, Social-Media-Widgets und iframes können animierte Inhalte einfügen, die axe-core nicht analysieren kann, da es innerhalb der Same-Origin-Policy-Beschränkungen des Browsers arbeitet. Eine Testerin oder ein Tester muss alle eingebetteten und Drittanbieter-Inhalte während der Wiedergabe manuell beobachten, um die Konformität zu beurteilen.
• Manuelle Tests erforderlich – JavaScript-gesteuerte Animationen: Schnelles Umschalten von CSS-Klassen, Aktualisieren von Canvas-Pixeln oder Manipulieren von SVG-Elementen mit hoher Frequenz über JavaScript kann Blitzeffekte erzeugen, die in einem statischen DOM-Snapshot unsichtbar sind. Testerinnen und Tester müssen die Seite in einem Live-Browser ausführen, alle Animationszustände beobachten und die Blitzzyklen manuell oder mit Bildraten-Analysetools messen.

Wie man testet

1. Führen Sie einen automatisierten Scan als Ausgangspunkt durch: Verwenden Sie axe DevTools, Lighthouse oder das integrierte Audit des Accsible-Widgets, um gemeldete animierungsbezogene Probleme zu identifizieren. Auch wenn keine Regel direkt auf 2.3.2 abbildet, können diese Tools verwandte Warnungen zu CSS-Animationen oder ARIA-Live-Regionen anzeigen, die sich schnell aktualisieren. Notieren Sie alle gemeldeten Punkte, verstehen Sie aber, dass ein sauberer automatisierter Bericht keine Konformität mit 2.3.2 bestätigt.
2. Identifizieren Sie alle animierten Inhalte manuell: Laden Sie die Seite in einem Browser und beobachten Sie sie mindestens 30 Sekunden lang ohne Interaktion. Notieren Sie jedes Element, das blinkt, aufblitzt, animiert ist oder seinen visuellen Zustand wiederholt ändert. Schließen Sie Ladeindikatoren, Banner, Hero-Animationen, automatisch abspielende Videos, animierte Hintergründe und alle Drittanbieter-Widgets ein. Erstellen Sie ein Inventar dieser Elemente.
3. Verwenden Sie das Photosensitive Epilepsy Analysis Tool (PEAT): Für Videoinhalte oder Bildschirmaufnahmen von Animationen verwenden Sie PEAT (ein kostenloses Tool des Trace Research and Development Center), um das Material Bild für Bild zu analysieren. PEAT markiert Sequenzen, die die Blitzschwellen überschreiten, und meldet sowohl den allgemeinen Blitzschwellenwert als auch den Rotblitz-Schwellenwert. Ein Verstoß gegen 2.3.2 ist jeder Blitz, der mehr als dreimal pro Sekunde auftritt, unabhängig von anderen Schwellenwerten.
4. Messen Sie CSS- und JavaScript-Animationsraten: Öffnen Sie die DevTools des Browsers (Chrome oder Firefox) und verwenden Sie den Performance-Tab, um eine 5-sekündige Sitzung aufzuzeichnen, während Animationen laufen. Untersuchen Sie das Flame-Chart auf sich schnell wiederholende Paint- oder Layout-Operationen. Sie können auch das Animations-Panel in den Chrome DevTools öffnen, um laufende Animationen und deren Dauer zu sehen – teilen Sie 1000 ms durch die Animationsdauer, um die Hz zu berechnen.
5. Testen Sie mit NVDA + Firefox, VoiceOver + Safari und JAWS + Chrome: Screenreader-Nutzerinnen und -Nutzer sind nicht von Fotosensitivität ausgenommen. Starten Sie jeden Screenreader und navigieren Sie normal zur Seite. Wenn Inhalte, die visuell blitzen, auch so präsentiert werden, dass sie schnelle Bildschirmaktualisierungen verursachen (z. B. eine Live-Region, die jedes Frame eines Zählers ankündigt), dokumentieren Sie dies. Visuelles Blinken bleibt ein Verstoß, selbst für Screenreader-Nutzende, da sie möglicherweise über ein gewisses Restsehvermögen verfügen.
6. Überprüfen Sie Drittanbieter- und eingebettete Inhalte: Scrollen Sie durch alle iframes, eingebetteten Social-Media-Posts, Werbeflächen und Videoplayer. Spielen Sie alle Videos, bei denen Autoplay deaktiviert ist, manuell ab und beobachten Sie sie auf schnelles Flackern. Prüfen Sie animierte GIFs, indem Sie mit der rechten Maustaste klicken und die Frame-Daten in einem Bildeditor oder im Network-Tab des Browsers inspizieren, um die Bildrate abzuschätzen.
7. Wiederholen Sie Tests auf verschiedenen Geräten und in verschiedenen Browsern: Einige Animationen laufen auf Mobilgeräten aufgrund von Hardwarebeschleunigung mit anderer Geschwindigkeit als auf dem Desktop. Testen Sie sowohl in einem Desktop-Browser als auch auf einem Mobilgerät (iOS Safari und Android Chrome), um eine konsistente Konformität zu bestätigen.

Wie man es behebt

CSS-Keyframe-Animation blinkt zu schnell – Falsch

<!-- Ein Badge, das zur Aufmerksamkeitslenkung blinkt und 8 Zyklen pro Sekunde durchläuft -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz – weit über 3 pro Sekunde */
  }
</style>
<span class='alert-badge'>NEW</span>

CSS-Keyframe-Animation blinkt zu schnell – Richtig

<!-- Animation verlangsamt, sodass weniger als 3 Zyklen pro Sekunde abgeschlossen werden -->
<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 – sicher unterhalb des 3-Hz-Schwellenwerts */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Noch besser: die Animation vollständig entfernen und ein statisches, kontrastreiches Badge verwenden -->

JavaScript-DOM-Umschaltung verursacht schnelles Flackern – Falsch

<!-- Skript schaltet die Sichtbarkeit 10-mal pro Sekunde um, um einen Stroboskopeffekt zu simulieren -->
<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); /* Wird alle 100 ms ausgelöst = 10 Blitze pro Sekunde – ein ernstes Anfallsrisiko */
</script>

JavaScript-DOM-Umschaltung verursacht schnelles Flackern – Richtig

<!-- Das schnelle Umschalten vollständig entfernt; Zustandsänderung stattdessen über Text oder Icon vermitteln -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- Wenn eine Animation wirklich nötig ist, halten Sie sie deutlich unter 3 Hz und bevorzugen Sie
     Opazitäts-/Farbübergänge gegenüber hochkontrastierenden Leuchtdichtewechseln -->

Animiertes GIF mit hoher Bildrate – Falsch

<!-- Eine animierte GIF-Werbung, die die Frames mit 10 fps durchläuft -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- Die interne Frame-Verzögerung des GIF ist auf 10 ms pro Frame eingestellt, was schnelles Flackern erzeugt -->

Animiertes GIF mit hoher Bildrate – Richtig

<!-- Ersetzen Sie das animierte GIF durch ein statisches Bild oder exportieren Sie das GIF neu
     mit einer minimalen Frame-Verzögerung von 334 ms pro Frame (3 fps oder langsamer) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- Wenn Bewegung erhalten bleiben muss, verwenden Sie eine CSS-Animation mit Unterstützung für 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>

Häufige Fehler

• Die Annahme, die „kleine Fläche“-Ausnahme aus 2.3.1 gelte für 2.3.2: WCAG 2.3.1 erlaubt blinkende Inhalte, die weniger als 25 % eines 10-Grad-Sichtfelds einnehmen. WCAG 2.3.2 hat keine solche Ausnahme – ein winziger blinkender Cursor oder ein kleiner Ladepunkt, der mehr als dreimal pro Sekunde blinkt, ist ein vollständiger Verstoß auf AAA-Niveau.
• Setzen von CSS animation-duration auf Werte wie 0.1s oder 0.2s, ohne die resultierende Blitzrate zu berechnen: Eine 0,1s-Animation, die zwischen zwei Zuständen oszilliert, durchläuft 10 Zyklen pro Sekunde (10 Hz). Teilen Sie 1 durch die Dauer in Sekunden, um Hz zu erhalten; stellen Sie sicher, dass das Ergebnis 3 oder weniger beträgt.
• Einbetten von Drittanbieter-Werbeskripten ohne Überprüfung des Animationsverhaltens: Werbenetzwerke liefern häufig animierte Creatives mit hohen Blitzraten, die auf Klickrate und nicht auf Barrierefreiheit optimiert sind. Prüfen Sie Drittanbieter-Inhalte immer mit PEAT oder manueller Frame-Inspektion, bevor Sie sie ausrollen.
• Verwendung von setInterval- oder requestAnimationFrame-Schleifen, um CSS-Klassen schnell für Lade- oder Fortschrittsindikatoren umzuschalten: Jede JavaScript-Schleife, die die Leuchtdichte oder Sichtbarkeit eines Elements mehr als dreimal pro Sekunde ändert, erzeugt einen Verstoß gegen 2.3.2, selbst wenn der Effekt unter normalen Betrachtungsbedingungen subtil wirkt.
• Keine Tests animierter SVGs und Canvas-Elemente: SVG-Animationen mit <animate> oder SMIL sowie Canvas-basierte Spiele oder Datenvisualisierungen werden selten mit PEAT oder Bildraten-Tools getestet, können aber problemlos den Blitzschwellenwert überschreiten.
• Sich ausschließlich auf axe-core oder Lighthouse verlassen, um 2.3.2-Konformität zu bestätigen: Automatisierte Tools können dieses Kriterium nicht erkennen. Ein sauberer automatisierter Scan bedeutet für 2.3.2 gar nichts; nur manuelle Überprüfung und PEAT-Analyse können Konformität bestätigen.
• prefers-reduced-motion als vollständige Lösung für 2.3.2 betrachten: Die Beachtung der prefers-reduced-motion-Media-Query ist eine Best Practice und für viele Nutzerinnen und Nutzer hilfreich, aber sie ist ein Mechanismus, der eine aktive Entscheidung der Nutzenden erfordert. WCAG 2.3.2 verlangt, dass Inhalte standardmäßig sicher sind, nicht nur, wenn die Nutzerin oder der Nutzer eine Systemeinstellung gesetzt hat. Personen, die diese Einstellung nicht konfiguriert haben, bleiben gefährdet.
• Begrenzung der Blitzrate nur auf Videos, nicht aber auf CSS-, JavaScript- oder GIF-Animationen: Teams prüfen manchmal Videoinhalte mit PEAT, übersehen aber CSS-Keyframe-Animationen und JavaScript-gesteuerte Umschaltungen. Alle Animationstechnologien müssen bewertet werden.
• Verwendung von background-image-CSS-Eigenschaften zur Anzeige animierter GIFs: Animierte GIFs, die als CSS-Hintergrundbilder gesetzt sind, sind für Testerinnen und Tester bei einer visuellen Prüfung weniger auffällig und werden bei Audits leicht übersehen. Nehmen Sie Hintergrundbilder immer in Ihr Animationsinventar auf.
• Unterlassen der erneuten Tests, nachdem A/B-Tests oder Personalisierungsänderungen neue animierte Inhalte einfügen: Marketing- und Personalisierungssysteme können dynamisch Banner oder Overlays mit Animationen einfügen, die nie auf WCAG-2.3.2-Konformität geprüft wurden. Richten Sie eine Prüfschranke für alle dynamisch eingefügten Inhalte ein.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Web- und Mobile-Barrierefreiheitsstandards für eine breite Palette von Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung übernimmt WCAG 2.2 als technischen Bezugsrahmen, wobei die verpflichtende Konformität im Allgemeinen die Stufen A und AA umfasst.

WCAG 2.3.2 ist ein Kriterium der Stufe AAA und daher für die meisten erfassten Einrichtungen nicht rechtlich vorgeschrieben. Sein Gegenstand – die Vermeidung von Inhalten, die Anfälle auslösen können – überschneidet sich jedoch direkt mit der allgemeinen Sorgfaltspflicht und den Gleichbehandlungsgrundsätzen, die der Regelung zugrunde liegen. Die folgenden Einrichtungstypen werden von der Verfügung erfasst und sollten 2.3.2 als starke Best-Practice-Verpflichtung behandeln, auch wenn es nicht strikt erforderlich ist: E-Commerce-Plattformen, öffentliche Einrichtungen und Regierungsbehörden, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung (MoNE) zugelassen sind.

Insbesondere für öffentliche Einrichtungen und Gesundheitsdienstleister sind die ethischen Implikationen von 2.3.2 besonders hoch. Ein staatliches Gesundheitsportal oder eine Patienteninformationsseite eines Krankenhauses, die bei einer fotosensitiven Besucherin oder einem fotosensitiven Besucher einen Anfall auslöst, würde sowohl ein Sicherheitsversagen als auch eine Reputationskrise darstellen. Obwohl die Verfügung die Einhaltung der Stufe AAA nicht ausdrücklich vorschreibt, sollten Organisationen, die eine erstklassige Barrierefreiheit nachweisen wollen – sei es für die Eignung bei Ausschreibungen, für das öffentliche Vertrauen oder für internationale Geschäftspartnerschaften – 2.3.2 zusätzlich zu ihren verpflichtenden A- und AA-Verpflichtungen umsetzen.

Organisationen, die Dienstleistungen für den Markt der Europäischen Union erbringen, sollten außerdem beachten, dass der European Accessibility Act (EAA), der im Juni 2025 in Kraft trat, auf EN 301 549 verweist, der wiederum auf WCAG verweist. Türkische Unternehmen, die digitale Produkte oder Dienstleistungen in EU-Mitgliedstaaten exportieren, können über diesen Kanal strengeren Anforderungen ausgesetzt sein. Die proaktive Umsetzung von 2.3.2 positioniert türkische Organisationen sowohl für die inländische als auch für die grenzüberschreitende Konformität gut.

Aus praktischer Umsetzungssicht kann das Accsible-Overlay-Widget-SDK erfassten Organisationen helfen, indem es Nutzerinnen und Nutzern die Möglichkeit bietet, alle Animationen auf einer Seite zu pausieren oder zu stoppen, was das Risiko von Fotosensitivität für Personen verringert, die sich ihrer Erkrankung bewusst sind. Diese nutzergesteuerte Kontrolle ist jedoch eine ergänzende Maßnahme und kein Ersatz für das Entfernen oder Verlangsamen blinkender Inhalte an der Quelle, wie es 2.3.2 verlangt.