Karten & Drag-and-drop barrierefrei

Jede Funktion, die per Ziehbewegung bedient wird, braucht seit WCAG 2.2 einen zweiten Weg mit einem einzelnen Zeiger ohne Ziehen – Buttons, ein Verschieben-Menü oder ein Eingabefeld. Bei interaktiven Karten gilt derselbe Grundsatz für die Information selbst: Die Adresse gehört als Text auf die Seite, die Karte ist die Illustration dazu.

Interaktive Karten und Drag-and-drop teilen ein Grundproblem: Beide sind in ihrer Rohform reine Zeige-Interaktionen – ziehen, zoomen, greifen, fallen lassen. Für Tastaturnutzer, Screenreader und Menschen mit motorischen Einschränkungen braucht es gleichwertige Alternativen. Die gute Nachricht: Die Alternativen sind meist simpler als das Original – und regelmäßig präziser.

Das Wichtigste in Kürze

• WCAG 2.5.7 Ziehbewegungen (Stufe AA) verlangt: Jede Zieh-Funktion muss auch mit einem einzelnen Zeiger ohne Ziehen bedienbar sein – Ausnahmen nur, wenn das Ziehen unerlässlich ist oder der Browser die Funktion selbst bereitstellt.
• Tastaturbedienbarkeit allein erfüllt 2.5.7 nicht. Das Kriterium betrifft Zeigernutzung: Kopfmaus, Trackball, Stift, zitternde Hand. Eine Funktion kann per Tastatur perfekt sein und trotzdem durchfallen.
• Bewährte Klick-Wege: „Nach oben/unten“-Buttons bei Listen, ein „Verschieben nach …“-Menü bei Spalten, ein sichtbarer „Datei auswählen“-Button neben der Drop-Zone, Klick auf die Schiene bei Schiebereglern.
• Jede Verschiebung braucht eine Ansage per role="status" mit neuer Position – sonst passiert die Aktion für Screenreader-Nutzer lautlos.
• Das Ablegen darf nicht am Down-Event hängen. Loslassen außerhalb der Zielzone muss abbrechen (2.5.2).
• Für Drag-and-drop gibt es kein ARIA-Muster im ARIA Authoring Practices Guide. Die alten Attribute aria-grabbed und aria-dropeffect sind veraltet und wirkungslos.
• Bei Karten steht die Information im Text: Adresse kopierbar, Ergebnisliste als Hauptweg, <iframe> mit beschreibendem title.
• Online-Karten sind rechtlich ein Sonderfall: Artikel 1 Absatz 4 der EU-Richtlinie 2016/2102 nimmt sie aus, sofern bei Karten für Navigationszwecke die wesentlichen Informationen barrierefrei digital bereitstehen.

Was 2.5.7 genau verlangt

Der Wortlaut lohnt sich, weil er drei verbreitete Missverständnisse ausräumt: Jede Funktionalität, die eine Ziehbewegung nutzt, muss auch mit einem einzelnen Zeiger ohne Ziehen erreichbar sein – es sei denn, das Ziehen ist unerlässlich oder die Funktion wird vom Browser bereitgestellt und nicht vom Autor verändert.

Missverständnis 1: „Wir haben Tastaturbedienung, also sind wir durch.“ Nein. Das W3C stellt in der Erläuterung ausdrücklich klar, dass Tastaturbedienbarkeit dieses Kriterium nicht automatisch erfüllt. Wer mit einer Kopfmaus arbeitet, hat einen Zeiger und keine Tastatur – und für den muss ein Tippen genügen.

Missverständnis 2: „Das ist dasselbe wie 2.5.1 Zeigergesten.“ Nicht ganz. 2.5.1 betrifft pfadabhängige Gesten, bei denen der Weg zählt – Wischen, Streichen, Zwei-Finger-Zoom. Bei einer Ziehbewegung sind nur Anfangs- und Endpunkt von Bedeutung, der Weg dazwischen ist beliebig. Eine Interaktion kann beide Kriterien gleichzeitig verletzen.

