WCAG 2.5.4: Betätigung durch Bewegung

Q: Gilt das auch für Web-Anwendungen oder nur für Apps?

Für beide. Die Web-Schnittstellen devicemotion und deviceorientation machen dieselben Muster im Browser möglich, und die WCAG unterscheidet nicht nach Plattform. Im Web ist die Anwendbarkeit nur seltener gegeben, weil bewegungsgesteuerte Funktionen dort weniger verbreitet sind.

Von Jakob Sommer Zuletzt geändert am 4. September 2026

WCAG 2.5.4 verlangt für jede Funktion, die durch Bewegung des Geräts oder Bewegung vor der Kamera ausgelöst wird, zwei Dinge zugleich: ein gewöhnliches Bedienelement, das dasselbe leistet, und die Möglichkeit, die Bewegungssteuerung abzuschalten. Ausgenommen sind nur Fälle, in denen die Bewegung die Funktion selbst ist. Ein Schrittzähler misst nun einmal Bewegung.

(Englisch: Motion Actuation. Im BIK-BITV-Test heißt der Prüfschritt „2.5.4 Alternativen für Bewegungsaktivierung“.)

Stufe	Prinzip	Teil der WCAG seit	Rechtlich verbindlich?
A	Bedienbar	2.1 (2018)	Ja über EN 301 549 in BFSG & BITV

Das Wichtigste in Kürze

Zwei Anforderungen, beide müssen erfüllt sein: eine Alternative über normale Bedienelemente und eine Abschaltmöglichkeit für die Bewegungssteuerung.
Gemeint sind beide Richtungen: Bewegung des Geräts (Schütteln, Kippen, Neigen) und Bewegung der Person vor Kamera oder Sensor.
Die Abschaltmöglichkeit ist der Teil, der meistens fehlt: eine Alternative gibt es oft, einen Aus-Schalter fast nie.
Fest montierte Geräte sind der Kernfall: Wer sein Tablet am Rollstuhl befestigt hat, kann es nicht schütteln.
Unwillkürliche Bewegung löst ungewollt aus. Bei Tremor ist eine Schüttelgeste kein Bedienweg, sondern eine Fehlerquelle.
Die Ausnahme greift nur bei essenziellen Funktionen: Schrittzähler, Bewegungsmessung, Anwendungen, die Bewegung selbst zum Gegenstand haben.
Auch die Systemebene zählt: Wenn das Betriebssystem eine wirksame Abschaltung anbietet, kann der Prüfschritt darüber erfüllt sein.
Stufe A, seit WCAG 2.1 (2018) und über die EN 301 549 verbindlich.

Darf Schütteln eine Funktion auslösen?

Nur zusätzlich. Es braucht immer ein gewöhnliches Bedienelement mit derselben Wirkung und die Möglichkeit, die Bewegungssteuerung abzuschalten.

Im Web ist dieses Kriterium seltener anwendbar als in nativen Apps. Die Web-Schnittstellen für Bewegungssensoren existieren aber, und wer sie einsetzt, macht dieselben Fehler. devicemotion und deviceorientation liefern Beschleunigungs- und Lagedaten; über die Kamera lassen sich Gesten erkennen. Sobald daran eine Funktion hängt, greift 2.5.4.

Die bekannten Muster: „Schütteln zum Rückgängigmachen“, „Kippen zum Blättern“, Neigungssteuerung in Spielen und Karten, „Winken zum Bestätigen“ in Kamera-Oberflächen, das Drehen des Geräts als Auslöser für einen Moduswechsel. Für jede solche Funktion gilt doppelt:

Alternative. Ein reguläres Bedienelement muss dasselbe leisten (ein Knopf „Rückgängig“, eine Blätternavigation, ein Umschalter). Der BIK-BITV-Test formuliert das als Prüffrage: Existieren für jede bewegungsaktivierte Funktion zugängliche alternative Bedienelemente?

Abschaltbarkeit. Die Bewegungssteuerung muss sich deaktivieren lassen. Das ist nicht dasselbe wie die Alternative, und genau hier scheitern die meisten Umsetzungen. Eine Schüttelgeste, die zusätzlich zum Knopf existiert, löst bei Menschen mit Tremor trotzdem ungewollt aus. Solange sie nicht abschaltbar ist, bleibt sie eine Barriere. Der Prüfschritt erlaubt dabei ausdrücklich, dass die Abschaltung über Betriebssystemeinstellungen erfolgt, sofern sie wirksam ist.

