WCAG 2.5.1: Zeigergesten

WCAG 2.5.1 verlangt, dass alle Funktionen, die Mehrpunkt- oder pfadbasierte Gesten verwenden (wie zum Beispiel Pinch-to-Zoom oder Wischen), auch mit einem einzelnen Zeiger ohne pfadbasierte Geste bedient werden können, es sei denn, die Geste ist wesentlich. Dies schützt Nutzer mit motorischen Beeinträchtigungen, die komplexe Touch-Gesten nicht zuverlässig ausführen können.

Was diese Regel bedeutet

WCAG 2.5.1 Pointer Gestures verlangt, dass jede Funktionalität auf einer Webseite, die auf Mehrpunktgesten angewiesen ist (Gesten mit zwei oder mehr gleichzeitigen Berührungspunkten, wie etwa ein Zwei-Finger-Zoom oder ein Drei-Finger-Wisch) oder auf pfadbasierten Gesten (Gesten, bei denen der vom Zeiger zurückgelegte Pfad relevant ist, wie ein Wisch, ein Ziehen entlang einer bestimmten Route oder eine gezeichnete Form), auch mit einem einzelnen Zeiger bedienbar sein muss, und zwar auf eine Weise, die keine pfadbasierte Geste erfordert. Ein einzelner Zeiger ist jede Eingabe, die an einem einzelnen Punkt arbeitet – dazu gehören eine einzelne Fingerberührung, ein Mausklick, ein Stift-Tipp und ähnliche Eingaben.

Praktisch bedeutet das: Wenn Ihr Karussell Folien weiterschaltet, wenn der Nutzer horizontal darüber wischt, müssen Sie zusätzlich Vor- und Zurück-Schaltflächen bereitstellen, die mit einem einzelnen Tipp oder Klick aktiviert werden können. Wenn Ihr benutzerdefiniertes Karten-Widget auf eine Zwei-Finger-Zoomgeste reagiert, müssen Sie außerdem Zoom-in- und Zoom-out-Steuerelemente bereitstellen, die nur einen einzelnen Tipp erfordern. Das Kriterium verbietet Mehrpunkt- oder pfadbasierte Gesten nicht – es verlangt lediglich, dass immer eine gleichwertige Alternative mit einem einzelnen Zeiger existiert.

Die offizielle WCAG-Ausnahme besagt: Die Anforderung gilt nicht, wenn die Mehrpunkt- oder pfadbasierte Geste wesentlich ist. Eine wesentliche Geste ist eine, deren Entfernung die Information oder Funktionalität grundlegend verändern würde und bei der Text oder eine andere Alternative denselben Zweck nicht erreichen kann. Ein Freihand-Signatur-Widget oder eine Zeichenanwendung, bei der der gezeichnete Pfad selbst die Ausgabe ist, würde als wesentlich gelten. Die überwiegende Mehrheit von Navigations-, Karussell-, Karten- und Slider-Interaktionen fällt jedoch nicht unter diese Ausnahme, da sie mit einfachen Tipp-/Klick-Alternativen ohne Informationsverlust repliziert werden können.

Dieses Kriterium gilt für alle Zeigereingaben: Touchscreens, Maus, Stift, Blickverfolgungszeiger und jedes andere Zeigegerät. Es ist eine Anforderung der Stufe A unter WCAG 2.2, was bedeutet, dass es als grundlegende Barrierefreiheitsanforderung gilt, die für eine minimale Konformität erfüllt sein muss.

Eine bestehende Implementierung bietet mindestens einen Mechanismus, um jede gestenabhängige Funktion mit einer Aktivierung durch einen einzelnen Punkt ohne Pfad zu erreichen – typischerweise eine sichtbare Schaltfläche, einen Link oder ein anderes fokussierbares Steuerelement. Eine nicht bestehende Implementierung verlässt sich ausschließlich auf eine Wisch-, Zoom-, Spreiz-, Rotations- oder gezeichnete Pfadgeste, um eine Funktion auszuführen, ohne eine gleichwertige Alternative mit einem einzelnen Zeiger bereitzustellen.

Warum das wichtig ist

Motorische Beeinträchtigungen betreffen einen erheblichen Teil der Weltbevölkerung. Erkrankungen wie Parkinson, essenzieller Tremor, Zerebralparese, Schlaganfall-bedingte Hemiplegie, Gliedmaßenunterschiede und Belastungsschäden können es für Nutzer schwierig oder unmöglich machen, präzise Mehrpunkt- oder pfadbasierte Gesten zuverlässig auszuführen. Laut der Weltgesundheitsorganisation leben weltweit etwa 1,3 Milliarden Menschen mit einer Form einer erheblichen Behinderung, und motorische und Mobilitätsbeeinträchtigungen gehören zu den häufigsten Kategorien. Wenn Weboberflächen ausschließlich auf komplexe Gesten angewiesen sind, werden diese Nutzer vollständig von Funktionen ausgeschlossen, die sehende, nicht behinderte Nutzer als selbstverständlich ansehen.

