Was sind bewegungsausgelöste Störungen in der Software?

Was sind bewegungsausgelöste Störungen in der Software?

„Bewegungsausgelöste Störungen“ ist kein WCAG-Begriff. Gemeint sind Menschen, bei denen Bewegung Beschwerden oder Fehlbedienung auslöst: vestibuläre Störungen (Schwindel, Übelkeit, Kopfschmerzen durch Animationen), photosensitive Anfälle durch Blitzen und motorische Einschränkungen wie Tremor, bei denen Schütteln oder Kippen des Geräts versehentlich Aktionen auslöst. Gutes Design begrenzt Bewegung, lässt sie abschalten und macht sie nie zur einzigen Bedienmöglichkeit.

Drei Gruppen, drei unterschiedliche Risiken

• Vestibuläre Störungen. Laut W3C gehören Schwindel, Übelkeit und Kopfschmerzen zu den Reaktionen, die schwer ausfallen können. MDN nennt das Skalieren oder Verschieben großer Objekte als typische Auslöser. Parallax, Zoom-Übergänge und automatisches Scrollen sind die üblichen Verdächtigen.
• Photosensitive Anfälle. Auslöser ist schnelles Blitzen, nicht Bewegung an sich. WCAG 2.3.1 (Stufe A) verlangt, dass eine Seite nicht öfter als dreimal pro Sekunde blitzt, es sei denn, die Blitze liegen unter den Grenzwerten für allgemeines Blitzen und Rotblitzen.
• Motorische Einschränkungen. Menschen mit Tremor lösen Schüttel- oder Kippfunktionen versehentlich aus, manche können die Geste gar nicht ausführen. Pfadbasierte oder Mehrfinger-Gesten und winzige Tippziele machen ähnliche Probleme.

Was WCAG 2.2 verlangt

• 2.3.1 Dreimaliges Blitzen oder unterhalb des Grenzwerts (A): kein Inhalt, der öfter als dreimal pro Sekunde oberhalb der Grenzwerte blitzt.
• 2.2.2 Pausieren, Beenden, Ausblenden (A): Bewegte, blinkende oder scrollende Inhalte, die automatisch starten, länger als fünf Sekunden laufen und neben anderem Inhalt stehen, brauchen eine Möglichkeit zum Pausieren, Beenden oder Ausblenden.
• 2.3.3 Animation durch Interaktion (AAA): Bewegungsanimation, die durch Interaktion ausgelöst wird, lässt sich abschalten, sofern sie nicht wesentlich ist. Das ist die strengste Anforderung, viele Teams setzen sie als Ziel.
• 2.5.4 Bewegungsaktivierung (A): Was durch Schütteln oder Kippen geht, muss auch über ein normales Bedienelement gehen, und die Bewegungsreaktion lässt sich abschalten. Wo Bewegung wesentlich ist, etwa bei einem Schrittzähler, gilt eine Ausnahme.
• 2.5.1 Zeigergesten (A): Mehrpunkt- oder pfadbasierte Gesten brauchen eine Alternative mit einem einzelnen Zeiger, außer die Geste ist wesentlich, etwa eine Unterschrift.
• 2.5.8 Zielgröße, Minimum (AA): Zeigerziele sind mindestens 24 mal 24 CSS-Pixel groß, mit Ausnahmen wie ausreichendem Abstand und Links im Fließtext.

Den Rahmen erklärt WCAG, zu Video und Audio siehe barrierefreie Medientypen.

So setzt du es um

Berücksichtige die Einstellung des Betriebssystems über die Media Query prefers-reduced-motion. MDN beschreibt sie so: Der Browser erfährt, dass die Nutzerin oder der Nutzer eine Oberfläche bevorzugt, die bewegungsbasierte Animationen entfernt, reduziert oder ersetzt:

.hero { animation: slide-in 600ms ease-out; }
@media (prefers-reduced-motion: reduce) {
  .hero { animation: none; }
}

Biete zusätzlich einen Schalter in der App an, für Menschen, die die Systemeinstellung nicht erreichen. Starte keine Endlos-Videos ohne Pausenknopf, gib jeder Schüttel- oder Kippgeste eine sichtbare Schaltfläche und ersetze Bewegung durch eine Überblendung, statt das Feedback ganz zu streichen.

Häufige Fehler

• „Bewegung reduzieren“ nur im CSS beachten, aber JavaScript-Animationen, Karussells und automatisch startende Videos vergessen.
• Jegliches Feedback entfernen, statt eine große Bewegung durch eine sanfte zu ersetzen.
• „Schütteln zum Rückgängigmachen“ ohne Schaltfläche „Rückgängig“.
• Annehmen, ein bestandener automatischer Scan heiße „sicher“. Ein Tool kann nicht beurteilen, ob eine Animation jemandem Schwindel macht.

Testen und überwachen

Schalte „Bewegung reduzieren“ im Betriebssystem oder in den Browser-Entwicklertools ein und gehe die wichtigen Abläufe von Hand durch, am besten als Teil deiner manuellen Barrierefreiheitstests. Automatisiertes Barrierefreiheitstesten zeigt nur einen Teil des Bildes, nutze es als Regressionsalarm. Aufwendige Animationen kosten außerdem Performance: LoadFocus Page-Speed-Monitoring führt geplante Lighthouse-Audits aus, damit du merkst, wenn ein neuer Effekt die Seite bremst. Was automatisierte Prüfungen leisten und was nicht, steht in diesem Beitrag zu Performance-Tests und Barrierefreiheit.

Häufige Fragen: Bewegungsausgelöste Störungen

Ist „bewegungsausgelöste Störung“ ein offizieller Begriff der Barrierefreiheit?

Nein. WCAG spricht von einzelnen Erfolgskriterien wie Blitzen, Animation durch Interaktion und Bewegungsaktivierung. Der Ausdruck ist ein praktischer Sammelbegriff für die Beschwerden, die diese Kriterien schützen.

Was ist prefers-reduced-motion?

Ein CSS-Media-Feature, das meldet, ob die Nutzerin oder der Nutzer das Gerät um weniger Bewegung gebeten hat. Damit entfernst oder milderst du Animationen für diese Personen.

Ist Blitzen dasselbe wie Animation?

Nein. Blitzen ist ein schneller Helligkeitswechsel und kann Anfälle auslösen, deshalb begrenzt WCAG 2.3.1 es schon auf Stufe A. Animation durch Interaktion ist ein eigenes Thema, vor allem bei vestibulären Störungen.

Muss ich jede Animation vermeiden?

Nein. Kleine, sinnvolle Übergänge sind in Ordnung. Vermeide großes Skalieren, Verschieben und Parallax für Personen mit reduzierter Bewegung und biete bei automatisch laufenden Inhalten eine Pausenfunktion.

Kann ein automatisiertes Tool diese Probleme finden?

Nur einen Teil, und nicht, ob eine Animation unangenehm ist. Prüfe von Hand mit aktivierter Bewegungsreduzierung.