WCAG 2.5.7: Ziehbewegungen

WCAG 2.5.7 verlangt, dass jede Funktionalität, die eine Ziehbewegung verwendet, auch mit einem einzelnen Zeiger ohne Ziehen ausgeführt werden kann, es sei denn, das Ziehen ist wesentlich. Dies stellt sicher, dass Nutzer mit motorischen Beeinträchtigungen, die Ziehgesten nicht zuverlässig ausführen können, weiterhin auf alle Funktionalitäten zugreifen können.

Was diese Regel bedeutet

WCAG 2.5.7 — Dragging Movements (Level AA, eingeführt in WCAG 2.2) besagt, dass alle Funktionen, die für ihre Bedienung eine Ziehbewegung verwenden, auch durch eine einzelne Zeigeraktion ohne Ziehen ausführbar sein müssen, außer in Fällen, in denen die Ziehbewegung für die Funktionalität wesentlich ist und kein alternatives Verfahren existiert.

Eine Ziehbewegung ist definiert als eine Interaktion, bei der der Zeiger gedrückt, gehalten und an eine neue Position bewegt wird, bevor er losgelassen wird. Häufige Beispiele sind: Sortieren von Listenelementen per Drag-and-drop, Ändern der Größe von Panels durch Ziehen eines Trennbalkens, Verwenden eines Sliders durch Greifen und Ziehen des Schiebereglers, Zeichnen auf einer Zeichenfläche und Neuanordnen von Kanban-Karten. Alle diese Muster müssen eine gleichwertige Alternative mit einem einzelnen Zeiger bieten – einen Mechanismus, den der oder die Nutzer*in aktivieren kann, ohne die Zeigertaste während der Bewegung gedrückt halten zu müssen.

Die Einschränkung auf den einzelnen Zeiger ist wichtig. Die Alternative muss keine Tastenkombination sein; sie kann ein Mausklick, ein Tippen oder jede andere Aktion sein, die nur einen Kontaktpunkt umfasst und keine anhaltende Bewegung bei gedrücktem Zeiger erfordert. Ein Slider, der es Nutzer*innen beispielsweise erlaubt, direkt auf die Leiste zu klicken, um zu einem Wert zu springen, erfüllt das Kriterium, weil das Klicken auf die Leiste eine Einzelzeigeraktion ohne Ziehen ist.

Was als erfüllt gilt: Eine verschiebbare Liste, die zusätzlich Auf-/Ab-Pfeiltasten oder einen Dialog „An Position verschieben“ anbietet; ein Bereichs-Slider, der Klicks überall auf der Leiste akzeptiert; ein größenveränderbares Panel, das zusätzlich ein numerisches Eingabefeld oder eine „Doppelklick zum Einklappen“-Funktion hat; eine Karte, die sowohl durch Klicken auf Navigationspfeile als auch durch Ziehen verschoben werden kann.

Was als nicht erfüllt gilt: Eine sortierbare Liste, bei der die einzige Möglichkeit zum Neuanordnen von Elementen das Ziehen ist; ein Split-Pane-Resizer ohne alternative Bedienmöglichkeit; ein Datei-Upload, der nur Drag-and-drop akzeptiert und keine Button-Alternative bietet; ein Farbwähler, bei dem die einzige Möglichkeit zur Auswahl eines Farbtons darin besteht, über einen Farbverlauf zu ziehen, ohne numerische oder Texteingabe-Alternative.

Offizielle Ausnahme: Das Kriterium erlaubt ausdrücklich Oberflächen, die ausschließlich Ziehen verwenden, wenn Ziehen wesentlich ist – das heißt, wenn das Entfernen dieser Geste die Aktivität grundlegend verändern oder ungültig machen würde. Eine Gesten-Zeichnen-Anwendung oder ein Widget zur Erfassung von Unterschriften ist ein klassisches Beispiel. Diese Ausnahme ist jedoch bewusst eng gefasst; die meisten alltäglichen UI-Muster (Slider, sortierbare Listen, größenveränderbare Spalten) gelten nicht als Szenarien, in denen Ziehen wesentlich ist.

Warum das wichtig ist

