Wie erkennt man Barrierefreiheitsprobleme bei eingebetteten Karten?

Barrierefreiheitsprobleme bei eingebetteten Karten entstehen typischerweise dort, wo interaktive Elemente weder per Tastatur bedienbar noch für Screenreader lesbar sind. Google Maps, OpenStreetMap und ähnliche Kartendienste werden meist als iFrame eingebunden und bringen von Haus aus eine Reihe technischer Schwachstellen mit, die Nutzerinnen und Nutzer mit Behinderungen ausschließen können. Dieser Artikel beantwortet die wichtigsten Fragen rund um das Thema Barrierefreiheit bei eingebetteten Karten und zeigt, wie Sie Probleme erkennen, testen und beheben.

Welche Barrierefreiheitsprobleme treten bei eingebetteten Karten am häufigsten auf?

Die häufigsten Barrierefreiheitsprobleme bei eingebetteten Karten sind fehlende Alternativtexte, mangelnde Tastaturbedienbarkeit, unzureichende Farbkontraste und fehlende ARIA-Beschriftungen. Da Kartendienste meist als iFrame eingebunden werden, fehlen dem äußeren HTML-Dokument oft alle semantischen Informationen, die Screenreader benötigen, um den Inhalt sinnvoll vorzulesen.

Im Einzelnen treten folgende Probleme besonders häufig auf:

• Fehlender Titel am iFrame: Ein iFrame ohne aussagekräftiges title-Attribut gibt Screenreader-Nutzenden keine Information darüber, was sich im eingebetteten Bereich befindet.
• Keine Tastaturbedienbarkeit: Interaktive Kartenelemente wie Zoom-Buttons, Marker oder Menüs sind häufig nur per Maus erreichbar. Nutzerinnen und Nutzer, die ausschließlich die Tastatur verwenden, können die Karte weder navigieren noch verlassen.
• Unzureichende Farbkontraste: Kartenbeschriftungen, Straßennamen und Markierungen erfüllen oft nicht die WCAG-Kontrastanforderungen, was für Menschen mit Sehbeeinträchtigungen zu erheblichen Problemen führt.
• Fehlende Textergänzung: Eine Karte, die einen Standort zeigt, enthält selten eine textuelle Alternative, die denselben Informationsgehalt vermittelt.
• Fokus-Falle: Einige iFrame-Implementierungen fangen den Tastaturfokus ein und lassen ihn nicht mehr heraus, sodass Nutzende auf der Seite nicht weiternavigieren können.

Diese Probleme betreffen nicht nur Menschen mit dauerhaften Behinderungen. Auch Personen, die in einer hellen Umgebung arbeiten oder vorübergehend eine motorische Einschränkung haben, sind davon betroffen.

Welche WCAG-Kriterien sind für eingebettete Karten relevant?

Für eingebettete Karten sind vor allem die WCAG-Erfolgskriterien 1.1.1 (Nicht-Text-Inhalt), 2.1.1 (Tastatur), 2.1.2 (Keine Tastaturfalle), 1.4.3 (Kontrast) und 4.1.2 (Name, Rolle, Wert) relevant. Diese Kriterien decken die zentralen technischen Anforderungen ab, die eine eingebettete Karte erfüllen muss, um WCAG 2.2 Level AA zu bestehen.

Im Detail bedeutet das:

• 1.1.1 Nicht-Text-Inhalt (Level A): Jede Karte, die inhaltliche Informationen vermittelt, benötigt eine Textalternative. Das kann ein beschreibender title am iFrame oder eine ergänzende Adressangabe im Fließtext sein.
• 2.1.1 Tastatur (Level A): Alle Funktionen der Karte müssen per Tastatur erreichbar sein, sofern sie für die Nutzung der Seite relevant sind.
• 2.1.2 Keine Tastaturfalle (Level A): Nutzerinnen und Nutzer müssen den Fokus jederzeit aus dem iFrame herausbewegen können.
• 1.4.3 Kontrast (Minimum) (Level AA): Text innerhalb der Karte, etwa Straßennamen oder Ortsbeschriftungen, muss ein Kontrastverhältnis von mindestens 4,5:1 aufweisen.
• 4.1.2 Name, Rolle, Wert (Level A): Interaktive Elemente innerhalb der Karte müssen programmatisch benannt sein, damit Hilfstechnologien sie korrekt interpretieren können.

Die WCAG liegen aktuell in Version 2.2 vor und bilden die Grundlage sowohl für das deutsche Barrierefreiheitsstärkungsgesetz (BFSG) als auch für die BITV-Prüfung. Wer eine Barrierefreiheitsprüfung seiner Website durchführt, sollte diese Kriterien gezielt für eingebettete Karteninhalte berücksichtigen.

Wie kann man eingebettete Karten manuell auf Barrierefreiheit testen?

