WCAG 2.5.4: Bewegungsaktivierung

WCAG 2.5.4 verlangt, dass jede Funktionalität, die durch Bewegungen des Geräts oder des Nutzers (wie Schütteln oder Neigen) ausgelöst wird, auch über herkömmliche Benutzeroberflächenkomponenten bedienbar ist und dass Nutzer die Bewegungssteuerung deaktivieren können müssen, um eine unbeabsichtigte Aktivierung zu verhindern.

Was diese Regel bedeutet

WCAG 2.5.4 — Motion Actuation befasst sich mit einem spezifischen, aber zunehmend häufigen Szenario in modernen Webanwendungen: Funktionalität, die durch physische Bewegung des Geräts ausgelöst wird, wie das Schütteln eines Smartphones, das Neigen eines Geräts oder Gesten vor einer Kamera. Das Kriterium legt zwei parallele Anforderungen fest, die beide erfüllt sein müssen, um konform zu sein.

Erstens muss jede Funktionalität, die durch Gerätebewegung oder Benutzerbewegung bedient werden kann, auch über eine Benutzeroberflächenkomponente bedienbar sein — also über eine Schaltfläche, einen Link, ein Formularelement oder ein ähnliches interaktives Element, das nicht auf Bewegung angewiesen ist. Dies stellt sicher, dass Menschen, die physische Bewegungsgesten nicht ausführen können oder nicht zuverlässig ausführen können, nicht vollständig vom Zugriff auf diese Funktionalität ausgeschlossen werden.

Zweitens müssen Benutzer die Bewegungsreaktion deaktivieren können, damit unbeabsichtigte oder unwillkürliche Bewegungen keine unerwünschten Aktionen auslösen. Dies schützt Benutzer mit Tremor oder anderen motorischen Beeinträchtigungen, die ungewollte Gerätebewegungen verursachen, davor, ständig durch unerwartetes Anwendungsverhalten gestört zu werden.

Das Kriterium gilt für zwei unterschiedliche Arten von Bewegung: Gerätebewegung, die über Sensoren wie Beschleunigungsmesser und Gyroskope in Smartphones und Tablets erkannt wird (zugänglich über APIs wie DeviceMotionEvent und DeviceOrientationEvent), und Benutzerbewegung, die über Kameras oder andere Eingabesensoren erkannt wird, die Körperbewegungen oder Gesten und nicht das Gerät selbst verfolgen.

Eine bestehende Implementierung stellt alle bewegungsgesteuerten Funktionen über ein Standard-UI-Steuerelement (eine Schaltfläche, einen Link oder ein Äquivalent) bereit UND ermöglicht es dem Benutzer, die Bewegungserkennung zu deaktivieren, wenn er dies wünscht. Eine fehlende Implementierung bietet entweder ausschließlich bewegungsbasierte Zugriffe auf eine Funktion ohne alternatives UI-Steuerelement oder bietet zwar eine Alternative, aber keine Möglichkeit, den Bewegungsauslöser zu deaktivieren, sodass unwillkürliche Bewegungen keine Probleme verursachen.

WCAG 2.5.4 definiert zwei wichtige Ausnahmen. Bewegungssteuerung ist ausgenommen, wenn die Bewegung für die Funktion wesentlich ist und ihre Deaktivierung die Aktivität grundlegend verändern würde — zum Beispiel eine Schrittzähler-Fitnessanwendung, bei der Bewegungserfassung der Kernzweck ist, oder ein Spiel, das ausdrücklich auf Neigungsmechaniken ausgelegt ist. Die zweite Ausnahme gilt, wenn die Bewegung zur Bedienung von Funktionalität über eine unterstützte Barrierefreiheits-Schnittstelle verwendet wird, was bedeutet, dass die plattformeigenen Barrierefreiheitsfunktionen die Bewegungsinteraktion auf eine Weise handhaben, die der Benutzer unabhängig steuert.

Warum das wichtig ist

