Was prüft ein WCAG-Test bei Animationen und bewegten Inhalten?

Ein WCAG-Test prüft bei Animationen und bewegten Inhalten, ob diese für Menschen mit bestimmten Behinderungen wahrnehmbar, bedienbar und sicher sind. Konkret geht es darum, ob Inhalte Anfälle auslösen können, ob Nutzer Bewegungen pausieren oder stoppen können und ob Animationen die Wahrnehmung oder Bedienung beeinträchtigen. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um WCAG-Kriterien für Animationen, Flackern, Parallax-Effekte und barrierefreie Umsetzung.

Welche WCAG-Kriterien gelten speziell für Animationen?

Für Animationen und bewegte Inhalte sind in den Web Content Accessibility Guidelines (WCAG) vor allem drei Erfolgskriterien relevant: 2.2.2 (Pausieren, Stoppen, Ausblenden), 2.3.1 (Grenzwert von dreimaligem Aufblitzen) und 2.3.3 (Animation durch Interaktion). Diese Kriterien decken unterschiedliche Risiken ab und gelten für Konformitätslevel A beziehungsweise AAA.

Die Kriterien lassen sich thematisch gruppieren:

• Bewegung und Ablenkung (2.2.2): Automatisch startende, bewegte oder scrollende Inhalte, die länger als fünf Sekunden andauern, müssen pausierbar oder stoppbar sein.
• Anfallsauslösende Effekte (2.3.1 und 2.3.2): Inhalte dürfen keine Blitzeffekte erzeugen, die Krampfanfälle auslösen können. Kriterium 2.3.1 ist Level A, Kriterium 2.3.2 verschärft die Anforderungen auf Level AAA.
• Vestibulär bedingte Beschwerden (2.3.3): Animationen, die durch Interaktion ausgelöst werden, müssen abschaltbar sein, sofern sie nicht funktional notwendig sind. Dieses Kriterium gilt für Level AAA.

Zusätzlich spielen Kriterien zur Tastatursteuerung (2.1.x) eine Rolle, wenn Animationen über die Tastatur ausgelöst oder gesteuert werden sollen. Wer eine Website auf Barrierefreiheit prüfen möchte, sollte diese Kriterien systematisch durchgehen, da sie unterschiedliche Nutzergruppen schützen.

Was versteht die WCAG unter „bewegten Inhalten“?

Die WCAG definiert „bewegte Inhalte“ als alle Elemente auf einer Webseite, die sich automatisch bewegen, blinken, scrollen oder aktualisieren und dabei die Aufmerksamkeit des Nutzers beanspruchen. Dazu zählen unter anderem Karussells, Ticker, animierte Banner, Ladeanimationen, automatisch abspielende Videos und scrollende Textbereiche.

Entscheidend für die WCAG-Bewertung sind zwei Merkmale: Ob der Inhalt automatisch startet und ob er länger als fünf Sekunden andauert. Nur wenn beide Bedingungen zutreffen, greift Erfolgskriterium 2.2.2. Kurze, einmalige Animationen, die weniger als fünf Sekunden dauern, fallen damit nicht unter diese Anforderung.

Nicht gemeint sind rein dekorative Animationen, die keinerlei Information transportieren und keine Ablenkung erzeugen, sowie Animationen, die der Nutzer selbst ausgelöst hat und die er unmittelbar kontrolliert. Die Abgrenzung ist in der Praxis nicht immer eindeutig: Ein animiertes Hintergrundbild, das subtil scrollt, kann für Menschen mit vestibulären Störungen dennoch problematisch sein, auch wenn es technisch unter den Schwellenwert fällt.

Wie werden Flackern und Blitzen bei einem WCAG-Test gemessen?

Beim WCAG-Test wird Flackern anhand der Blitzfrequenz und der betroffenen Bildschirmfläche gemessen. Erfolgskriterium 2.3.1 (Level A) besagt, dass Inhalte nicht mehr als dreimal pro Sekunde aufblitzen dürfen oder die Blitze unterhalb der allgemeinen Blitz- und Rotblitz-Grenzwerte liegen müssen. Für die Messung werden spezifische Schwellenwerte aus dem Bereich der Photosensibilitätsforschung herangezogen.

Die technische Messung erfolgt über spezialisierte Werkzeuge, die Videosequenzen oder animierte Inhalte frameweise analysieren. Das bekannteste frei verfügbare Tool für diesen Zweck ist das Photosensitive Epilepsy Analysis Tool (PEAT) des Trace Research and Development Center. Es bewertet, ob ein Inhalt das Risiko eines photosensitiven Anfalls erzeugt.

