Barrierefreie interaktive Karten ermöglichen es, dieselbe ortsbezogene Aufgabe per Tastatur, assistiver Technologie oder Berührung zu erledigen, ohne auf Ziehen, Farbe oder einen Pin angewiesen zu sein, den man sehen muss. Suche, Ergebnisliste, Details und eine Antwort, die den Ort ausdrücklich nennt, tragen die Aufgabe. Die Karte bleibt die visuelle Ansicht dieses gemeinsamen Zustands.
Die folgenden Abschnitte trennen die Aufgabe von der Kartenfläche und behandeln anschließend Ortsidentität, Tastaturreihenfolge, Ziehen, Farbe, Ansagen und KI-Antworten. Eine Reflow-Ausnahme für die Karte entschuldigt nicht den Rest der Seite. Kaleidr Studio, Viewer und Chat stehen neben den Host-Steuerelementen, die die Aufgabe bedienbar machen.
Grundlagen barrierefreier interaktiver Karten
- Aufgabe benennen: Suchen, vergleichen, auswählen und handeln sind die Aufgabe. Die Kartenfläche ist nur eine Ansicht dieser Aufgabe.
- Eine Ortskennung gemeinsam nutzen: Liste, Marker, Details und KI-Antwort beziehen sich auf denselben Datensatz.
- Einen Weg ohne Ziehen anbieten: Schwenk-Schaltflächen, ein Tipp-Ziel, Adresseingabe sowie Nach-oben- oder Nach-unten-Steuerelemente stehen neben der Ziehgeste.
- Bedeutung nicht nur durch Farbe codieren: Ein Status braucht zusätzlich zur Farbe Text, Form oder ein Symbol.
- Ergebnis ansagen: Anzahl der Treffer, eine fertige Route oder ein leerer Treffer gehören in eine Statusmeldung. Geladene Kartenkacheln nicht.
Was sind barrierefreie interaktive Karten?
Barrierefreie interaktive Karten sind ortsbezogene Erlebnisse, bei denen Nutzer von Tastatur, assistiven Technologien und Zeigegeräten dieselbe Aufgabe abschließen können. Die Aufgabe kann darin bestehen, ein Museum mit stufenlosem Eingang zu finden, drei Bibliotheken zu vergleichen oder eine Apotheke auszuwählen, die geöffnet bleibt. Die Karte zeigt räumliche Beziehungen. Suche, Filter, Ergebnisliste, Details und eine schriftliche Antwort vermitteln die Fakten, die jemand braucht, wenn die Kartenfläche schwer zu sehen, zu ziehen oder anzutippen ist. Eine Oberfläche, die nur mit einem Zeigegerät funktioniert, ist eine visuelle Karte, aber keine barrierefreie.
WCAG 2.2 ist eine W3C-Empfehlung vom 12. Dezember 2024. Diese Empfehlung ist der aktuelle Webstandard, den dieser Leitfaden auf Kartenaufgaben anwendet, darunter Fokus, Ziehen, Zielgröße, Farbe, Kontrast und Reflow (W3C, 2024). Das Titelbild kombiniert eine Ergebnisliste mit einer Karte und einer Antwort, die City Museum, eine Beispieldistanz und Beispielausstattungen nennt. Diese Distanzen und Ausstattungsangaben dienen nur der Veranschaulichung. Eine produktive Karte sollte echte Felder aus dem Ortsdatensatz ausgeben, und ein Filter namens „Barrierefrei“ ist kein Nachweis dafür, dass ein Ort auditiert wurde.
Warum mit der Aufgabe statt mit der Kartenfläche beginnen?
Ein Weg, der nur über die Karte führt, verlangt, dass jemand die Kartenfläche erkundet, einen Pin findet, ein Popup liest und anschließend handelt. Dieser Weg erfordert visuelle Interpretation und präzise Zeigerbedienung. Ein barrierefreier Weg beginnt mit Suche oder Eingabeaufforderung, führt dann zu einer strukturierten Ergebnisliste, anschließend zu Ortsdetails und schließlich zu einer Aktion wie Route, Speichern oder Teilen. Die Karte aktualisiert sich neben diesen Schritten und ist nicht der einzige Weg durch die Aufgabe. Kaleidrs Einbettungsleitfaden verlangt bereits Überschriften, Zusammenfassungen und eine Ortsliste außerhalb der Kartenfläche, damit die Seite für Tastaturnutzer, assistive Technologien und Suche nützlich bleibt (Kaleidr, 2026).
Der linke Weg behandelt die Karte als Oberfläche und setzt visuelle Interpretation sowie Zeigerpräzision voraus. Der rechte Weg führt über Suche, Ergebnisliste, Details und eine Aktion, wobei die Karte eine unterstützende Ansicht ist. Beispielnamen von Bibliotheken, Adressen und Distanzen dienen nur der Veranschaulichung. Die Trennung ist eine Architekturentscheidung, kein Kaleidr-Score.
Die wesentlichen Datensätze gehören in HTML. Name, Adresse, Kategorie, Öffnungszeiten und die nächste Aktion sollten auch dann vorhanden sein, wenn Kartenkacheln nicht geladen werden. Das Popup kann diese Fakten wiederholen. Es darf nicht die einzige Kopie sein. Stabile Ortskennungen, die im nächsten Abschnitt behandelt werden, halten Listenzeile und Marker mit demselben Datensatz verbunden.
Warum ist eine gemeinsame Ortskennung wichtig?
Suche, Ergebniskarte, Detailbereich, Kartenmarker, KI-Antwort und ein Analytics-Ereignis sollten dieselbe Ortskennung verwenden. Wenn die Kennung zwischen Oberflächen ihre Bedeutung ändert, kann ein Tastaturnutzer in der Liste FreshMart auswählen, während die Karte ein anderes Geschäft hervorhebt und die Antwort ein drittes beschreibt. Die Abbildung stellt diese Kennung in die Mitte und verbindet sie mit jeder Oberfläche. Beispielstraßenadressen, Sternebewertung, Anzahl der Bewertungen, Telefonnummer, Koordinaten und Zeitstempel in der Abbildung dienen nur der Veranschaulichung und sind kein Live-Kaleidr-Datensatz.
Eine gemeinsame Ortskennung versorgt Ergebniskarte, Detailbereich, Marker, Antwort und Analytics-Ereignis. Jede Oberfläche zeigt denselben Namen und dieselbe Adresse. Bewertung, Telefonnummer, Koordinaten und Ereigniszeit in der Abbildung sind Beispiele. Produktive Analytics sollten die Kennung behalten und keine Felder kopieren, die das Ereignis nicht benötigt.
Die Auswahl folgt der Kennung, nicht einer Bildschirmkoordinate. Das Aktivieren einer Listenzeile setzt den ausgewählten Ort, bewegt die Karte und aktualisiert die Details, ohne dass die Person nach dem Pin suchen muss. Ein Klick auf den Marker macht das Umgekehrte und hebt dieselbe Zeile hervor. Verschieben Sie den Tastaturfokus nicht bei jeder Auswahl auf die Karte, sonst verliert ein Screenreader-Nutzer seine Position in der Liste. Fokus und Auswahl sind unterschiedliche Zustände, und der nächste Abschnitt hält sie getrennt.
Welche Tastaturreihenfolge schließt die Aufgabe ab?
Gestalten Sie die Fokusreihenfolge nach der Aufgabe. Eine praktikable Reihenfolge ist Suche, Filter, Ergebniszusammenfassung, Ergebnisliste, Kartensteuerung, Details und Hauptaktion. Die Person kann die Trefferzahl verstehen, einen Ort aus der Liste wählen, die Karte bei Bedarf schwenken oder zoomen, Details lesen und anschließend eine Route abrufen. Kartenmarker benötigen nicht jeweils einen Tab-Stopp, wenn die Liste dieselben Orte bereits zugänglich macht. Pfeiltasten können innerhalb der Liste navigieren. Tab wechselt zwischen den größeren Bereichen.
Der Pfad führt von Suche über Filter, Ergebniszusammenfassung, Liste, Kartensteuerung und Details zur Hauptaktion. Ein ausgewählter Park bleibt mit seiner Listenzeile und seiner Detailkarte verbunden. Trefferzahl und Beispieldistanzen dienen nur der Veranschaulichung. Die Fokusreihenfolge folgt der Aufgabe, und die Karte ist ein einziger Stopp statt eines Feldes voller Pins.
Vom Autor erstellte Inhalte, die ein fokussiertes Steuerelement vollständig verdecken, etwa eine feststehende Suchleiste oder ein Chatbereich, erfüllen Erfolgskriterium 2.4.11 (AA) in WCAG 2.2 nicht. Anmerkung 2 dieses Kriteriums erlaubt es, dass von der Person geöffnete Inhalte, etwa eine Detailschublade, das Steuerelement verdecken, wenn sie es ohne Verschieben des Tastaturfokus wieder sichtbar machen kann. Teilweises Verdecken, bei dem ein Teil des Steuerelements sichtbar bleibt, ist Erfolgskriterium 2.4.12 (AAA). Sichtbarer Fokus und sichtbare Auswahl benötigen unterschiedliche Stile, weil eine blaue Listenzeile und ein Fokusring unterschiedliche Fragen beantworten. Die WAI-ARIA-Tastaturleitlinien fordern Autoren auf, Fokus und Auswahl zu unterscheiden, insbesondere wenn ausgewählte Elemente in einer Komponente liegen, die selbst keinen Fokus hält (W3C, 2026). Lassen Sie den Fokusring auf dem Steuerelement, das den nächsten Tastendruck erhält, und verwenden Sie für den Ort eine eigene Auswahlmarkierung.
Warum darf Ziehen nicht der einzige Weg sein?
Karten laden zum Ziehen ein, doch Ziehen darf nicht die einzige Möglichkeit sein, die Karte zu schwenken, einen Stopp festzulegen oder eine Route neu zu ordnen. Erfolgskriterium 2.5.7 in WCAG 2.2 sagt, dass Funktionen mit Ziehbewegung mit einem einzelnen Zeiger ohne Ziehen ausgeführt werden können müssen, sofern Ziehen nicht wesentlich ist oder der User Agent das Verhalten bestimmt und der Autor es nicht verändert hat. Eine Tastaturalternative erfüllt diese Zeigeranforderung allein nicht. Bieten Sie Richtungsschaltflächen zum Schwenken, ein Antippziel zum Setzen des Ziels, ein Adressfeld sowie Nach-oben- und Nach-unten-Steuerelemente für geordnete Stopps an. Erfolgskriterium 2.5.8 in derselben Empfehlung legt eine Mindestzielgröße von 24 mal 24 CSS-Pixeln fest, mit Ausnahmen unter anderem für Abstände und ein gleichwertiges Steuerelement an anderer Stelle auf der Seite.
Das linke Panel zeigt Ziehen als einzige Möglichkeit, die Karte zu bewegen. Das rechte ergänzt Schwenk-Schaltflächen, ein Antippziel, ein Adressfeld, Schaltflächen zum Neuordnen und Tastaturtasten zum Schwenken. Die Beispieladresse dient nur der Veranschaulichung. Ein Tastaturweg bleibt notwendig und ersetzt nicht die Ein-Zeiger-Alternative zum Ziehen.
Verlassen Sie die Karte, ohne die Tastatur einzuschließen. Wenn Pfeiltasten die Karte schwenken, während der Fokus auf der Karte liegt, sollte Escape oder eine dokumentierte Taste den Fokus zur Liste oder zum nächsten Steuerelement zurückführen. Zoom, Standort und Schließen benötigen zugängliche Namen statt reiner Symbolschaltflächen, die ein Screenreader nicht beschriften kann. Die Zielgröße ist bei diesen Steuerelementen und auch bei Listenzeilen wichtig, denn eine winzige Trefferfläche benachteiligt Personen, die tippen oder einen weniger präzisen Zeiger verwenden.
Warum reicht Farbe auf einer Karte nicht aus?
Erfolgskriterium 1.4.1 sagt, dass Farbe nicht das einzige visuelle Mittel sein darf, um Informationen zu vermitteln, eine Aktion anzuzeigen, zu einer Reaktion aufzufordern oder ein Element zu unterscheiden. Ein grüner Punkt für „geöffnet“ und ein roter Punkt für „geschlossen“ scheitert, wenn der Farbton der einzige Unterschied ist. Ergänzen Sie die Farbe durch eine Beschriftung, ein Häkchen, ein Kreuz oder eine andere Form. Dieselbe Regel gilt für Kategoriemarker, ausgewählte Routen und „Sie sind hier“. Erfolgskriterium 1.4.11 in derselben Empfehlung verlangt außerdem für visuelle Informationen, die zur Erkennung von Benutzeroberflächenkomponenten und Zuständen erforderlich sind, ein Kontrastverhältnis von mindestens 3:1, ausgenommen inaktive Komponenten oder Komponenten, deren Erscheinungsbild vom User Agent bestimmt wird. Eine weiße Zoom-Schaltfläche auf einer hellen Basiskarte kann dieses Verhältnis verfehlen, auch wenn die Markenfarben auf einer weißen Seite gut aussehen.
Das schwache Beispiel verwendet einen grünen Kreis für „Geöffnet“ und einen roten Kreis für „Geschlossen“. Das stärkere Beispiel ergänzt Häkchen, Kreuz, Warnform und die Wörter Geöffnet, Geschlossen und Verzögert. Farbe hilft weiterhin. Text und Form tragen die Bedeutung, wenn Farbe nicht wahrgenommen werden kann.
Legenden gehören in Text, nicht nur in einen farbigen Schlüssel auf der Karte. Ein Kategoriefilter sollte seinen ausgewählten Zustand im Namen des Steuerelements oder in einer benachbarten Beschriftung angeben. Fordern Sie eine Person in der Oberfläche nicht auf, „dem roten Pin zu folgen“. Nennen Sie den Ort. Der KI-Abschnitt weiter unten wendet dieselbe Regel auf generierte Antworten an.
Was sollten assistive Technologien hören?
Sagen Sie das Ergebnis einer Aktion an, nicht den Renderer. Eine hilfreiche Statusmeldung sagt, dass vier Geschäfte den Filtern entsprechen, dass eine Route fertig ist und wie lange sie dauert oder dass keine barrierefreien Eingänge passen. „Kachel geladen“, „Marker verschoben“ und „Kartenzentrum geändert“ sind Rauschen. Eine Live-Region um die gesamte Karte würde diese technischen Ereignisse vorlesen und den Satz überlagern, den die Person benötigt. WAI dokumentiert mit ARIA22 eine Technik, role=status zur Darstellung von Statusmeldungen zu verwenden. Diese Technik ist ein Beispiel dafür, wie WCAG erfüllt werden kann, keine Vorgabe, dass jede Karte genau diese Rolle verwenden muss (W3C, 2026).
Der nützliche Kanal meldet die Trefferzahl, eine fertige Route und einen leeren Treffer für barrierefreie Eingänge. Der ignorierte Kanal listet geladene Kacheln, Markerbewegungen und Änderungen des Kartenzentrums. Beispielnamen von Geschäften, Distanzen und die 18-Minuten-Route dienen nur der Veranschaulichung. Sagen Sie den Zustand an, auf den die Person reagieren kann.
Suche und Filter brauchen dieselbe Disziplin. Melden Sie nach einer Abfrage die Trefferzahl oder den leeren Zustand einmal, nicht einen Strom von Markeraktualisierungen. Halten Sie die Ansage kurz genug, um höflich zu unterbrechen. Verschieben Sie den Fokus nicht auf die Karte, wenn sich die Trefferzahl ändert. Die Liste bleibt der Ort, an dem die Person die Treffer liest, und die Karte spiegelt dieselbe Menge wider.
Warum muss die KI-Antwort den Ort nennen?
Eine KI-Kartenantwort muss als Text für sich allein stehen. „Downtown Pharmacy ist bis Mitternacht geöffnet und 1,2 Meilen von Ihrem ausgewählten Ausgangspunkt entfernt“ nennt Ort, Öffnungszeiten und Distanz. „Ich habe den roten Pin hervorgehoben“ verweist auf die Kartenfläche und hilft niemandem, der den Pin nicht sehen kann. Die Karte kann denselben Ort auswählen und eine Route zeichnen. Der Satz muss die Entscheidung trotzdem tragen. Streamen Sie die fertige Antwort oder eine kurze Zusammenfassung in den Statuskanal. Senden Sie nicht jedes Token an assistive Technologien und ziehen Sie bei jedem Fragment nicht den Fokus in den Chat.
Die hilfreiche Antwort nennt Downtown Pharmacy, die Schließzeit und die Distanz von einem ausgewählten Ausgangspunkt. Die Karte zeigt diesen Ort und eine Route. Die abgelehnte Antwort sagt nur, ein roter Pin sei hervorgehoben worden. Apothekenname, Öffnungszeiten und Distanz in der Abbildung dienen nur der Veranschaulichung.
Halten Sie das Modell von der Zugriffsentscheidung fern. Der Host autorisiert die Datensätze, und die Antwort darf nur Orte beschreiben, die bereits in der Ergebnismenge liegen. Lassen Sie generierten Text keinen stufenlosen Eingang, kein barrierefreies WC und keine Zertifizierung erfinden, wenn die Quelldaten diese Information nicht enthalten. Fehlt im Datensatz ein Barrierefreiheitsfeld, sollte die Antwort sagen, dass der Wert unbekannt ist. Eine Hervorhebung auf der Karte ist eine optionale Bestätigung, nicht der Inhalt der Antwort.
Was funktioniert noch, wenn die Karte keinen Reflow unterstützt?
Erfolgskriterium 1.4.10 in WCAG 2.2 behandelt bestimmte Inhalte so, dass sie für Nutzung oder Bedeutung ein zweidimensionales Layout erfordern. Hinweis 2 nennt für das Verständnis erforderliche Bilder wie Karten und Diagramme und akzeptiert für diese Teile zweidimensionales Scrollen. Die Ausnahme gilt für die Karte. Sie gilt nicht für Seitenüberschrift, Suche, Filter, Ergebnistext, Schaltflächen, KI-Antwort oder Detailkarte. Bei schmaler Breite oder starkem Zoom sollte die Liste ober- oder unterhalb der Karte gestapelt werden, die Karte in einem eigenen scrollbaren Bereich bleiben und der Text außerhalb dieses Bereichs stehen. Die Person sollte die Aufgabe weiterhin abschließen können, wenn die Kartenfläche nur ein kleines Fenster ist.
Fehlerfälle brauchen dieselbe Trennung. Wenn Kartenkacheln nicht geladen werden, bleiben Ergebnisliste, Details und Hauptaktion verfügbar. Sagen Sie, dass die Karte nicht geladen wurde, und halten Sie die Datensätze zugänglich. Eine leere Kartenfläche ohne Text ist eine kaputte Aufgabe, kein Stylingproblem. Auch reduzierte Bewegung gehört hierher. Verlassen Sie sich nicht auf eine lange Fly-to-Animation, um mitzuteilen, welcher Ort ausgewählt wurde. Aktualisieren Sie Auswahl und Liste auch dann, wenn die Kamerabewegung verkürzt oder übersprungen wird.
Wo sollten barrierefreie interaktive Karten neben Kaleidr sitzen?
Belassen Sie Suche, Filter, Ergebnisliste, Details, Hauptaktionen und Statusmeldungen auf der Host-Seite. Teilen Sie Orts-, Routen-, Auswahl-, Filter- und Ergebnismengenkennungen mit der Karte. In Kaleidr Studio verwandeln Teams Ideen in interaktive Karten mit Orten, Inhalten und Verhalten (Kaleidr, 2026). Viewer bettet eine veröffentlichte Karte über ihre share id ein und benötigt für dieses Embed keinen publishable key (Kaleidr, 2026). Die Entwicklerdokumentation beschreibt Chat als Spatial AI in der Host-Karte, Viewer als Veröffentlichung einer Karte, Tile als gestaltete Basiskarten und Editor als Zeichnen und Bearbeiten (Kaleidr, 2026). Der Host bleibt für den barrierefreien Weg rund um diese Oberflächen verantwortlich.
Die Host-Seite besitzt Suche, Filter, Ergebnisliste, Details, Aktionen und Statusmeldungen. Gemeinsame Kennungen verbinden diese Seite mit Studio, Viewer, Chat und der Karte. Die Fußzeile der Abbildung sagt, dass Kaleidr die WCAG-Konformität nicht automatisch garantiert. Das Testen der ausgelieferten Erfahrung bleibt Aufgabe des Publishers.
Eine Vorlage oder Kartenkomponente kann eine Grundlage liefern. Der No-Code-Launch-Leitfaden sagt, dass eine Vorlage keine Konformität garantieren kann, sobald ein Publisher Farben, Inhalte und Kartenverhalten hinzufügt, denn Konformität gilt für das tatsächlich ausgelieferte Ergebnis (Kaleidr, 2026). Testen Sie die vollständige Aufgabe mit Tastatur, Screenreader, Zoom und schmalem Viewport. Nehmen Sie einen Fehlerfall auf, in dem die Karte nicht geladen wird. Dieser Artikel ist ein Implementierungsleitfaden, kein Konformitäts-Audit und keine Rechtsberatung.
Kaleidr Studio erkunden, um die Karte zu gestalten und zu veröffentlichen. Entwicklerdokumentation lesen für die dokumentierten Oberflächen Chat, Viewer, Tile und Editor. Belassen Sie Ergebnisliste und ausdrücklich benannte Antwort auf der Host-Seite und verknüpfen Sie beides mit derselben Ortskennung, die die Karte verwendet.
Hinweis: Kaleidr verwendet KI-gestützte Werkzeuge für Bilderstellung, Inhaltsverfeinerung und Recherche in seinen kreativen und Entwicklungs-Workflows.
FAQs
Ersetzt eine Tastaturalternative einen Zeigerweg ohne Ziehen?
Nein. WCAG 2.2 verlangt für eine Ziehaktion eine Möglichkeit mit einem einzelnen Zeiger ohne Ziehen, sofern Ziehen nicht wesentlich ist oder der User Agent das Verhalten bestimmt. Tastaturzugang ist eine separate Anforderung für dieselbe Aufgabe.
Deckt die Reflow-Ausnahme der Karte Suche und Ergebnisliste ab?
Nein. Karten und Diagramme dürfen zweidimensionales Scrollen beibehalten. Überschriften, Suche, Filter, Ergebnisse, Schaltflächen und die KI-Antwort müssen bei schmaler oder gezoomter Seite weiterhin nutzbar bleiben.
Garantiert Kaleidr WCAG-Konformität für eine veröffentlichte Karte?
Nein. Studio, Viewer und Chat sind Produktoberflächen. Die Konformität hängt von der ausgelieferten Seite ab, einschließlich Beschriftungen, Kontrast, Ergebnisliste, Statusmeldungen und Tests.
Sollte eine KI-Kartenantwort „den roten Pin“ sagen?
Nein. Nennen Sie den Ort, den relevanten Status und die Distanz oder Route im Text. Die Karte kann denselben Ort auswählen. Der Satz muss ohne die Kartenfläche verständlich bleiben.
References
- World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, December 12, 2024. Includes 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 1.4.1 Use of Color, 1.4.11 Non-text Contrast, and the 1.4.10 Reflow note that lists maps and diagrams. Accessed October 7, 2026. https://www.w3.org/TR/WCAG22/
- Kaleidr. Embed Interactive Map on a Website. Asks for headings, summaries, and a location list outside the canvas. https://kaleidr.com/blog/how-to-embed-interactive-map-on-a-website
- W3C Web Accessibility Initiative. Developing a Keyboard Interface. Distinguishes keyboard focus from selection. Accessed October 7, 2026. https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
- W3C Web Accessibility Initiative. ARIA22: Using role=status to present status messages. An example technique, not a required implementation. Accessed October 7, 2026. https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22
- Kaleidr. AI Map Maker for Branded Interactive Maps. Studio turns ideas into interactive maps with locations, content, and behavior. Accessed October 7, 2026. https://kaleidr.com/studio
- Kaleidr Developer Docs. Viewer. Embeds a published map by its share id, and that embed does not require a publishable key. Accessed October 7, 2026. https://docs.kaleidr.com/viewer
- Kaleidr Developer Docs. Introduction. Chat is Spatial AI in the host map, Editor is draw and edit, Tile is designed basemaps, and Viewer publishes a map. Accessed October 7, 2026. https://docs.kaleidr.com/
- Kaleidr. Launch a No-Code Map Website. A template does not guarantee conformance of the experience a publisher ships. https://kaleidr.com/blog/launch-a-map-website-no-code
@misc{w3c_wcag22_2024,
title = {Web Content Accessibility Guidelines (WCAG) 2.2},
author = {{World Wide Web Consortium}},
year = {2024},
url = {https://www.w3.org/TR/WCAG22/}
}
@misc{kaleidr_embed_map_2026,
title = {Embed Interactive Map on a Website},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/how-to-embed-interactive-map-on-a-website}
}
@misc{w3c_keyboard_interface_2026,
title = {Developing a Keyboard Interface},
author = {{World Wide Web Consortium}},
year = {2026},
url = {https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/}
}
@misc{w3c_aria22_2026,
title = {ARIA22: Using role=status to present status messages},
author = {{World Wide Web Consortium}},
year = {2026},
url = {https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22}
}
@misc{kaleidr_studio_a11y_2026,
title = {AI Map Maker for Branded Interactive Maps},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/studio}
}
@misc{kaleidr_docs_viewer_a11y_2026,
title = {Viewer},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/viewer}
}
@misc{kaleidr_docs_home_a11y_2026,
title = {Introduction},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/}
}
@misc{kaleidr_launch_map_2026,
title = {Launch a No-Code Map Website},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/launch-a-map-website-no-code}
}