WCAG 2.5.1: Zeigergesten

WCAG 2.5.1 verlangt, dass jede Funktion, die eine Mehrfinger-Geste oder eine pfadbasierte Geste benötigt, auch mit einem einzigen Zeiger ohne Pfad bedienbar ist (also mit Tippen, Doppeltippen oder Tippen-und-Halten). Ausgenommen sind nur Gesten, die für die Funktion unentbehrlich sind, etwa das Zeichnen einer Unterschrift.

(Englisch: Pointer Gestures. Der BIK-BITV-Test nennt den Prüfschritt „Alternativen für komplexe Zeiger-Gesten“.)

Das Wichtigste in Kürze

• Zwei Gestenarten sind gemeint: Mehrpunkt-Gesten (zwei Finger zum Zoomen oder Drehen) und pfadbasierte Gesten (Wischen, Streichen entlang einer Strecke).
• Die Alternative muss mit einem Zeiger ohne Pfad funktionieren (ein Tippen, ein Klick, ein Halten). Sie muss sichtbar und auf derselben Ebene erreichbar sein.
• Drag-and-drop zählt nicht dazu. Beim Ziehen kommt es nur auf Anfang und Ende an, nicht auf den Weg. Dafür gibt es seit WCAG 2.2 das eigene Kriterium 2.5.7.
• Nur selbst gebaute Gesten zählen. Was Browser oder Betriebssystem bereitstellen (natives Scrollen, der Zoom des Browsers), fällt nicht unter das Kriterium.
• Eine Tastaturbedienung reicht nicht als Nachweis. 2.5.1 verlangt eine Alternative für Zeigereingaben; die Tastatur regelt 2.1.1.
• Geprüft wird auf dem Gerät. Der BITV-Test verlangt den Aufruf auf dem Smartphone, weil Desktop-Alternativen dort fehlen können.
• Häufigste Verstöße: Karussells nur per Wischen, Menüs, die vom Bildschirmrand hereingezogen werden, Karten nur mit Zwei-Finger-Zoom.
• Die Ausnahme ist eng: unentbehrlich ist eine Geste nur, wenn der Pfad selbst die Information ist (Unterschrift, Handschrifterkennung, Zeichenfläche).

Muss ich Wischgesten ersetzen?

Ja. Jede Funktion, die eine Mehrfinger- oder pfadbasierte Geste braucht, muss auch mit einem einzelnen Zeiger ohne Pfad bedienbar sein.

Das Kriterium kam 2018 mit WCAG 2.1 dazu, als Reaktion auf die Verbreitung von Touchscreens. Es unterscheidet zwei Arten von Gesten, die vielen Menschen nicht zur Verfügung stehen:

• Mehrpunkt-Gesten brauchen mehr als einen Kontaktpunkt gleichzeitig: Aufziehen mit zwei Fingern, Drehen, Zwei-Finger-Tippen, Drei-Finger-Wischen.
• Pfadbasierte Gesten setzen voraus, dass der Zeiger einen bestimmten Weg nimmt: Wischen nach links, Streichen vom Rand her, das Nachzeichnen eines Musters.

Für beide muss es einen Weg geben, der mit einem einzigen Zeiger und ohne Pfad funktioniert. In der Praxis heißt das: sichtbare Schaltflächen. Ein Karussell bekommt Vor- und Zurück-Knöpfe, eine Karte bekommt Plus und Minus, eine Liste mit Wisch-Aktionen bekommt ein Menü oder direkt sichtbare Schaltflächen.

Zwei Abgrenzungen entscheiden im Audit häufig über das Ergebnis:

Drag-and-drop ist keine pfadbasierte Geste. Beim Ziehen eines Elements von A nach B ist der Weg dazwischen bedeutungslos. Nur Start und Ziel zählen. Genau deshalb fällt Ziehen nicht unter 2.5.1. Es blieb bis 2023 ungeregelt und bekam dann mit WCAG 2.2 das eigene Kriterium 2.5.7 Ziehbewegungen auf Stufe AA. Wer eine Sortierliste per Ziehen baut, prüft also 2.5.7, nicht 2.5.1.

Nur selbst gebaute Gesten zählen. Das Aufziehen mit zwei Fingern, mit dem der Browser die ganze Seite vergrößert, ist eine Funktion des Betriebssystems. Sie steht ohnehin systemweit unter Kontrolle des Nutzers und fällt nicht unter das Kriterium. Sobald deine Karte diese Geste aber selbst abfängt und für ihren eigenen Zoom verwendet, ist sie deine Geste, und dann braucht sie Knöpfe.

Und noch ein Punkt, der oft falsch beantwortet wird: Die Tastatur rettet dich hier nicht. Wer nachweist, dass sich ein Karussell mit den Pfeiltasten bedienen lässt, hat 2.1.1 Tastatur erfüllt, aber nicht 2.5.1. Viele Menschen bedienen ein Touchgerät mit einem Stift, einem Knöchel oder einer Kopfmaus (ohne jede Tastatur). Die Alternative muss für den Zeiger da sein.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.5.1; das deutsche Prüfvorgehen beschreibt der Prüfschritt 2.5.1 des BIK BITV-Tests.