Missverständnis 3: „Der native Scrollbalken müsste dann auch einen Klick-Weg haben.“ Muss er nicht – das ist die Browser-Ausnahme. Wer einen Scrollbalken aber selbst nachbaut, verliert sie.

Die Ausnahme „unerlässlich“ ist eng zu verstehen. Ein Zeichenprogramm, in dem die freie Linienführung der Zweck ist, fällt darunter. Ein Kanban-Board nicht: Dass eine Karte von einer Spalte in die andere kommt, ist das Ziel – dass man sie dabei zieht, ist eine Bedienweise unter mehreren.

Drag-and-drop: Ziehen als Komfort, Klicken als Weg

Bewährte Muster je Anwendungsfall:

• Liste umsortieren: „Nach oben/unten“-Buttons je Eintrag – zugleich der Tastaturweg.
• Kanban/Spalten: Element auswählen → „Verschieben nach …“-Menü mit den Zielspalten.
• Datei-Upload: Drop-Zone gern, aber der native „Datei auswählen“-Button (<input type="file">) bleibt sichtbar – er ist die robusteste Lösung im ganzen Muster.
• Schieberegler: <input type="range"> nehmen (Tastatur und Klick auf die Schiene kommen vom Browser) oder ein Zahlenfeld daneben anbieten.
• Zuschnitt, Farbwahl, Position: Werte per Eingabefeld setzbar machen. Das ist der Weg, den auch Grafikprogramme seit Jahrzehnten anbieten.

<li class="task">
  Rechnung #4711 prüfen
  <span class="task-actions">
    <button type="button" aria-label="Rechnung #4711 prüfen: nach oben">↑</button>
    <button type="button" aria-label="Rechnung #4711 prüfen: nach unten">↓</button>
    <button type="button" aria-expanded="false" aria-controls="ziel-4711">
      <span class="visually-hidden">Rechnung #4711 prüfen: </span>verschieben nach …
    </button>
    <ul id="ziel-4711" hidden>
      <li><button type="button">In Prüfung</button></li>
      <li><button type="button">Freigegeben</button></li>
      <li><button type="button">Archiv</button></li>
    </ul>
  </span>
</li>

<p role="status" id="sort-status"></p>

Nach jeder Verschiebung schreibt das Skript eine Statusmeldung: „Rechnung #4711 nach In Prüfung verschoben, Position 1 von 4.“ Drei Bestandteile gehören hinein – was verschoben wurde, wohin, und wo genau es jetzt liegt. Ohne die Position bleibt die Meldung eine Bestätigung ohne Orientierung.

Beim Ziehen selbst gilt 2.5.2 Zeiger-Abbruch: Die Aktion darf nicht beim Herunterdrücken ausgelöst werden, sondern beim Loslassen – und Loslassen außerhalb der Zielzone bricht ab, statt Chaos anzurichten. Praktisch heißt das: pointerup statt pointerdown, und ein Esc während des Ziehens setzt zurück.

Ein Wort zu ARIA: Es gibt kein fertiges Drag-and-drop-Muster im ARIA Authoring Practices Guide. Die Attribute aria-grabbed und aria-dropeffect aus ARIA 1.0 sind veraltet, werden von aktuellen Screenreadern nicht ausgewertet und sollten nicht mehr verwendet werden. Wer sie in einer Bibliothek findet, hat einen Hinweis auf ihr Alter gefunden, nicht auf ihre Qualität. Die Interaktion wird stattdessen über bewährte Bausteine gelöst: Buttons, Menüs, Listen, Live-Region.

Die Buttons brauchen dabei genug Fläche. Drei 16-Pixel-Symbole nebeneinander sind ein Trefferproblem für genau die Zielgruppe, für die man sie gebaut hat – Mindestmaß sind 24 × 24 Pixel, angenehm sind 44.

Karten: Die Information zählt, nicht die Kachel

