Make municipal sensor dashboards accessible and understandable

A public sensor dashboard shows a water level as a line on a map. The line turns green when the level falls and amber when it rises. A resident who cannot move the map with a mouse or distinguish those colours may miss the dashboard's main point.

A municipality can make a dashboard understandable by presenting each essential reading in coordinated ways: a short text statement, a structured table and, where useful, a chart or map. Time, unit, location and data status should sit beside the value. Filters, time controls and map functions need keyboard access.

Start with the resident's question

Dashboard projects often begin with the sensor: which sites report, which measure can be calculated and what map could show it? For a public service, the team should first state the question a resident needs to answer. For a water gauge, that might be: what is the level today, which way is it changing and when did the sensor last report? For urban green space, it might be: which neighbourhoods report dry soil, and how old are those readings?

That question shapes the first visible statement. A number without a unit is incomplete, a line without a time window says little about change, and a dot without a recognisable place name is hard to locate. The data owner should show the measured property, unit, location, observation time and status for every reading. If the system estimates or aggregates a value, the label should say so.

A public sensor dashboard serves a question accessibly when residents can identify the place, latest value, unit, measurement time and data status without relying on one colour, mouse gesture or visual chart. This definition keeps discussions about palettes and chart types focused on the task the dashboard must support.

Text, table and chart answer different parts of the same question

A summary sentence, chart and table should reinforce the same point. They are not three separate products.

Public question	At-a-glance statement	Supporting view	Failure the acceptance test should prevent
What is the latest reading?	value, unit, place, time and status in text	time-series chart and structured readings table	value appears only as a coloured dot
What has changed?	short description of direction and unusual periods	labelled time series with selectable window	trend must be guessed from coloured bands
Where is the monitoring site?	place name and area in text	map with labelled markers	the map is the only way to find the place
Which sites need attention?	list ordered by area or status	map or comparison chart	colour alone identifies the concerning values

The summary should state the useful change: for example, the level has risen since morning at two sites, while a third series has reported no new value since 10 a.m. Residents who need detail can use the table or a downloadable data view.

For a complex chart, “water-level history” is not a sufficient text alternative. The W3C tutorial for complex images recommends a short identification and a fuller description of the information, values, relationships and trends. That description should be available to everyone, not only screen-reader users. For a municipal dashboard, state the period, high and low values, and relevant changes in text, then link to the underlying table.

A data table needs understandable headers. The W3C Tables Tutorial explains that header and data cells need to be distinguished in markup and explicitly associated where necessary. For a gauge dashboard, columns such as “site”, “value”, “unit”, “measured at” and “status” help more than a row of unnamed numbers. The municipal content team should repeat a place name in each row when otherwise it would be unclear which site belongs to each reading during linear reading.

A map must not be the only way to find a place

A map brings spatial patterns together, but it assumes users can see spatial relationships, operate controls and orient themselves. Include a list or table with the same monitoring sites. One entry might read “Mill Street, North neighbourhood, water level 1.42 metres, last measured 14:32, current status”. Residents can browse places by name, area or status.

A list does not replace a map for every task. Spatial distribution may itself be the main insight for a municipal planner. In that case, add text that explains the relationships: site A lies upstream from site B, and both belong to the same watercourse. Only describe relationships supported by the source data. An inaccurate verbal map can create another barrier.

Test the order too. A list sorted by area supports local queries; sorted by status, it brings unusual or old readings to the top. Explain the default sort. Filters need a visible description of the current selection and a simple way to clear it.

Colour can signal status, but cannot carry it alone

A green and red dot look different to many people. Others may see similar shades, use monochrome displays or miss colours at larger text sizes. The W3C explanation of WCAG's “Use of Color” criterion says colour cannot be the sole visual means of conveying information or an action.

Pair colour with a word and a second visual cue. A status might read “current”, “stale”, “checked” or “no reading”, with an icon or pattern alongside it. Decide which statuses a department can assign. “Warning” is useful only when an expert has checked the threshold and a named team knows what response follows. A data gap should not appear as an ordinary value in a paler shade.