Betrachten Sie ein konkretes Szenario aus der realen Welt: Eine Nutzerin mit essenziellem Tremor surft auf einem Tablet auf einer türkischen E-Commerce-Seite. Die Produktbildgalerie verwendet ausschließlich eine Wischgeste, um zwischen Fotos zu wechseln. Die Nutzerin kann keinen sauberen horizontalen Wisch zuverlässig ausführen – ihr Tremor führt zu versehentlichen Tippbewegungen, diagonalen Bewegungen oder unbeabsichtigten Mehrfingerberührungen. Ohne Zurück-/Weiter-Schaltflächen kann sie keine weiteren Produktfotos ansehen und bricht den Kauf möglicherweise ganz ab. Zwei einfache Pfeilschaltflächen hinzuzufügen kostet das Entwicklungsteam nur wenige Minuten, beseitigt aber für diese Nutzerin eine vollständige Barriere.

Über motorische Beeinträchtigungen hinaus kommt dieses Kriterium auch Nutzern mit Prothesen der oberen Gliedmaßen oder Ein-Schalter-Zugangsgeräten zugute, die einen einzelnen Zeiger emulieren, Nutzern, die Geräte verwenden, die an Rollstühlen montiert sind, bei denen Rotation oder Multitouch mechanisch unpraktisch ist, und älteren Erwachsenen, die komplexe Touchgesten als nicht intuitiv oder schwer erlernbar empfinden. Nutzer, die ein Gerät mit einer Maus oder einem nicht-touchfähigen Stift bedienen, sind ebenfalls direkt betroffen – diese Eingabemethoden sind von Natur aus Ein-Zeiger-Eingaben und können Mehrpunktgesten überhaupt nicht ausführen.

Aus Nutzbarkeits- und Geschäftsperspektive verbessern explizite Steuerelemente für einen einzelnen Zeiger (Schaltflächen, Links) auch die Auffindbarkeit für alle Nutzer, reduzieren die kognitive Belastung und können sich positiv auf Aufgabenerfüllungsraten und Konversionskennzahlen auswirken. Suchmaschinen können außerdem schaltflächenbasierte Navigation zuverlässiger parsen und folgen als gestenbasierte Interaktionen, was sekundäre SEO-Vorteile für durchsuchbare Navigationsmuster bietet.

Wie man testet

Führen Sie einen automatisierten Scan als Basis durch: Verwenden Sie axe DevTools, Lighthouse oder das integrierte Audit des Accsible-Widgets, um die Seite zu scannen. Obwohl keine Regel direkt auf 2.5.1 abbildet, können die Scanergebnisse verwandte Probleme markieren (wie fehlende fokussierbare Steuerelemente), die Kontext für die manuelle Überprüfung liefern. Notieren Sie alle interaktiven Elemente, die wegen fehlender Tastatur- oder Zeigerunterstützung markiert werden.
Identifizieren Sie gestenabhängige Funktionalität: Erkunden Sie die Seite manuell auf einem Touchgerät (oder mit der Geräteemulation im Browser in den Chrome DevTools – aktivieren Sie die Gerätetoolleiste und interagieren Sie mit simuliertem Touch). Suchen Sie nach Karussells, Slidern, Karten, Akkordeons, Bildgalerien, scrollbaren Panels, Drag-and-Drop-Oberflächen, Zeichenwerkzeugen und allen anderen Komponenten, die auf Touchgesten reagieren. Dokumentieren Sie jede Funktion, die Sie entdecken und die durch einen Wisch, Zoom, eine Rotation oder eine andere pfadbasierte oder Mehrpunktgeste ausgelöst wird.
Versuchen Sie Ein-Zeiger-Äquivalente: Versuchen Sie für jede identifizierte gestenabhängige Funktion, dieselbe Funktion nur mit einzelnen Tipps (oder Mausklicks auf einem Desktop) auszuführen. Prüfen Sie, ob sichtbare Steuerelemente wie Schaltflächen, Pfeile oder Links vorhanden sind, die dasselbe Ergebnis auslösen. Versuchen Sie, diese Steuerelemente mit einer Maus, einer Tastatur (Tab zum Fokussieren, Enter/Leertaste zum Aktivieren) und einem Screenreader zu bedienen.
Screenreader-Überprüfung (NVDA + Firefox): Öffnen Sie NVDA und Firefox. Navigieren Sie mit Tab- und Pfeiltasten durch die interaktiven Komponenten. Vergewissern Sie sich, dass Ein-Zeiger-Steuerelemente (Schaltflächen, Links) für gestenbasierte Funktionen vom Screenreader angekündigt werden, über die Tastatur erreichbar sind und beim Aktivieren das erwartete Ergebnis liefern.
Screenreader-Überprüfung (VoiceOver + Safari auf iOS): Aktivieren Sie VoiceOver auf einem iPhone oder iPad. Wischen Sie mit einem Finger nach rechts, um durch Elemente zu navigieren. Vergewissern Sie sich, dass alle Steuerelemente, die Ein-Zeiger-Alternativen zu Gesten bieten, über VoiceOvers Tippgeste erreichbar und aktivierbar sind und dass sie das richtige Ergebnis liefern.
Screenreader-Überprüfung (JAWS + Chrome): Verwenden Sie JAWS mit Chrome unter Windows. Tabben Sie durch interaktive Komponenten und vergewissern Sie sich, dass gestenalternative Steuerelemente fokussierbar, korrekt beschriftet und funktionsfähig sind.
Bewerten Sie die wesentliche Ausnahme: Bestimmen Sie für jede gestenabhängige Funktion ohne Ein-Zeiger-Alternative, ob die Geste für den Inhalt oder die Funktionalität wirklich wesentlich ist. Wenn Sie die Ausnahme nicht rechtfertigen können, vermerken Sie dies als Fehler. Dokumentieren Sie Ihre Ergebnisse mit Screenshots und Schritten zur Reproduktion.

