Search and map pin demo

What it is

A streetmap of a residential subdivision: a raster (PNG) base for sighted context, with a checkbox-curated pin overlay as the accessible layer on top. The pins are of two kinds — the properties for sale, which are the search results, and a handful of local amenities around them: a school, shops, a place of worship, somewhere to walk. Cartesian via touch, polar on tap; the selected pin sits at the centre of the viewport as the datum everything else is described against.

Shown briefly at the 2019 Guelph Accessibility Conference alongside the East End Toronto streetmap, where the family’s interaction model was first presented.

Why a raster base, and why that’s right here

The later maps in the family draw everything as addressable SVG, because their job is to let a non-sighted user explore the detailed space itself. This demo does not work that way, and that is a deliberate, fit-for-purpose choice rather than a shortcoming. Here what matters are the pinned points of interest— where the properties are in the subdivision — not the detail of the streets around them. The map renders a raster base for sighted context, and the accessible, interactive layer is the pin overlay drawn on top: only the pins need to be addressable, focusable, and described, because only the pins are what the map is about.

This is the family’s working principle in miniature: there is no single right way to render an accessible map — the rendering should follow the job. This demo answers “where are the properties, and what is near each one?”; the East End Toronto streetmap and the terminal mapanswer “help me explore this whole space,” and pay the cost of making every feature addressable to do it. Why one model renders so differently across the family is taken up in how an accessible map is built.

The information behind the pins

Each pin is a typed node. A property carries its address and the things a buyer filters on — bedrooms, bathrooms, style, price. An amenity carries its name and its class: education, retail, a place of worship, somewhere to walk. Between a property and the amenities around it runs the relation that actually matters to a buyer — convenience: how near each amenity is, and in which direction.

That relation is not stored. It is computed from the coordinates the moment a property is chosen, which is why the same handful of pins can answer one buyer’s priorities and then another’s without the map changing. The general shape of this — typed nodes, a convenience graph, weights that follow need — is set out in how an accessible map is built; this demo is its simplest instance, which is exactly what makes it a good place to see it.

Search, and where focus goes

The search filters the properties: bedrooms, bathrooms, style, and price narrow which pins the map shows. Choosing a result then does something deliberately unobvious — focus stays on the results list rather than jumping to the property on the map.

The reason is the buyer’s actual task. People want to pick several candidates and then compare where they sit relative to the things they care about; pulling focus onto the map at each pick would wreck that. Instead, a live region announces “property displayed on the map,” and the property waits there to be found. Keeping focus put avoids an unexpected change of context, and the announcement does the work the focus move would have done.

Finding a property, and the description around it

Because focus does not move, every pin has to be cheap to reach by navigation — so each property is both a heading and a button. A screen-reader user can jump straight to it by heading or by control, whichever rotor they reach for, and activate it once there.

One subtlety, because it is a common trap: the heading and the button are kept as siblings, not nested. ARIA treats a button’s descendants as presentational, so a heading placed inside a button can be folded into the button’s name and disappear from the headings list. Keeping them siblings guarantees the heading stays a heading; the reasoning is worked through in how an accessible map is built.

Land on a property and its surroundings are described from it outward: the nearest amenities first, then the next ring further out, each given as a name, a distance, and a compass direction. That onion-ring order is the polar reading made concrete — closest matters most, and the description sweeps around the compass rather than scattering across the map. Why that order is a separate problem from the importance of each amenity — and why a plain “nearest first” list is not enough — is worked through in how an accessible map is built; here the set is small enough to hear in full.

Why this demo produced the polar finding

The simplicity is the point. Most accessible-mapping prototypes start by piling on features — POIs, accessibility tags, transit overlays — and the cognitive load of the feature set obscures whatever spatial-cognition decision is being made underneath. With residential streets and nothing else, the modality-conversion problem became visible: the sighted observer scans the map in two dimensions; the non-sighted user, hearing announcements sequentially, has nothing like a two-dimensional reference frame to hold those announcements in. The visual map is Cartesian. The audio experience the user inhabits is polar.

The finding generalised. It applies to a terminal’s gates and washrooms and a streetmap’s pubs and parks as much as to this demo’s residential streets. The simplicity here is what made the generalisation visible; the richer demos use it without re-discovering it.

Try the interactive demo

Open the search and map pin demo (opens in a new window)

Once opened, the demo takes over keyboard navigation, focus management, and screen-reader announcements, so it runs on its own surface rather than inside this page — which is why it opens in a new window. Close it to come back here.

Source

GPL-3.0. Source: github.com/bobdodd/search-and-map-pins. A single self-contained HTML file; the base map and all assets are original work.