Karten & Drag-and-drop barrierefrei

Interaktive Karten und Drag-and-drop teilen sich 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.

Karten: Die Information zählt, nicht die Kachel

Die erste Frage ist ehrlich gestellt: Wozu ist die Karte da? In neun von zehn Fällen lautet die Antwort „Anfahrt/Standorte 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">
    Karte 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 Navi nutzbar.
• Der Karten-iframe braucht einen beschreibenden title.
• Bei Filialfinder & Co.: die Ergebnisliste ist der Hauptweg (durchsuchbar, als Liste ausgezeichnet), die Karte die Illustration dazu – nicht umgekehrt. Genau so behandeln es auch BITV und EU-Richtlinie: Karten sind ausgenommen, solange es für Navigationszwecke eine zugängliche Alternative gibt.

Wird die Karte selbst bedient, gelten die üblichen Regeln: Zoom über echte Buttons (nicht nur Pinch – 2.5.1), Verschieben auch per Pfeiltasten, Marker-Popups schließbar und fokussierbar. Und: Die Karte scrollt im eigenen Container, ohne die Seite zu kapern (Reflow-Ausnahme sauber genutzt).

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

Seit WCAG 2.5.7 „Ziehbewegungen“ ist es offiziell: Jede Zieh-Funktion braucht eine Ein-Zeiger-Alternative ohne Ziehen. Bewährte Muster je Fall:

• Liste umsortieren: „Nach oben/unten“-Buttons je Eintrag – zugleich der Tastaturweg.
• Kanban/Spalten: Element auswählen → „Verschieben nach …“-Menü mit 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.

<li class="task" draggable="true">
  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-label="Rechnung #4711 prüfen: verschieben nach …">⋯</button>
  </span>
</li>
<p role="status" id="sort-status"></p>

Nach jeder Verschiebung schreibt das Skript eine Statusmeldung („Rechnung #4711 an Position 2 von 5 verschoben“) – sonst passiert die Aktion für Screenreader-Nutzer lautlos. Beim Ziehen selbst gilt 2.5.2: Loslassen außerhalb der Zielzone bricht ab, statt Chaos anzurichten.

Randnotiz – die Alternative macht das Feature besser. Auf-/Ab-Buttons und „Verschieben nach“-Menüs sind nicht das Behinderten-Extra neben dem „echten“ Drag-and-drop – sie sind präziser (keine Zitter-Drops in die falsche Spalte), mobil zuverlässiger und automatisierbar. Wieder ein Fall von Curb-Cut.

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.
• Karten-Widget fängt das Scrollen der Seite – Zoom-Falle beim Vorbeiscrollen.
• Down-Event löst den Drop aus – Fehlklicks nicht abbrechbar.

Häufige Fragen

Muss die Karte selbst WCAG-konform sein?

Karten(-dienste) 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.

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

Kein fertiges Pattern im heutigen ARIA Authoring Practices Guide – gerade deshalb gilt: Interaktion über bewährte Bausteine lösen (Buttons, Menüs, Listen, Live-Region) statt aria-grabbed-Ruinen aus alten Spezifikationen zu kopieren (das Attribut ist veraltet).

Wie testet man das am schnellsten?

Maus weglegen: Lässt sich jede Karte bedienen, jede Liste umsortieren, jede Datei hochladen – nur mit Tastatur? Danach eine NVDA-Stichprobe: Werden Ergebnis und Position angesagt?

Fazit

Karten brauchen die Information als Text, Drag-and-drop braucht den Klick-Weg – beides fordert 2.5.7 schwarz auf weiß, beides macht die Komponente auch für alle anderen besser. Die Nachbar-Muster: sortierbare Tabellen für Daten, Slider & Karussells für geführte Bewegung, Status-Ansagen für das Feedback danach.