WCAG 2.5.7: Ziehbewegungen

WCAG 2.5.7 verlangt, dass jede Funktion, die eine Ziehbewegung braucht (Drag-and-drop, ein Schieberegler, eine verschiebbare Karte), auch mit einem einfachen Zeiger ohne Ziehen bedienbar ist: durch Tippen, Klicken oder Auswählen. Ausgenommen sind nur Fälle, in denen das Ziehen unverzichtbar ist oder vom Browser selbst kommt.

(Englisch: Dragging Movements. Der BIK-BITV-Test führt den Prüfschritt unter demselben Namen.)

Das Wichtigste in Kürze

• Ziehen heißt: greifen, bewegen, loslassen. Anfangs- und Endpunkt zählen, der Weg dazwischen ist egal. Genau das unterscheidet es von den pfadbasierten Gesten aus 2.5.1.
• Die Alternative muss für den Zeiger da sein, nicht für die Tastatur. Eine funktionierende Tastaturbedienung erfüllt 2.5.7 ausdrücklich nicht.
• Anerkannte Muster: Auswählen und Ziel aus einem Menü wählen, Pfeilknöpfe je Zeile, direktes Antippen der Reglerschiene, ein Zahlenfeld neben dem Regler.
• Was Browser und Betriebssystem beisteuern, zählt nicht: natives Scrollen, die Bildlaufleiste, Textmarkierung, Overflow-Bereiche.
• Unverzichtbar ist eng auszulegen. Eine Unterschrift entsteht durch die Bewegung. Ein Kanban-Board zeigt Aufgaben, egal wie sie in die Spalte kommen.
• Es gilt für Maus, Trackpad, Stift und Touch gleichermaßen. Der Normtext spricht von Zeigereingaben, nicht von Touchgeräten.
• Die Alternative muss sichtbar und auf derselben Ebene sein. Ein Menüpunkt drei Klicks tiefer ist im Prüfbericht keine Alternative.
• Häufigste Fundstellen: Preisregler in Shops, Sortierlisten in Redaktions- systemen, Kanban-Boards, Ablageflächen für Dateien, Kartenausschnitte.

Muss Drag-and-drop ersetzt werden?

Ja. Jede Funktion, die eine Ziehbewegung braucht, muss auch mit einem einfachen Zeiger ohne Ziehen bedienbar sein.

2.5.7 schließt eine Lücke, die WCAG 2.1 offen gelassen hatte. 2.5.1 Zeigergesten deckt Mehrfinger- und pfadbasierte Gesten ab. Also solche, bei denen die zurückgelegte Strecke die Bedeutung hat. Beim Ziehen ist der Weg aber bedeutungslos: Ob du eine Karte im Bogen oder in gerader Linie in die Zielspalte schiebst, spielt keine Rolle. Damit fiel Drag-and-drop bis 2023 durch jedes Raster. Seit WCAG 2.2 hat es sein eigenes Kriterium auf Stufe AA.

Der Kern ist eine einzige Frage: Kommt man auch ohne gedrückt gehaltene Taste ans Ziel? Der BITV-Prüfschritt bringt es auf den Punkt: „Selbst die einfachste Ziehbewegung erfordert eine recht präzise Steuerung des Zeigers.“ Halten und gleichzeitig genau bewegen ist die Kombination, die vielen Menschen nicht zur Verfügung steht.

Zwei Abgrenzungen entscheiden im Audit über das Ergebnis:

Nicht jedes Ziehen ist deins. Natives Scrollen, das Verschieben der Bildlaufleiste, das Markieren von Text, ein Bereich mit overflow: auto. All das stellt der Browser bereit und steht ohnehin unter der Kontrolle des Nutzers. Sobald deine Anwendung die Bewegung aber selbst abfängt und interpretiert, ist es deine Ziehbewegung, und dann braucht sie einen zweiten Weg.

Die Tastatur rettet dich hier nicht. Das ist der Punkt, an dem die meisten Selbsteinschätzungen kippen. Der Prüfschritt fragt ausdrücklich nach einer Alternative für einfache Zeigereingaben. Wer nachweist, dass sich die Sortierliste mit Pfeiltasten bedienen lässt, hat 2.1.1 Tastatur erfüllt. 2.5.7 bleibt offen. Viele Menschen bedienen ein Touchgerät mit einem Stift, einem Knöchel oder einer Kopfmaus und haben gar keine Tastatur in Reichweite.

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

Wen betrifft es besonders?

Menschen mit Tremor, Spastik oder Kraftverlust scheitern genau an der Kombination: gedrückt halten und präzise bewegen. Ein Klick ist ein kurzer Moment, in dem die Hand still sein muss; eine Ziehbewegung verlangt Ruhe über die gesamte Strecke. Bei Parkinson oder Multipler Sklerose löst sich der Griff unterwegs. Die Karte landet irgendwo, oft mit ungewollten Folgen.

