WCAG 2.5.2: Zeiger-Abbruch

WCAG 2.5.2 verlangt, dass Funktionen nicht schon beim Herunterdrücken des Zeigers auslösen, sondern erst beim Loslassen. Damit bleibt ein Fehlklick durch Wegziehen abbrechbar. Wer trotzdem auf das Down-Ereignis reagiert, muss einen Abbruch, ein Rückgängigmachen oder eine Rücknahme beim Loslassen anbieten.

(Englisch: Pointer Cancellation. Im BIK-BITV-Test heißt der Prüfschritt „2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden“.)

Das Wichtigste in Kürze

• Das native click-Ereignis erfüllt das Kriterium von Haus aus. Es feuert beim Loslassen und nur, wenn Drücken und Loslassen auf demselben Element lagen.
• Verstöße entstehen fast ausschließlich durch selbstgebaute Handler auf mousedown, touchstart oder pointerdown.
• Vier Bedingungen, eine genügt: kein Down-Ereignis, Abbruch möglich, Rücknahme beim Loslassen, oder das Down-Verhalten ist unverzichtbar.
• Unverzichtbar ist eng auszulegen: eine Klaviertastatur, eine virtuelle Tastatur, eine Zeichenfläche. Ein Menü, das beim Drücken aufgeht, gehört nicht dazu.
• Browserfunktionen bleiben außen vor. Das Kontextmenü der rechten Maustaste wird bei der Prüfung ignoriert.
• Auch Drag-and-drop fällt darunter: Loslassen außerhalb der Zielzone muss die Aktion abbrechen oder rückgängig machen lassen.
• Der Prüfschritt sieht ausdrücklich den Test auf dem Smartphone vor: antippen, Finger liegen lassen, beobachten, ob schon etwas passiert.
• Stufe A, seit WCAG 2.1 (2018) und über die EN 301 549 verbindlich.

Wann darf ein Klick auslösen?

Jede Bedienung mit einem Zeiger (Maus, Finger, Stift) besteht aus zwei Ereignissen: dem Herunterdrücken und dem Loslassen. Zwischen beiden liegt ein Moment, in dem sich ein Fehler noch korrigieren lässt: Man zieht den Finger zur Seite, lässt daneben los, und nichts passiert. Genau diesen Moment schützt 2.5.2.

Das Kriterium ist erfüllt, wenn mindestens eine von vier Bedingungen zutrifft:

1. Kein Down-Ereignis. Die Funktion wird nicht durch das Herunterdrücken ausgelöst. Das ist der Normalfall und der Grund, warum die allermeisten Websites das Kriterium ohne Zutun erfüllen.
2. Abbruch möglich. Die Aktion lässt sich vor Abschluss abbrechen oder danach rückgängig machen.
3. Rücknahme beim Loslassen. Das Loslassen macht rückgängig, was das Drücken begonnen hat (bei Drag-and-drop etwa das Zurücklegen an den Ursprungsort).
4. Das Down-Verhalten ist unverzichtbar. Bei einer virtuellen Klaviertastatur muss der Ton beim Drücken erklingen; alles andere wäre die Funktion selbst.

Der BIK-BITV-Test nennt drei Ereignisse als prüfrelevant: mousedown, touchstart und pointerdown. Wer im Code danach sucht und die Treffer durchgeht, hat den größten Teil der Prüfung erledigt. Ausdrücklich ausgenommen sind Browserfunktionen. Dass das Kontextmenü beim Drücken der rechten Maustaste erscheint, ist kein Verstoß deiner Seite.

Ein Punkt, der bei mehrstufigen Eingaben oft übersehen wird: Der Prüfschritt verlangt bei Drag-and-drop einen Weg, versehentlich ausgeführte Eingaben rückgängig zu machen (über eine Rückgängig-Schaltfläche, einen Bestätigungsdialog oder einen anderen Mechanismus). Das Kriterium hört also nicht beim Loslassen auf, sondern schließt die Frage ein, was nach einer Fehleingabe passiert.

Der Normtext steht im Understanding-Dokument des W3C zu 2.5.2, das deutsche Prüfvorgehen im Prüfschritt „2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden“.

Wen betrifft es besonders?

Menschen mit Tremor, Spastik oder Kraftverlust treffen seltener genau das, was sie treffen wollen. Für sie ist der Abbruch durch Wegziehen kein Komfort, sondern die einzige Korrekturmöglichkeit, die es zwischen Absicht und Wirkung gibt. Bei Parkinson kann die Hand beim Absenken abrutschen; wenn die Aktion schon beim Aufsetzen feuert, ist der falsche Knopf gedrückt, bevor die Bewegung überhaupt zu Ende ist.