Die erste Frage lautet: Wozu ist die Karte da? In den meisten Fällen ist die Antwort „Anfahrt und Standort zeigen“ – und dann ist die zugängliche Lösung vor allem Text:

<h2>So finden Sie uns</h2>
<p>
  Musterstraße 12, 50667 Köln<br />
  <a href="https://www.openstreetmap.org/?mlat=50.94&mlon=6.96#map=17/50.94/6.96">
    Standort auf OpenStreetMap öffnen
  </a>
  ·
  <a href="/anfahrt.html">Anfahrtsbeschreibung (ÖPNV &amp; Parken)</a>
</p>

<iframe
  src="…"
  title="Karte: Standort Musterstraße 12, Köln"
  loading="lazy"
></iframe>

• Adresse als Text vor der Karte – kopierbar, vorlesbar, fürs Navigationsgerät nutzbar. Und übrigens die Variante, die auch Sehende am häufigsten brauchen.
• Der Karten-iframe braucht einen beschreibenden title. „Karte“ ist keiner.
• Bei Filialfinder und Co.: die Ergebnisliste ist der Hauptweg – durchsuchbar, als Liste ausgezeichnet, mit Entfernung und Öffnungszeiten. Die Karte ist die Illustration dazu, nicht umgekehrt.

Genau so behandelt es auch das Recht: Artikel 1 Absatz 4 der EU-Richtlinie 2016/2102 nimmt Online-Karten und Kartendienste aus – sofern bei Karten, die der Navigation dienen, die wesentlichen Informationen in barrierefrei zugänglicher digitaler Form bereitstehen. Die Ausnahme ist also an eine Bedingung geknüpft, und diese Bedingung ist die Adresse im Text. Die deutsche Umsetzung übernimmt das; mehr zum Zusammenhang unter EU-Richtlinie 2016/2102.

Wenn die Karte selbst bedient wird

Sobald du eigene Bedienelemente um die Karte baust, gelten die normalen Regeln – die Ausnahme deckt die Karte, nicht deine Steuerung:

• Zoom über echte Buttons, nicht nur Pinch (2.5.1) und nicht nur Doppelklick.
• Verschieben auch per Pfeiltasten, wenn die Karte Fokus hat – und mit sichtbarem Fokusrahmen, damit man weiß, dass sie ihn hat.
• Marker-Popups sind schließbar und fokussierbar (1.4.13): Esc schließt, der Inhalt bleibt stehen, solange der Zeiger darin ist.
• Marker haben Namen. Ein Kartenstift ohne zugänglichen Namen ist ein Bedienelement ohne Beschriftung.
• Die Karte kapert das Scrollen nicht. Wer die Seite herunterscrollt und dabei über die Karte fährt, soll nicht plötzlich in Zoomstufe 3 landen. Der übliche Weg: Zoom per Mausrad erst nach einem Klick in die Karte aktivieren – und dann sichtbar sagen, dass es so ist.

Da würd ich mir bei fremden Karten-Widgets keine Illusionen machen: Die meisten eingebetteten Kartendienste erfüllen diese Punkte nur teilweise. Das ist ein Argument dafür, die Karte klein zu halten und die Arbeit in die Liste und die Anfahrtsbeschreibung zu stecken – dort wirkt jede Stunde mehr.

So testest du beides

1. Maus weglegen. Lässt sich jede Liste umsortieren, jede Karte verschieben, jede Datei hochladen – nur mit Tastatur?
2. Nur klicken, nicht ziehen. Der eigentliche 2.5.7-Test: Maus benutzen, aber die Maustaste nie gedrückt halten. Kommst du überall hin?
3. Zittertest. Beim Ziehen die Taste außerhalb der Zielzone loslassen. Bricht die Aktion ab, oder landet die Karte irgendwo?
4. NVDA-Stichprobe. Werden Ergebnis und Position nach dem Verschieben angesagt? Haben Marker und Zoom-Buttons Namen?
5. Scroll-Test. Über die Karte scrollen: Bleibt die Seite in Bewegung?

Häufige Fehler

