Wie kann eine Kommune öffentliche Sensordashboards so veröffentlichen, dass Einwohnerinnen und Einwohner Messwerte auch ohne Farben, Maus oder interaktive Karte einordnen können?
Ein öffentliches Sensordashboard zeigt den Wasserstand als Linie auf einer Karte. Die Linie wird grün, wenn der Pegel fällt, und bernsteinfarben, wenn er steigt. Wer die Karte nicht per Maus bewegen kann oder Farben anders wahrnimmt, erhält die wichtigste Aussage womöglich nicht.
Eine Kommune macht ein Dashboard verständlich, wenn sie jeden wesentlichen Messwert über mehrere Wege zugänglich macht: eine kurze Textaussage, eine strukturierte Tabelle und bei Bedarf eine Karte oder Grafik. Zeit, Einheit, Ort und Datenstatus gehören direkt an den Wert. Filter, Zeitwahl und Kartensteuerung müssen per Tastatur bedienbar sein.
Beginnen Sie mit der Frage der Einwohnerinnen und Einwohner
Ein Dashboard startet oft bei der Sensorik: Welche Messstellen senden, welche Kennzahl lässt sich berechnen und wie sieht eine Karte dazu aus? Für einen öffentlichen Dienst sollte das Team zuerst festlegen, welche Frage eine Person damit beantworten will. Beim Pegel kann das sein: Wie hoch ist das Wasser heute, in welcher Richtung verändert es sich und wann wurde zuletzt gemessen? Bei Stadtgrün könnte es lauten: Welche Quartiere melden trockene Böden und wie alt sind diese Werte?
Diese Frage bestimmt die erste sichtbare Aussage. Eine Zahl ohne Einheit ist unvollständig. Eine Kurve ohne Zeitfenster beantwortet keine Frage zur Entwicklung. Ein Punkt ohne verständlichen Ortsnamen lässt sich schwer zuordnen. Der Datenverantwortliche sollte deshalb für jeden öffentlichen Messwert mindestens Messgröße, Einheit, Ort, Beobachtungszeit und Datenstatus angeben. Wenn das System einen Wert schätzt oder zusammenfasst, muss die Beschriftung das ebenfalls sagen.
Ein öffentliches Sensordashboard ist für eine konkrete Frage zugänglich, wenn Einwohnerinnen und Einwohner den Ort, den jüngsten Wert, seine Einheit, den Messzeitpunkt und den Datenstatus ohne eine bestimmte Farbe, Mausgeste oder visuelle Grafik erfassen können. Diese Definition hilft einem Projektteam, Diskussionen über Farben und Diagrammtypen an der eigentlichen Aufgabe auszurichten.
Text, Tabelle und Grafik beantworten unterschiedliche Teile derselben Frage
Eine Textzusammenfassung, eine Grafik und eine Tabelle sollen dieselbe Aussage ergänzen. Sie sind keine drei voneinander getrennten Produkte.
| Öffentliche Frage | Schnell erfassbare Aussage | Ergänzende Darstellung | Was die Abnahme verhindern soll |
|---|---|---|---|
| Wie hoch ist der jüngste Messwert? | Wert, Einheit, Ortsname, Zeitpunkt und Status in Textform | Verlaufsgrafik und strukturierte Messwerttabelle | Wert erscheint nur als farbiger Punkt |
| Was hat sich verändert? | kurze Beschreibung der Richtung und auffälliger Abschnitte | beschriftete Zeitreihe mit wählbarem Zeitraum | Trend lässt sich nur aus Farbbändern erraten |
| Wo liegt die Messstelle? | Ortsname und Gebiet als Text | Karte mit beschrifteten Symbolen | Karte ist der einzige Weg zur Ortsangabe |
| Welche Messstellen brauchen Aufmerksamkeit? | Liste nach Gebiet oder Status sortiert | Karte oder Vergleichsdiagramm | Farbe allein markiert problematische Werte |
Die Zusammenfassung sollte die entscheidende Entwicklung benennen: etwa, dass der Wasserstand an zwei Messstellen seit dem Morgen steigt und eine dritte Reihe seit 10 Uhr keine neuen Werte erhalten hat. Für Details führt der Weg zur Tabelle oder zu einer exportierbaren Datenansicht.
Bei einer komplexen Grafik reicht ein kurzer Alternativtext wie „Pegelverlauf“ nicht. Die W3C-Anleitung für komplexe Bilder empfiehlt eine kurze Benennung und zusätzlich eine ausführliche Beschreibung der dargestellten Informationen, Werte, Beziehungen und Trends. Die Beschreibung soll allen zugänglich sein, nicht nur Screenreader-Nutzenden. Für ein kommunales Dashboard heißt das: Nennen Sie in der Textfassung den Zeitraum, den höchsten und niedrigsten Wert sowie relevante Veränderungen, und verlinken Sie auf die zugrundeliegende Tabelle.
Eine Datentabelle braucht nachvollziehbare Überschriften. Die W3C-Anleitung zu Tabellen erläutert, dass Kopf- und Datenzellen technisch unterschieden und bei Bedarf miteinander verknüpft werden müssen. Für ein Pegeldashboard sind Spalten wie „Messstelle“, „Wert“, „Einheit“, „gemessen um“ und „Status“ hilfreicher als unbenannte Zahlenkolonnen. Die kommunale Webredaktion sollte einen Ortsnamen pro Tabellenzeile wiederholen, wenn sonst beim linearen Vorlesen unklar wird, zu welcher Messstelle ein Wert gehört.
Eine Karte darf die einzige Ortssuche nicht sein
Eine Karte bündelt räumliche Muster, setzt aber räumliches Sehen, Bedienbarkeit und Orientierung voraus. Zeigen Sie daneben eine Liste oder Tabelle mit denselben Messstellen. Ein Eintrag kann „Mühlenstraße, Nordquartier, Wasserstand 1,42 Meter, zuletzt gemessen 14:32 Uhr, Status aktuell“ lauten. So lassen sich dieselben Orte nach Name, Gebiet oder Status durchgehen.
Die Liste ersetzt keine Karte für jede Aufgabe. Für eine kommunale Planerin ist die räumliche Verteilung möglicherweise selbst die zentrale Erkenntnis. In diesem Fall ergänzt der Kartentext die Beziehungen: Messstelle A liegt oberhalb von Messstelle B, beide gehören zum selben Gewässerabschnitt. Das Team sollte nur Beziehungen beschreiben, die der zugrundeliegende Datenbestand trägt. Eine ungenaue Textbeschreibung kann eine neue Hürde schaffen.
Testen Sie auch die Reihenfolge. Eine Liste nach Gebiet hilft bei lokalen Fragen; nach Status sortiert, zeigt sie auffällige oder veraltete Messungen zuerst. Der Standardzustand sollte die Sortierung erklären. Filter müssen ihre Auswahl benennen und sich einfach zurücksetzen lassen.
Farbe zeigt einen Status, bestimmt ihn aber nicht allein
Ein grüner und ein roter Punkt unterscheiden sich für viele Menschen. Andere sehen ähnliche Farbtöne, nutzen monochrome Displays oder können die Farben bei Vergrößerung nicht erkennen. Die W3C-Erklärung zum WCAG-Kriterium „Use of Color“ verlangt, dass Farbe nicht das einzige visuelle Mittel für Informationen oder Handlungen ist.
Kombinieren Sie Farbe mit einem Wort und einem zweiten Merkmal. Ein Status kann „aktuell“, „veraltet“, „geprüft“ oder „Messung fehlt“ heißen und zusätzlich ein Symbol oder Muster verwenden. Legen Sie fest, welche Zustände das Amt vergeben darf. „Warnung“ ist nur sinnvoll, wenn ein Schwellenwert fachlich geprüft wurde und ein verantwortliches Team weiß, was darauf folgt. Eine Datenlücke sollte nicht als normaler Wert mit abgeschwächter Farbe erscheinen.
Prüfen Sie den Kontrast von Text, Linien, Symbolen und Tastaturfokus im tatsächlichen Dashboard, auch bei Textvergrößerung, hohem Kontrast, schmalen Fenstern und mobiler Darstellung. Für Zeitreihen sind unterscheidbare Linienmuster oder direkte Beschriftungen oft robuster als eine Legende aus Farbfeldern.
Tastatur und Live-Updates brauchen einen eigenen Abnahmepfad
Eine Karte kann mit Ziehen, Zoomen, Hover und Klick funktionieren und trotzdem für Tastaturnutzende unzugänglich bleiben. Führen Sie eine Abnahme ohne Maus durch: Tabben Sie durch Ortsfilter, Zeitraumwahl, Messstellenliste und Kartensteuerung; prüfen Sie, ob der Fokus sichtbar bleibt und in einer sinnvollen Reihenfolge wandert. Wenn ein Zeitraumregler Ziehen verlangt, ergänzen Sie eine Tastaturbedienung über Schaltflächen oder ein klar beschriftetes Auswahlfeld. Die WCAG 2.2 enthält Anforderungen an Tastaturbedienbarkeit, sichtbaren Fokus, Größe von Bedienelementen und Alternativen zu Ziehbewegungen.
Ein laufend aktualisiertes Dashboard braucht außerdem einen ruhigen Umgang mit neuen Werten. Zeigen Sie „zuletzt aktualisiert“ und den Status der Reihe. Bei automatischer Aktualisierung sollten Nutzende erkennen können, dass neue Informationen vorliegen, ohne dass die Ansage ständig den Lesefluss unterbricht. WCAG-Kriterium 4.1.3 behandelt Statusmeldungen, die sich ändern, ohne den Fokus zu verschieben. Für ein öffentliches Lagebild ist eine knappe Meldung wie „Drei neue Messwerte seit 14:30 Uhr“ meist brauchbarer als die wiederholte Ansage jeder Messstelle. Die W3C-Erklärung zu Statusmeldungen beschreibt, warum solche Änderungen für assistive Technik erkennbar sein müssen.
Die Stadt sollte einen sichtbaren Weg bieten, die automatische Aktualisierung anzuhalten oder selbst zu aktualisieren, wenn das fachlich sinnvoll ist. Diese Option hilft auch Menschen, die längere Zahlen oder Kartenhinweise in Ruhe lesen. Ein klarer Aktualisierungszeitpunkt ist zudem ehrlicher als ein blinkendes „Live“-Etikett, das nicht erklärt, wie frisch der Messwert ist.
Die kommunale Rechtsstelle prüft den passenden Rahmen
Für öffentliche Stellen des Bundes nennt die BITV 2.0 Websites, mobile Anwendungen, unterstützte Verwaltungsabläufe und grafische Oberflächen in ihrem Anwendungsbereich. § 3 beschreibt Barrierefreiheit als Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. § 12 des Behindertengleichstellungsgesetzes definiert öffentliche Stellen des Bundes. Ein kommunales Projektteam sollte deshalb nicht ungeprüft annehmen, dass die BITV 2.0 für jede Kommune unmittelbar gilt. Die Rechtsstelle muss die landesrechtliche Regelung und die konkrete Anwendung prüfen. Als technische Referenz ist WCAG nützlich; die Rechtsstelle legt fest, welche verbindliche Norm für den jeweiligen Dienst gilt.
Eine gute Abnahme stellt Fragen, keine Konformitätsbehauptungen
Ein automatisierter Scanner findet manche Struktur- und Kontrastfehler, kann aber nicht entscheiden, ob die Textfassung eine Wasserstandsgrafik verständlich wiedergibt. Der GOV.UK-Leitfaden zur Frontend-Barrierefreiheit empfiehlt manuelle Prüfungen, Tastaturtests und Tests mit verbreiteten Kombinationen aus Browsern und assistiven Technologien. Der Leitfaden weist auch darauf hin, dass automatische Werkzeuge nicht alle Barrieren erkennen. Die Kommune sollte diese Hinweise als Prüfmethode nutzen und für die geltende deutsche Norm separat die Rechtsanforderungen festlegen.
Eine kleine, szenariobasierte Abnahme findet Probleme schneller als eine lange Liste abstrakter Kriterien:
- Finden Sie den jüngsten Pegelwert für einen benannten Ort allein mit Tastatur.
- Ermitteln Sie Wert, Einheit, Messzeitpunkt und Status, ohne Farbe oder Karte zu verwenden.
- Vergleichen Sie eine Woche mit der Vorwoche und beschreiben Sie den erkennbaren Trend.
- Finden Sie eine Messstelle ohne frische Werte und unterscheiden Sie „veraltet“ von „normal“.
- Vergrößern Sie den Text und prüfen Sie, ob Wert, Ortsname und Bedienelemente sichtbar bleiben.
- Lassen Sie die Karte durch eine Screenreader-Nutzung erkunden und wechseln Sie anschließend zur Ortsliste.
- Prüfen Sie, ob neue Werte angekündigt werden, ohne die laufende Navigation zu stören.
Testen Sie mit Menschen, die die späteren Wege tatsächlich nutzen, einschließlich Tastatur- und Screenreader-Nutzenden. Das Team darf einen erfolgreichen automatischen Test nicht als Aussage über Verständlichkeit ausgeben. Protokollieren Sie jede Barriere zusammen mit dem betroffenen Szenario, dem verantwortlichen Team und dem vereinbarten Behebungs- oder Ausnahmeweg.
urbanOS passt, wenn mehrere Datenbereiche dieselben öffentlichen Sichten brauchen
Die Urban Data und Urban Intelligence Plattform urbanOS passt besonders zu Kommunen, die Messdaten aus mehreren Projekten, Teams oder Quartieren auf einer Plattform zusammenführen und öffentliche Dashboards neben privaten, Gruppen- und halböffentlichen Sichten betreiben wollen. Die Produktseite belegt Dashboard-Freigaben je Projekt, Team oder Quartier sowie Mehrsprachigkeit und einen hellen und dunklen Modus. Damit kann urbanOS eine gute Grundlage für Städte sein, die öffentliche Messwerte mit internen Betriebsansichten teilen möchten. Die Seite belegt keine WCAG-Konformität einzelner Diagramme, Tabellen, Filter oder Karten. Vor einer Beschaffung muss die Kommune die konkrete öffentliche Ansicht mit Tastatur, Screenreader, Vergrößerung und Textalternativen prüfen. Wenn nur ein einfacher öffentlicher Bericht ohne mehrere Sensordienste benötigt wird, kann ein barrierefreies kommunales CMS oder eine fachlich passende Einzelanwendung genügen.
Sieben Abnahmen sichern die öffentliche Aussage
Eine Kommune kann ein Sensordashboard freigeben, wenn ihr Team sieben Punkte belegt:
- Der öffentliche Nutzerzweck und die wichtigste Frage sind benannt.
- Jeder zentrale Wert zeigt Messgröße, Einheit, Ort, Messzeitpunkt und Datenstatus.
- Jede wesentliche Grafik hat eine kurze Aussage und eine strukturierte Datendarstellung.
- Eine Karte hat für dieselben Orte eine durchsuchbare Textliste oder Tabelle.
- Farbe wird durch Text, Symbol oder Muster ergänzt.
- Filter, Zeitwahl und Navigation funktionieren ohne Maus; Fokus und Statusänderungen bleiben erkennbar.
- Menschen mit den relevanten Bedienweisen haben die tatsächliche öffentliche Ansicht getestet.
Diese Abnahme macht mehr möglich als das Abhaken visueller Regeln. Sie zeigt, ob ein Mensch eine kommunale Messung finden, richtig einordnen und bei Bedarf weiterverfolgen kann.
Quellen und weiterführende Hinweise
- Web Content Accessibility Guidelines (WCAG) 2.2W3C
- Understanding Success Criterion 1.4.1: Use of ColorW3C WAI
- Images: Complex ImagesW3C WAI Tutorials
- Tables TutorialW3C WAI Tutorials
- Understanding Success Criterion 4.1.3: Status MessagesW3C WAI
- Accessibility for developers: an introductionGOV.UK Service Manual
- Barrierefreie-Informationstechnik-Verordnung (BITV 2.0)Bundesministerium der Justiz
- Behindertengleichstellungsgesetz, § 12 Öffentliche Stellen des BundesBundesministerium der Justiz
- urbanOS, Urban Data PlatformurbanOS