Für Nutzende von Kopfsteuerung, Mundstab oder Switch-Bedienung kommt ein zweiter Aspekt dazu: Die Zeigerbewegung ist bei ihnen langsam und ungenau, und das Absetzen erfolgt nicht punktgenau. Ein Down-Ereignis unterwegs ist dort keine Ausnahme, sondern Alltag.

Menschen mit Sehbehinderung, die den Bildschirm stark vergrößern, tasten sich oft mit dem Zeiger an ein Element heran, um zu prüfen, ob es das richtige ist. Bei einem Down-Handler wird aus dem Tasten ein Auslösen.

Und dann der situative Fall, den jeder kennt: das Telefon in der einen Hand, der Bus fährt an. Der Daumen landet daneben. Ohne Abbruchmöglichkeit ist die Bestellung raus.

Richtig & falsch im Code

Die gute Nachricht zuerst: Wer native Elemente verwendet, ist fertig.

// Falsch: die Aktion feuert schon beim Drücken
loeschKnopf.addEventListener('pointerdown', eintragLoeschen);

// Richtig: click feuert beim Loslassen und nur, wenn
// Down und Up auf demselben Element lagen
loeschKnopf.addEventListener('click', eintragLoeschen);

Das ist keine Konvention, sondern in der Spezifikation so festgelegt: click wird nur ausgelöst, wenn Drücken und Loslassen dasselbe Element betreffen. Zieht man mit gedrückter Taste vom Knopf herunter, bleibt es aus. Genau das ist der Mechanismus, den 2.5.2 verlangt und genau deshalb ist der Griff zum nativen <button> hier die halbe Miete.

Verstöße entstehen dort, wo jemand aus Gründen der gefühlten Geschwindigkeit auf das Down-Ereignis wechselt:

// Falsch: „reagiert schneller" und löst beim Antippen aus,
// noch bevor der Finger wieder oben ist
karte.addEventListener('touchstart', () => oeffneDetails(karte.id));

// Falsch: Menü öffnet beim Drücken, schließt beim Loslassen
menuKnopf.addEventListener('mousedown', menuOeffnen);

Wo ein Down-Handler fachlich nötig ist (etwa beim Greifen eines eigenen Schiebereglers oder beim Start einer Ziehbewegung), ist er zulässig, solange die Rücknahme funktioniert:

// Richtig: Down startet nur das Ziehen, die Wirkung entsteht beim Up
griff.addEventListener('pointerdown', starteZiehen);

griff.addEventListener('pointerup', (e) => {
  if (!ueberZielzone(e)) {
    legeZurueck();   // Bedingung 3: Up nimmt zurück, was Down begann
    return;
  }
  uebernehmePosition(e);
});

// Richtig: zusätzlich ein Weg zurück nach abgeschlossener Aktion
zeigeHinweis('Karte verschoben.', {
  aktion: { text: 'Rückgängig', ausfuehren: stelleWiederHer },
});

Der Rückgängig-Hinweis ist dabei mehr als Kür. Der Prüfschritt nennt ihn als anerkannten Mechanismus für mehrstufige Eingaben und er hilft bei 3.3.4 Fehlervermeidung gleich mit. Wie so ein Hinweis angesagt wird, steht unter Live-Regionen.

Ein häufiger Sonderfall ist das lange Drücken:

// Falsch: Aktion nach 600 ms Halten, ohne Ausstieg
kachel.addEventListener('pointerdown', () => {
  timer = setTimeout(loescheKachel, 600);
});

// Richtig: Der Zeiger, der das Element verlässt, bricht ab
kachel.addEventListener('pointerdown', () => {
  timer = setTimeout(zeigeAktionsmenue, 600);
});
kachel.addEventListener('pointerleave', () => clearTimeout(timer));
kachel.addEventListener('pointerup', () => clearTimeout(timer));

So testest du es

1. Den Wegzieh-Test machen. Auf jedem folgenreichen Bedienelement (Löschen, Kaufen, Absenden, Abmelden) die Maustaste drücken, den Zeiger vom Element herunterziehen und dort loslassen. Es darf nichts passieren.
2. Auf dem Smartphone gegenprüfen. Element antippen und den Finger kurz liegen lassen, ohne loszulassen: Passiert schon etwas? Der Prüfschritt sieht genau diesen Handgriff vor.
3. Den Code durchsuchen nach mousedown, touchstart und pointerdown und jeden Treffer einordnen: Startet er nur eine Bewegung, oder löst er eine Aktion aus?
4. Drag-and-drop prüfen: Bricht das Loslassen außerhalb der Zielzone sauber ab? Gibt es nach einer Verschiebung einen Weg zurück?
5. Stichprobe genügt, wenn die Umsetzung gleichartig ist (etwa bei einer Komponentenbibliothek, die überall dieselben Knöpfe liefert).
6. Browserfunktionen ausklammern. Kontextmenü, Textmarkierung und Bildlaufleiste gehören nicht in den Befund.
7. Zielgröße nebenbei mitprüfen. Wer beim Wegzieh-Test häufig danebentrifft, findet meist zugleich einen Fall für 2.5.8 Zielgröße.

