CSS · Barrierefreiheit · WCAG · Animationen
CSS prefers-reduced-motion
Animationen barrierefrei und WCAG-konform

Für Menschen mit vestibulären Störungen, Migräne oder Epilepsie können exzessive Animationen auf Webseiten physische Beschwerden auslösen. Die CSS Media Query prefers-reduced-motion gibt Entwicklern die Möglichkeit, Animationen systemweit zu respektieren – und WCAG 2.2 macht das zur Pflicht. Dieser Artikel erklärt die Hintergründe, die richtigen Implementierungsstrategien und häufige Fehler.

10 Min. Lesezeit prefers-reduced-motion · WCAG 2.2 · CSS Media Query · Animation Alle modernen Browser

1. Warum Animationen Barrierefreiheit betreffen

Barrierefreiheit im Web wird häufig auf Screenreader-Kompatibilität, Farbkontrast und Tastaturbedienbarkeit reduziert. Animationen gelten in vielen Projekten als rein ästhetisches Element, das keine Zugänglichkeitsprobleme verursachen kann. Das ist ein schwerwiegender Irrtum. Für Menschen mit vestibulären Störungen, Migräne, Epilepsie oder anderen neurologischen Erkrankungen können exzessive Bewegungen, parallax-Effekte und schnelle Übergänge auf Webseiten zu Schwindel, Übelkeit, Kopfschmerzen oder sogar Anfällen führen.

Die CSS Media Query prefers-reduced-motion ist die technische Antwort auf dieses Problem. Sie liest die Systemeinstellung des Nutzers aus – auf macOS, Windows, iOS, Android und allen modernen Betriebssystemen können Nutzer in den Bedienungshilfen angeben, dass sie reduzierte Bewegung bevorzugen. Mit prefers-reduced-motion kann CSS auf diese Präferenz reagieren und Animationen entsprechend anpassen oder deaktivieren. Die Unterstützung ist in allen modernen Browsern vollständig – es gibt keine Entschuldigung für das Fehlen dieser Media Query in Projekten mit Animationen.

Die Bedeutung von prefers-reduced-motion geht über individuelle Zugänglichkeit hinaus. In einem Umfeld, in dem Webseiten zunehmend von komplexen Animationen und Scroll-Effekten geprägt sind, ist diese Media Query eine fundamentale Sicherheitsfunktion für betroffene Nutzer. Schätzungen zufolge haben etwa 35% aller Menschen irgendwann im Leben vestibuläre Störungen – die betroffene Gruppe ist also erheblich größer als oft angenommen.

2. Vestibuläre Störungen und Motion Sickness im Web

Das vestibuläre System ist der Teil des Innenohrs, der Gleichgewicht und Raumorientierung steuert. Wenn die visuellen Eindrücke auf dem Bildschirm nicht mit den Signalen des vestibulären Systems übereinstimmen – wie bei parallax-Scrollen, großflächigen Animationen oder schnell wechselnden Inhalten – kann das das Gehirn überlasten und zu Symptomen wie Schwindel, Übelkeit und Desorientierung führen. Dieser Effekt ist als Cybersickness oder Web-Motion-Sickness bekannt.

Besonders problematisch sind großflächige Bewegungen, die nicht durch physische Bewegung des Nutzers ausgelöst wurden: Hintergrundvideos, die beim Scrollen ihre Position ändern, Hero-Sektionen mit parallax-Effekten, seitenweite Übergangsanimationen beim Navigieren und Elemente, die beim Scrollen herein- oder herausschweben. All diese Muster lösen bei betroffenen Nutzern Beschwerden aus. Die prefers-reduced-motion Media Query ist die einzige verlässliche Methode, diese Nutzergruppe zu schützen, ohne auf Animationen für alle anderen zu verzichten.


/* Base: animations enabled for all users */
.hero-background {
  animation: parallax-drift 8s ease-in-out infinite alternate;
}

.slide-in {
  animation: slide-from-left 0.6s cubic-bezier(0.34, 1.56, 0.64, 1) both;
}

@keyframes parallax-drift {
  from { transform: translateY(0) scale(1.05); }
  to   { transform: translateY(-24px) scale(1.05); }
}