Wen betrifft es besonders?

Menschen mit motorischen Einschränkungen können koordinierte Bewegungen mit mehreren Fingern oft gar nicht ausführen. Bei Tremor gerät jeder Pfad ins Zittern, bei Spastik lässt sich der Druck nicht gleichmäßig halten, bei einer Prothese oder einem versteiften Gelenk gibt es den zweiten Kontaktpunkt schlicht nicht.

Wer mit Kopf-, Augen- oder Mundsteuerung arbeitet, hat technisch nur einen Zeiger. Viele dieser Eingabehilfen können überhaupt nur Einzelklicks erzeugen. Eine Zwei-Finger-Geste ist damit nicht schwierig, sondern unmöglich.

Screenreader-Nutzer auf Touchgeräten haben ein zusätzliches Problem: VoiceOver und TalkBack belegen die Standardgesten selbst. Ein Wischen nach rechts bedeutet dort „nächstes Element“, nicht „nächstes Bild im Karussell“. Selbst wenn die Fingerfertigkeit da ist, kommt die Geste gar nicht bei der Seite an.

Und dann die situative Gruppe: eine Hand am Haltegriff in der Bahn, ein Kind auf dem Arm, Handschuhe im Winter, ein Gipsarm. Zwei Finger sind eine Annahme, keine Selbstverständlichkeit.

Richtig & falsch im Code

Der Klassiker ist das Karussell, bei dem der Inhalt nur per Wischen erreichbar ist:

<!-- Falsch: die Inhalte liegen hinter einer Wischgeste -->
<div class="carousel" data-swipe-only>…</div>

<!-- Richtig: Wischen als Abkürzung, Knöpfe als Weg -->
<div class="carousel">
  <button type="button" class="prev">Vorheriges Angebot</button>
  <div class="slides" aria-live="polite">…</div>
  <button type="button" class="next">Nächstes Angebot</button>
</div>

Bei Karten reicht es nicht, sich auf den Zoom des Browsers zu verlassen, sobald die Bibliothek die Geste selbst abfängt:

// Falsch: die Bibliothek greift die Zwei-Finger-Geste ab, ohne Ersatz
karte.enablePinchZoom();

// Richtig: dieselbe Funktion zusätzlich über Schaltflächen
document.getElementById('zoom-plus')
  .addEventListener('click', () => karte.setZoom(karte.getZoom() + 1));
document.getElementById('zoom-minus')
  .addEventListener('click', () => karte.setZoom(karte.getZoom() - 1));

<div class="karte-steuerung">
  <button type="button" id="zoom-plus">Karte vergrößern</button>
  <button type="button" id="zoom-minus">Karte verkleinern</button>
</div>

Wisch-Aktionen in Listen (etwa „zum Löschen nach links wischen“) brauchen ein sichtbares Gegenstück. Am robustesten ist ein Menü pro Zeile, weil es auch bei mehreren Aktionen skaliert:

<!-- Richtig: die Wischgeste bleibt, die Aktion ist auch antippbar -->
<li class="mail">
  <a href="/mail/4711">Rechnung März 2026</a>
  <button type="button" aria-expanded="false" aria-controls="menu-4711">
    Aktionen für „Rechnung März 2026“
  </button>
  <ul id="menu-4711" hidden>
    <li><button type="button">Löschen</button></li>
    <li><button type="button">Archivieren</button></li>
  </ul>
</li>

Die Faustregel: Gesten sind ein Extra, kein Muss. Jede Geste bleibt erlaubt und erwünscht. Vorausgesetzt ist nur, dass derselbe Weg auch über ein sichtbares, antippbares Bedienelement führt. Muster dafür stehen unter Slider & Karussells und Menüs & Dropdowns.

So testest du es

1. Auf dem echten Smartphone aufrufen. Der BITV-Prüfschritt verlangt das ausdrücklich: Alternativen, die im Desktop-Browser vorhanden sind, können in der mobilen Ansicht fehlen. Der Geräteemulator der DevTools reicht dafür nicht.
2. Gesten inventarisieren. Wo wird gewischt, gestrichen, gezogen, aufgezogen, gedreht? Auch nach Menüs suchen, die man vom Bildschirmrand hereinzieht. Die sind besonders leicht zu übersehen, weil sie kein sichtbares Bedienelement haben.
3. Jede Geste einordnen. Selbst gebaut oder vom System? Mehrpunkt oder Pfad? Oder ist es Drag-and-drop und damit ein Fall für 2.5.7?
4. Die Alternative mit einem Finger suchen. Lässt sich dieselbe Funktion durch Tippen, Doppeltippen oder Tippen-und-Halten auslösen? Sichtbar auf derselben Ebene, nicht in einem Menü drei Ebenen tiefer?
5. Mit eingeschaltetem Screenreader gegenprüfen. VoiceOver oder TalkBack aktivieren und dieselbe Aufgabe erledigen. Wenn die Bedienung nur mit der Geste geht, funktioniert sie hier gar nicht mehr.
6. Am Rechner gegenprobieren. Alles nur mit einfachen Klicks bedienen, ohne „Maus-Wischen“ und ohne die Maustaste gedrückt zu halten. Was dabei liegenbleibt, ist der Befund.