Barrieren durch Bewegungssteuerung betreffen überproportional Menschen mit motorischen und Mobilitätsbeeinträchtigungen, aber die Auswirkungen sind breiter, als viele Entwickler zunächst annehmen. Zu verstehen, wer betroffen ist — und wie — hilft Teams, dieses Kriterium angemessen zu priorisieren.

Menschen mit Tremorerkrankungen — einschließlich essenziellem Tremor, Parkinson-Krankheit und Multipler Sklerose — können konstante oder intermittierende unwillkürliche Bewegungen ihrer Hände und Arme erleben. Wenn sie ein Smartphone halten, reicht ihr natürlicher Tremor aus, um Dialoge wie „Schütteln zum Rückgängig machen“, Aktualisierungsaktionen oder andere bewegungsaktivierte Funktionen wiederholt und unerwartet auszulösen. Die Weltgesundheitsorganisation schätzt, dass weltweit etwa 1,3 Milliarden Menschen mit einer Form einer erheblichen Behinderung leben, und Erkrankungen, die die Feinmotorik beeinträchtigen, gehören in allen Altersgruppen zu den häufigsten.

Menschen mit Lähmungen oder Gliedmaßenunterschieden verwenden ihre Geräte möglicherweise an Rollstühlen oder Halterungen montiert oder nutzen Kopfzeiger, Blicksteuerung oder Schaltersteuerungen zur Interaktion mit ihren Geräten. Diese Benutzer können ein Gerät oft überhaupt nicht schütteln oder neigen, wodurch ausschließlich bewegungsbasierte Funktionen völlig unzugänglich werden. Wenn die einzige Möglichkeit, eine Texteingabe in einer mobilen Webanwendung rückgängig zu machen, darin besteht, das Gerät zu schütteln, kann ein Rollstuhlnutzer mit einem montierten Telefon auf diese Funktion schlicht nicht zugreifen.

Ältere Erwachsene sind eine weitere stark betroffene Gruppe. Altersbedingte Beeinträchtigungen wie verringerte Griffkraft, Arthritis und essenzieller Tremor werden mit zunehmendem Alter immer häufiger, was bedeutet, dass ein wachsender Teil der Bevölkerung — der zugleich immer aktiver digitale Angebote nutzt — Schwierigkeiten mit präzisen oder gezielten Bewegungsgesten haben kann.

Betrachten Sie ein konkretes Szenario aus der realen Welt: Eine türkische E-Commerce-Website fügt eine „Schütteln zum Mischen“-Funktion hinzu, die den Nutzern eine zufällige Produktempfehlung anzeigt, wenn sie ihr Telefon schütteln, um das Stöbern ansprechender zu machen. Die Funktion ist unterhaltsam und neuartig, aber es gibt keine entsprechende Schaltfläche, um das Mischen auszulösen, und keine Möglichkeit, die Schüttelerkennung zu deaktivieren. Ein Nutzer mit Parkinson-Krankheit, der diese Seite besucht, erlebt ständige, unkontrollierte Misch-Aktivierungen, da sein natürlicher Tremor die Geste auslöst. Er kann nicht in Ruhe stöbern, weil die Seite ständig zu zufälligen Produkten springt. Dieser Nutzer ist faktisch von einem normalen Einkaufserlebnis ausgeschlossen — und nach den türkischen Barrierefreiheitsvorschriften ist dies nicht nur ein UX-Problem, sondern ein Verstoß gegen die rechtliche Compliance.

Über den Zugang für Menschen mit Behinderungen hinaus verbessert das Deaktivieren oder Bereitstellen von Alternativen zu Bewegungsfunktionen auch das Erlebnis für Nutzer in Umgebungen, in denen Gerätebewegung unzuverlässig ist — im öffentlichen Verkehr, in Büros oder in jeder Umgebung, in der ein Nutzer sein Gerät nicht frei bewegen kann.

Wie man testet