@keyframes slide-from-left {
  from { opacity: 0; transform: translateX(-40px); }
  to   { opacity: 1; transform: translateX(0); }
}

/* Reduced motion: disable animations that cause vestibular issues */
@media (prefers-reduced-motion: reduce) {
  /* Large-area motion: remove completely */
  .hero-background {
    animation: none;
  }

  /* Entry animations: keep opacity fade, remove movement */
  .slide-in {
    animation: fade-in 0.3s ease both;
  }

  /* Global fallback: shorten all durations drastically */
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

@keyframes fade-in {
  from { opacity: 0; }
  to   { opacity: 1; }
}

3. Die prefers-reduced-motion Media Query

Die prefers-reduced-motion Media Query hat zwei mögliche Werte: no-preference (Standard, keine spezielle Einstellung des Nutzers) und reduce (Nutzer hat in den Systemeinstellungen angegeben, weniger Bewegung zu bevorzugen). In der Praxis schreibt man den Media Query Block für reduce und legt darin fest, wie Animationen angepasst werden. Es gibt zwei grundlegende Ansätze: Entweder verwendet man prefers-reduced-motion: reduce als Opt-out, indem man Animationen standardmäßig aktiviert und im Media Query deaktiviert, oder man nutzt prefers-reduced-motion: no-preference als Opt-in und aktiviert Animationen nur dann explizit, wenn der Nutzer keine Reduktion wünscht.

Der Opt-in-Ansatz mit no-preference wird von Zugänglichkeitsexperten bevorzugt, weil er sicherstellt, dass Animationen in unbekannten Umgebungen standardmäßig deaktiviert sind. Für bestehende CSS-Codebasen ist der Opt-out-Ansatz praktikabler, da er weniger Umstrukturierung erfordert. In jedem Fall sollte prefers-reduced-motion in jedem Projekt eingesetzt werden, das Animationen, Transitions oder Scroll-Effekte verwendet. Es ist kein optionales Feature, sondern eine grundlegende Zugänglichkeitsverpflichtung.

4. WCAG 2.2 und Animations-Anforderungen

Die Web Content Accessibility Guidelines (WCAG) 2.2 enthalten mehrere Kriterien, die direkt mit Animationen zusammenhängen. Das wichtigste ist Erfolgskriterium 2.3.3 (Animation from Interactions, Level AAA): Bewegungsanimationen, die durch Interaktion ausgelöst werden, können deaktiviert werden, außer die Animation ist für die Funktion oder Weitergabe von Informationen unerlässlich. Auf Level AA greift Kriterium 2.3.1, das Inhalte verbietet, die mehr als dreimal pro Sekunde blinken – was direkt auf Epilepsie-Prävention abzielt.

Auch wenn Kriterium 2.3.3 auf Level AAA angesiedelt ist und damit nicht für die meisten Projekte verpflichtend ist, empfiehlt sich seine Umsetzung dringend. Viele Länder haben Barrierefreiheitsgesetze verabschiedet, die WCAG AA als Mindeststandard vorschreiben, und es ist nur eine Frage der Zeit, bis AAA-Anforderungen für öffentliche Websites ebenfalls verbindlich werden. Die technische Implementierung von prefers-reduced-motion ist außerdem minimal – der Aufwand ist im Verhältnis zur Wirkung gering.


/*
 * Opt-in approach: animations only when the user has NOT
 * requested reduced motion — safest accessibility pattern
 */

/* Base state: no animation */
.scroll-reveal {
  opacity: 0;
  transform: translateY(20px);
}

/* Add animation only for users who prefer motion */
@media (prefers-reduced-motion: no-preference) {
  .scroll-reveal {
    transition: opacity 0.5s ease, transform 0.5s cubic-bezier(0.22, 1, 0.36, 1);
  }

  /* Parallax: only for users who can handle it */
  .parallax-hero {
    animation: subtle-parallax 12s ease-in-out infinite alternate;
  }

  /* Staggered entry: fine for no-preference users */
  .card-grid .card:nth-child(1) { transition-delay: 0.05s; }
  .card-grid .card:nth-child(2) { transition-delay: 0.10s; }
  .card-grid .card:nth-child(3) { transition-delay: 0.15s; }
}

/* Visible state added by Intersection Observer */
.scroll-reveal.is-visible {
  opacity: 1;
  transform: translateY(0);
}

@keyframes subtle-parallax {
  from { background-position: 50% 0%; }
  to   { background-position: 50% 8%; }
}

5. Reduktionsstrategien: Abschalten vs. Alternativen

Nicht alle Animationen sind gleich problematisch. Beim Einsatz von prefers-reduced-motion ist eine differenzierte Strategie besser als das pauschale Abschalten aller Animationen. Großflächige Bewegungsanimationen, Parallax-Effekte und Inhalte, die schnell über den Bildschirm fliegen, sollten vollständig entfernt werden. Subtile Opacity-Fades, die Zustandswechsel signalisieren (beispielsweise das Ein- und Ausblenden von Benachrichtigungen), können beibehalten werden, solange keine Positionsänderung damit verbunden ist. Kurze Transitions auf kleinen Elementen – wie das Hover-Feedback eines Buttons – können in stark reduzierter Dauer beibehalten werden.

Eine häufige Fehlannahme ist, dass prefers-reduced-motion bedeutet, dass der Nutzer gar keine Bewegung sehen möchte. Das stimmt nicht. Die Präferenz bedeutet, dass exzessive oder nicht essenzielle Bewegungen reduziert werden sollen. Das bedeutet: Opacity-Fades bleiben, Transform-Animationen über große Distanzen entfallen. Crossfades statt Slides für Seitenwechsel. Keine kontinuierlichen Hintergrundanimationen. Kurze Feedback-Animationen auf Interaktionen können mit reduzierter Dauer bestehen bleiben.

6. Implementierungsmuster für CSS-Animationen

Ein praktisches Muster für barrierefreie CSS-Animationen ist der Einsatz von CSS Custom Properties als Animation-Token. Man definiert eine Variable --animation-duration, die per prefers-reduced-motion Media Query auf 0.01ms gesetzt wird, und verwendet diese Variable in allen Animations- und Transitions-Definitionen. Das zentrale Überschreiben in einer einzigen Media Query betrifft dann automatisch alle Animationen im gesamten System, ohne jede einzelne Regel überarbeiten zu müssen.

Für komplexe Komponentenbibliotheken empfiehlt sich ein eigenes prefers-reduced-motion-Layer in der CSS-Architektur. Alle animations-relevanten Regeln werden in eine dedizierte Schicht ausgelagert, die durch eine Media Query als Ganzes gesteuert werden kann. Das ist besonders relevant für Tailwind CSS v4.0, das Layer-basierte Architektur unterstützt, und für Hyvä-Themes, bei denen Alpine.js-Transitions ebenfalls die prefers-reduced-motion-Präferenz respektieren sollten.


/* CSS Custom Property tokens for motion — central control */
:root {
  --duration-fast:   150ms;
  --duration-base:   300ms;
  --duration-slow:   600ms;
  --duration-xslow: 1200ms;
  --ease-spring: cubic-bezier(0.34, 1.56, 0.64, 1);
  --ease-out:    cubic-bezier(0.22, 1, 0.36, 1);
}

/* Single override point for reduced motion */
@media (prefers-reduced-motion: reduce) {
  :root {
    --duration-fast:   0.01ms;
    --duration-base:   0.01ms;
    --duration-slow:   0.01ms;
    --duration-xslow:  0.01ms;
    /* Keep spring ease — doesn't matter if duration is near 0 */
  }
}

/* All components use the tokens — automatically motion-safe */
.button {
  transition: background-color var(--duration-fast) ease,
              box-shadow var(--duration-fast) ease,
              transform var(--duration-fast) var(--ease-spring);
}

.modal {
  transition: opacity var(--duration-base) var(--ease-out),
              transform var(--duration-base) var(--ease-out);
}

.page-transition {
  transition: opacity var(--duration-slow) ease;
  /* Note: no transform transition — avoids large-area motion */
}

7. prefers-reduced-motion in JavaScript abfragen

Nicht alle Animationen werden in CSS implementiert. JavaScript-Bibliotheken, Canvas-Animationen, SVG-Animationen und Web Animations API-basierte Effekte müssen ebenfalls auf prefers-reduced-motion reagieren. Der Zugriff erfolgt über die JavaScript-API window.matchMedia('(prefers-reduced-motion: reduce)'). Das zurückgegebene MediaQueryList-Objekt hat eine matches-Eigenschaft und kann mit addEventListener('change', ...) auf Änderungen der Systemeinstellung reagieren – ohne Seitenneuladen.

Für Alpine.js-basierte Animationen in Hyvä-Themes empfiehlt sich eine globale Magic Property, die den prefers-reduced-motion-Status reaktiv macht. Alternativ kann man Alpine.js-Transitions mit x-transition in eine Bedingung mit $store.motionReduced einwickeln. Web Animations API-Aufrufe sollten grundsätzlich die matches-Eigenschaft vor dem Start einer Animation prüfen und bei true entweder keine Animation starten oder die Duration auf nahezu null setzen.

8. prefers-reduced-motion in Tailwind CSS

Tailwind CSS bietet seit Version 2 das Modifier-Präfix motion-reduce: an, das Klassen nur im prefers-reduced-motion: reduce-Kontext anwendet. Das Gegenstück motion-safe: wendet Klassen nur an, wenn der Nutzer keine Reduzierung angefordert hat. Diese Modifier können mit allen Tailwind-Animationsklassen kombiniert werden. Die empfohlene Praxis in Tailwind ist, Animationsklassen grundsätzlich mit motion-safe: zu qualifizieren und bei Bedarf mit motion-reduce: alternative Darstellungen zu definieren.

In Tailwind CSS v4.0 mit CSS-first-Konfiguration kann man prefers-reduced-motion auch direkt in der CSS-Konfiguration als Media Query verwenden und eigene Utilities definieren, die automatisch deaktiviert werden. Da Hyvä-Themes Tailwind CSS v4.0 einsetzen, bietet sich eine CSS-Variable-basierte Lösung an, die sowohl in Tailwind-Klassen als auch in direktem CSS genutzt werden kann.

9. Animationstypen im Barrierefreiheitsvergleich

Nicht jede Animation ist gleich problematisch für Nutzer mit vestibulären Störungen. Die folgende Übersicht klassifiziert häufige Animationstypen nach ihrer Risikoklasse für betroffene Nutzer und zeigt, welche Maßnahme im prefers-reduced-motion-Fall angemessen ist.

Animationstyp Risikoklasse Maßnahme bei reduce Beispiel
Parallax-Scrollen Hoch Vollständig entfernen animation: none
Seitenübergang (Slide) Hoch Durch Fade ersetzen transform → opacity
Element-Einblenden (Fade) Niedrig Beibehalten, Dauer kürzen duration: 0.01ms
Blinkende Elemente Sehr hoch Vollständig entfernen animation: none
Button-Hover-Feedback Niedrig Beibehalten duration: 0.01ms

Die Klassifizierung nach Risikoklassen hilft, Prioritäten bei der Implementierung von prefers-reduced-motion-Anpassungen zu setzen. Nicht jede Animation muss identisch behandelt werden. Das Ziel ist nicht das Entfernen aller visuellen Dynamik, sondern das Schützen betroffener Nutzer vor Animationen, die physische Beschwerden verursachen können.

Mironsoft

Barrierefreies CSS, WCAG-Konformität und zugängliches Frontend

Barrierefreie Animationen für euer Projekt?

Wir analysieren bestehende CSS-Animationen auf WCAG-Konformität, implementieren prefers-reduced-motion korrekt und stellen sicher, dass euer Projekt alle Nutzergruppen einschließt.

Accessibility-Audit

Animationen auf WCAG 2.2 und prefers-reduced-motion prüfen

Refactoring

CSS-Token-System für zentrale Motion-Kontrolle einführen

Hyvä / Tailwind

motion-reduce: Modifier und Alpine.js-Transitions barrierefrei machen

10. Zusammenfassung

Die CSS Media Query prefers-reduced-motion ist keine optionale Zugabe, sondern eine grundlegende Zugänglichkeitsanforderung für jedes Projekt mit Animationen. Für Menschen mit vestibulären Störungen, Migräne oder Epilepsie sind exzessive Webanimationen nicht nur unangenehm, sondern können physische Beschwerden auslösen. WCAG 2.2 verlangt, dass durch Interaktionen ausgelöste Animationen deaktivierbar sind. Die technische Implementierung ist minimal: Eine zentrale Media Query mit CSS-Custom-Properties als Token reicht aus, um das gesamte Animationssystem mit einer einzigen Regel anzupassen.

Die differenzierte Strategie – großflächige Bewegungen entfernen, kleine Fades beibehalten, Slides durch Fades ersetzen – ist wichtig, um sowohl die Zugänglichkeit zu gewährleisten als auch die visuelle Qualität für nicht betroffene Nutzer zu erhalten. prefers-reduced-motion in JavaScript über window.matchMedia abzufragen ermöglicht dieselbe Respektierung der Nutzerpräferenz für JS-basierte Animationen. In Tailwind CSS sind die Modifier motion-reduce: und motion-safe: der empfohlene Weg. Kein Projekt mit nennenswerten Animationen sollte diese Media Query ignorieren.

prefers-reduced-motion — Das Wichtigste auf einen Blick

Media Query

@media (prefers-reduced-motion: reduce) — liest Systemeinstellung aus. Vollständige Browser-Unterstützung.

WCAG 2.2

Kriterium 2.3.3 (AAA): Interaktionsanimationen abschaltbar machen. Kriterium 2.3.1 (AA): kein Blinken >3×/s.

CSS-Token-Ansatz

--duration-base: 300ms → bei reduce 0.01ms. Alle Komponenten nutzen das Token — zentrale Kontrolle.

JavaScript

window.matchMedia('(prefers-reduced-motion: reduce)').matches — JS-Animationen ebenfalls respektieren.

11. FAQ: CSS prefers-reduced-motion

1Was ist prefers-reduced-motion?
CSS Media Query, die die Systemeinstellung des Nutzers abfragt. Bei reduce hat der Nutzer weniger Bewegung in den Bedienungshilfen des Betriebssystems aktiviert.
2Wer braucht prefers-reduced-motion?
Menschen mit vestibulären Störungen, Migräne, Epilepsie oder neurologischen Erkrankungen. Betrifft schätzungsweise 35% aller Menschen irgendwann im Leben.
3Alle Animationen entfernen?
Nein. Opacity-Fades behalten. Transform-Bewegungen über große Distanzen entfernen. Kurze Feedback-Transitions mit reduzierter Dauer beibehalten.
4WCAG-Kriterien für Animationen?
2.3.1 (AA): kein Blinken >3×/s. 2.3.3 (AAA): Interaktionsanimationen müssen deaktivierbar sein. Beide betreffen Epilepsie und vestibuläre Störungen.
5Tailwind CSS und prefers-reduced-motion?
motion-reduce: und motion-safe: Modifier. Beispiel: motion-safe:animate-bounce motion-reduce:animate-none.
6JavaScript-Abfrage?
window.matchMedia('(prefers-reduced-motion: reduce)').matches — gibt true zurück. Mit addEventListener auf Änderungen reagieren.
7reduce vs. no-preference?
no-preference: keine spezielle Einstellung gesetzt. reduce: Nutzer hat Reduzierung aktiviert. Opt-in-Ansatz: Animationen nur bei no-preference aktivieren.
8CSS-Token-Ansatz?
Custom Properties als Tokens: --duration-base: 300ms. Bei reduce: 0.01ms. Alle Komponenten nutzen Tokens — eine Überschreibung wirkt systemweit.
9Welche Animationen komplett entfernen?
Parallax-Scrollen, Seiten-Slides, großflächige Transform-Animationen, Hintergrundvideos mit Bewegung, blinkende Elemente. Stärkste Auslöser vestibulär Betroffener.
10vestibuläre Störungen — was ist das?
Das Innenohr-System für Gleichgewicht und Raumorientierung. Bei Diskrepanz zwischen visueller und physischer Bewegung: Schwindel, Übelkeit, Desorientierung — Cybersickness.