Motorische Beeinträchtigungen betreffen einen erheblichen Teil der Weltbevölkerung. Laut Weltgesundheitsorganisation leben weltweit über 1,3 Milliarden Menschen – etwa 16 % der Weltbevölkerung – mit irgendeiner Form von Behinderung, und motorische oder körperliche Beeinträchtigungen gehören zu den häufigsten Kategorien. Erkrankungen wie essenzieller Tremor, Parkinson, RSI (Repetitive-Strain-Verletzungen), Hemiplegie, Rückenmarksverletzungen und Gliedmaßenunterschiede erschweren oder verunmöglichen es, eine Zeigertaste gedrückt zu halten und gleichzeitig den Zeiger präzise zu bewegen.

Für eine Person mit Handtremor ist es nicht nur unbequem, einen Slider-Schieberegler von einem Ende der Leiste zum anderen zu ziehen – es kann völlig unzuverlässig sein. Der Zeiger kann abrutschen, der Ziehvorgang kann während der Ausführung abgebrochen werden, oder die erforderliche Präzision übersteigt schlicht das, was Hände mit Tremor leisten können. Diese Nutzer*innen sind häufig auf klickbasierte Alternativen, Tastaturnavigation oder Schaltersteuerungsgeräte angewiesen. Wenn der einzige Weg zu einer Funktion ein Ziehgestus ist, ist die gesamte Funktion für sie faktisch unzugänglich.

Konkretes Szenario: Stellen Sie sich eine E-Commerce-Produktseite mit einem Preisbereichsfilter vor, der als Bereichsslider mit zwei Griffen implementiert ist. Eine Person mit eingeschränkter Feinmotorik versucht, den Preisbereich einzugrenzen, kann aber keinen der Griffe zuverlässig an die Zielposition ziehen – der Zeiger driftet, der Griff springt zu falschen Werten, und die Frustration führt dazu, dass die Aufgabe abgebrochen wird. Würde derselbe Filter zusätzlich ein Paar numerischer Texteingabefelder neben dem Slider bereitstellen, könnte diese Person einfach die gewünschten Mindest- und Höchstpreise eingeben und absenden. Diese eine Ergänzung verwandelt eine unzugängliche Funktion zu minimalen Entwicklungskosten in eine vollständig zugängliche.

Über motorische Beeinträchtigungen hinaus profitieren auch Nutzer*innen auf Touchscreens in herausfordernden Umgebungen – etwa beim Festhalten an einer Haltestange im öffentlichen Verkehr, beim Tragen von Handschuhen oder bei der Nutzung eines Stylus – von Alternativen mit einem einzelnen Zeiger. Auch die kognitive Zugänglichkeit spielt eine Rolle: Einfachere, klickbasierte Interaktionen verringern die kognitive Belastung im Vergleich zu Drag-and-drop-Operationen, die das Verständnis eines räumlichen Metaphers erfordern, während gleichzeitig physische Präzision aufrechterhalten werden muss.

Aus Sicht von Usability und SEO führt die Sicherstellung, dass interaktive Steuerelemente über einfache Zeigeraktionen erreichbar sind, tendenziell zu einer saubereren Komponentenarchitektur mit besserem semantischem Markup, was wiederum die Auffindbarkeit durch unterstützende Technologien und Suchmaschinen-Crawler verbessert.

Wie man testet