Eingebettete Karten lassen sich manuell testen, indem Sie die Tastaturnavigation prüfen, den iFrame-Titel im Quellcode kontrollieren, einen Screenreader aktivieren und die Farbkontraste visuell sowie mit einem Kontrastwerkzeug bewerten. Manuelle Tests sind bei Karten besonders wichtig, weil automatisierte Scanner nur einen Teil der Probleme erkennen können.

Gehen Sie dabei in folgenden Schritten vor:

1. Tastaturfokus testen: Navigieren Sie mit der Tab-Taste durch die Seite. Prüfen Sie, ob der Fokus die Karte erreicht, ob er sich innerhalb der Karte bewegen lässt und ob Sie die Karte wieder verlassen können.
2. Quellcode prüfen: Öffnen Sie die Entwicklertools des Browsers und suchen Sie das iFrame-Element. Prüfen Sie, ob ein aussagekräftiges title-Attribut vorhanden ist, zum Beispiel title=“Standortkarte: Unser Büro in Hamburg“.
3. Screenreader aktivieren: Testen Sie mit NVDA (Windows, kostenlos) oder VoiceOver (macOS/iOS), ob der Screenreader den iFrame-Titel vorliest und ob interaktive Elemente innerhalb der Karte korrekt angekündigt werden.
4. Kontrast messen: Verwenden Sie ein Browser-Plugin oder ein dediziertes Werkzeug, um die Kontrastverhältnisse von Kartenbeschriftungen zu messen. Achten Sie besonders auf Texte auf farbigen Kartenflächen.
5. Textalternative prüfen: Kontrollieren Sie, ob unterhalb oder neben der Karte eine textuelle Adressangabe vorhanden ist, die denselben Informationsgehalt bietet.

Manuelle Tests dieser Art lassen sich mit automatisierten Scans kombinieren, um ein vollständigeres Bild zu erhalten. Da Schätzungen davon ausgehen, dass automatisierte Tests nur etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme abdecken, ist der manuelle Test bei komplexen Elementen wie Karten besonders wertvoll.

Was können automatisierte Accessibility-Scanner bei Karten erkennen, und was nicht?

Automatisierte Accessibility-Scanner können bei eingebetteten Karten technische HTML-Fehler erkennen, etwa fehlende iFrame-Titel, unzureichende Farbkontraste und fehlende ARIA-Attribute. Sie können jedoch nicht beurteilen, ob die Karte inhaltlich sinnvoll beschriftet ist, ob die Tastaturbedienbarkeit tatsächlich funktioniert oder ob der Fokus korrekt verwaltet wird.

Was automatisierte Scanner erkennen

Ein automatisierter Accessibility-Scanner analysiert den HTML-Code der Seite und kann dabei folgende kartenspezifische Probleme identifizieren:

• Fehlendes oder leeres title-Attribut am iFrame-Element
• Unzureichende Farbkontrastverhältnisse bei sichtbarem Text innerhalb der Karte
• Fehlende ARIA-Labels oder -Beschreibungen an interaktiven Elementen
• Verwendung von Elementen ohne semantische Bedeutung für interaktive Steuerelemente

Was nur manuell erkennbar ist

Folgende Aspekte entziehen sich der automatisierten Prüfung und müssen manuell getestet werden:

• Ob der Tastaturfokus tatsächlich korrekt durch die Karte navigiert und nicht in einer Fokus-Falle bleibt
• Ob ein Screenreader die Karteninformationen sinnvoll und vollständig vorliest
• Ob die vorhandene Textalternative inhaltlich äquivalent zur Karte ist
• Ob die Karte unter vergrößerter Darstellung (Zoom bis 200 %) noch bedienbar bleibt

Für einen vollständigen Accessibility-Test einer Website empfiehlt sich daher immer eine Kombination aus automatisiertem Scan und manueller Prüfung. Automatisierte Tests sind trotzdem sinnvoll, um mit geringem Aufwand eine erste Einschätzung zu erhalten und offensichtliche technische Fehler schnell zu finden.

Welche barrierefreien Alternativen zu eingebetteten Karten gibt es?

Barrierefreie Alternativen zu eingebetteten Karten sind textuelle Adressangaben mit Wegbeschreibung, statische Kartenbilder mit Alternativtext sowie zugängliche interaktive Karten auf Basis von Bibliotheken wie Leaflet.js, die sich gezielt barrierefrei konfigurieren lassen.

Die Wahl der Alternative hängt davon ab, welche Funktion die Karte auf Ihrer Website erfüllt:

• Standortangabe: Eine vollständige Adresse mit Postleitzahl, Stadt und optionaler Wegbeschreibung im Fließtext ist für die meisten Nutzenden ausreichend und vollständig barrierefrei. Ergänzend kann ein Link zu Google Maps oder einer anderen Kartenanwendung angeboten werden.
• Statisches Kartenbild: Ein Screenshot oder eine generierte Karte als Bild ist einfach einzubinden und benötigt lediglich einen aussagekräftigen Alternativtext, der den dargestellten Bereich beschreibt.
• Zugängliche interaktive Karte: Bibliotheken wie Leaflet.js bieten mehr Kontrolle über ARIA-Attribute, Tastaturbedienbarkeit und Fokusmanagement als eingebettete Drittanbieter-iFrames. Mit entsprechender Konfiguration lässt sich eine deutlich bessere Barrierefreiheit erreichen.
• Kombination aus Bild und Text: Die robusteste Lösung ist häufig die Kombination: ein statisches Kartenbild mit Alternativtext plus eine strukturierte Adress- und Wegbeschreibung im Text darunter.