Häufiger Fehler in der Praxis

Der häufigste Verstoß entsteht aus einer guten Absicht: gefühlte Geschwindigkeit. Irgendwann in den 2010er-Jahren setzte sich in der App-Entwicklung die Idee durch, auf touchstart zu reagieren, weil das ein paar hundert Millisekunden spart. Diese Verzögerung existiert in modernen Browsern längst nicht mehr, das Muster aber schon (vor allem in älteren Komponentenbibliotheken). Wer eine solche Bibliothek einbindet, erbt den Verstoß, ohne eine Zeile selbst geschrieben zu haben.

Der zweite ist die Kachel mit Langdruck-Menü. In Verwaltungsoberflächen und Dashboards wird gern ein Kontextmenü über langes Drücken angeboten. Läuft dabei ein Timer, der nach ein paar hundert Millisekunden zuschlägt, ohne dass ein Wegziehen ihn stoppt, ist das ein klarer Fall. Der Fix sind zwei Zeilen: pointerleave und pointerup löschen den Timer.

Der dritte ist das Drag-and-drop ohne Rückweg. Die Karte lässt sich verschieben, das Loslassen außerhalb der Zielzone bricht sogar sauber ab. Wenn die Karte aber einmal in der falschen Spalte gelandet ist, gibt es kein Zurück außer erneutem Ziehen. Für Menschen, denen das Ziehen ohnehin schwerfällt, ist das keine Lösung. Ich würd bei jeder Sortier- und Verschiebefunktion einen Rückgängig-Hinweis einbauen; das deckt gleichzeitig 2.5.7 Ziehbewegungen und 3.3.4 mit ab.

Und ein Fehler, der selten auffällt: der selbstgebaute Knopf aus einem div. Wer statt eines <button> ein div mit Klick-Handler verwendet, verliert nicht nur Tastaturbedienbarkeit und Rolle, sondern oft auch das saubere Down-Up-Verhalten. Das liegt daran, dass die Ereignisse dann von Hand verdrahtet werden. Das native Element bringt all das mit.

Häufige Fragen

Erfüllt ein normaler Button das Kriterium automatisch?

Ja. Das click-Ereignis feuert beim Loslassen und nur dann, wenn Drücken und Loslassen dasselbe Element betrafen. Wer mit gedrückter Taste vom Knopf wegzieht, löst nichts aus. Solange keine eigenen Down-Handler dazukommen, ist bei nativen Elementen nichts zu tun.

Ist mousedown grundsätzlich verboten?

Nein. Verboten ist nur, damit eine Funktion auszulösen. Eine Ziehbewegung, ein Reglergriff oder das Setzen eines Startpunkts dürfen beim Drücken beginnen. Dann muss das Loslassen die Sache abschließen oder zurücknehmen. Der Unterschied liegt zwischen „etwas beginnen“ und „etwas tun“.

Was fällt unter die Ausnahme „unverzichtbar“?

Anwendungen, bei denen die Reaktion beim Drücken die Funktion selbst ist: virtuelle Klaviaturen, Bildschirmtastaturen, Zeichen- und Malflächen, teilweise Spiele. Ein Menü, das beim Drücken aufklappt, oder ein Formular, das beim Drücken absendet, fällt nicht darunter. Dort ist das Verhalten eine Entwurfsentscheidung, keine Notwendigkeit.

Gilt das Kriterium auch für Touchgeräte?

Ja, und der Prüfschritt sieht den Test dort ausdrücklich vor: antippen, Finger liegen lassen, beobachten. Auf Touchgeräten ist das Wegziehen sogar die geläufigere Korrektur. Wer daneben tippt, schiebt den Finger zur Seite, bevor er ihn hebt.

Zählt das Kontextmenü der rechten Maustaste als Verstoß?

Nein. Der Prüfschritt schließt Browserfunktionen aus. Dass das Kontextmenü beim Drücken erscheint, ist Verhalten des Browsers und nicht deiner Seite. Anders sieht es aus, wenn du ein eigenes Kontextmenü baust, das beim Down-Ereignis öffnet und dabei eine Aktion auslöst.

Verwandte Themen

• 2.5.7 Ziehbewegungen: jede Ziehfunktion braucht zusätzlich einen Klickweg
• 2.5.1 Zeigergesten: Mehrfinger- und pfadbasierte Gesten
• 3.3.4 Fehlervermeidung: das Sicherheitsnetz für folgenreiche Aktionen
• Buttons vs. Links: native Elemente, natives Verhalten
• Karten & Drag-and-drop: Ziehen mit Abbruch und Rückweg
• 2.5.8 Zielgröße (Minimum): damit man seltener danebentrifft