Automatisierter Scan als Ausgangspunkt: Führen Sie axe DevTools, Lighthouse oder den Accsible-Barrierefreiheitsprüfer auf der Seite aus. Diese Tools werden Verstöße gegen 2.5.4 nicht automatisch kennzeichnen, können aber verwandte Probleme aufzeigen. Notieren Sie alle markierten Punkte und fahren Sie dann mit den manuellen Schritten fort. Das Fehlen automatischer Hinweise bedeutet nicht, dass die Seite 2.5.4 besteht.
Bewegungsgesteuerte Funktionalität identifizieren: Öffnen Sie Chrome DevTools und navigieren Sie zum Elements-Panel. Durchsuchen Sie die JavaScript-Quelldateien der Seite (über den Tab Sources und die globale Suche mit Strg+Umschalt+F) nach den Zeichenfolgen devicemotion, deviceorientation, accelerat, gyro und shake. Dokumentieren Sie jede gefundene Instanz und die zugehörige Funktionalität.
Überprüfen, ob UI-Alternativen existieren: Versuchen Sie für jede im vorherigen Schritt entdeckte bewegungsgesteuerte Funktionalität, dieselbe Aktion ausschließlich mit Tastaturnavigation und Mausklicks — ohne Gerätebewegung — auszuführen. Navigieren Sie mit Tab, Eingabetaste, Leertaste und Pfeiltasten durch die Oberfläche. Wenn Sie kein bedienbares UI-Steuerelement finden, das dasselbe Ergebnis erzielt, fällt die Seite bei diesem Kriterium durch.
Überprüfen, ob Bewegung deaktiviert werden kann: Suchen Sie nach einem Einstellungsmenü, einem Präferenz-Panel, Barrierefreiheits-Einstellungen oder einem speziellen Schalter für Bewegungsfunktionen. Versuchen Sie, die Bewegungssteuerung zu deaktivieren. Wenn es keine solche Steuerung gibt oder wenn das Deaktivieren der Bewegung auch die UI-Alternative deaktiviert, fällt die Seite bei diesem Kriterium durch.
Testen auf einem physischen Gerät: Laden Sie die Seite auf einem tatsächlichen Smartphone oder Tablet. Bewegen Sie das Gerät absichtlich sanft (Simulation eines unwillkürlichen Tremors — kleine, kontinuierliche Bewegungen) und beobachten Sie, ob Funktionalität unbeabsichtigt ausgelöst wird. Führen Sie denselben Test anschließend durch, nachdem Sie die Bewegung über verfügbare Einstellungen deaktiviert haben.
Screenreader- und Tastaturtests: Navigieren Sie mit NVDA und Firefox, VoiceOver und Safari auf iOS oder JAWS und Chrome ausschließlich mit Tastatur und Screenreader-Befehlen durch die Seite. Bestätigen Sie, dass alle über Bewegung erreichbaren Funktionen auch über die Screenreader-Navigation erreichbar sind und dass die Steuerung zum Deaktivieren der Bewegung (falls vorhanden) selbst mit der Tastatur zugänglich und korrekt beschriftet ist.
Gerätesimulation in den Browser-DevTools: Öffnen Sie in Chrome DevTools das Sensors-Panel (More Tools > Sensors) und verwenden Sie die Steuerungen zur Simulation von Geräteausrichtung und Beschleunigungsmesser, um Bewegungsereignisse programmatisch auszulösen. Dies ermöglicht Desktop-Tests bewegungsgesteuerten Verhaltens ohne physisches Gerät.

Wie man es behebt

Shake-to-Refresh ohne Alternative — Falsch

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Shake-to-Refresh ohne Alternative — Richtig

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Tilt-to-Scroll-Carousel ohne Deaktivierungsoption — Falsch

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Tilt-to-Scroll-Carousel ohne Deaktivierungsoption — Richtig

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Kamera-Gestenfunktion ohne Alternative — Falsch

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Kamera-Gestenfunktion ohne Alternative — Richtig

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Häufige Fehler