• Karte ohne Adresse im Text – die Information existiert nur als Pixel.
• <iframe> ohne title, Marker ohne Namen.
• Upload nur per Drop-Zone, der Datei-Button wurde „weggestylt“.
• Sortieren nur per Griff – ohne Buttons, ohne Tastatur, ohne Ansage.
• Nur Tastatur-Alternative und kein Klick-Weg – erfüllt 2.1.1, nicht 2.5.7.
• Karten-Widget fängt das Scrollen der Seite – Zoom-Falle beim Vorbeiscrollen.
• Down-Event löst den Drop aus – Fehlklicks nicht abbrechbar.
• aria-grabbed nachgerüstet – veraltetes Attribut ohne Wirkung.
• Aktions-Buttons als 16-Pixel-Symbole – zu klein für die Zielgruppe.

Häufige Fragen

Muss die Karte selbst WCAG-konform sein?

Karten und Kartendienste gelten in EN 301 549 und Web-Richtlinie als Sonderfall: Für Navigationszwecke genügt die zugängliche Alternative – Adresse, Liste, Beschreibung. Eigene Bedienelemente, die du um die Karte herum baust, müssen aber regulär bedienbar sein. Und die Ausnahme gilt nur, wenn die Alternative wirklich existiert.

Gibt es ein offizielles ARIA-Muster für Drag-and-drop?

Nein. Der ARIA Authoring Practices Guide hat kein Drag-and-drop-Pattern, und die alten Attribute aria-grabbed/aria-dropeffect sind veraltet. Gerade deshalb gilt: Interaktion über bewährte Bausteine lösen – Buttons, Menüs, Listen, Live-Region – statt ARIA-Ruinen aus alten Spezifikationen zu kopieren.

Reicht es, wenn Drag-and-drop per Tastatur funktioniert?

Nein, und das ist der häufigste Prüffehler zu 2.5.7. Das Kriterium verlangt einen Weg mit einem einzelnen Zeiger. Wer eine Kopfmaus, einen Trackball oder einen Stift benutzt, hat keine Tastatur zur Hand – für den muss ein Tippen reichen. Tastatur ist zusätzlich Pflicht, aber über 2.1.1.

Sind Schieberegler von 2.5.7 betroffen?

Ja, wenn du sie selbst baust. Ein nativer <input type="range"> bringt Tastatursteuerung und den Klick auf die Schiene mit und fällt damit unter die Browser-Ausnahme. Ein nachgebauter Regler, der nur auf Ziehen reagiert, ist ein klarer Verstoß – ein Zahlenfeld daneben löst es in zwei Zeilen.

Wie sage ich eine Verschiebung an, ohne zu nerven?

Eine role="status"-Region, ein Satz, drei Angaben: was, wohin, welche Position. Bei Mehrfachaktionen kurz sammeln und einmal melden, statt fünf Meldungen hintereinander zu schicken. Details unter Live-Regionen.

Fazit

Karten brauchen die Information als Text, Drag-and-drop braucht den Klick-Weg – und zwar einen, der ohne Tastatur funktioniert. Beides fordert 2.5.7 seit WCAG 2.2 ausdrücklich, und beides macht die Komponente auch für alle anderen besser: Auf-/Ab-Buttons treffen präziser als jeder Drop, und die Ergebnisliste findet den Standort schneller als die Karte.

Das ist wieder ein Fall von Curb-Cut – die Alternative ist nicht das Extra neben dem „echten“ Bedienweg, sondern oft der bessere. Die Nachbar-Muster: sortierbare Tabellen für Daten, Slider & Karussells für geführte Bewegung, Status-Ansagen für das Feedback danach.

Quellen

• Understanding SC 2.5.7 Dragging Movements (W3C – Wortlaut, Ausnahmen und der Hinweis, dass Tastaturbedienung das Kriterium nicht erfüllt)
• Richtlinie (EU) 2016/2102 (EUR-Lex – Artikel 1 Absatz 4 mit der Ausnahme für Online-Karten und Kartendienste)