Terminal map

Try the interactive demo

Open the interactive terminal map (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.

What a map is for

A map is not an in-situ, point-to-point guided navigation tool. It is usable without being at the place it represents: it lets you explore the space, discover spatial relationships, and understand scale from anywhere. It is alsousable when you are at the location — if the map knows where you are, it can give immediate context and the turn-by-turn experience. That second, location-aware experience is, in practice, what Google and Apple Maps give sighted, non-disabled users. This demo does the first part; it has no location sensing (see Limitations).

A map also has a physicality. Unlike step-by-step guidance, it fills the page or the screen, and every point within it has meaning tied directly to its Cartesian coordinates in that space. Proximity matters; spatial relationships matter; there is a tactile experience to be had. On a touchscreen that is an opportunity to design for explore-by-touch, and a challenge: translating that experience into meaningful interaction for a screen-reader user.

That challenge is sharper than it first appears. For blind screen-reader users in particular, explore-by- touch of a map is still a new and novel experience. Faced with a Cartesian map view, users often become disoriented, and frustrated by compass directions: they are used to relative, body-centred terms — forward, left, right, slide-right — or clock-face directions. Usability testing has recorded complaints like “That’s no good! What do you mean go east? I don’t know where east is — I need to know whether to go forward or not.” The modality breaks because the user has no prior experience of the concept of a map. People who lost their sight later in life tend to understand it; people blind from birth much less so. Maps have existed in their current form for centuries, yet for these users they are a novel interface that has to be explained.

That is why the very first focusable items on the page — before even the skip links — are two help controls, styled like skip links so they appear only on focus: Help for screen reader users and Help for keyboard navigation users, each opening a help dialog. The skip-to-map-controls and per-pier skip links follow them.

How the map is built

Major digital mapping companies serve up an imageand then render additional content — sometimes SVG — on top of it to decorate it. This terminal map has no underlying image: everything is drawn as SVG. Bob took a PDF of a terminal map and re-rendered it in SVG; the Google or OpenStreetMap approach would instead have been to take a screenshot and add interactivity on top.

Drawing everything as SVG makes the number of rendered nodes on the page far higher than the image-plus-overlay approach, which is a real cost (see Limitations). The payoff is full flexibility for assistive technology to render and interact with the map. It also avoids the “layers of zoom” images commercial maps rely on — the same picture re-served at different zoom levels for rendering efficiency — the problem Bob’s raw-OpenStreetMap Toronto model set out to replace.

The deeper reason to build from SVG is the filters. Filters over an image are limited by the detail baked into that image: it is hard to take content away, far easier to add content to a blank canvas. So the map is built bottom-up, in the manner of the CISNA model: features are drawn from an inventory up into a semantic layer to match user need and preference, and the navigation layer is then adapted to the needs of assistive-technology users. As Bob puts it, “maps really do need CISNA.”

Getting around the map

A map is not just a rectangle of coordinates; it needs other content to help a user explore it and understand what they find. The terminal map has three conceptual blocks of navigable content: the map itself, the map controls (pan and zoom), and the header(search and filters). Both the header and the controls float above the map and can be shrunk to expose more of it — because here, unlike on a Google map where the only navigable content is the sidebar, the map itself is navigable content. (In practice the header is mostly full-screen, so it could nearly as well have been pinned full-size.)

Those blocks are exposed as ARIA landmarks: the header is a banner, the map is a main region (the SVG inside it carries role=“document”), and the controls are a named region, “Map controls”. A screen-reader user can therefore step block-to-block with landmark navigation — the R key in JAWS, D in NVDA, the Landmarks rotor in VoiceOver.

Landmark navigation has a catch: it always lands you at the startof a landmark, which is not always what you want. Having explored by touch to a particular point of interest, you may want to dip back into the header or controls without losing your place on the map. So the three blocks behave like windows in Microsoft Windows — each keeps its own focus history. The F6 key moves focus to the last-focused location in each block in turn (a default the first time), announcing where focus has landed; F6 cycles left-to-right, Shift+F6 right-to-left.

F6matters beyond screen-reader efficiency. For sighted disabled users with a mobility impairment who do not use a screen reader but do use the keyboard — directly, or through assistive technology that drives the interface with keyboard events — it is the only quick way around a map interface, especially one that lets you tab through map elements. Bob’s view is that F6 is the shortcut missing from almost every website that has enough blocks of content for landmark navigation to be worthwhile.

There are also skip-to-pier links: focus-revealed links that jump to the first gate in piers A, B, C, D, and E. They are the map’s equivalent of the traditional skip-to-content link, useful on repeated visits and for keyboard-only users. How well they serve switch users is a more complicated question, covered in the switch-access and magnifier notes.

Describing space in words

To describe a whole space when there is no directional point of reference, you need Cartesian coordinates — or at least the experience of their surface. But at any single point within that space, what a person needs is relative, polar description: what is here, what is nearby, what is further away but useful, and what timely information relates to this place. The terminal map describes those relationships with compass direction and distance.

Compass directions sit awkwardly with the tester frustration noted above, and the reason is a real constraint. Egocentric directions (forward, left, right) are impossible without knowing which way the user is facing, and the demo cannot sense that. Compass plus distance is the only description that stays consistent for a fixed-orientation drawn map. Going egocentric would mean mapping the map’s frame onto the user’s body — understanding that “forward” is currently to the left and “right” is up the page — which is what a sighted person does with a paper map (unless they rotate it). Point-to-point directions could switch to egocentric once the user has been located and oriented (“turn east, then walk forward ten metres until the gate is on your right”); this demo, with no sensing, stays in compass terms.

The description comes at two levels. Sticky tooltipsname what is under the finger or at a location and give the immediately useful, timely facts — the current or next flight from a gate, whether a shop is open or closed. The left-hand panel gives the richer account: not just the place itself but where it sits relative to the gates and points of interest around it, in compass-and-distance terms. That is spatial information delivered without having to explore the map at all.

The tooltips are deliberately stickyrather than the browser’s default title-attribute tooltip, which is not accessible: it appears on hover and vanishes the moment the pointer leaves the element. At high magnification the tooltip is rarely fully inside the magnifier window, so the user must move to read it — and moving dismisses it. The sticky tooltip instead persists until the user presses Escape (all pop-up content on the map closes with Escape) or hovers another element, and it is drawn as close as possible to the hover point so at least part of it lands inside the magnifier window. This is what WCAG 2.2 success criterion 1.4.13, Content on Hover or Focus, asks for: dismissable, hoverable, persistent.

Even “what is nearby” is constructed from user need rather than read off the map. The nearest washrooms might be promoted even if they are further away than something else; if the rotor is set to optimise for blind users, a service-dog rest area might be promoted. That is CISNA in action at the most banal level.

Search

Search is central to any dense map, and on the web that means the search landmark together with explore-by-touch. Here the search field lives in the header, reachable by landmark navigation, and it is the default destination for F6 if the user has not yet visited the header.

Search is also central to not using the map. For most blind and low-vision users, search is where they will want to be, so a working principle of the design is that all of the information the graphical map shows must be findable through search, without going to the map at all. The map may explain that information better, but the information has to exist outside the map.

In practice the field offers auto-complete, with a live region announcing the number of completions as the user types (a role=“combobox” with aria-autocomplete=“list”and a shared polite status region). It should also draw on the browser’s own text history, which means the HTML autocompleteattribute should be on — even the few digital maps that offer search often break this.

One honest exception in this demo: its search and directions forms set autocomplete=“off”on purpose. With it on, the field surfaces the recorder’s own past searches, which is not wanted in the demo videos. Production maps should leave autocomplete on; the demo turns it off only to keep recordings clean.

Selecting a search result on a map is not like selecting a conventional web result, where many results resolve to one linked target and the page navigates there. On a map the behaviour is context-sensitive. On the Groves map, selecting a property highlights it and adds it to the map’s tab order with a live-region announcement, but focus stays in the results so the user can add several properties before exploring them spatially. On the terminal map, selecting a result shows that gate or POI’s full details in the header andhighlights it on the map with a live-region announcement, while focus stays on the details for reading. Those details include the item’s context — the gates and points of interest around it — so, again, spatial information without exploring the map.

A selected item is highlighted on the map with a pulsing halo, but on a busy map that can still be hard to find, especially under magnification. The “Find on map” buttonanswers that by moving the selected result to the exact centre of the map viewport — a known, repeatable location — and moving focus there. Whether a magnifier then follows that focus depends on the magnifier; the centring is the part that does not depend on it. (Details in the switch-access and magnifier notes.) A cross-hair marking that centre is a likely future improvement.

Zoom

A digital map needs two kinds of zoom: zooming the map, and zooming the whole pageso the header and controls magnify with it — the latter so that low-vision users who need text magnification can read all the text on the page, not just the text on the map. The terminal map makes this context-sensitive: the on-screen control buttons and pinch-to-zoom on the map zoom only the map; pinch-to-zoom on the header or the controls zooms the whole page. The context of use selects the mode.

Routing and step-by-step directions

The map can draw a route between selected gates or points of interest. It is an illustrative route, not real pathfinding. The header then offers step-by-step navigation: a Next button announces each segment in turn, an End step-by-step navigationbutton exits, and a segments list lets the user jump to any segment — each entry announces its distance, the active one is marked, and the matching segment highlights on the map while the others dim. The underlying route also carries an accessible-route flag, a total distance, and an estimated time.

Limitations

The demo is a proof of the approach, not a finished product, and it is worth being precise about where it stops.

• No location sensing.It supports exploration — understanding the space and its relationships from anywhere — but not the in-situ, point-to-point experience that needs to know where the user is.
• Switch access is only partially served. The skip-to-pier links and rich interactive structure are not a reliable primary accommodation for switch users; landmark structure and F6 region cycling help more, but the high node count works against them. The switch-access notes set out why.
• A high rendered-node count.Drawing everything as SVG, rather than image-plus-overlay, produces many more DOM nodes — more for a switch user to scan through, and a potential rendering cost.
• Zoom does not change level of detail. Gate numbers and POIs simply scale; nothing is grouped or dropped as you zoom out. A fuller version would group gates (a single “gates 41–44”) and group POIs semantically (“shops”), while keeping security and washrooms ungrouped until the zoom level forced otherwise.
• Two dimensions only.Buildings are three-dimensional; the map shows one level (Level 3, Departures). There is a level selector but no visible connectors between levels. A fuller version would add connector POIs for stairs, elevators, and escalators, with “teleport” controls that move the user between levels — focus landing on the connecting POI on the far side, with live-region announcements to re-orient.
• The highlight pulse does not yet respect reduced-motion. The pulse is deliberate — it draws attention to a point — but under prefers-reduced-motion it should pulse only briefly, for a user-configurable time. There is no settings surface for that yet.

Open questions

Some design questions are genuinely open. When directions cross between levels, the expectation is that the route shows the segment for the level currently displayed, and changing level shows that level’s segment. But the step-by-step instructions raise unresolved questions: should per-segment progress be represented on the map at all, and what should a blind screen-reader user know about what is happening on the map as they step through a route? These are not yet answered.

Reading on

• Switch access and magnifier support — how skip links, landmarks, and focus behave across switch-access and magnification software, and what that means for this map.
• The CISNA Model — the layered architecture the map is built from.
• Maps— the wider accessible-maps work this demo belongs to.

Source

GPL-3.0. Source: github.com/bobdodd/terminal-map. The terminal map has its own repository; the other two demos live in accessible-maps.