Keine dieser Alternativen garantiert automatisch vollständige Barrierefreiheit. Auch eine selbst eingebundene Leaflet-Karte muss sorgfältig auf Tastaturbedienbarkeit und Screenreader-Kompatibilität geprüft werden.

Wann erfüllt eine eingebettete Karte die Anforderungen des BFSG?

Eine eingebettete Karte erfüllt die Anforderungen des Barrierefreiheitsstärkungsgesetzes (BFSG), wenn sie die relevanten WCAG-2.2-Level-AA-Erfolgskriterien besteht, insbesondere hinsichtlich Tastaturbedienbarkeit, Alternativtexten, Farbkontrasten und ARIA-Beschriftungen. Zusätzlich muss die Karte in der Barrierefreiheitserklärung der Website korrekt dokumentiert sein.

Das BFSG gilt ab 2025 für viele private Anbieter digitaler Produkte und Dienstleistungen und verweist auf die WCAG als technischen Standard. Für eingebettete Karten bedeutet das konkret:

• Der iFrame muss ein aussagekräftiges title-Attribut tragen.
• Alle wesentlichen Informationen der Karte müssen auch ohne visuelle Wahrnehmung zugänglich sein.
• Interaktive Elemente müssen per Tastatur erreichbar und bedienbar sein.
• Farbkontraste müssen die Mindestanforderungen nach WCAG 1.4.3 erfüllen.
• Wenn die Karte nicht vollständig barrierefrei gemacht werden kann, muss eine gleichwertige barrierefreie Alternative bereitgestellt werden.

Wichtig: Das Bestehen eines automatisierten Scans bedeutet nicht, dass eine Karte alle BFSG-Anforderungen erfüllt. Automatisierte Tests decken typischerweise nur einen Teil der relevanten Kriterien ab. Eine abschließende rechtliche Bewertung sollte durch qualifizierte Fachleute erfolgen. Für eine strukturierte Überprüfung empfiehlt sich eine BITV-Prüfung, die sowohl automatisierte als auch manuelle Testmethoden kombiniert.

So unterstützt decareto Sie bei der Barrierefreiheitsprüfung von Websites

Wir bei decareto haben eine Accessibility-Software entwickelt, die Websites automatisiert auf Barrierefreiheitsprobleme scannt und dabei auch Schwachstellen bei eingebetteten Elementen wie Karten identifiziert. Unsere Plattform hilft Ihnen, Probleme strukturiert zu erkennen, zu priorisieren und zu beheben:

• Automatisierter Accessibility-Scan: Wir prüfen Ihre Website auf Basis der WCAG 2.2, BITV und BFSG und erkennen dabei technische Probleme wie fehlende iFrame-Titel, Kontrastfehler und fehlende ARIA-Attribute.
• Priorisierung nach Schweregrad: Gefundene Probleme werden nach kritisch, schwerwiegend, mittel und geringfügig eingestuft, damit Sie wissen, wo Sie zuerst ansetzen sollten.
• Konkrete Handlungsempfehlungen: Zu jedem Problem liefern wir klare Hinweise zur Behebung, verständlich für Entwicklerinnen und Entwickler sowie für Beraterinnen und Berater.
• Manuelle Probleme ergänzen: Barrierefreiheitsprobleme, die nur manuell erkennbar sind, können Sie direkt in unseren Reports erfassen und dokumentieren.
• Dauerhaftes Monitoring: Hunderte Websites lassen sich kontinuierlich überwachen. Bei Änderungen erhalten Sie automatische Benachrichtigungen, sodass neue Barrieren sofort erkannt werden.
• Reports teilen: Barrierefreiheits-Reports können direkt mit Kunden geteilt werden, auch unter eigenem Logo über die Whitelabel-Funktion.

Möchten Sie Ihre Website auf Barrierefreiheitsprobleme prüfen? Starten Sie jetzt mit decareto und erhalten Sie in wenigen Minuten einen strukturierten Überblick über die Barrierefreiheit Ihrer Website.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Was ist der Unterschied zwischen DSGVO-Audit und DSGVO-Monitoring?
• Welche Barrierefreiheitsanforderungen gelten für Tooltips und Overlays?
• Wie laufen Crawling, Analyse und Reporting bei einem DSGVO-Website-Scan technisch ab?
• Welche Unterseiten und Bereiche werden bei einem DSGVO-Scan oft übersehen?
• Welche Datenschutzrisiken bestehen bei der Verarbeitung von Bewerberdaten auf Karriereseiten?