Wer mit Kopfmaus, Eye-Tracking oder Mundstab arbeitet, kann in der Regel klicken, aber kaum kontinuierlich ziehen. Bei Eye-Tracking ist ein „Halten“ physisch anstrengend, weil der Blick fixiert bleiben muss, während sich der Zeiger bewegt.

Sprachsteuerung hat für Klicks einen fertigen Befehl: „Klicke Speichern“. Für Ziehbewegungen gibt es praktisch keinen. Dragon kennt ein Mausraster, mit dem sich Ziehen simulieren lässt; das dauert allerdings mehrere Schritte und ist in der Praxis kaum benutzbar.

Und der situative Fall, den jeder kennt: Trackpad im Zug, eine Hand am Kaffee. Eine Ziehbewegung mit dem Finger auf dem Trackpad ist unter Erschütterung eine Wette.

Richtig & falsch im Code

Der häufigste Fall ist die sortierbare Liste. Der Griff darf bleiben. Er braucht nur Gesellschaft:

<!-- Falsch: Umsortieren geht ausschließlich über den Ziehgriff -->
<li draggable="true">
  <span class="griff" aria-hidden="true">⠿</span>
  Newsletter-Anmeldung
</li>

<!-- Richtig: Ziehen bleibt als Abkürzung, Knöpfe sind der Weg -->
<li draggable="true">
  <span class="griff" aria-hidden="true">⠿</span>
  Newsletter-Anmeldung
  <span class="reihenfolge">
    <button type="button" aria-label="Newsletter-Anmeldung nach oben">↑</button>
    <button type="button" aria-label="Newsletter-Anmeldung nach unten">↓</button>
  </span>
</li>

Bei mehr als einer Handvoll Einträgen wird das Klicken mit Pfeilknöpfen mühsam. Dann ist ein Zielmenü die bessere Lösung. Der BITV-Prüfschritt nennt genau dieses Muster als anerkannte Alternative:

<!-- Richtig: Element auswählen, Ziel aus einer Liste wählen -->
<li>
  Newsletter-Anmeldung
  <button type="button" aria-expanded="false" aria-controls="ziel-4711">
    Verschieben nach …
  </button>
  <ul id="ziel-4711" hidden>
    <li><button type="button">Position 1</button></li>
    <li><button type="button">Position 2</button></li>
    <li><button type="button">Ans Ende</button></li>
  </ul>
</li>

Beim Schieberegler ist der native Weg fast immer der beste: input type="range" lässt sich auch durch Klicken auf die Schiene setzen, ohne dass du etwas tust. Wer einen eigenen Regler baut, muss das nachbilden und sollte ein Zahlenfeld danebenstellen:

<!-- Richtig: nativ, plus ein Feld für die genaue Eingabe -->
<label for="preis-max">Höchstpreis</label>
<input type="range" id="preis-max" name="preis-max"
       min="0" max="500" step="10" value="250" />
<label for="preis-zahl" class="visually-hidden">Höchstpreis in Euro</label>
<input type="number" id="preis-zahl" min="0" max="500" step="10" value="250" />

// Falsch: eigener Regler, der nur auf Ziehen reagiert
schiene.addEventListener('pointerdown', starteZiehen);

// Richtig: derselbe Regler nimmt auch einen einzelnen Klick entgegen
schiene.addEventListener('click', (e) => {
  const box = schiene.getBoundingClientRect();
  const anteil = (e.clientX - box.left) / box.width;
  setzeWert(Math.round(anteil * (max - min) + min));
});

Für Ablageflächen gilt: Das native <input type="file"> bringt seinen Knopf schon mit. Wer die Ablagefläche baut, darf das Feld nicht wegwerfen, sondern legt es darüber oder daneben:

<!-- Richtig: Ablagefläche als Zugabe, das Feld bleibt bedienbar -->
<div class="ablage">
  <p>Datei hierher ziehen. Oder:</p>
  <label for="datei">Datei auswählen</label>
  <input type="file" id="datei" name="anhang" />
</div>

Das ausführliche Muster inklusive Statusansage über eine Live-Region steht unter Karten & Drag-and-drop; Reglerdetails stehen unter Toggles & Custom Controls.

So testest du es

1. Inventur machen. Wo wird auf der Seite gezogen? Regler, Sortierlisten, Kanban-Spalten, Ablageflächen, Kartenausschnitte, Terminraster, Bildzuschnitte, Vorher-Nachher-Schieber.
2. Jede Stelle einordnen. Ist es wirklich Ziehen (Start und Ziel zählen) oder eine pfadbasierte Geste? Letztere gehört zu 2.5.1, nicht hierher.
3. Kommt es vom Browser? Natives Scrollen, Bildlaufleiste, Textmarkierung und Overflow-Bereiche fallen heraus. Alles, was dein JavaScript abfängt, bleibt drin.
4. Nur mit einzelnen Klicks bedienen. Maustaste bewusst nie gedrückt halten: Lässt sich dieselbe Aufgabe erledigen? Das ist der eigentliche Prüfschritt.
5. Auf dem Touchgerät wiederholen. Manche Alternativen erscheinen nur in der Desktop-Ansicht und ausgerechnet auf dem Handy fehlen sie dann.
6. Sichtbarkeit prüfen. Erscheinen die Ersatz-Knöpfe erst beim Überfahren mit der Maus? Auf einem Touchgerät gibt es kein Überfahren, dann existiert die Alternative aus Sicht des Prüfschritts nicht.
7. Zielgröße gegenprüfen. Kleine Pfeilknöpfe lösen 2.5.7 und reißen dafür 2.5.8 Zielgröße ein. 24 × 24 CSS-Pixel sind das Minimum.

