Zeigergesten und Abbruch von Zeigeraktionen: Wischen, Ziehen, Loslassen, barrierefrei gedacht

Warum Gesten nicht für alle funktionieren

Ein einzelner Zeiger(englisch single pointer ) ist im WCAG-Sinn jede Eingabe, die genau einen Punkt auf dem Bildschirm anspricht: eine Maus, ein einzelner Finger auf dem Touchscreen, ein Stift. Dazu gehören Klicks, Doppelklicks, Taps und auch einfache Zieh- und Wischbewegungen. Mehrpunkt-Gesten brauchen dagegen zwei oder mehr Zeiger gleichzeitig, etwa das Zwei-Finger-Zoomen. Und pfadbasierte Gesten hängen nicht nur von Start- und Endpunkt ab, sondern vom Weg dazwischen, etwa ein Wisch, der in einer bestimmten Richtung und Geschwindigkeit ausgeführt werden muss.

Genau diese komplexen Gesten schließen Menschen aus: Wer mit Tremor, Spastik oder eingeschränkter Feinmotorik arbeitet, wer nur einen Finger, einen Kopfzeiger oder einen Eye-Tracker nutzt, kann eine präzise Zwei-Finger-Drehung oder einen schnellen Wisch oft nicht ausführen. Eine Bedienoberfläche, die solche Gesten als einzigen Weg anbietet, ist für diese Menschen schlicht verschlossen.

Kriterium 2.5.1: Jede Geste braucht eine Ein-Zeiger-Alternative

Das Erfolgskriterium 2.5.1 „Zeigergesten"(Stufe A) verlangt: Jede Funktion, die eine Mehrpunkt-Geste oder eine pfadbasierte Geste nutzt, muss auch mit einem einzelnen Zeiger ohne pfadbasierte Geste bedienbar sein, es sei denn, die Geste ist essenziell. Erlaubte Alternativen sind also einfache Interaktionen wie Tippen, Klicken, Doppelklicken oder Drücken-und-Halten.

Wichtig: Das Kriterium verbietet keine Gesten. Der schnelle Wisch durch die Bildergalerie darf bleiben, er ist für viele der bequemste Weg. Es muss nur zusätzlich einen einfachen Weg geben:

Kriterium 2.5.2: Aktionen müssen abbrechbar sein

Das zweite Kriterium setzt eine Ebene tiefer an, bei jeder einzelnen Zeiger-Interaktion. 2.5.2 „Abbruch von Zeigeraktionen"(Stufe A) verlangt: Für jede Funktion, die mit einem einzelnen Zeiger bedient wird, muss mindestens eine der vier folgenden Aussagen zutreffen. Hintergrund ist das Daneben-Tippen: Menschen mit motorischen Einschränkungen treffen häufiger das falsche Ziel und brauchen einen Weg, die Aktion noch zu verhindern oder zurückzunehmen.

Diese Tabelle ist zugleich die Eselsbrücke zum Kriterium: In fast allen Fällen erfüllst du 2.5.2 automatisch, wenn du Funktionen erst beim Loslassen auslöst. Genau das machen die nativen HTML-Elemente von Haus aus.

Das Up-Event als sicherer Standard

Der JavaScript- click -Event feuert bei Maus und Touch erst, wenn der Zeiger über dem Ziel losgelassen wird. Wer also schlicht click verwendet, bekommt das Abbruch-Verhalten geschenkt: Du drückst, merkst den Fehler, ziehst den Finger oder Zeiger vom Ziel weg und lässt erst dort los, nichts passiert. Probleme entstehen, wenn Aktionen vorzeitig an mousedown , pointerdown oder touchstart gehängt werden, das ist der dokumentierte Failure F101 zu diesem Kriterium:

 // ✕ Nicht konform: Aktion feuert schon beim Drücken, 
 //   kein Weg mehr, sie abzubrechen (Failure F101) 
button.addEventListener('pointerdown', bestellungAbsenden); // ✓ Konform: Aktion feuert beim Loslassen über dem Ziel. 
 //   Wegziehen vor dem Loslassen bricht ab. 
button.addEventListener('click', bestellungAbsenden);

Es gibt legitime Gründe für pointerdown , etwa um eine Zieh-Interaktion zu beginnen oder visuelles Feedback zu geben. Nicht konform ist nur, die eigentliche Funktion bereits beim Drücken abzuschließen, ohne einen der vier Wege aus der Tabelle anzubieten.

Drag-and-drop mit Rückweg

Drag-and-drop berührt beide Kriterien und ist deshalb das beste Übungsbeispiel. Ein konformes Karten-Board (etwa eine Aufgaben-Spalte) sieht so aus:

• 2.5.1, Alternative: Jede Karte bietet zusätzlich zur Zieh-Geste eine Ein-Zeiger-Bedienung, etwa ein Menü mit „Verschieben nach…" oder Hoch/Runter-Buttons. Davon profitiert nebenbei die Tastaturbedienung (Kriterium 2.1.1), die für Drag-and-drop ohnehin eine Alternative braucht.
• 2.5.2, Abbruch: Die Karte wird mit dem Drücken aufgenommen, mit dem Loslassen abgelegt. Loslassen außerhalb einer gültigen Ablagezone bricht ab und legt die Karte an ihren Ursprungsort zurück. Das ist die vom W3C in Technik G210 beschriebene Abbruch-Mechanik. Alternativ oder ergänzend: ein Rückgängig-Button nach dem Ablegen.

Wann „essenziell" wirklich greift

Beide Kriterien enthalten eine Ausnahme für essenzielle Fälle, und bei beiden ist sie eng gemeint. „Essenziell" heißt im WCAG-Glossar: Ohne dieses Verhalten würde sich die Funktion grundlegend ändern, und es gibt keinen konformen anderen Weg. Zwei anerkannte Beispiele:

• Pfad als Inhalt: Eine Unterschrift in einem Signatur-Feld ist selbst eine pfadbasierte Information, ein Klick kann sie nicht ersetzen (2.5.1).
• Down-Event als Funktionskern: Eine Bildschirm-Klaviertaste muss beim Drücken klingen, nicht beim Loslassen, sonst wäre es kein Klavier (2.5.2). Das W3C nennt ausdrücklich auch Tastatur-Emulation: Bildschirmtastaturen dürfen Buchstaben beim Drücken ausgeben.

Nicht essenziell ist dagegen fast alles, was nur Gewohnheit oder Design-Vorliebe ist: Ein Karussell muss nicht gewischt werden, eine Liste muss nicht per Swipe gelöscht werden. Im Zweifel gilt: Alternative anbieten.

Web oder App: wo dieses Thema spielt

Diese Seite behandelt Weboberflächen: Inhalte, die im Browser laufen und deren Gesten dein HTML, CSS und JavaScript interpretieren. Dieselben Grundideen gelten über die EN 301 549 auch für native iOS- und Android-Apps, dort aber mit eigenen Werkzeugen: Plattform-Gesten der Screenreader, System-APIs für alternative Eingaben und eigene Plattform-Konventionen. Wie Barrierefreiheit in nativen Apps funktioniert, behandelt unsere Sammelseite Barrierefreie Apps, vom WCAG-Transfer über VoiceOver bis TalkBack.

Checkliste für Gesten und Zeigeraktionen

Wie bei der Tastatur gilt auch hier: Was Menschen mit motorischen Einschränkungen zwingend brauchen, macht die Bedienung für alle fehlertoleranter. Den versehentlichen Tap auf „Kaufen" hat schließlich jede:r schon einmal gerade noch abgewendet, durch genau das Wegziehen, das 2.5.2 garantiert.