Die Ausnahmen sind zwei: Die Bewegungseingabe ist über eine als barrierefrei unterstützte Schnittstelle umgesetzt (etwa als Systemgeste der Bedienungshilfen) oder sie ist für die Funktion unverzichtbar. Der Prüfschritt nennt als Beispiel Anwendungen zur Aktivitätsverfolgung: Ein Schrittzähler ohne Bewegungsmessung wäre kein Schrittzähler. Die W3C-Technik dazu heißt G213 („konventionelle Steuerelemente bereitstellen“), das dokumentierte Fehlermuster F106 beschreibt genau den Fall, dass sich die Bewegungseingabe nicht abschalten lässt.

Der Normtext steht im Understanding-Dokument des W3C zu 2.5.4, das deutsche Prüfvorgehen im Prüfschritt „2.5.4 Alternativen für Bewegungsaktivierung“.

Oben die beiden Anforderungen des Kriteriums, verbunden mit dem Wort UND: erstens eine Alternative über Bedienelemente, also ein sichtbarer Knopf, der dasselbe leistet und ohne jede Bewegung erreichbar ist; zweitens die Abschaltbarkeit, also die Möglichkeit, die Bewegungssteuerung zu deaktivieren, in der Anwendung oder über eine wirksame Systemeinstellung. Darunter eine Tabelle mit vier Funktionen. Schütteln zum Rückgängigmachen über devicemotion hat einen Knopf als Alternative, aber keinen Aus-Schalter, Bewertung nicht erfüllt, weil die Geste bei Tremor weiter ungewollt auslöst. Kippen zum Blättern über deviceorientation hat Vor- und Zurück-Knöpfe und einen Aus-Schalter, erfüllt. Winken zum Bestätigen über Kamera-Gestenerkennung hat einen Bestätigen-Knopf und einen Aus-Schalter, erfüllt. Der Schrittzähler ist nicht anwendbar, weil die Bewegungseingabe unverzichtbar ist. Darunter links, was nicht hierher gehört: Wischen und Ziehen fallen unter 2.5.1 und 2.5.7, Zwei-Finger-Zoom unter 2.5.1, dekorative Parallaxe unter 2.2.2. Rechts, wen es betrifft: Menschen mit fest am Rollstuhl montiertem Tablet, Menschen mit Tremor, Menschen, die per Mundstab oder Kopfmaus bedienen. — Eine Alternative allein genügt nicht. Ohne Aus-Schalter feuert die Geste weiter.

Wen betrifft es besonders?

Menschen mit Tremor oder Spastik stehen gleich doppelt im Regen. Die Geste willentlich auszuführen, gelingt oft nicht und gleichzeitig lösen unwillkürliche Bewegungen sie ständig aus. Bei essenziellem Tremor kann eine Schüttelgeste zum Rückgängigmachen dazu führen, dass Eingaben in einer Endlosschleife verschwinden. Das ist keine theoretische Konstruktion; es ist der Grund, warum das Kriterium überhaupt existiert.

Menschen, deren Gerät fest montiert ist (am Rollstuhl, an einem Ständer, an einem Halterungsarm im Bett), können es schlicht nicht bewegen. Für sie ist eine bewegungsgebundene Funktion nicht schwierig, sondern nicht vorhanden. Dasselbe gilt für alle, die ihr Tablet auf dem Tisch liegend mit einem Mundstab oder einer Kopfmaus bedienen.

Nutzende von Switch- und Kopfsteuerungen haben oft gar keinen direkten Kontakt zum Gerät. Ihre Eingabe läuft über einen Taster oder eine Kopfbewegung, die auf einen Zeiger übersetzt wird. Eine Gerätebewegung kommt dabei nicht vor.

Und schließlich der situative Fall: Wer im Liegen liest, hat das Gerät in einer Position, in der Neigungssensoren wilde Werte liefern. Wer im fahrenden Zug sitzt, schüttelt permanent. Beides trifft Menschen, die von einer Behinderung weit entfernt sind und ist trotzdem derselbe Fehler.

Richtig & falsch im Code

Der typische Verstoß ist wenige Zeilen lang und sieht harmlos aus:

// Falsch: Rückgängigmachen gibt es nur per Schütteln
window.addEventListener('devicemotion', (e) => {
  if (istSchuetteln(e)) letzteAktionRueckgaengig();
});

