East End Toronto streetmap

A map of the city fabric, not a set of pins

It helps to set this map against the search and map pin demo, because both show something called a “map” and they are fundamentally different kinds of thing. In the search and pin demo the streetmap is essentially a hero image: a backdrop on which the pins and controls are displayed. It isn’t the subject; it’s the canvas. Its information model is about a subdivision— the properties for sale and the handful of amenities around them — and the relationships it expresses are the relationships of the subdivision itself and of the amenities to each other, not to the world they sit in. It is, in effect, “Google Maps search and pins” for a subdivision, with the surrounding city present only as imagery.

This map has the opposite job. It is about the underlying streetmap itself— or at least one small fraction of a city map. Here the map is the subject. Its information model is the city fabric: land areas populated with buildings — houses, shops, schools, bus stops, places of worship — and the relationships between them, in real geographic space. And this simple demo has no search at all, where the pin demo is built around it.

That difference is why everything here is drawn as addressable SVG, while the pin demo can render a raster base and make only its pins reachable. When the space itself is the content, the reader needs ways through it; a handful of pins does not. There is no single right answer across the family — the rendering and the affordances follow the job. The tiled Toronto map and the terminal map inherit this map’s “explore the space” brief and the navigation model that goes with it; the terminal map then adds search, routing, level structure, and the F6 region cycle on top.

Everything is interactive — so explore by touch

Making the map the content has a consequence: there are many, many more interactive elements than a pin map has. Almost everything on the map is nominally interactive, or at the very least has to be described to a screen-reader user. That is huge. Imagine tabbing through every single feature of a city block, even if you wanted to — it is untenable. The map needs ways for a reader to take it in without walking the whole of it in a line, and the family’s three navigation patterns — explore-by-touch, filters, and the rotor — exist precisely to make that possible.

The first pattern is explore-by-touch. Move a finger over a touchscreen — or a mouse over the map — and you hear what is under it. That lets blind and low-vision readers build up the spatial relationships of a place directly: a mental picture of what is where, and what sits next to what, formed by exploring the surface rather than reconstructing it from a linear list of announcements. It assumes the reader has some proprioception — the kinaesthetic sense of where their hand and finger are in space — and a sense of touch to know when their finger is actually on the surface. For the people it suits, it turns the map from a list back into a space.

Filters

The second pattern is filters, which literally add and remove whole categories of content from the map — buildings, transit stops, shops. For everyone, they cut visual clutter: a category the reader isn’t interested in simply isn’t drawn. For a screen-reader user moving through the map by keyboard or swipe, they cut a huge amount of noise, because a category that isn’t shown is also a category that isn’t announced. This is a basic demo, so there are only a few filters; the tiled Toronto map has a great many more, over far more data.

The rotor

The third pattern is the rotor, and it exists specifically to help keyboard and swipe users, letting them focus on one category of map content at a time. In this demo the rotor is a set of radio buttons— one category at a time; the tiled map expands it to multi-select checkboxes, so a reader can hold several categories in view at once. Filters change the map for everyone; the rotor narrows things only for the keyboard and swipe reader, without altering what is drawn for a sighted one.

The name is deliberate. The map rotor tries to replicate a concept a screen-reader user already knows. On the web, a screen-reader user reaches for their rotor to choose what they navigate by — paragraphs, words, buttons, headings, links. This rotor reuses exactly that mental model, except that instead of selecting paragraphs or buttons, the reader is selecting categories of map information— transit, shops, schools, places of worship, parks. Taken together with the filters, it is what makes tabbing with a keyboard, or swiping on a touchscreen, practicable at all: without it, you would be stepping through every feature on a city map; with it, you constrain the journey to the category you care about.

Underneath, the framing is a piece of plain computer science. The map is a giant directed graph, and the filters and the rotor are choosing which of its nodes are visible and which circuits a reader travels through them — deciding which nodes exist for navigation, and in what sequence you move between them. That is the same underlying idea the simpler search and map pin demo uses, in lighter form; the rotor here is the richer expression of it, and the shared model — typed nodes, the convenience graph, the order a circuit is read in — is set out in how an accessible map is built.

The look and feel

The East End Toronto map was an exploration of the underlying OpenStreetMap data and of navigation modalities, and out of that Bob built a very simplified rendering model. Buildings are drawn, but streets are just lines, and there is no text on the map at all. The whole thing is black and white. None of that is an oversight: the focus was much more on the screen-reader reader’s perspective than on producing a visually rich map, so the rendering was kept deliberately spare and the experiment could be about data and navigation rather than cartographic polish. (The only text a sighted user sees is the demo’s sticky tooltip, discussed below.)

