Ziehbewegungen: Warum Drag-and-drop eine Alternative braucht (WCAG 2.5.7)

Warum Ziehen für viele eine Hürde ist

Eine Ziehbewegung(englisch dragging movement ) ist im WCAG-Sinn eine Interaktion, bei der ein Zeiger ein Element beim Drücken aufnimmt und das Element dem Zeiger bis zum Loslassen folgt. Was nach einer einzigen Handbewegung aussieht, besteht in Wirklichkeit aus vier Teilschritten, die nahtlos ineinandergreifen müssen: den Startpunkt treffen, den Kontakt halten, den Zeiger bewegen und am Zielpunkt loslassen.

Schritt zwei und drei sind die eigentliche Hürde: Halten und gleichzeitig präzise bewegen. Menschen mit Tremor, Spastik oder eingeschränkter Feinmotorik verlieren dabei leicht den Kontakt oder das Ziel. Und wer mit Trackball, Kopfzeiger, Eye-Tracking oder einer sprachgesteuerten Maus-Emulation arbeitet, kann Ziehen oft nur umständlich und fehleranfällig ausführen. Ein einzelner Klick oder Tap ist dagegen für fast alle machbar.

Was WCAG 2.5.7 verlangt

Das Erfolgskriterium 2.5.7 „Ziehbewegungen" ist eines der neun neuen Kriterien der WCAG 2.2 (veröffentlicht im Oktober 2023) und gehört zur Stufe AA. Es verlangt: Jede Funktion, die über eine Ziehbewegung bedient wird, muss auch mit einem einzelnen Zeiger ohne Ziehen erreichbar sein. Es gibt nur zwei Ausnahmen: Das Ziehen ist essenziell, oder die Funktion stammt vom Browser selbst und wurde von dir nicht verändert.

Wie schon bei den Zeigergesten gilt: Das Kriterium verbietet nichts. Drag-and-drop darf bleiben, es ist für viele Menschen der schnellste Weg. Es braucht nur zusätzlich einen Weg über einfache Klicks oder Taps. Die zweite Ausnahme ist im Alltag wichtig, denn nicht jedes „Ziehen" auf einer Website liegt in deiner Verantwortung:

Ziehen ist keine Geste: Abgrenzung zu 2.5.1 und zur Tastatur

Auf den ersten Blick wirkt 2.5.7 wie eine Wiederholung des Kriteriums 2.5.1 „Zeigergesten". Der Unterschied steckt im Weg des Zeigers: Bei einer pfadbasierten Geste zählt die Bewegung selbst, etwa Richtung und Verlauf eines Wischs. Bei einer Ziehbewegung zählen dagegen nur Start- und Endpunkt; sobald das Element aufgenommen ist, spielt der Weg dazwischen keine Rolle. Genau deshalb fällt klassisches Drag-and-drop nicht unter 2.5.1, und genau diese Lücke schließt 2.5.7 in WCAG 2.2. Verlangt eine Komponente beides, etwa ein Slider, der nur reagiert, wenn der Zeiger exakt der Spur folgt, kann sie gegen beide Kriterien gleichzeitig verstoßen.

Die zweite wichtige Abgrenzung: Eine Tastatur-Alternative genügt nicht. Die Kriterien 2.1.1 und 2.1.3 verlangen ohnehin, dass Ziehen auch per Tastatur funktioniert. 2.5.7 wird davon aber nicht automatisch erfüllt, denn wer ein Smartphone oder Tablet ohne physische Tastatur nutzt, kann nicht tabben. Die Alternative muss per Klick oder Tap bedienbar sein. Ein Texteingabefeld zählt dabei als Ein-Zeiger-Alternative: Die Bildschirmtastatur, die sich für Touch-Nutzer:innen öffnet, wird per Tippen bedient.

Alternativen in der Praxis

Die gute Nachricht: Für praktisch jedes Drag-Muster gibt es ein erprobtes Klick-Pendant. Die Alternative muss dabei nicht dieselbe Komponente sein. Es genügt, wenn dieselbe Funktion auf derselben Seite ohne Ziehen erreichbar ist, etwa ein Zahlenfeld neben dem Farbwähler. Die W3C-Technik G219 beschreibt dieses Muster als ausreichend für das Kriterium.

Code-Beispiel: Slider mit Zahlenfeld koppeln

Das einfachste G219-Muster für Slider ist ein gekoppeltes Zahlenfeld: Beide Eingaben zeigen denselben Wert, jede Änderung am einen Element aktualisiert das andere. Damit haben Nutzer:innen drei Wege zum Ziel: ziehen, in die Spur klicken oder den Wert direkt eintippen.

<label for="lautstaerke">Lautstärke</label>
<input type="range" id="lautstaerke"
       min="0" max="100" step="5" value="40">
<label for="lautstaerke-wert">Lautstärke in Prozent</label>
<input type="number" id="lautstaerke-wert"
       min="0" max="100" step="5" value="40">

 // Das Zahlenfeld ist die Ein-Zeiger-Alternative zum Ziehen: 
 // Touch-Nutzer:innen tippen den Wert über die Bildschirmtastatur. 
const slider = document.querySelector('#lautstaerke');
const feld   = document.querySelector('#lautstaerke-wert');
slider.addEventListener('input', () => { feld.value = slider.value; });
feld.addEventListener('input', () => { slider.value = feld.value; });

Für Kanban-Boards und sortierbare Listen ist das Muster dasselbe, nur die Bedienoberfläche ändert sich: Nach dem Antippen eines Elements erscheinen Buttons oder ein Menü, die die Verschiebung ohne Ziehen auslösen. Wichtig ist, dass die Alternative sichtbar oder leicht auffindbar ist; eine Funktion, die niemand entdeckt, hilft niemandem.

Wann Ziehen essenziell ist

Wie bei den Zeigergesten ist die Essenziell-Ausnahme 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. Bei Ziehbewegungen trifft das fast nur zu, wenn die Bewegung selbst der Inhalt ist, etwa beim freien Zeichnen in einem Mal-Werkzeug: Eine Freihandlinie lässt sich nicht durch zwei Klicks ersetzen, ohne dass aus der Zeichnung etwas anderes wird.

Bemerkenswert ist, wie weit die W3C-Beispiele selbst bei scheinbar „untrennbaren" Drag-Interaktionen gehen: Sogar das Aufziehen eines Auswahlrechtecks auf einem Bild gilt nicht als essenziell, weil ein Auswahlmodus mit zwei Klicks (erste Ecke, zweite Ecke) dasselbe leistet. Die Ausnahme ist also wirklich für Sonderfälle reserviert.

Zwei Mythen zu Ziehbewegungen

Checkliste für Ziehbewegungen

Wie überall im Prinzip „Bedienbar" gilt: Was für Menschen mit motorischen Einschränkungen zwingend nötig ist, macht die Bedienung für alle robuster. Einen Slider-Wert exakt zu treffen ist auch mit ruhiger Hand auf einem kleinen Touchscreen mühsam; das Zahlenfeld daneben freut alle.