Bereitstellung einer UI-Alternativschaltfläche, aber Vergessen des Schalters zum Deaktivieren der Bewegung: Viele Entwickler fügen eine entsprechende Schaltfläche hinzu, implementieren jedoch nie eine Möglichkeit, den Bewegungs-Listener zu deaktivieren, sodass Nutzer mit Tremor weiterhin unerwünschte Auslösungen erleben, obwohl die Funktion technisch auf andere Weise bedienbar ist.
Verstecken der Option zum Deaktivieren der Bewegung in einem Hamburger-Menü oder tief verschachtelten Einstellungsseiten: Die Steuerung zum Deaktivieren der Bewegung muss selbst leicht erreichbar sein. Wenn ein Nutzer mit Tremor „Schütteln zum Aktualisieren“ wiederholt auslöst, bevor er fünf Menüebenen tief navigieren kann, um es zu deaktivieren, ist die Deaktivierungsoption praktisch nicht zugänglich.
Die Annahme, dass die Betriebssystemeinstellung „Bewegung reduzieren“ 2.5.4 erfüllt: Die Media Query prefers-reduced-motion und die Barrierefreiheits-Einstellungen des Betriebssystems betreffen Animationen und vestibuläre Belange, deaktivieren aber nicht automatisch Gerätebewegungs-Event-Listener in Webanwendungen. Sie müssen dies in Ihrem eigenen Code handhaben.
Zu niedrig eingestellte Bewegungsschwellenwerte: Sehr empfindliche Schwellenwerte für DeviceMotionEvent-Beschleunigungswerte bedeuten, dass kleine, unwillkürliche Tremorbewegungen die Schwelle überschreiten können. Schwellenwerte sollten eine gezielte, hochgradige Bewegung erfordern, und selbst dann ist eine Deaktivierungsoption erforderlich.
Globales Registrieren von Bewegungs-Listenern auf window, ohne sie jemals zu entfernen: Einen Listener anzuhängen und nie einen Codepfad bereitzustellen, um ihn mit removeEventListener zu entfernen, bedeutet, dass der Deaktivierungsschalter das Verhalten nur bedingt unterdrücken kann — wenn der Schalter selbst ausfällt oder beim Neuladen der Seite zurückgesetzt wird, bleibt die Bewegung aktiv.
Die Deaktivierungs-Checkbox für Bewegung unzugänglich machen: Die Implementierung des Deaktivierungsschalters als gestyltes <div> oder <span> mit einem Klick-Listener anstelle eines richtigen <input type='checkbox'> oder ARIA-verbesserten Steuerelements bedeutet, dass Tastatur- und Screenreader-Nutzer die Steuerung, die ihnen helfen soll, nicht erreichen oder bedienen können.
Nichtpersistieren der Bewegungspräferenzen des Nutzers über Sitzungen hinweg: Wenn ein Nutzer die Bewegungssteuerung deaktiviert, die Präferenz aber nicht gespeichert wird (z. B. über localStorage oder eine Benutzereinstellung im Konto), muss er sie bei jedem Besuch erneut deaktivieren, was für die am stärksten betroffenen Nutzer eine wiederkehrende Belastung darstellt.
Zu breite Anwendung der Ausnahme für wesentliche Funktionen: Die Ausnahme „wesentlich“ ist eng gefasst. Eine Produktgalerie, die „Schütteln zum Mischen“ verwendet, ist nicht wesentlich — die Mischfunktion ist nicht die Kernfunktion einer Shopping-Seite. Teams wenden diese Ausnahme manchmal falsch an, um Implementierungsaufwand zu vermeiden.
Kein Testen auf einem echten physischen Gerät mit tatsächlicher Bewegung: Sich ausschließlich auf Desktop-Simulationstools oder automatisierte Scans zu verlassen, bedeutet, dass Probleme mit der Empfindlichkeit in der realen Welt — einschließlich des Verhaltens der Funktion, wenn ein Nutzer einen natürlichen Tremor hat — erst entdeckt werden, wenn Nutzer sie melden.
Vergessen, dass von Drittanbieter-SDKs oder Analysebibliotheken hinzugefügte Bewegungsfunktionen ebenfalls konform sein müssen: Bewegungs-Listener, die in Drittanbieter-Chat-Widgets, Gamification-SDKs oder A/B-Testing-Tools eingebettet sind, sind weiterhin Teil der Konformitätsverantwortung der Seite. Wenn ein Drittanbieter-Skript einen devicemotion-Listener registriert, ohne eine Alternative bereitzustellen, verstößt die Seite gegen 2.5.4.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung Nr. 2025/10, veröffentlicht im Amtsblatt (Nr. 32933) am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit fest, die sich an WCAG 2.2 orientieren. WCAG 2.5.4 Motion Actuation ist ein Kriterium der Stufe A, was bedeutet, dass es in die höchste Prioritätsstufe der verbindlichen Compliance unter dieser Verfügung fällt.