Für automatisierte WCAG-Tests über Bibliotheken wie axe-core ist die Blitzmessung nur eingeschränkt möglich, da sie eine dynamische Analyse des gerenderten Inhalts erfordert. Statische HTML-Analysen können zwar bestimmte CSS-Animationen identifizieren, aber nicht zuverlässig beurteilen, ob die Frequenz den Grenzwert überschreitet. Dieser Bereich gehört daher zu jenen, die einen manuellen Test erfordern, um eine belastbare Aussage zu erhalten.

Welche Anforderungen stellt die WCAG an Pause- und Stopp-Funktionen?

Die WCAG verlangt gemäß Erfolgskriterium 2.2.2, dass Nutzer automatisch startende, bewegte oder scrollende Inhalte pausieren, stoppen oder ausblenden können, wenn diese länger als fünf Sekunden andauern und parallel zu anderen Inhalten angezeigt werden. Die Steuerungsmöglichkeit muss für alle Nutzer zugänglich sein, also auch über die Tastatur erreichbar.

Konkret bedeutet das für die Umsetzung:

• Karussells und Slider: Müssen eine sichtbare Pause-Schaltfläche haben, die auch per Tastatur erreichbar ist. Ein reines Anhalten beim Hover-Effekt reicht nicht aus, da Tastaturnutzer diese Interaktion nicht auslösen können.
• Scrollende Ticker: Benötigen ebenfalls eine Stopp-Funktion. Alternativ kann der Inhalt als statische Liste angeboten werden.
• Automatisch abspielende Videos: Müssen pausierbar sein. Zusätzlich gilt, dass Videos mit Ton, die automatisch starten, eine Möglichkeit zum Stummschalten benötigen.
• Animierte GIFs: Sind schwieriger zu kontrollieren, da sie kein natives Pause-Interface bieten. Eine barrierefreie Alternative ist der Einsatz von Video-Elementen mit entsprechenden Steuerelementen oder JavaScript-Lösungen.

Die Anforderung gilt nicht für Animationen, die für den Betrieb oder die Aktivität wesentlich sind, zum Beispiel ein Ladebalken, der den Fortschritt eines Vorgangs anzeigt.

Was prüft ein WCAG-Test bei Parallax-Effekten und CSS-Animationen?

Bei Parallax-Effekten und CSS-Animationen prüft ein WCAG-Test vor allem, ob diese Bewegungseffekte für Menschen mit vestibulären Störungen abschaltbar sind und ob sie die Tastatur- oder Screenreader-Bedienung beeinträchtigen. Parallax-Scrolling ist ein häufig übersehenes Barrierefreiheitsproblem, da es bei manchen Nutzern Schwindel, Übelkeit oder Desorientierung auslösen kann.

Für CSS-Animationen und Parallax-Effekte sind folgende Prüfpunkte relevant:

• Respektierung der Systemeinstellung „prefers-reduced-motion“: Moderne Betriebssysteme bieten Nutzern die Möglichkeit, Bewegungseffekte zu reduzieren. WCAG 2.3.3 (Level AAA) fordert, dass Websites diese Einstellung über die CSS-Media-Query prefers-reduced-motion auswerten und Animationen entsprechend deaktivieren oder vereinfachen.
• Funktionalität ohne Animation: Inhalte müssen auch ohne die Animation verständlich und bedienbar sein. Ein Menü, das nur durch eine Einflug-Animation sichtbar wird, muss ohne diese Animation zugänglich bleiben.
• Fokus und Lesbarkeit: Bewegte Hintergründe können den Tastaturfokus schwer erkennbar machen. Automatisierte Tests prüfen unter anderem, ob Fokusindikatoren ausreichend kontrastreich sind.

Automatisierte Tests können erkennen, ob CSS-Animationen vorhanden sind und ob die prefers-reduced-motion-Media-Query implementiert wurde. Ob die Umsetzung inhaltlich korrekt ist, also ob die reduzierte Variante tatsächlich eine sinnvolle Alternative bietet, erfordert hingegen eine manuelle Prüfung. Das ist ein typisches Beispiel dafür, warum ein Barrierefreiheits-Test-Tool immer in Kombination mit manuellen Prüfschritten eingesetzt werden sollte.

Wie lassen sich Animationen WCAG-konform umsetzen?

Animationen lassen sich WCAG-konform umsetzen, indem Bewegungseffekte gezielt eingesetzt, nutzerkontrollierbar gestaltet und systemseitige Präferenzen berücksichtigt werden. Der wichtigste Grundsatz lautet: Keine Animation sollte zwingend erforderlich sein, um Inhalte zu verstehen oder Funktionen zu nutzen.