Häufiger Fehler in der Praxis

Der Klassiker ist die Sortierliste im Redaktionssystem. Redakteure ziehen Menüpunkte, Seitenreihenfolgen und Slider-Bilder in Position; alternative Knöpfe gibt es nicht, weil „das ja jeder kann“. Solange das Werkzeug nur intern läuft, fällt es nicht auf. Erst wenn jemand mit Tremor im Team anfängt oder das Backend selbst Teil des Prüfumfangs wird, fällt es auf. Und öffentliche Stellen müssen ihre internen Anwendungen nach BITV 2.0 ebenfalls barrierefrei bereitstellen.

Der zweite ist der selbstgebaute Preisregler im Shop-Filter. Native input type="range"-Elemente sind schwer zu gestalten, also wird ein eigener Regler gebaut und der reagiert nur auf pointermove. Ein Klick auf die Schiene tut nichts, ein Zahlenfeld gibt es nicht. Da beiß ich mir bei fast jedem Shop-Audit auf die Zunge: Die zwei Zeilen für den Klick auf die Schiene wären in zehn Minuten erledigt gewesen.

Der dritte ist das Kanban-Board mit falscher Nummer im Bericht. Karten, die man zwischen Spalten zieht, werden gern als 2.5.1-Verstoß notiert. Ist es aber nicht. Der Weg der Karte ist bedeutungslos, damit fällt es unter 2.5.7. Für die Umsetzung ändert das nichts, für die Diskussion mit dem Prüfer schon.

Und ein Argument, das immer wieder kommt: „Wir haben doch Tastaturbedienung eingebaut.“ Gut so. 2.1.1 ist damit erfüllt. Für 2.5.7 zählt es nicht, weil das Kriterium ausdrücklich eine Alternative für Zeigereingaben verlangt. Beides ist Pflicht, keines ersetzt das andere.

Häufige Fragen

Zählt Drag-and-drop nicht schon unter 2.5.1 Zeigergesten?

Nein, und das ist genau die Lücke, die 2.5.7 schließt. 2.5.1 regelt Mehrfinger- und pfadbasierte Gesten, bei denen die Strecke die Bedeutung hat. Beim Ziehen zählen nur Anfangs- und Endpunkt. Deshalb blieb Drag-and-drop bis WCAG 2.2 ungeregelt und hat seit 2023 sein eigenes Kriterium auf Stufe AA.

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

Nein. Der Prüfschritt verlangt eine Alternative mit einfachem Zeiger: Tippen oder Klicken genügt. Eine funktionierende Tastaturbedienung erfüllt 2.1.1, lässt 2.5.7 aber offen. Wer mit Stift, Kopfmaus oder Knöchel auf einem Tablet arbeitet, hat keine Tastatur zur Hand.

Muss ich Drag-and-drop abschaffen?

Nein. Das Kriterium verlangt eine zusätzliche Möglichkeit, kein Verbot. Ziehen ist für viele Menschen schnell und angenehm. Es darf bleiben. Unzulässig ist nur, dass es der einzige Weg ist. Die Faustregel: Ziehen ist ein Extra, kein Pflichtweg.

Fällt Scrollen mit gedrückter Maustaste auch darunter?

Nein, solange es der Browser macht. Natives Scrollen, das Ziehen der Bildlaufleiste und Bereiche mit overflow: auto sind ausdrücklich ausgenommen, ebenso das Markieren von Text. Sobald deine Anwendung die Bewegung selbst abfängt (etwa für einen eigenen Kartenausschnitt), ist es deine Ziehbewegung.

Wann greift die Ausnahme „unverzichtbar“?

Wenn ohne die Bewegung die Funktion selbst verloren geht. Eine Unterschrift besteht aus dem Weg, den der Stift nimmt; eine freie Zeichenfläche ebenso. Die Ausnahme greift nicht, wenn das Ziehen nur die Bedienung ist. Ein Kanban-Board zeigt Aufgaben, unabhängig davon, wie sie in die Spalte gelangen.

Verwandte Themen

• 2.5.1 Zeigergesten: die Abgrenzung zu pfadbasierten Gesten
• 2.5.8 Zielgröße (Minimum): die Ersatzknöpfe müssen auch treffbar sein
• 2.1.1 Tastatur: die zweite Pflicht, die 2.5.7 nicht ersetzt
• Karten & Drag-and-drop: das vollständige Umsetzungsmuster
• Toggles & Custom Controls: Regler, die auch auf Klicks hören
• Die neuen WCAG-2.2-Kriterien: alle Neuerungen im Überblick