Automatisierter Scan als Basis: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um verwandte Probleme mit Zeiger- oder Eingabemodalitäten aufzudecken. Auch wenn keine axe-Regel direkt 2.5.7 abbildet, liefert die Überprüfung der unter 2.5.x gekennzeichneten Probleme nützlichen Kontext. Notieren Sie alle Komponenten, die von axe wegen unzureichender Tastaturunterstützung markiert werden, da diese häufig mit ausschließlich drag-basierten Mustern überlappen.
Alle verschiebbaren Komponenten identifizieren: Öffnen Sie Chrome DevTools, wechseln Sie zum Elements-Panel und verwenden Sie den Tab Event Listeners, um nach Handlern für dragstart, drag, drop, pointermove, mousemove und touchmove zu suchen. Alternativ können Sie im Seitenquelltext nach dem Attribut draggable und nach JavaScript-Mustern wie .addEventListener('dragstart' suchen. Listen Sie jede Komponente auf, die Ziehen erfordert.
Jede verschiebbare Komponente auf Alternativen testen: Versuchen Sie bei jeder identifizierten Komponente, dasselbe Ergebnis ausschließlich mit Einzelzeiger-Klicks oder -Taps – ohne Ziehen – zu erreichen. Klicken Sie bei einem Slider direkt auf die Leiste an der gewünschten Position. Suchen Sie bei einer sortierbaren Liste nach Verschiebe-Buttons oder Kontextmenüoptionen. Suchen Sie bei einem größenveränderbaren Panel nach Doppelklick- oder klickbasierten Steuerelementen. Wenn keine Alternative existiert, ist das Kriterium nicht erfüllt.
Prüfung der Tastaturnavigation (sekundäres Signal): Testen Sie alle verschiebbaren Komponenten ausschließlich mit der Tastatur (Tab zum Fokussieren, Pfeiltasten, Enter/Leertaste). Während die Tastaturunterstützung durch WCAG 2.1.1 abgedeckt ist, korreliert das Vorhandensein robuster Tastaturunterstützung häufig mit dem Vorhandensein von Alternativen ohne Ziehen, was diesen Schritt zu einer nützlichen Bestätigung macht. Verwenden Sie NVDA + Firefox, VoiceOver + Safari (macOS/iOS) oder JAWS + Chrome und verifizieren Sie, dass die vollständige Funktionalität der Komponente ohne Zeigegerät bedienbar ist.
Überprüfung auf Touch-Geräten: Versuchen Sie auf einem Mobilgerät oder mit der Geräteemulation im Touch-Modus in Chrome DevTools, dieselben Aufgaben mit Tippgesten (ohne Wischen-und-Halten) zu erledigen. Bestätigen Sie, dass einzelne Taps oder Tippen auf Ziele für alle Funktionen ausreichen.
Ergebnisse dokumentieren: Halten Sie für jede getestete Komponente fest, ob eine konforme Einzelzeiger-Alternative existiert, ob sie den vollen Funktionsumfang abdeckt und ob die Ziehoperation als wesentlich angesehen werden könnte. Verwenden Sie die manuelle Test-Checkliste für WCAG 2.5.7 in Accessibility Insights for Web als strukturierte Anleitung.

Wie man es behebt

Bereichs-Slider ohne Klick-auf-Leiste-Unterstützung – Falsch

<!-- Slider, der nur auf Ziehen am Schieberegler reagiert;
     Klicken auf die Leiste bewirkt nichts -->
<div class='slider-container'>
  <div class='slider-track'>
    <div class='slider-thumb'
         id='priceSlider'
         onmousedown='startDrag(event)'>
    </div>
  </div>
</div>

Bereichs-Slider mit Klick-auf-Leiste und numerischer Eingabe – Richtig

<!-- Das native <input type='range'> bietet Ziehen, Klick-auf-Leiste
     und Tastaturunterstützung von Haus aus. Eine numerische Eingabe
     bietet eine zusätzliche Einzelzeiger-Alternative. -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input type='range'
       id='priceRange'
       name='priceRange'
       min='0'
       max='1000'
       value='500'
       step='10'
       aria-valuemin='0'
       aria-valuemax='1000'
       aria-valuenow='500'
       oninput='document.getElementById("priceValue").textContent = this.value;
                document.getElementById("priceNumber").value = this.value;'>
<label for='priceNumber'>Or enter a value:</label>
<input type='number'
       id='priceNumber'
       name='priceNumber'
       min='0'
       max='1000'
       value='500'>

Drag-and-drop-sortierbare Liste ohne Alternative – Falsch

<!-- Elemente können nur durch Ziehen neu angeordnet werden.
     Es gibt keine Move-Buttons oder Tastatur-Neuanordnung. -->
<ul id='taskList'>
  <li draggable='true' ondragstart='handleDrag(event)' id='item1'>Task One</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item2'>Task Two</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item3'>Task Three</li>
</ul>

Drag-and-drop-sortierbare Liste mit Move-Buttons – Richtig

<!-- Drag-and-drop bleibt für Nutzer*innen erhalten, die es verwenden können.
     Move Up / Move Down-Buttons bieten für jedes Element eine
     Einzelzeiger- (und tastaturbedienbare) Alternative. -->
<ul id='taskList' aria-label='Sortable task list'>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item1'>
    <span>Task One</span>
    <button type='button'
            onclick='moveItem("item1", -1)'
            aria-label='Move Task One up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item1", 1)'
            aria-label='Move Task One down'>
      &darr; Move Down
    </button>
  </li>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item2'>
    <span>Task Two</span>
    <button type='button'
            onclick='moveItem("item2", -1)'
            aria-label='Move Task Two up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item2", 1)'
            aria-label='Move Task Two down'>
      &darr; Move Down
    </button>
  </li>
</ul>

Größenveränderbares Split-Pane ohne Alternative – Falsch

<!-- Der Teiler kann nur durch Ziehen verschoben werden.
     Es gibt keine Prozent-Eingabe oder Buttons für Voreinstellungen. -->
<div class='split-pane'>
  <div class='pane pane-left' id='leftPane'>Content A</div>
  <div class='divider'
       onmousedown='startResize(event)'
       aria-hidden='true'></div>
  <div class='pane pane-right' id='rightPane'>Content B</div>
</div>

Größenveränderbares Split-Pane mit Buttons für Voreinstellungen – Richtig

<!-- Der Teiler unterstützt weiterhin Ziehen, aber Layout-Buttons
     mit Voreinstellungen erlauben eine Einzelzeiger-Verschiebung.
     Der Teiler ist außerdem per Tastatur fokussierbar und mit
     Pfeiltasten bedienbar. -->
<div class='split-pane-wrapper'>
  <div class='split-controls' role='group' aria-label='Panel size presets'>
    <button type='button' onclick='setSplit(25)'>25 / 75</button>
    <button type='button' onclick='setsplit(50)'>50 / 50</button>
    <button type='button' onclick='setSplit(75)'>75 / 25</button>
  </div>
  <div class='split-pane'>
    <div class='pane pane-left' id='leftPane'>Content A</div>
    <div class='divider'
         role='separator'
         tabindex='0'
         aria-label='Resize panels'
         aria-valuenow='50'
         aria-valuemin='10'
         aria-valuemax='90'
         onmousedown='startResize(event)'
         onkeydown='resizeWithKeys(event)'>
    </div>
    <div class='pane pane-right' id='rightPane'>Content B</div>
  </div>
</div>

Häufige Fehler

Slider als benutzerdefinierte, auf <div> basierende Komponenten ohne Klick-auf-Leiste-Unterstützung implementieren, die sich vollständig auf das Ziehen des Schiebereglers verlassen und click-Events auf dem Leisten-Element selbst nicht verarbeiten, um den Wert an die angeklickte Position zu springen.
Anzunehmen, dass Drag-and-drop-Datei-Upload der einzige benötigte Upload-Mechanismus ist, ohne einen sichtbaren, anklickbaren Datei-Auswahl-Button (<input type='file'>) als verpflichtende Fallback-Option neben der Drop-Zone bereitzustellen.
Die Ausnahme der Wesentlichkeit zu breit anzuwenden – etwa indem eine sortierbare To-do-Liste oder ein Kanban-Board als „wesentliches Ziehen“ behandelt wird, obwohl Move-Up/Down-Buttons die Nutzerbedürfnisse vollständig ohne Funktionsverlust erfüllen würden.
Tastaturalternativen bereitzustellen, aber keine Einzelzeiger-Alternativen, indem WCAG 2.5.7 fälschlich so interpretiert wird, dass Tastaturunterstützung allein ausreicht. Das Kriterium verlangt ausdrücklich einen Einzelzeiger-Pfad; reine Tastaturlösungen adressieren 2.1.1, nicht 2.5.7.
Move-Buttons oder numerische Eingaben hinter Hover-Zuständen oder sekundären Menüs zu verstecken, die ihrerseits Ziehinteraktionen oder komplexe Zeigersequenzen erfordern, um sichtbar zu werden, wodurch die Zugänglichkeit der Alternative faktisch aufgehoben wird.
Touch-Geräte zu vernachlässigen, indem Alternativen zum Ziehen nur mit einer Desktop-Maus getestet werden und dann für Nutzer*innen auf Touchscreens bereitgestellt werden, bei denen sich das Verhalten von Ziehgesten und deren Alternativen deutlich von der Desktop-Implementierung unterscheiden kann.
pointer-events: none in CSS auf die Slider-Leiste anzuwenden, um versehentliche Klicks während des Ziehens zu verhindern, was unbeabsichtigt die Klick-auf-Leiste-Alternative blockiert, die 2.5.7 verlangt.
Keine Alternative für Kartenverschiebungen/-ziehinteraktionen bereitzustellen bei eingebetteten Karten oder benutzerdefinierten, canvas-basierten Visualisierungen, bei denen das Klicken auf Richtungspfeile oder die Eingabe von Koordinaten eine ausreichende Einzelzeiger-Alternative darstellen würde.
Die Einzelzeiger-Alternative selbst als Drag-and-drop-Ziel zu implementieren – etwa durch Erstellen einer „Hier ablegen“-Zone, die weiterhin ein Ziehen erfordert – statt eines wirklich anderen Interaktionsmodells wie eines Buttons oder einer Texteingabe.
Zu vergessen, Alternativen über den gesamten Wertebereich einer verschiebbaren Komponente zu testen. Ein Slider, der Nutzer*innen nur erlaubt, auf einige wenige voreingestellte Positionen auf der Leiste zu klicken, aber nicht auf beliebige Positionen, bietet keine vollständige Alternative, wenn die Ziehvariante kontinuierliche Werte unterstützt.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, etabliert einen umfassenden nationalen Rahmen für die Barrierefreiheit digitaler Dienste. Die Verfügung verpflichtet die erfassten Stellen zur Einhaltung der Web Content Accessibility Guidelines und verweist ausdrücklich auf die Konformität mit Level AA als Standard für den Erhalt des Erişilebilirlik Logosu (Barrierefreiheitslogo), des offiziellen Zertifizierungszeichens, das vom Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird.

WCAG 2.5.7 fällt als Level-AA-Kriterium, das in WCAG 2.2 eingeführt wurde, in den Anwendungsbereich der Anforderungen, die für den Erhalt und die Aufrechterhaltung des Barrierefreiheitslogos notwendig sind. Für Organisationen, die auf Drag-and-drop-Interaktionen angewiesen sind – etwa E-Commerce-Plattformen mit Produktfilter-Slidern oder sortierbaren Wunschlisten, Bankanwendungen mit Portfolio-Management-Dashboards oder Buchungstools von Reiseagenturen mit Datumsbereichs-Auswahl – würde eine Nichtkonformität mit 2.5.7 ein direktes Hindernis für die Zertifizierung darstellen.

Die von der Präsidialverfügung 2025/10 erfassten Stellen umfassen einen breiten Querschnitt der türkischen Digitalwirtschaft: öffentliche Institutionen und staatliche Stellen auf zentraler und lokaler Ebene; Banken und Finanzdienstleister, die der Aufsicht der Bankenregulierungs- und Aufsichtsbehörde (BDDK) unterliegen; E-Commerce-Plattformen, die in der Türkei tätig sind; Krankenhäuser und private Gesundheitsdienstleister; Telekommunikationsanbieter mit 200.000 oder mehr Abonnent*innen; Reiseagenturen und private Transportunternehmen; sowie Privatschulen, die vom Bildungsministerium (Milli Eğitim Bakanlığı — MoNE) autorisiert sind.

Für diese Organisationen ist das Versäumnis, Einzelzeiger-Alternativen zu Ziehinteraktionen bereitzustellen, nicht nur ein technischer Mangel – es ist eine Compliance-Lücke, die die Zertifizierung verhindern, die Organisation einer regulatorischen Prüfung aussetzen und einen erheblichen Teil der Nutzer*innen mit motorischen Beeinträchtigungen ausschließen kann. Die türkischen Statistiken zu Behinderungen spiegeln die globalen Trends wider: Millionen von Einwohner*innen leben mit Bedingungen, die die Feinmotorik beeinträchtigen, und digitale Dienste, die ausschließlich auf Ziehgesten beruhen, errichten für diese Bevölkerungsgruppe unnötige Barrieren.

Praktisch gesehen sollten Organisationen, die das Erişilebilirlik Logosu anstreben, WCAG 2.5.7 in ihre Barrierefreiheits-Audit-Checklisten aufnehmen, sicherstellen, dass alle interaktiven Komponenten mit Ziehfunktionalität auf konforme Alternativen überprüft werden, und ihre Konformitätsentscheidungen – einschließlich aller Berufungen auf die Ausnahme der Wesentlichkeit – als Teil ihrer Barrierefreiheits-Erklärung (Erişilebilirlik Beyanı) dokumentieren, die die Verfügung von den erfassten Stellen verlangt und deren Aktualität sie sicherstellen müssen.