Die Verfügung umfasst ein breites Spektrum öffentlicher und privater Einrichtungen. Öffentliche Institutionen — einschließlich aller zentralen und lokalen Regierungsstellen, Ministerien und öffentlichen Behörden — müssen innerhalb von einem Jahr nach Veröffentlichung der Verfügung vollständige Konformität auf Stufe A erreichen. Private Einrichtungen in den erfassten Kategorien müssen denselben Standard innerhalb von zwei Jahren erreichen. Zu den erfassten privaten Kategorien gehören E-Commerce-Plattformen und -Marktplätze, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die mit Genehmigung des Ministeriums für Nationale Bildung (MoNE) betrieben werden.

Bewegungssteuerung ist für türkische digitale Dienste besonders relevant, da die mobile Internetnutzung in der Türkei sehr hoch ist und der Großteil des Webverkehrs von Smartphones stammt. Mobile-first- und Mobile-only-Webanwendungen sind daher in allen erfassten Sektoren äußerst verbreitet. Jede türkische E-Commerce-Seite, Banking-Anwendung oder jedes Regierungsportal, das „Schütteln zum Aktualisieren“, Neigungsnavigation, gestenbasierte Interaktionen oder ähnliche Bewegungsfunktionen implementiert hat, ohne UI-Alternativen und Deaktivierungssteuerungen bereitzustellen, verstößt direkt gegen eine verbindliche Anforderung der Stufe A gemäß der Präsidialverfügung 2025/10.

Für erfasste Einrichtungen, die Compliance-Roadmaps vorbereiten, sollte Bewegungssteuerung als Teil eines umfassenderen Audits der mobilen Barrierefreiheit bewertet werden. Da automatisierte Tools Verstöße gegen 2.5.4 nicht erkennen können, sollten Organisationen manuelle Tests durch qualifizierte Barrierefreiheits-Spezialisten in ihren Konformitätsprüfprozess einbeziehen. Da die Verfügung keine Übergangsfrist für Funktionen vorsieht, die vor ihrer Veröffentlichung implementiert wurden — sondern nur einen Zeitplan für das Erreichen der Konformität — muss jede derzeit auf erfassten Seiten bereitgestellte bewegungsbasierte Funktionalität innerhalb der geltenden Frist behoben werden.

Einrichtungen, die die Anforderungen der Verfügung nicht erfüllen, können mit Verwaltungssanktionen belegt werden und unterliegen der Durchsetzung durch die für ihren Sektor zuständigen Aufsichtsbehörden. Über das regulatorische Risiko hinaus stellt die Nichteinhaltung von 2.5.4 auf einer stark frequentierten türkischen Mobilseite ein reales Usability-Versagen für Millionen von Nutzern dar, die motorische Beeinträchtigungen oder Tremor haben oder unterstützende Technologien nutzen — eine Bevölkerungsgruppe, deren Bedürfnisse durch die Übernahme von WCAG 2.2 Stufe A als Basisstandard in der Verfügung ausdrücklich anerkannt und geschützt werden.