Wie man es behebt

Bildkarussell mit ausschließlich Wisch-Navigation – Falsch

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

Bildkarussell mit ausschließlich Wisch-Navigation – Richtig

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

Karte mit ausschließlich Pinch-to-Zoom – Falsch

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

Karte mit ausschließlich Pinch-to-Zoom – Richtig

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

Bereichsregler mit ausschließlich Drag-Pfad-Geste – Falsch

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

Bereichsregler mit ausschließlich Drag-Pfad-Geste – Richtig

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<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'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

Häufige Fehler

Bereitstellung von ausschließlich wischbasierten Karussells ohne Vor-/Zurück-Schaltflächen: Viele Karussell-Bibliotheken werden nur mit Gestenunterstützung ausgeliefert; Entwickler müssen Navigationsschaltflächen explizit konfigurieren und rendern, um eine Alternative mit einem einzelnen Zeiger bereitzustellen.
Ausblenden von Navigationsschaltflächen auf Touchgeräten über CSS-Media-Queries: Ein gängiges Muster blendet Pfeilschaltflächen auf Bildschirmen aus, von denen angenommen wird, dass es sich um Touchgeräte handelt (z. B. @media (pointer: coarse)), wodurch die Ein-Zeiger-Alternative für motorisch beeinträchtigte Nutzer entfernt wird, die selbst auf Touchscreens darauf angewiesen sind.
Verlassen auf eine Zwei-Finger-Pinch-Geste für Kartenzoom ohne Zoom-Schaltflächen: Eingebettete Karten von Drittanbietern (benutzerdefinierte Implementierungen) lassen häufig Zoom-Steuerelemente weg, sodass Pinch die einzige Zoom-Möglichkeit bleibt.
Verwendung von Wisch-zum-Löschen- oder Wisch-zum-Anzeigen-Mustern ohne alternative Aktionsschaltfläche: Listenelemente in Web-Apps, die Lösch- oder Aktionsoptionen nur über einen horizontalen Wisch anzeigen, haben keinen gleichwertigen tippbasierten Mechanismus für Nutzer, die nicht zuverlässig wischen können.
Benutzerdefinierte Drag-and-Drop-Oberflächen ohne alternative Tastatur- oder Klick-basierte Umordnung: Drag-Interaktionen sind von Natur aus pfadbasiert; das Versäumnis, einen alternativen Mechanismus bereitzustellen (wie Auf-/Ab-Schaltflächen oder ein Ausschneiden-und-Einfügen-Modell), verstößt gegen dieses Kriterium.
Zeichen- oder Signatur-Widgets, die davon ausgehen, dass der gezeichnete Pfad selbst nicht die Ausgabe ist: Entwickler berufen sich manchmal fälschlicherweise auf die „wesentliche“ Ausnahme für Widgets, die in Wirklichkeit nur UI-Steuerelemente sind (z. B. ein Gesten-Entsperrmuster zum Anzeigen von Inhalten) und keine echten Freihand-Eingabetools.
Platzierung von Ein-Zeiger-Alternativsteuerelementen außerhalb des sichtbaren Viewports oder standardmäßig in einem eingeklappten Zustand: Wenn die gleichwertigen Schaltflächen im DOM vorhanden sind, aber visuell verborgen sind oder eine zusätzliche Interaktion erfordern, um angezeigt zu werden, erfüllen sie die Anforderung an eine wahrnehmbare und bedienbare Ein-Zeiger-Alternative nicht vollständig.
Implementierung von Gestenbibliotheken, die Zeigerereignisse abfangen und Standardverhalten verhindern: Bibliotheken, die event.preventDefault() bei Touch-Ereignissen aufrufen, können unbeabsichtigt die eigenen Ein-Zeiger-Interaktionen und das Scrollen des Browsers blockieren und so unbeabsichtigte Fehler über das Gestenkriterium hinaus erzeugen.
Die Annahme, dass das Hinzufügen von aria-label zu einer ausschließlich gestenbasierten Zone ausreicht: Die Beschriftung eines Wischbereichs bietet keine Ein-Zeiger-Alternative – sie beschreibt ihn nur für Screenreader-Nutzer, die ihn ohne Gestenunterstützung dennoch nicht bedienen können.
Kein Testen auf realen Geräten oder mit Touch-Simulation: Entwickler, die nur auf dem Desktop mit einer Maus testen, stellen möglicherweise nie fest, dass eine Funktion auf Mobilgeräten ausschließlich gestenbasiert bedient wird, weil der Mausklick-Fallback auf dem Desktop zufällig funktioniert, der Touch-only-Codepfad jedoch kein Klick-Äquivalent hat.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Web- und Mobile-Barrierefreiheitsverpflichtungen für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung übernimmt WCAG 2.2 als normative technische Norm und macht damit alle Erfolgskriterien der Stufe A – einschließlich WCAG 2.5.1 Pointer Gestures – zu rechtlich verbindlichen Mindestanforderungen.