A fragment, not the whole

One thing to be clear about: this demo deliberately uses only a small part of the data — a static fragment of a single OpenStreetMap tile, not all of OpenStreetMap, and not even a whole tile. That is a scoping choice for an experiment, and it has a visible consequence: the map fades out towards its edges. Because only the fragment is rendered, a great deal of land use is left unpopulated near the boundaries — even though the full boundaries of that land use exist in the data, the fragment simply doesn’t draw them all in.

The effect is a faintly Thirteenth Floor quality — after the film in which people discover they are inside a simulation by travelling somewhere they’d never normally think to go, and finding the rendering of their world breaking down at the edges. Travel far enough towards the boundary of this map and the world thins out and stops being rendered in just that way. It is an honest artefact of using a single static fragment, not a polished edge.

The SVG architecture

The demo is a single SVG generated from a long-ago, one-time pull of that OpenStreetMap fragment, with ARIA labels pre-built at generation time. The data is not refreshed and is not the point — nothing on the demo queries OpenStreetMap (or any spatial database) at runtime; filter toggles run at CSS speed rather than at JavaScript speed; the SVG is served as a plain asset. The interest of the artefact is the structure of the SVG itself: whether an OSM extract could be turned into screen-reader-navigable structure rather than into a picture a sighted user looks at.

The architecture is a four-layer CISNA instantiation in cartographic form — Adaptation (which features to show this reader), Navigation (how to move between them), Semantics (what each feature means and how it relates to nearby features), and Inventory (which OSM features have been rendered into the SVG) — with External Content sitting beneath everything as the raw OpenStreetMap fragment.

The pipeline that processes OSM data into many pre-rendered SVG tiles served from Bob’s own tile server, with the viewer fetching tiles as the viewport pans, is the contribution of the tiled Toronto map. It isn’t part of this single-fragment demo.

Feature inventory

Within that fragment, the renderer handles eighteen top-level OSM categories with hundreds of subcategories: buildings, roads (with casings), transit stops, parks, healthcare, transportation infrastructure (railways/airports/highways/platforms), financial services, sustenance & food, accommodation & tourism, entertainment & culture, emergency services, historic features, shops, schools, places of worship, addresses, barriers, natural features. That breadth of kinds is what makes it a map rather than a points-of-interest overlay — even though, in extent, it is only the one small fragment.

The trouble with the data

The hardest problem on this map — and on the tiled map — is information quality. The map is built from real OpenStreetMap data, and what you get for the East End of Toronto is incomplete, out of date, and unstructured. This is the standing problem with crowd-sourced information, and OpenStreetMap is full of it: there is no overarching quality assurance, and no process to age information out. Many accessibility initiatives that build on OpenStreetMap hit exactly the same wall — it isn’t unique to this map. In places the data is years out of date: shops that have changed or closed, and buildings long since gone that are still in the record.

The lack of structure bites too. OpenStreetMap gives the locations of transit stops, sometimes with route numbers and sometimes not, and without the order of the route. So if a reader wants to move through the transit stops, it is hard to know what order to present them in — the circuit has no inherent pattern. In practice the demo uses the order the OpenStreetMap database happens to give, which falls out as a rough geographic clustering rather than the order you would actually ride the route. The reason to use OpenStreetMap regardless is simple and pragmatic: it is one of the few — if not the only — international streetmaps with open data.

Semantic data for graphical content

That leads to a simple observation, and it is the through-line for this whole family of maps:

In the same way that we need a semantic data structure to help assistive technology present HTML content and navigation options to users, we need semantic data for graphical content — maps like this, or graphs, charts, or animated simulations — and the quality of that data structure directly affects usability for all users, and for disabled users in particular.

Semantic HTML is what lets assistive technology present a document and its navigation options. Graphical content needs the direct equivalent: an underlying semantic structure, of the same kind. The need generalises well beyond maps — the same is true of graphs, charts, and animated simulations, anything graphical a reader has to understand and navigate. And the quality of that structure is the lever: where the data is thin, stale, or unstructured, as the previous section describes, the experience built on it can only be as good as the structure allows — and it is disabled readers, who depend most on the structure being there and being correct, who feel the shortfall first. These map demos are a worked example of that principle, not just “accessible maps.” The four-layer model it sits inside is the CISNA Model.

Colour

This demo simply avoids colour — the map is black and white — because colour on a complex, busy map is genuinely hard for low-vision readers, and the black-and-white choice sidesteps that to keep the focus on structure and navigation. Three things make map colour hard:

• Colour blindness. The particular hues you choose decide whether colour-blind readers can tell categories apart at all.
• Adjacent-feature contrast. On a busy map features sit right next to each other, so the contrast between adjacent fills and lines becomes a problem in its own right, not just contrast against the background.
• Brightness. Large shifts in overall brightness across a map can force a reader to adjust the brightness of their monitor to cope.

The likely answer is to bring onto the map the discipline this site already uses: it varies hue to separate and section content while holding the contrast ratio identical between page groups, so no group is harder to read than another and the brightness never lurches. A map probably needs the same — distinguish categories by hue, hold contrast and brightness constant across them — rather than letting category colours vary in contrast and brightness and creating the problems above.

Text on the map

No text is drawn on the map at all; the only text a sighted reader sees is carried by the (accessible, sticky) tooltip. Whether on-map lettering can be made accessible is, for Bob, an open question, and it sits on a real tension. Accessible text is usually taken to be horizontal and, for western languages, left to right. That doesn’t suit most maps: street names are conventionally written within the rendering of the street, and follow and bend along it— curving, rotating, running at whatever angle the road runs. Building and amenity names are often horizontal, but street names are not, because it makes little sense to write a horizontal street name on a street running primarily vertically up the page; the label has to follow the geometry of the road to read as belonging to it.

So the two conventions pull against each other — “accessible means horizontal, left to right” versus “a street label must follow the curving line of its street.” Bob’s current best guess — untested, and not yet put to users — is to render street names traditionally, following and bending along the road as cartography expects, and to rely on the sticky tooltip and the ARIA label to carry the accessible, horizontal reading, rather than to force the on-map text itself to be accessible.

Speaking the map, and finding your place

Two harder problems get a page of their own, because they are live design questions rather than settled practice. The first is how features are announced. This map plays a particular trick: it exposes the SVG so that the screen reader itself announces what is under the finger on explore-by-touch — but delegating the announcement to the screen reader also means delegating the focus outline, which today is a rectangle regardless of the feature’s shape and a default colour and weight that work poorly over a map. The terminal map takes the opposite choice — announcing through a live region, which lets it draw its own highlight but makes announcements queue and go stale on a busy map. The proposed way out is the Web Speech API, behind an opt-in accessibility toggle, with the operating system’s audio ducking keeping the screen reader legible over the map’s voice.

The second is how a reader stays oriented: keeping focus visible when the map is zoomed out and its features are tiny (a question with four candidate answers, from a magnification lens to contextual semantic zoom), and knowing where you are when a streetmap, unlike the pin demo, has no single anchor to describe everything against — addressed by a relative account (nearest neighbours, their importance, and compass direction), an absolute one (the view’s real-world size, and how far a finger-width represents), or by letting the reader plant an anchor of their own.

Speaking the map, and finding your place works through both in full.

Where it came from

First publicly shown as a 45-minute in-person session at the 2019 Guelph Accessibility Conference at the University of Guelph — this is the demo that has actually been presented publicly. The talk demoed an earlier, low-fidelity, black-and-white, file:///-served rendering of the streetmap with the dual-mode interaction model and the pin-as-datum already present in primitive form; the search and map pin demo was shown briefly alongside it. The architectural decisions on this page — SVG over raster, CSS filters over JS, OpenStreetMap as the data source — came from the work that followed. The project’s earlier working name was “Guelph streetmap” for that reason; it has since been renamed for the area it actually covers — the East End of Toronto, which is the real name of that part of the city, not a loose “east Toronto.”

The lineage reads in three steps. The search and map pin demo came first — it introduced the Cartesian-to-polar verbal description of space (the vocabulary the rotor still uses: “1 o’clock, fifty metres” rather than “at coordinates X, Y”). This East End Toronto demo came second — the conceptual model of ARIA Landmarks + filters + rotor that the family of maps now shares. The three maps that inherit the model: the tiled Toronto map (the direct architectural successor, scaling the single-fragment pipeline shown here to a full city), the terminal map (which carries the same conceptual model into an indoor airport surface), and this demo itself, which remains live as the architectural reference.

Try the interactive demo

Open the East End Toronto streetmap (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/east-toronto-streetmap. The web-app source and the full OpenStreetMap-derived data pipeline — the raw map.osm extract, the shapefile exports, and the GeoJSON layers — are part of the public artefact; the map data is © OpenStreetMap contributors, under ODbL.

Reading on

• Speaking the map, and finding your place — the two open problems in full: how features are announced (and who draws focus), and how a reader stays oriented at zoom and without an anchor.
• How an accessible map is built — the shared model behind the family: typed nodes, the convenience graph, the polar circuit, and how it is exposed to assistive technology.
• The CISNA Model — the four-layer architecture this map is an instantiation of.