Häufiger Fehler in der Praxis

Der häufigste Fall ist das Karussell mit unsichtbaren Knöpfen. Es gibt Vor- und Zurück-Schaltflächen, aber sie erscheinen erst beim Überfahren mit der Maus und auf dem Touchgerät gibt es kein Überfahren. Aus Sicht des Kriteriums existiert die Alternative damit nicht. Dasselbe gilt für Knöpfe, die per opacity: 0 erst bei :hover sichtbar werden.

Der zweite ist die Wisch-Navigation ohne Gegenstück: ein Menü, das man vom linken Rand hereinzieht. Das Muster stammt aus nativen Apps, wo es Konvention ist. Im Web ist es eine Geste ohne Anzeige. Es braucht zusätzlich einen sichtbaren Menüknopf, und zwar nicht nur als Ersatz, sondern weil sonst niemand ahnt, dass das Menü überhaupt existiert.

Der dritte ist ein Einordnungsfehler im Prüfbericht: Ein Kanban-Board mit Karten, die man zwischen Spalten zieht, wird gern als 2.5.1-Verstoß notiert. Ist es aber nicht. Ziehen ist keine pfadbasierte Geste, weil der Weg dazwischen egal ist. Der richtige Befund lautet 2.5.7 Ziehbewegungen, Stufe AA, seit WCAG 2.2. Ich sag’s mal so: Die Anforderung an die Umsetzung ist am Ende dieselbe. Im Bericht steht aber dann die richtige Nummer, und das erspart eine Diskussion mit dem Prüfer.

Häufige Fragen

Ist Drag-and-drop eine Zeigergeste im Sinne von 2.5.1?

Nein. Beim Ziehen zählen nur Anfangs- und Endpunkt, der Weg dazwischen ist ohne Bedeutung. Damit ist es keine pfadbasierte Geste. Das W3C nimmt Drag-and-drop ausdrücklich aus. Geregelt wird es seit WCAG 2.2 durch 2.5.7 Ziehbewegungen auf Stufe AA, das eine Alternative durch einfaches Antippen verlangt.

Reicht es, wenn die Funktion mit der Tastatur bedienbar ist?

Nein. 2.5.1 verlangt eine Alternative für Zeigereingaben. Viele Menschen bedienen ein Touchgerät mit Stift, Knöchel oder Kopfmaus und haben keine Tastatur zur Hand. Die Tastaturbedienung ist über 2.1.1 ohnehin Pflicht. Sie ersetzt die Ein-Zeiger-Alternative aber nicht.

Muss ich das Aufziehen mit zwei Fingern verbieten?

Nein, im Gegenteil. Das Kriterium verlangt keine Abschaffung von Gesten, sondern eine zusätzliche Möglichkeit. Wisch- und Zoom-Gesten sind für viele Menschen schnell und angenehm. Sie dürfen bleiben. Verboten ist nur, dass sie der einzige Weg sind. Und den Zoom des Browsers darfst du ohnehin nicht sperren, das verlangt 1.4.4.

Wann greift die Ausnahme „unentbehrlich“?

Wenn der Pfad selbst die Information ist. Eine Unterschrift besteht aus dem Weg, den der Stift nimmt; Handschrifterkennung ebenso; eine Zeichenfläche auch. Die Ausnahme greift nicht, wenn der Pfad nur die Bedienung ist. Ein Karussell zeigt Bilder, egal wie man weiterblättert.

Gilt das auch für Zeigergesten am Rechner?

Ja. Der Normtext spricht von Zeigereingaben allgemein, also auch von Maus, Trackpad und Stift. In der Praxis fällt es dort weniger auf, weil Mehrfinger-Gesten selten sind. Ein Regler, der sich nur durch Ziehen entlang einer Strecke verstellen lässt, ist aber auch am Rechner ein Befund.

Verwandte Themen

• 2.5.7 Ziehbewegungen: der Nachfolger für alles, was gezogen wird
• 2.5.2 Zeiger-Abbruch: Fehlbedienung verzeihen statt verhindern
• 2.5.8 Zielgröße (Minimum): die Ersatz-Schaltflächen müssen auch treffbar sein
• Slider & Karussells: das Bauteil mit den meisten Befunden
• Karten & Drag-and-drop: Muster für Kartendienste und Sortierlisten