WCAG-Erfolgskriterien · Level A
WCAG 2.3.1: Drei Blitze oder unterhalb des Schwellenwerts
WCAG 2.3.1 verlangt, dass Webinhalte nichts enthalten, das mehr als dreimal pro Sekunde aufblitzt, es sei denn, das Aufblitzen liegt unter den allgemeinen oder roten Blitzschwellen. Dieses Kriterium ist entscheidend, um Anfälle und körperliche Reaktionen bei Nutzern mit fotosensitiver Epilepsie oder ähnlichen neurologischen Erkrankungen zu verhindern.
Was diese Regel bedeutet
WCAG 2.3.1 — Drei Blitze oder unterhalb des Schwellenwerts — ist ein Erfolgskriterium der Stufe A unter dem Prinzip „Bedienbar“. Es schreibt vor, dass Webseiten keine Inhalte enthalten dürfen, die mehr als dreimal innerhalb eines Zeitraums von einer Sekunde blitzen, es sei denn, dieser blitzende Inhalt ist klein genug oder schwach genug, um unter den definierten allgemeinen Blitzschwellenwert oder den Rotblitz-Schwellenwert zu fallen.
Ein Blitz ist definiert als ein Paar entgegengesetzter Änderungen der relativen Leuchtdichte, die bei empfindlichen Personen Anfälle auslösen können. Konkret definiert WCAG zwei Arten von gefährlichen Blitzen:
- Allgemeiner Blitz: Ein Paar entgegengesetzter Änderungen, bei denen die höhere Leuchtdichte mindestens 10 % der maximalen relativen Leuchtdichte (0,80) beträgt und der Leuchtdichteunterschied mindestens 10 % des Maximums ausmacht. In der Praxis bedeutet dies Inhalte, die schnell genug zwischen einem hellen und einem dunklen Zustand wechseln, um einen stroboskopischen Effekt zu erzeugen.
- Rotblitz: Ein Paar entgegengesetzter Übergänge, an denen eine gesättigte rote Farbe beteiligt ist. Dies wird mit besonderer Sorgfalt behandelt, da Rotblitze klinisch mit einem höheren Risiko in Verbindung gebracht wurden, fotosensitive Anfälle auszulösen.
Das Kriterium gilt für alle Webinhalte unabhängig vom Format — HTML-Animationen, CSS-Übergänge, JavaScript-gesteuerte Effekte, eingebettete Videos, GIFs, SVG-Animationen, WebGL-Szenen, Canvas-gerenderte Grafiken und Werbe-Widgets von Drittanbietern. Wenn Inhalte mit einer Frequenz von mehr als drei Blitzen pro Sekunde blitzen und nicht unter die Leuchtdichte- oder Größen-Schwellenwerte fallen, verfehlen sie dieses Kriterium ausnahmslos.
Ausnahmen und Schwellenwerte, die Inhalte bestehen lassen: WCAG 2.3.1 erlaubt blitzende Inhalte, wenn eine der folgenden Bedingungen erfüllt ist:
- Die kombinierte Fläche der gleichzeitig auftretenden Blitze deckt nicht mehr als insgesamt 0,006 Steradiant innerhalb eines visuellen 10-Grad-Sichtfelds auf dem Bildschirm ab (ungefähr ein Rechteck von 341 × 256 Pixeln bei typischen Betrachtungsabständen oder etwa 21.824 Quadratpixel auf einem 1.024 Pixel breiten Display in Armlänge).
- Der Blitz liegt unterhalb des allgemeinen Blitzschwellenwerts (Leuchtdichteänderung ist geringer als 10 %) oder unterhalb des Rotblitz-Schwellenwerts (die gesättigte Rotkomponente ändert sich nicht um mehr als den definierten Schwellenwert).
Ein einzelnes Blitzerereignis mit sehr geringem Leuchtdichtekontrast oder einer sehr kleinen Bildschirmfläche kann daher zulässig sein. Da diese Schwellenwerte jedoch nuanciert sind und photometrische Messwerkzeuge erfordern, um sie präzise zu überprüfen, wählen die meisten Praktiker den konservativen Ansatz, einfach alle Inhalte zu vermeiden, die mehr als dreimal pro Sekunde blitzen. Inhalte, die genau dreimal pro Sekunde (3 Hz) blitzen, liegen an der Grenze — Inhalte, die 3 Hz überschreiten, sind unabhängig von der Größe nicht konform, es sei denn, die Größen- oder Leuchtdichte-Schwellenwerte werden eindeutig eingehalten.
Das Kriterium regelt alle Inhalte, die während der normalen Seiteninteraktion gerendert werden. Es schließt keine Inhalte aus, die hinter benutzergesteuerten Steuerelementen verborgen sind, wenn diese Inhalte beim Laden der Seite automatisch abgespielt werden. Wenn ein Video automatisch zu spielen beginnt und Sequenzen enthält, die die Schwellenwerte überschreiten, verfehlt die Seite dieses Kriterium ab dem Moment, in dem sie geladen wird.
Warum es wichtig ist
Fotosensitive Epilepsie betrifft weltweit etwa 1 von 4.000 Menschen — ungefähr 3 % der gesamten Epilepsiepopulation. Die Empfindlichkeit gegenüber schnell blitzendem oder flackerndem Licht ist jedoch breiter gefasst als die klinische Epilepsie allein. Viele Menschen mit Migräneerkrankungen, vestibulären Funktionsstörungen, Autismus-Spektrum-Störungen und postkommotionellen Syndromen können durch schnell blitzende visuelle Reize erhebliche Beschwerden, Desorientierung, Übelkeit oder Schmerzen erfahren, selbst wenn bei ihnen keine Anfallserkrankung diagnostiziert wurde.
Die Tragweite ist bei diesem Kriterium im Vergleich zu den meisten anderen Barrierefreiheitsanforderungen besonders hoch. Ein Nutzer, der auf fehlenden Alternativtext stößt, erlebt Ausschluss und Frustration. Ein Nutzer, der auf Inhalte stößt, die einen fotosensitiven Anfall auslösen, kann einen medizinischen Notfall erleiden — einschließlich Bewusstlosigkeit, Verletzungen durch Stürze und in seltenen, aber dokumentierten Fällen lebensbedrohliche Folgen. Der Harding Flash and Pattern Analyzer, ein weit verbreitetes Rundfunkwerkzeug, wurde speziell entwickelt, um solche Ereignisse im Fernsehen zu verhindern, und das Web birgt analoge Risiken.
Ein konkretes Szenario aus der realen Welt veranschaulicht die Gefahr gut: Man stelle sich eine Nachrichtenwebsite vor, die automatisch ein Werbevideo abspielt, das eine schnelle Abfolge abwechselnder heller und dunkler Frames enthält — ein häufiges Artefakt bestimmter Videokompressions- oder Kamera-Blitzeffekte. Eine Person mit fotosensitiver Epilepsie besucht die Startseite während ihres morgendlichen Arbeitswegs auf einem mobilen Gerät. Ohne jede Warnung und ohne Möglichkeit, die Inhalte zu deaktivieren, ist sie einer Sequenz ausgesetzt, die einen Anfall auslöst, während sie öffentliche Verkehrsmittel nutzt. Dieses Szenario ist nicht hypothetisch; es ist in realen Kontexten aufgetreten, einschließlich der berüchtigten Pokémon-Folge von 2007, die bei Hunderten von Zuschauern in Japan Anfälle auslöste, sowie dokumentierter Fälle mit webbasierten Werbeeinheiten.
Über die Sicherheitsdimension hinaus hat die Einhaltung dieses Kriteriums auch Auswirkungen auf die Benutzerfreundlichkeit für allgemeine Zielgruppen. Schnell blitzende Inhalte führen zu einer schlechten Leseerfahrung, erhöhen die kognitive Belastung und gelten in den meisten Designkontexten als störend und unprofessionell. Die Beseitigung solcher Inhalte verbessert die Konzentration, senkt die Absprungraten und signalisiert Vertrauenswürdigkeit — all dies wirkt sich positiv auf SEO-Kennzahlen wie Verweildauer und Engagement-Raten aus. Darüber hinaus berücksichtigen Suchmaschinen-Crawler zunehmend Core Web Vitals und User-Experience-Signale in ihren Rankings, und Websites mit aufdringlichen, blitzenden Werbeanzeigen oder Animationen können indirekt abgestraft werden.
Verwandte Axe-core-Regeln
WCAG 2.3.1 erfordert manuelle Tests, da automatisierte Werkzeuge die photometrischen Eigenschaften dynamischer Inhalte in Echtzeit nicht zuverlässig analysieren können. Es gibt keine automatisierte axe-core-Regel, die direkt diesem Kriterium zugeordnet ist. Die Gründe für diese Einschränkung sind grundlegend für die Funktionsweise von Barrierefreiheits-Automatisierung:
- Warum Automatisierung hier scheitert: Automatisierte Scanner analysieren das statische DOM und CSS zu einem bestimmten Zeitpunkt. Sie können erkennen, dass eine Animation oder ein Videoelement existiert, aber sie können weder die tatsächliche Blitzfrequenz noch die Leuchtdichtewerte in jedem Frame oder die räumliche Fläche des blitzenden Bereichs messen, wie sie von einem menschlichen Betrachter in typischer Betrachtungsentfernung wahrgenommen wird. Die Feststellung, ob ein Blitz die 3-Hz-Schwelle oder die 0,006-Steradiant-Flächenschwelle überschreitet, erfordert eine photometrische Analyse Frame für Frame — eine Aufgabe, die spezielle Werkzeuge wie den Harding Flash and Pattern Analyzer (HFPA), das Photosensitive Epilepsy Analysis Tool (PEAT) oder eine manuelle Überprüfung der Animationsquell-Dateien erfordert.
- Eingebettete Videos und Inhalte von Drittanbietern: Ein Großteil der risikoreichsten Inhalte (automatisch abspielende Videoanzeigen, eingebettete Social-Media-Widgets, Animationsbibliotheken von Drittanbietern) wird von externen Domains geladen. Automatisierte Werkzeuge können in der Regel nicht auf Cross-Origin-Inhalte auf Frame-Ebene zugreifen oder sie analysieren, was es unmöglich macht, die Blitzfrequenz innerhalb dieser Ressourcen programmatisch zu beurteilen.
- GIF- und Canvas-Animationen: Animierte GIF-Dateien und HTML5-Canvas-Elemente rendern ihre Animationsframes außerhalb des normalen Barrierefreiheitsbaums. Axe-core und Lighthouse fehlt die Fähigkeit, GIF-Frame-Timings zu dekodieren oder Canvas-Zeichenaufrufe abzufangen, um Leuchtdichteänderungen zwischen Frames zu berechnen.
- CSS- und JavaScript-Animationen: Während axe-core das Vorhandensein von CSS-
animation- odertransition-Eigenschaften erkennen kann, kann es nicht bewerten, ob die resultierende visuelle Ausgabe zur Laufzeit Leuchtdichteänderungen erzeugt, die die allgemeinen oder roten Blitzschwellenwerte überschreiten.
Da keine automatisierte Regel diesen Verstoß erfasst, liegt die gesamte Verantwortung für die Einhaltung bei der manuellen Designprüfung, der Videoanalyse vor der Veröffentlichung und dem Bewusstsein der Entwickler während der Inhaltserstellungsphase. Dies macht redaktionelle und QS-Prozesskontrollen — nicht nur technische Nachbesserungen — zu einem wesentlichen Bestandteil nachhaltiger Compliance.
Wie man testet
- Bestandsaufnahme aller dynamischen Inhalte: Führen Sie vor jedem werkzeugbasierten Test eine Prüfung der Seite auf alle Inhalte durch, die sich bewegen, blitzen, blinken oder animieren. Dazu gehören automatisch abspielende Videos, animierte GIFs, CSS-Keyframe-Animationen, JavaScript-gesteuerte Animationen, SVG-Animationen, Canvas-Elemente und eingebettete Widgets von Drittanbietern wie Werbeeinheiten oder Social-Media-Einbettungen. Dokumentieren Sie jede Instanz mit ihrer Quelle und ihrem Steuerungsmechanismus.
- Verwendung des Photosensitive Epilepsy Analysis Tool (PEAT): PEAT ist ein kostenloses Tool, das vom Trace Research and Development Center entwickelt wurde und speziell dafür ausgelegt ist, Videoinhalte gemäß der Harding-Spezifikation auf Blitzgefahren zu analysieren. Nehmen Sie eine Bildschirmaufnahme der betreffenden Webseite oder Animation in voller Auflösung auf und importieren Sie die Videodatei dann in PEAT. Das Tool meldet, ob eine Sequenz den allgemeinen Blitzschwellenwert oder den Rotblitz-Schwellenwert überschreitet und zu welchen Zeitstempeln.
- Anwendung des Harding Flash and Pattern Analyzer für Inhalte in Rundfunkqualität: Für Videoinhalte, die aus Produktions-Workflows eingebettet werden (z. B. Websites von Rundfunkanstalten, Nachrichtenorganisationen), sollten Quellvideodateien vor der Veröffentlichung durch den HFPA laufen. Dies ist das Goldstandard-Werkzeug für die Vorabprüfung.
- Manuelle Beobachtung — die Drei-Blitze-Zählung: Für CSS-Animationen, JavaScript-Effekte oder GIF-Dateien, bei denen eine werkzeugbasierte Analyse unpraktisch ist, spielen Sie die Animation ab und versuchen Sie, die Anzahl vollständiger Hell-Dunkel-Hell-Zyklen innerhalb einer Sekunde zu zählen. Wenn Sie drei oder mehr vollständige Zyklen pro Sekunde beobachten, sind die Inhalte wahrscheinlich nicht konform. Verwenden Sie Bildschirmaufzeichnungssoftware mit Frame-für-Frame-Wiedergabe, um diese Zählung zu unterstützen.
- Videoinhalte Frame für Frame prüfen: Öffnen Sie Videodateien in einem Videoeditor (z. B. DaVinci Resolve, kostenlose Version), der Wellenform- oder Histogrammdaten auf Frame-Ebene anzeigt. Scrubben Sie durch Abschnitte mit schnellen visuellen Änderungen und prüfen Sie auf abwechselnde Muster hoher und niedriger Leuchtdichte, die mehr als dreimal pro Sekunde auftreten. Achten Sie besonders auf Sequenzen mit gesättigtem Rot vor dunklem Hintergrund.
- Mit Browser-Entwicklertools für CSS-Animationen testen: Öffnen Sie in den Chrome DevTools das Animations-Panel (More Tools → Animations). Untersuchen Sie deklarierte Animationsdauern und Iterationszyklen. Eine Animation mit einer Dauer von weniger als 333 Millisekunden, die bei jeder Iteration zwischen kontrastreichen Zuständen wechselt, überschreitet die 3-Hz-Schwelle. Berechnung: Wenn ein vollständiger Hell-Dunkel-Hell-Zyklus in weniger als 333 ms abgeschlossen ist, sind die Inhalte nicht konform.
- Räumliche Fläche bei Grenzfällen beurteilen: Wenn Inhalte mit einer Frequenz von mehr als 3 Hz blitzen, aber auf dem Bildschirm sehr klein erscheinen, messen Sie ihre Pixelabmessungen. Bei einem 1.024 Pixel breiten Display in normaler Betrachtungsentfernung (ungefähr 57–60 cm) liegt der sichere Flächenschwellenwert bei etwa 21.824 Quadratpixeln. Multiplizieren Sie die Breite und Höhe des blitzenden Bereichs; wenn das Ergebnis unter diesem Schwellenwert liegt, kann der Inhalt unter die sichere Flächenausnahme fallen — dokumentieren Sie diese Bewertung jedoch sorgfältig.
- Automatisch abspielende Videos beim Laden der Seite testen: Nehmen Sie nach dem Laden der Seite keine Interaktion vor und beobachten Sie, ob ein Video oder eine Animation automatisch zu spielen beginnt. Wenn dies der Fall ist, wenden Sie die oben genannten Tests sofort auf die automatisch abspielenden Inhalte an, da der Nutzer keine Möglichkeit hat, einzugreifen, bevor er exponiert wird.
Wie man es behebt
Automatisch abspielendes GIF mit schnellem Blitzen — Falsch
<!-- 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'>
Automatisch abspielendes GIF mit schnellem Blitzen — Richtig
<!-- 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>
CSS-Keyframe-Animation mit Blitzen zwischen kontrastreichen Farben — Falsch
<!-- 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>
CSS-Keyframe-Animation mit Blitzen zwischen kontrastreichen Farben — Richtig
<!-- 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>
Eingebettetes automatisch abspielendes Video mit Blitzsequenzen — Falsch
<!-- 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>
Eingebettetes automatisch abspielendes Video mit Blitzsequenzen — Richtig
<!-- 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>
Häufige Fehler
- Davon ausgehen, dass GIF-Dateien standardmäßig sicher sind: Viele Entwickler glauben, dass animierte GIFs aufgrund ihres Legacy-Formats von Natur aus harmlos sind. In Wirklichkeit können GIFs mit einer Bildfrequenz wechseln, die 3 Hz überschreitet, und das Format setzt der Bildfrequenz keine technischen Grenzen. Jedes GIF mit abwechselnden kontrastreichen Frames muss zeitlich gemessen und bewertet werden.
- Übersehen von Werbeskripten Dritter: Display-Werbenetzwerke liefern häufig kreative Einheiten aus, die blitzende oder blinkende Animationen enthalten. Publisher, die Ad-Tags einbetten, ohne die kreativen Inhalte zu prüfen, sind weiterhin für alle WCAG-2.3.1-Verstöße verantwortlich, die diese Anzeigen auf ihren Seiten verursachen. Implementieren Sie Richtlinien zur Überprüfung von Werbemitteln und vertragliche Anforderungen mit Werbenetzwerken.
- WCAG 2.3.1 mit WCAG 2.2.2 (Pause, Stop, Ausblenden) verwechseln: Einige Teams beheben das Symptom, indem sie eine Pausentaste hinzufügen (was 2.2.2 erfüllt), gehen aber nicht auf die zugrunde liegende Blitzfrequenz ein (die 2.3.1 verletzt). Die beiden Kriterien sind unabhängig: Ein Pausen-Steuerelement macht Inhalte, die bereits zu blitzen begonnen haben, nicht nachträglich konform mit 2.3.1, da der Nutzer exponiert wird, bevor er interagieren kann.
- Den Rotblitz-Schwellenwert nicht gesondert berücksichtigen: Entwickler, die sich des allgemeinen 3-Hz-Schwellenwerts bewusst sind, übersehen manchmal den separaten Rotblitz-Schwellenwert. Inhalte mit schnell wechselnden gesättigten Rotwerten können bei einigen Personen auch bei Frequenzen knapp unter 3 Hz fotosensitive Anfälle auslösen. Gesättigte Rot-Animationen sollten mit besonderer Sorgfalt überprüft werden.
- Ignorieren von Inhalten, die in iframes geladen werden: Seiten, die Inhalte von Drittanbietern über
<iframe>-Elemente einbetten — einschließlich Social-Media-Widgets, Live-Chat-Tools oder eingebetteter Dashboards — sind für die Barrierefreiheit dieser Inhalte verantwortlich, so wie sie auf ihrer Seite gerendert werden. Blitzgefahren innerhalb eines iframes sind genauso gefährlich wie im Hauptdokument. - Die Implementierung der Media Query
prefers-reduced-motionüberspringen: Selbst wenn Basisanimationen unterhalb der 3-Hz-Schwelle liegen, bedeutet das Versäumnis,@media (prefers-reduced-motion: reduce)zu implementieren, dass Nutzer, die auf Betriebssystemebene eine Präferenz für reduzierte Bewegung signalisiert haben, keine Anpassung erhalten. Auch wenn dies primär durch WCAG 2.3.3 auf AAA-Niveau adressiert wird, ist die Einbindung der Media Query eine kostengünstige, wirkungsstarke Praxis, die Engagement für Barrierefreiheit zeigt und das Risiko reduziert. - Verwendung von JavaScript
setIntervaloderrequestAnimationFrameohne Ratenbegrenzung: Animationen, die durchsetInterval(fn, 50)gesteuert werden, werden alle 50 Millisekunden ausgelöst und erzeugen 20 Zyklen pro Sekunde — weit über der 3-Hz-Grenze. Entwickler müssen das Intervall explizit so berechnen, dass es bei höchstens einer Änderung pro 333 ms für jede Leuchtdichte-verändernde Animation bleibt. - Videoinhalte vor der Veröffentlichung nicht prüfen: Viele Organisationen haben einen Veröffentlichungs-Workflow, der visuelle QS und Urheberrechtsprüfung umfasst, aber keinen Schritt zur Prüfung von Blitzgefahren. Ohne die Integration von PEAT oder HFPA in die Vorveröffentlichungs-Pipeline können fotosensitive Gefahren in Videoinhalten unentdeckt bleiben, bis sie Schaden verursachen.
- Die Größen-Ausnahme als leicht ausnutzbar betrachten: Einige Entwickler erfahren von der 0,006-Steradiant-Sicherheitsausnahme und versuchen, sie zu nutzen, um gefährliche Blitzeffekte durch Verkleinerung zu rechtfertigen. In der Praxis erfordert die genaue Berechnung, ob Inhalte unter den Schwellenwert fallen, Kenntnisse über die Betrachtungsentfernung und die Displayauflösung des Nutzers — Variablen, die der Entwickler nicht kontrollieren kann. Sich ohne photometrische Messung auf die Größen-Ausnahme zu verlassen, ist riskant und rechtlich heikel.
- Blitzgefahren-Bewertungen nicht dokumentieren: Organisationen, die Video- oder Animationsinhalte auf Blitzgefahren testen, versäumen es häufig, Aufzeichnungen über diese Bewertungen aufzubewahren. Im Falle einer Nutzerbeschwerde oder einer behördlichen Prüfung ist dokumentierter Nachweis, dass PEAT- oder HFPA-Screenings durchgeführt wurden und die Inhalte als konform befunden wurden, entscheidend, um Sorgfalt nachzuweisen.
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 Anforderungen an die Barrierefreiheit von Web- und Mobilangeboten fest, die sich an WCAG 2.2 orientieren. WCAG 2.3.1 fällt als Erfolgskriterium der Stufe A in den Geltungsbereich der verbindlichen Einhaltung für alle erfassten Einrichtungen.
Die Verfügung definiert einen gestaffelten Zeitplan für die Einhaltung: öffentliche Institutionen und Behörden müssen innerhalb eines Jahres nach Inkrafttreten der Verfügung vollständige Konformität auf Stufe A erreichen, während private Sektorunternehmen, die von der Regelung erfasst sind, zwei Jahre Zeit für die Einhaltung haben. Angesichts der sicherheitskritischen Natur von WCAG 2.3.1 — das sich direkt auf das Risiko bezieht, bei Nutzern medizinische Notfälle auszulösen — birgt die Nichteinhaltung dieses speziellen Kriteriums ein erhöhtes Reputations- und Rechtsrisiko, selbst im Vergleich zu anderen Anforderungen der Stufe A.
Die folgenden Einrichtungstypen sind in der Präsidialverfügung 2025/10 ausdrücklich genannt und müssen daher WCAG 2.3.1 einhalten:
- Öffentliche Institutionen und Regierungsbehörden: Alle zentralen und lokalen Regierungsstellen, Ministerien, Gemeinden und staatsnahe Organisationen, die öffentlich zugängliche Websites oder mobile Anwendungen betreiben.
- E-Commerce-Plattformen: Online-Einzelhändler und Marktplatzbetreiber, die Verbrauchern über digitale Plattformen Waren oder Dienstleistungen anbieten, unabhängig vom Sektor.
- Banken und Finanzinstitute: Alle lizenzierten Banken, Beteiligungsbanken, Investmentfirmen und Fintech-Anbieter, die digitale Bank- oder Finanzdienstleistungen bereitstellen.
- Krankenhäuser und Gesundheitsdienstleister: Öffentliche und private Krankenhäuser, Polikliniken und Gesundheitsnetzwerke, die patientenorientierte digitale Dienste wie Terminbuchung und Patientenportale anbieten.
- Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten: Große Mobilfunknetzbetreiber und Internetdienstanbieter, die den Abonnentenschwellenwert erreichen, einschließlich ihrer Self-Service-Portale und mobilen Anwendungen.
- Reisebüros: Lizensierte Reise- und Tourismusagenturen, die Online-Buchungs-, Reservierungs- oder Informationsdienste anbieten.
- Private Transportunternehmen: Fluggesellschaften, Fernbusunternehmen, Fährbetreiber und andere private Transportanbieter mit verbraucherorientierten digitalen Plattformen.
- Private Schulen, die vom Bildungsministerium (MoNE) zugelassen sind: Private Bildungseinrichtungen mit MoNE-Zulassung, die Websites oder digitale Lernplattformen betreiben.
Für erfasste Einrichtungen erfordert die Einhaltung von WCAG 2.3.1 nicht nur ein einmaliges Audit, sondern ein fortlaufendes betriebliches Engagement. Da Blitzgefahren am häufigsten durch dynamische Inhalte eingeführt werden — Video-Uploads, Marketing-Animationen, Werbung von Drittanbietern — müssen Organisationen die Prüfung von Blitzgefahren in ihre Workflows zur Veröffentlichung von Inhalten einbetten, nicht nur in ihr anfängliches Site-Audit. Der Einsatz von Tools wie PEAT für die Vorabprüfung von Videoinhalten, kombiniert mit Entwickler-Schulungen zu sicheren Animationsfrequenzen und zur Implementierung von CSS-prefers-reduced-motion, stellt den Mindeststandard an betrieblicher Sorgfalt dar, der von erfassten Einrichtungen gemäß der Verfügung erwartet wird. Organisationen, die sich auf Content-Management- oder Werbesysteme von Drittanbietern stützen, müssen außerdem vertragliche Bestimmungen sicherstellen, die die Einhaltung von WCAG 2.3.1 durch ihre Lieferanten verlangen, da die regulatorische Verpflichtung bei der Einrichtung liegt, die den öffentlich zugänglichen digitalen Dienst betreibt.
