Playgrounds

Three interactive surfaces, each running real engine code in the browser. The Paradise playground analyses code as you type; the Action Language playground executes the original PhD-era language; the maps demo lets you experience the polar-coordinate finding first-hand. No screenshots, no “watch the video” placeholders — the artefact is the page.

Paradise playground

Edit HTML, JavaScript, and CSS across multiple files; watch the Paradise analyser re-run on every keystroke and report cross-file accessibility issues with severity, confidence, WCAG mapping, and suggested fixes. Five curated examples covering cross-file demonstrations and a deliberate-fail mode showing the analyser’s reasoning under each.

Bundles the simulator suite too: a virtual screen reader that walks the page as VoiceOver / NVDA / JAWS would, a switch-access scanner with configurable speed, and a session recorder/replayer for AT walks captured for later review.

The flagship playground. The site’s strongest single demonstration of accessibility analysis happening live.

Action Language playground

Four worked examples of the original PhD-era Action Language XML notation, executing in your browser via a TypeScript port of the Carnforth threaded-interpreter engine. Edit the XML and re-run; watch the action tree re-parse live; step through a structured execution trace.

The four examples build through Fibonacci (basic recursion), conditional content selection (accessibility-shaped if-then-else), Shlaer-Mellor state migration (notification lifecycle with disjoint-complete subtypes), and an adaptation example (button rollover with profile-dependent inventory selection).

Demonstrates the methodological substrate in code, not just in description. Cross-references the Shlaer-Mellor lens.

Accessible maps demo

The simplest of the three accessible-maps demos — The Groves subdivision in Buckhorn, Ontario. Residential streets, no interior features; the cognitive load is stripped down so the dual-mode interaction can be felt directly. Cartesian via touch (the finger gives spatial reference; each location announces what is under it) plus polar on tap (POIs described as name, distance, compass direction from the tapped point). Pin-as-datum at viewport centre; the map orbits the pin.

The simplicity is the point. With residential streets and nothing else, the modality-conversion problem becomes 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. That is the polar-coordinate finding.

The two richer demos (the terminal map’s interior wayfinding and the East Toronto streetmap, where the ARIA Landmarks + filters + rotor model first appeared) live at /maps/terminal-map and /maps/east-toronto-streetmap.

Why playgrounds, not screenshots

The site’s working principle for the demonstrations: where running code would teach better than a static description, the running code is what ships. Each playground above runs a real engine in the browser — the Paradise analyser, the Action Language threaded-interpreter, the accessible-maps SVG-rendered viewer with its four-population interaction model. The reader does not have to take the page’s word for what the engine does; they can run it and see.

The trade is that the bundles are heavier than they would be for prose pages, and that interactive surfaces carry an accessibility burden that prose pages do not. Both costs have been paid; the colophon names them.

Reading on

  • Tools— the companion accessibility-testing tools (Carnforth, automated-testing, lived user testing).
  • Paradise— the analyser engine the Paradise playground runs.
  • Maps— the seven-year body of work the maps demo belongs to.
  • Colophon— the full set of decisions, including the case for running code over screenshots and the choice of CodeMirror 6 across both code-editor surfaces.