Barrierefreie Animation: der WCAG-Leitfaden
Barrierefreie Animation ist Bewegung, die Bedeutung schafft, ohne jemanden auszuschließen — sie lässt sich pausieren, sie löst keinen Anfall aus, und sie tritt für Menschen zurück, die an ihrem Gerät weniger Bewegung eingestellt haben. Das Thema heißt auch Animation und Barrierefreiheit, und die meisten Anleitungen dazu stammen aus der Zeit vor WCAG 2.2 und enden bei einem einzigen reduced-motion-Schnipsel. Dieser Leitfaden ist auf dem Stand von 2026 und arbeitet so, wie ein Audit arbeitet: Kriterium für Kriterium. Drei Erfolgskriterien regeln Web-Bewegung; unten steht, was jedes verlangt, das Muster, das es erfüllt, und Code zum Kopieren, der besteht.
Warum Animation ein Thema der Barrierefreiheit ist
Bewegung ist nicht neutral. Für Menschen mit vestibulären Störungen können große Parallax-Effekte, zoomende Übergänge und rotierende Elemente echten Schwindel, Übelkeit und Migräne auslösen. Blinkende Inhalte können photosensitive Anfälle provozieren. Dauerhafte, automatisch startende Bewegung zieht die Aufmerksamkeit von allen ab, die mit einer Aufmerksamkeits- oder kognitiven Besonderheit den Text darunter lesen wollen. Nichts davon sind Randfälle; jedes betrifft einen realen Teil jedes Publikums. Die Web-Plattform liefert die Signale und die Bedienelemente für alle drei — die Aufgabe ist, sie bewusst einzusetzen, statt zu hoffen, dass eine Komponenten-Bibliothek es getan hat.
Die drei WCAG-Kriterien für Bewegung
Barrierefreiheits-Richtlinien für Animation sind kein vages „sei rücksichtsvoll". Sie lösen sich in drei konkrete, prüfbare Erfolgskriterien in WCAG 2.2 auf. Erfüllt man diese, ist der Rest barrierefreier Animation Feinschliff:
- 2.2.2 Pausieren, Stoppen, Ausblenden (Stufe A) — automatisch startende Bewegung, die länger als fünf Sekunden läuft, braucht ein Bedienelement zum Pausieren, Stoppen oder Ausblenden.
- 2.3.1 Drei Blitze oder darunter (Stufe A) — nichts darf mehr als dreimal in einer Sekunde blitzen.
- 2.3.3 Animation durch Interaktionen (Stufe AAA) — durch eine Nutzeraktion ausgelöste Bewegung muss sich abschalten lassen, außer sie ist essenziell.
Die beiden Stufe-A-Kriterien sind die Grundlinie, auf die fast jede Barrierefreiheits-Vorgabe zeigt; 2.3.3 ist AAA, aber mit einer einzigen Media Query leicht zu erfüllen und der Ort, an dem das bekannte prefers-reduced-motion-Muster wohnt. Eins nach dem anderen.
WCAG 2.2.2 — Pausieren, Stoppen, Ausblenden
Wenn Bewegung von selbst startet, länger als fünf Sekunden läuft und neben anderem Inhalt steht, muss die Person sie stoppen können. Karussells, automatisch scrollende Ticker, animierte Hintergründe und laufende Hero-Videos sind die üblichen Fälle. Eine Animation von höchstens fünf Sekunden, die einmal abläuft, ist in Ordnung; eine Schleife nicht, denn eine Schleife endet nie von selbst.
Der Mechanismus kann so klein sein wie ein Button, der animation-play-state umschaltet. Steuere ihn über ein data-Attribut, damit Bedienelement und CSS synchron bleiben:
<div class="ticker" data-playing="true">…</div>
<button type="button" class="ticker-toggle" aria-pressed="true">Pause</button>
.ticker[data-playing="false"] { animation-play-state: paused; }
const ticker = document.querySelector('.ticker');
const toggle = document.querySelector('.ticker-toggle');
toggle.addEventListener('click', () => {
const playing = ticker.dataset.playing === 'true';
ticker.dataset.playing = String(!playing); // schaltet das CSS um
toggle.setAttribute('aria-pressed', String(!playing));
toggle.textContent = playing ? 'Play' : 'Pause';
});
Der aria-pressed-Zustand macht das Bedienelement für assistive Technik lesbar — ein bloßes Icon ohne angesagten Zustand ist nur ein halber Fix. Und der ruhigste Weg, 2.2.2 zu erfüllen, ist oft, gar nicht automatisch zu starten: den Ticker pausiert beginnen lassen und die Person selbst starten lassen.
WCAG 2.3.1 — Drei Blitze oder darunter
Dieses Kriterium schützt vor photosensitiven Anfällen und ist das am wenigsten verhandelbare im Set: nichts auf der Seite darf mehr als dreimal in einem Ein-Sekunden-Fenster blitzen (außer die blitzende Fläche liegt unter den allgemeinen und den Rot-Schwellenwerten). Schnell strobende Farbwechsel, ein hartes Flackern zwischen kontrastreichen Frames oder ein stotterndes GIF können die Grenze überschreiten.
Es gibt kein cleveres CSS, das schnelles Blitzen sicher macht — der Fix ist, es nicht zu tun. In der Praxis heißt das: jedes wiederholte Blitzen auf höchstens dreimal pro Sekunde begrenzen, große Flächen mit gesättigtem Rot in schnellen Übergängen vermeiden und eine weiche Überblendung einem harten Schnitt vorziehen, wenn etwas den Blick fangen muss. Bei geerbten Inhalten, bei denen man unsicher ist, analysieren Werkzeuge wie das Photosensitive Epilepsy Analysis Tool (PEAT) eine Aufnahme Bild für Bild. Im Zweifel: langsamer machen; ein sanfter Übergang wirkt ohnehin hochwertiger.
WCAG 2.3.3 — Animation durch Interaktionen
Durch eine Nutzeraktion ausgelöste Bewegung — ein scroll-getriggertes Einblenden, ein Hover, der zoomt, eine Parallax-Ebene, die sich beim Scrollen verschiebt — muss sich abschalten lassen, außer sie vermittelt essenzielle Information. Der Schalter dafür ist das plattformeigene Signal: prefers-reduced-motion. Baue die Interaktions-Bewegung als Opt-in, sodass „reduziert" der Standard ist und du Bewegung nur hinzufügst, wenn die Person nicht dagegen entschieden hat:
/* Standard: das Element ist einfach da, keine Bewegung. */
.reveal { opacity: 1; }
/* Bewegung nur, wenn sie willkommen ist. */
@media (prefers-reduced-motion: no-preference) {
.reveal { animation: rise 0.5s ease-out both; }
}
JavaScript-getriebene Bewegung muss dieselbe Einstellung selbst prüfen — eine GSAP-Timeline oder eine Scroll-Bibliothek liest deine CSS-Media-Query nicht. Sichere sie mit matchMedia ab und reagiere auf Live-Änderungen:
const reduce = window.matchMedia('(prefers-reduced-motion: reduce)');
function setupMotion() {
if (reduce.matches) return; // Einstellung respektieren: Effekt auslassen
// …hier die Scroll-/Hover-Animation starten…
}
setupMotion();
reduce.addEventListener('change', setupMotion);
Das ist für die meisten Seiten das ganze 2.3.3. Die vollständigen Muster — das pauschale Opt-out, die Fallstricke je Bibliothek und die Wege, die Wirkung des Guards zu bestätigen — stehen im ausführlichen englischen Leitfaden prefers-reduced-motion, explained.
Über den Buchstaben hinaus: essenziell vs. dekorativ, und Performance
Die drei Kriterien zu erfüllen ist der Boden, nicht die Decke. Zwei Ermessensfragen entscheiden, ob Animation wirklich barrierefrei ist:
- Essenziell vs. dekorativ. „Reduzieren" heißt weniger Bewegung, keine eingefrorene Seite. Ein dekoratives Einschieben sollte unter reduced-motion verschwinden; eine Fortschrittsanzeige oder ein Übergang, der zeigt, was sich gerade geändert hat, trägt Bedeutung und darf bleiben, wenn er wirklich essenziell ist. Wenn du Bewegung entfernst, ersetze große Bewegung durch eine sanfte
opacity-Überblendung, statt jedes Feedback zu streichen — eine Zustandsänderung, die niemand wahrnimmt, ist selbst eine Barriere. - Performance ist Barrierefreiheit. Animation, die Frames verliert oder das Layout verschiebt, ist eine Barriere für Menschen auf schwachen Geräten und für alle mit Bewegungsempfindlichkeit, die Ruckeln als Unwohlsein spüren. Animiere nur
transformundopacity(die compositor-freundlichen Eigenschaften), niemalswidth,topoderbox-shadowin einer Schleife. Weiche, günstige Bewegung ist freundlichere Bewegung.
Checkliste für barrierefreie Animation
- Automatisch startende Bewegung über fünf Sekunden hat ein sichtbares Pause-/Stopp-Element mit angesagtem Zustand (2.2.2).
- Nichts blitzt mehr als dreimal pro Sekunde (2.3.1).
- Interaktions-Bewegung ist in beiden Schichten — CSS und JS — durch
prefers-reduced-motionabgesichert (2.3.3). - Reduced-motion fällt auf eine ruhige Überblendung zurück, nicht auf eine tote Seite; essenzielle Bewegung ist eine bewusste Ausnahme.
- Animationen bewegen nur
transform/opacityund halten eine stabile Bildrate. - Du hast es getestet — mit eingeschalteter Systemeinstellung, nicht nur im Code.
Wie man eine Seite prüft
Eine Checkliste ist nur so gut wie das Audit dahinter. Schalte zum Prüfen von 2.3.3 die Einstellung ein (macOS: Systemeinstellungen → Bedienungshilfen → Anzeige → Bewegung reduzieren; Windows: Einstellungen → Barrierefreiheit → Visuelle Effekte → Animationseffekte aus) und sieh, was sich noch bewegt. Um das gesamte CSS einer Seite in einem Durchgang zu scannen, füge die URL in den kostenlosen Motion-Accessibility-Check ein: er liest statisch das verlinkte CSS und die <style>-Blöcke gegen WCAG 2.2.2 und 2.3.3, löst auf, ob jede Animation tatsächlich abgesichert ist, und gibt jeden Befund mit dem Fix zurück — keine Anmeldung, nichts wird gespeichert. Er ist ehrlich über seinen Umfang: Laufzeit-Bewegung per JS/GSAP wird als nicht geprüft ausgewiesen, nicht stillschweigend durchgewinkt — kombiniere den Scan also mit dem Systemeinstellungs-Test.
Die dauerhafte Antwort ist, sich nicht mehr darauf zu verlassen, dass jede Entwicklerin und jeder generierte Schnipsel an den Guard denkt, sondern es strukturell zu machen — die Schicht, die MotionSpec baut: Animation, zusammengesetzt aus einem geprüften Katalog von Primitiven, die jeweils per Konstruktion einen prefers-reduced-motion-Fallback und ein Performance-Budget mitbringen, sodass unzugängliche Bewegung gar nicht erst entstehen kann.
Füge eine beliebige URL in den kostenlosen Motion-Accessibility-Check ein und sieh, welche Animationen 2.2.2 und 2.3.3 bestehen — jeder Befund mit dem Fix.
Kostenlosen Motion-Check starten