// Falsch: Kartenausschnitt folgt der Geräteneigung,
// ohne Alternative und ohne Aus-Schalter
window.addEventListener('deviceorientation', (e) => {
  verschiebeKarte(e.gamma, e.beta);
});

Die vollständige Umsetzung braucht beides (ein sichtbares Bedienelement und einen Schalter für die Geste):

<!-- Richtig: gleichwertiger Weg über einen normalen Knopf -->
<button type="button" id="rueckgaengig">
  Letzte Änderung rückgängig machen
</button>

<!-- Richtig: die Bewegungssteuerung lässt sich abschalten -->
<fieldset>
  <legend>Bewegungssteuerung</legend>
  <label>
    <input type="checkbox" id="schuetteln-aktiv" />
    Schütteln zum Rückgängigmachen verwenden
  </label>
</fieldset>

// Richtig: die Geste hängt am Schalter, und die Entscheidung
// überlebt den nächsten Aufruf
const schalter = document.querySelector('#schuetteln-aktiv');

// Vorgabe: aus. An ist die Geste nur, wenn jemand sie
// bewusst eingeschaltet hat.
schalter.checked = localStorage.getItem('schuetteln-aktiv') === 'ja';

schalter.addEventListener('change', () => {
  localStorage.setItem(
    'schuetteln-aktiv',
    schalter.checked ? 'ja' : 'nein'
  );
});

window.addEventListener('devicemotion', (e) => {
  if (!schalter.checked) return;
  if (istSchuetteln(e)) letzteAktionRueckgaengig();
});

Zwei Details lohnen den zweiten Blick. Erstens ist die Voreinstellung eine Entwurfsentscheidung: Eine Geste, die standardmäßig aus ist und bewusst eingeschaltet wird, erspart die ganze Diskussion. Deshalb steht im Beispiel kein checked. Zweitens braucht der Schalter eine sichtbare Beschriftung und eine dauerhafte Speicherung. Ein Aus-Schalter, der sich beim nächsten Aufruf zurücksetzt, ist keiner.

Der falsche Hebel an dieser Stelle ist prefers-reduced-motion. Die Einstellung sagt, dass die Seite weniger Animation abspielen soll; über Bewegung als Eingabe sagt sie nichts. Wer die Geste daran koppelt, schaltet sie bei Menschen ab, die nur keine Parallaxe mögen, und lässt sie bei Menschen mit Tremor weiter feuern. Für Animation, die die Seite selbst abspielt, ist die Abfrage richtig. Das ist der Fall von 2.2.2 Pausieren, beenden, ausblenden. Für 2.5.4 braucht es den eigenen Schalter.

Ein Sonderfall, der im Web häufiger vorkommt als echte Schüttelgesten: der Parallaxe-Effekt, der auf die Geräteneigung reagiert. Solange er nur dekorativ ist, fällt er nicht unter 2.5.4. Er fällt aber unter 2.2.2 Pausieren, beenden, ausblenden und kann bei vestibulären Beschwerden Übelkeit auslösen. Sobald er eine Funktion steuert, greifen beide Kriterien.

Und noch ein Hinweis zur Technik: devicemotion und deviceorientation liefern nur im sicheren Kontext, also über HTTPS, überhaupt Werte. Stand September 2026 verlangt Safari auf iOS zusätzlich eine ausdrückliche Freigabe über DeviceMotionEvent.requestPermission(), das nur aus einer Nutzeraktion heraus aufgerufen werden darf. Ohne diesen Dialog feuern die Ereignisse dort gar nicht. Was ohne Freigabe nicht läuft, ist kein Ersatz für eine Alternative: Die Funktion muss auch dann erreichbar sein, wenn jemand die Freigabe verweigert oder der Dialog nie erscheint.

So testest du es

Den Code durchsuchen nach devicemotion, deviceorientation, DeviceMotionEvent, Accelerometer, Gyroscope und nach Bibliotheken für Kamera-Gestenerkennung.
Für jeden Treffer die Funktion benennen. Was passiert bei der Bewegung? Steuert sie etwas, oder ist sie Dekoration?
Nach dem Bedienelement suchen. Gibt es für dieselbe Funktion einen sichtbaren Knopf, der ohne Bewegung erreichbar ist?
Nach dem Aus-Schalter suchen. Lässt sich die Bewegungssteuerung deaktivieren (in der Anwendung selbst oder über eine wirksame Systemeinstellung)?
Auf dem Gerät gegenprobieren. Löst normales Tragen, Gehen oder Ablegen die Funktion aus? Wer beim Testen im Sitzen bleibt, findet genau diese Fälle nicht.
Die Freigabe verweigern und prüfen, ob die Anwendung weiter benutzbar bleibt.
Die Ausnahme sauber begründen, falls du sie in Anspruch nimmst: Ist die Bewegung wirklich die Funktion oder nur der bequemste Weg dorthin?