Der Zeitplan für die Einhaltung der Verfügung ist gestaffelt: Öffentliche Institutionen und Körperschaften sind verpflichtet, innerhalb eines Jahres nach Inkrafttreten der Verfügung Konformität zu erreichen, während private Sektorunternehmen, die unter die Regelung fallen, ein zweijähriges Zeitfenster haben, um vollständige Konformität zu erreichen. Die Nichteinhaltung setzt betroffene Einrichtungen der aufsichtsrechtlichen Prüfung und Durchsetzungsmaßnahmen durch die zuständigen Aufsichtsbehörden aus.

Die von der Verfügung erfassten Einrichtungen umfassen einen breiten Querschnitt türkischer digitaler Dienstanbieter. Öffentliche Institutionen auf allen Ebenen der Regierung und ihre angeschlossenen Körperschaften sind erfasst. Im privaten Sektor gilt die Verfügung für E-Commerce-Plattformen und -Marktplätze, Banken und Finanzinstitute, private Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Personenverkehrsunternehmen und Privatschulen, die unter Genehmigung des Ministeriums für Nationale Bildung (MoNE) tätig sind.

Für diese Organisationen hat WCAG 2.5.1 direkte und praktische Auswirkungen. Türkische E-Commerce-Seiten verwenden häufig gestengetriebene Produktbildgalerien, wischbasierte Kategorienavigation und Pinch-to-Zoom-Produktbetrachter – all diese müssen nun Alternativen mit einem einzelnen Zeiger haben. Bank- und Finanzanwendungen, die gestenbasierte Authentifizierungsmuster oder drag-basierte Transaktionsoberflächen verwenden, müssen geprüft und überarbeitet werden. Gesundheitsportale mit kartenbasierten Klinikfindern, die Pinch-Zoom verwenden, müssen Zoom-Schaltflächen bereitstellen. Self-Service-Portale von Telekommunikationsunternehmen mit wischgesteuerten Tarifwählern müssen tippbasierte Steuerelemente hinzufügen.

Organisationen, die in der Türkei tätig sind, wird dringend empfohlen, WCAG 2.5.1 sofort in ihre Barrierefreiheitsprüfungs-Checklisten aufzunehmen, da die von diesem Kriterium betroffenen Gesteninteraktionsmuster in modernem responsivem Webdesign und Mobile-First-Entwicklung allgegenwärtig sind – aber häufig übersehen werden, weil sie für die Mehrheit der Nutzer scheinbar korrekt funktionieren. Die proaktive Berücksichtigung dieses Kriteriums als Teil eines WCAG-2.2-Konformitätsprogramms der Stufe A ist sowohl eine rechtliche Verpflichtung gemäß der Präsidialverfügung 2025/10 als auch eine bedeutende Verbesserung der digitalen Inklusion für türkische Nutzer mit motorischen Beeinträchtigungen.