Check text, line, icon and focus contrast in the actual dashboard, including enlarged text, high-contrast settings, narrow windows and mobile views. For time series, distinct line styles or direct labels often hold up better than a legend made only from coloured swatches.

Keyboard access and live updates need their own acceptance path

A map may use drag, zoom, hover and click while remaining unavailable to keyboard users. Run an acceptance test without a mouse: tab through the place filter, time selector, site list and map controls; check that focus is visible and moves in a useful order. If a time slider requires dragging, offer keyboard controls such as buttons or a clearly labelled selector. WCAG 2.2 includes requirements covering keyboard operation, visible focus, target size and alternatives to dragging movements.

A live dashboard needs a calm way to handle new readings. Show “last updated” and the state of the series. Residents should be able to notice a refresh without repeated interruptions. WCAG criterion 4.1.3 covers status messages that change without moving focus. “Three new readings since 14:30” is usually more useful than announcing every site again. The W3C explanation of status messages explains why assistive technology must detect such changes.

Where possible, let residents pause automatic updates or refresh the view themselves. A visible update time explains more than a flashing “live” label.

The legal team checks which rule applies

For public bodies within its scope, Germany's BITV 2.0 covers websites, mobile applications, electronically supported administrative workflows and graphical interfaces. Section 3 describes accessibility as perceivable, operable, understandable and robust. Section 12 of the Federal Disability Equality Act defines federal public bodies. A municipal team should therefore avoid assuming that BITV 2.0 directly applies to every municipality. Legal counsel should check the relevant Land rules and the specific service. WCAG is a useful technical reference; the legal team determines which standard governs the service.

A good acceptance test asks questions instead of claiming compliance

An automated checker finds some structure and contrast problems. It cannot decide whether a text summary explains a water-level chart. The GOV.UK frontend accessibility guide recommends manual checks, keyboard testing and tests with common browser and assistive-technology combinations. A municipality can use these methods while its legal team checks the binding German requirements.

A short scenario-based acceptance test finds problems faster than an abstract checklist:

1. Find the latest water-level reading for one named site using only the keyboard.
2. Identify the value, unit, observation time and status without using colour or the map.
3. Compare one week with the previous week and describe the visible trend.
4. Find a site without fresh data and distinguish “stale” from “normal”.
5. Increase the text size and check that values, place names and controls remain visible.
6. Explore the map with a screen reader, then switch to the site list.
7. Check that new readings are announced without disrupting navigation.

Test with people who use the relevant access methods, including keyboard and screen-reader users. The team should not present a passing automated scan as evidence that the dashboard is understandable. Record each barrier with the scenario it affects, the responsible team and an agreed fix or exception path.

urbanOS fits when several data areas need the same public views

The urbanOS Urban Data and Urban Intelligence platform suits municipalities that combine readings from several projects, teams or neighbourhoods and run public dashboards beside private, group and semi-public views. The platform page documents dashboard visibility by project, team or neighbourhood, along with multilingual support and light and dark modes. That can make urbanOS a useful foundation for cities sharing public readings alongside internal operations views. The page does not document WCAG conformance for individual charts, tables, filters or maps. Before purchase, the municipality needs to test the actual public view with keyboard, screen reader, text enlargement and text alternatives. A city that needs only one simple public report, without multiple sensor services, may find an accessible municipal CMS or a focused single-purpose service sufficient.

Seven checks support release of a public dashboard

A municipality can release a sensor dashboard when its team can show seven things:

• The public purpose and the resident's main question are clear.
• Each central reading shows its property, unit, place, observation time and status.
• Every important chart has a short statement and a structured data view.
• Each map has a searchable text list or table for the same sites.
• Text, icon or pattern reinforces any colour meaning.
• Filters, time selection and navigation work without a mouse; focus and status changes remain detectable.
• People using the relevant access methods have tested the actual public view.

This review does more than tick visual rules. It shows whether a resident can find a municipal reading, interpret it and follow up when needed.