East Toronto streetmap

What it is

A section of east Toronto rendered from one OSM tile, roughly 1km². Visual fidelity isn’t the point — the rendering is basic by design, because the interest was in the architecture of the SVG itself: whether OSM features could be turned into screen-reader-navigable structure rather than into a picture a sighted user looks at.

The conceptual model introduced here — ARIA Landmarks to group features, filters to show or suppress categories, and the rotor to skim a category fast — became the family resemblance that the three later maps in the lineage share: the multi-tile, fully-rendered Toronto streetmap currently in active development, the terminal map, and this east Toronto demo where the model originated.

The SVG architecture

The demo is a single SVG generated from a long-ago one-time pull of OpenStreetMap data for a section of east Toronto, 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 user), 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 extract.

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 in-development multi-tile Toronto streetmap. It isn’t part of this single-tile demo.

Feature inventory

Eighteen top-level OSM categories with hundreds of subcategories rendered: 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. The breadth that makes a map a map rather than a points-of-interest overlay.

A map to explore, not a set of pins

That last distinction is where this demo parts company with the Groves. The Groves is about its pinned points of interest— where the properties are — so it renders a raster base with an addressable pin overlay, and only the pins need to be reachable. This map has the opposite job: letting a non-sighted user explore the detailed space itself. That is why everythinghere is drawn as addressable SVG, and why the affordances for navigating a whole map — ARIA landmarks to group features, category filters to manage clutter, and the rotor to skim one category at a time — first became necessary, and first appeared, here. 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 multi-tile Toronto streetmap 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.

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. 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 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; the name has now been retired in favour of one that describes the map’s actual content.

The lineage reads in three steps. The Groves subdivision work 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 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 multi-tile Toronto streetmap currently under active development (the direct architectural successor, scaling the single-tile 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 it

The live demo currently lives at bobd76.sg-host.com pending migration off SiteGround to the OVH VPS. After migration the demo moves to maps-east-toronto.a11ybob.com and the link here updates.

Like the other two demos, the east Toronto map takes over keyboard navigation, focus management, and screen-reader announcements once opened; that is why it lives at its own URL rather than as an iframe on this page.

Source

GPL-3.0. Source: github.com/bobdodd/accessible-maps. The tile-generation Python pipeline and the web-app source are both part of the public artefact.

Reading on

• The CISNA Model — the four-layer architecture this tile pipeline is an instantiation of.