Die folgenden Maßnahmen bilden die Grundlage für barrierefreie Animationen:

1. prefers-reduced-motion implementieren: Setzen Sie die CSS-Media-Query @media (prefers-reduced-motion: reduce) ein, um Animationen für Nutzer zu deaktivieren, die dies systemseitig eingestellt haben. Dies ist eine der wirkungsvollsten Maßnahmen mit vergleichsweise geringem Implementierungsaufwand.
2. Pause- und Stopp-Steuerelemente anbieten: Jede automatisch startende Animation, die länger als fünf Sekunden dauert, benötigt eine sichtbare und per Tastatur erreichbare Stopp-Funktion.
3. Blitzfrequenz unter dem Grenzwert halten: Vermeiden Sie Effekte, die mehr als dreimal pro Sekunde aufblitzen. Testen Sie kritische Animationen mit einem spezialisierten Analyse-Tool.
4. Animationen auf das Wesentliche beschränken: Setzen Sie Bewegung nur ein, wenn sie einen klaren Mehrwert für die Nutzererfahrung bietet, zum Beispiel zur Orientierung bei Seitenübergängen. Rein dekorative Animationen sollten minimal gehalten werden.
5. Fokusmanagement sicherstellen: Animationen dürfen den Tastaturfokus nicht verschieben oder unsichtbar machen. Testen Sie die Tastaturnavigation mit und ohne aktive Animationen.
6. Alternative Inhalte bereitstellen: Wenn eine Animation Information transportiert, muss diese Information auch ohne Animation zugänglich sein, zum Beispiel als Text oder statisches Bild.

Für Agenturen und Entwicklungsteams empfiehlt sich eine Checkliste, die bereits im Designprozess ansetzt. Viele Barrierefreiheitsprobleme bei Animationen entstehen, weil Bewegungseffekte nachträglich hinzugefügt werden, ohne die Auswirkungen auf unterschiedliche Nutzergruppen zu berücksichtigen.

Wie unterstützt decareto bei der Prüfung von Animationen und Barrierefreiheit?

Wir bei decareto bieten eine automatisierte Accessibility-Software, die Websites systematisch auf Barrierefreiheitsprobleme scannt und dabei auch Aspekte rund um bewegte Inhalte und Animationen identifiziert. Unser Tool basiert auf der Open-Source-Bibliothek axe-core und orientiert sich an den aktuellen WCAG-Standards.

Konkret unterstützen wir Sie bei der Prüfung von Animationen und Barrierefreiheit durch folgende Funktionen:

• Automatisierter Scan auf technisch erkennbare Probleme wie fehlende Pause-Steuerelemente, Kontrastverstöße bei animierten Elementen und fehlende Implementierung von Barrierefreiheitsattributen
• Priorisierung nach Schweregrad, damit Sie wissen, welche Animationsprobleme kritisch sind und welche nachrangig behoben werden können
• Konkrete Handlungsempfehlungen zu jedem gefundenen Problem, verständlich für Entwickler und Berater
• Manuelle Erfassung von Problemen, die automatisiert nicht erkennbar sind, zum Beispiel ob eine reduzierte Animationsvariante inhaltlich sinnvoll ist
• Dauerhaftes Monitoring von Hunderten Websites mit automatischen Benachrichtigungen bei Änderungen
• Teilen von Reports direkt mit Kunden, optional unter eigenem Logo per Whitelabel-Funktion

Bitte beachten Sie: Ein gutes Ergebnis im decareto-Scan ist eine wichtige Grundlage, ersetzt aber keine vollständige manuelle Prüfung. Automatisierte Tests decken typischerweise einen Teil der möglichen Barrierefreiheitsprobleme ab. Für eine umfassende Bewertung empfehlen wir, automatisierte und manuelle Tests zu kombinieren.

Möchten Sie Ihre Website auf Animationsbarrieren und weitere Barrierefreiheitsprobleme prüfen? Jetzt kostenlos testen und in wenigen Minuten einen strukturierten Accessibility-Report erhalten.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Wie laufen Crawling, Analyse und Reporting bei einem DSGVO-Website-Scan technisch ab?
• Welche Barrierefreiheitsprobleme entstehen durch schlecht eingebettete Schriften?
• Gibt mein Zahlungsanbieter (z. B. PayPal, Stripe) unzulässig Daten an Dritte weiter?
• Welche Datenschutzlücken entstehen durch veraltete Blog-Beiträge mit alten Tracking-Skripten?
• Was prüft ein Web Accessibility Check bei der Fokusführung?