Häufiger Fehler in der Praxis

Der häufigste Fehler ist die halbe Erfüllung: Es gibt einen Knopf, also gilt das Kriterium als abgehakt. Der Prüfschritt verlangt aber beides (Alternative und Abschaltbarkeit). Die Begründung ist nicht formal: Eine Geste, die man nicht abschalten kann, feuert bei unwillkürlichen Bewegungen weiter, egal wie viele Knöpfe daneben stehen. Da beiß ich mir in Berichten regelmäßig auf die Zunge, weil der fehlende Schalter zehn Minuten Arbeit gewesen wäre.

Der zweite ist die Geste, die niemand dokumentiert hat. In gewachsenen Projekten findet sich irgendwo ein Sensor-Handler aus einer Kampagnenseite von vor drei Jahren. Er läuft noch, niemand weiß davon, und im Selbstcheck taucht er nicht auf, weil niemand nach ihm sucht. Der Code-Durchlauf nach den Ereignisnamen findet ihn in Sekunden.

Der dritte ist die Verwechslung mit Bildschirmgesten. Wischen, Ziehen und Zwei-Finger-Zoom sind Zeigergesten und gehören zu 2.5.1 beziehungsweise 2.5.7. 2.5.4 betrifft ausschließlich Bewegung des Geräts oder der Person (nicht des Fingers auf dem Glas). Für die Umsetzung macht das wenig Unterschied, für die Nummer im Prüfbericht schon.

Und der vierte: die Ausnahme, die zu weit ausgelegt wird. „Bei uns ist die Neigungssteuerung Teil des Erlebnisses“ ist keine Begründung im Sinne des Kriteriums. Unverzichtbar ist sie nur, wenn ohne sie die Funktion selbst verloren geht (bei einer Wasserwaage, einem Schrittzähler, einer Anwendung zur Bewegungsanalyse). Bei einem Bilderkarussell nicht.

Häufige Fragen

Betrifft 2.5.4 auch Wischgesten auf dem Bildschirm?

Nein. Wischen, Ziehen und Mehrfingergesten sind Zeigereingaben und gehören zu 2.5.1 Zeigergesten und 2.5.7 Ziehbewegungen. 2.5.4 betrifft nur Bewegungen des Geräts selbst oder Bewegungen der Person vor einem Sensor.

Reicht ein Knopf als Alternative aus?

Als Alternative ja, für das Kriterium insgesamt nein. Verlangt sind beide Teile: der alternative Bedienweg und die Möglichkeit, die Bewegungssteuerung abzuschalten. Ohne Aus-Schalter löst die Geste bei unwillkürlichen Bewegungen weiterhin aus und genau das soll das Kriterium verhindern.

Gilt das auch für Web-Anwendungen oder nur für Apps?

Für beide. Die Web-Schnittstellen devicemotion und deviceorientation machen dieselben Muster im Browser möglich, und die WCAG unterscheidet nicht nach Plattform. Im Web ist die Anwendbarkeit nur seltener gegeben, weil bewegungsgesteuerte Funktionen dort weniger verbreitet sind.

Wann ist Bewegung „unverzichtbar“?

Wenn die Funktion ohne sie ihren Zweck verliert. Ein Schrittzähler, eine Wasserwaage oder eine Anwendung zur Bewegungsanalyse messen Bewegung. Das ist ihre Aufgabe. Ein Karussell, das auf Neigung reagiert, oder ein Rückgängigmachen per Schütteln fallen nicht darunter; dort ist die Bewegung eine Bedienidee, keine Notwendigkeit.

Zählt eine Systemeinstellung als Abschaltmöglichkeit?

Ja, wenn sie wirksam ist. Der Prüfschritt verweist ausdrücklich darauf, dass die Deaktivierung auch über Betriebssystemeinstellungen erfolgen kann. Verlassen sollte man sich darauf nur, wenn die Einstellung die eigene Anwendung tatsächlich erreicht. Im Zweifel ist der eigene Schalter der sichere Weg.