Lineage

Paradise is the practical realisation of an idea I parked in 2010 when I left academia for CNIB. The route from there to here passes through real-time systems, Shlaer-Mellor executable UML, the W4A 2008 CISNA Model paper, twenty-five years of practitioner work at CNIB, and a long detour into tools that didn’t quite reach what the framework wanted. ActionLanguage, the intermediate representation (IR) at the heart of Paradise, descends directly from a tree-shaped semantic model I designed for that PhD-era work — finally matched, fifteen years later, with a problem it was the right shape for.

Real-time systems and Shlaer-Mellor

I started in real-time systems — telephony switching, ISDN call control, the kind of code where a missed deadline is a user-visible failure rather than an aesthetic concern. The dominant rigorous-modelling notation of that era was Shlaer-Mellor, later branded executable UML. Models had to be simulatable; specifications had to be precise enough to compile to running systems. The mindset that came with that work — small algorithm fragments described in formal languages, executable from their specification, substitutable at runtime — never left me.

The PhD: adaptive user interfaces

At Teesside University I worked on adaptive user interfaces for mobile accessibility — UIs that could reshape themselves for the user’s capabilities, context, and preferences, not by serving up a different design but by substituting algorithm fragments at runtime. The same mindset as Shlaer-Mellor: a program is a tree of actions; some sub-trees can be replaced with semantically-equivalent variants tuned to a particular user.

Two artefacts came out of that work. The Action Language Model — a tree-based semantic representation of small block-structured programs, with sequenced child actions, typed attributes, and an accompanying execution engine. And the Adaptation Model — a description of variations between algorithm versions, expressed as add/modify/delete operations on the action tree.

The PhD itself didn’t complete. Funding ran out, life changed, I went to CNIB. The Action Language Model and the execution engine sat on my hard drive for fifteen years.

The CISNA Model — W4A 2008

While the PhD was active, Steve Green, Elaine Pearson, and I published The CISNA Model of Accessible Adaptive Hypermedia at W4A 2008 (doi:10.1145/1368044.1368052). The paper extends the classical Dexter Model of hypertext for an era of script-heavy, AJAX-driven content, distinguishing five abstractions: content, inventory, semantics, navigation, and adaptation. The Action Language Model fitted into the adaptation layer — the place where algorithm fragments could be swapped to serve different users.

The paper has aged better than I expected. The five-layer decomposition still describes the actual structure of a modern web page reasonably well; the explicit adaptation layer turned out to be exactly where accessibility tooling operates when it operates at the right level. Paradise sits squarely in that layer.

Twenty-five years of practitioner work

At CNIB I led accessibility audits, remediation, and tooling for two and a half decades. The view from that work was that the gap between research and practice was persistent and structural. Every research framework I knew of presupposed a level of source-level analysis that the tools of the day couldn’t deliver — eslint-style AST checkers couldn’t see across files, and rendered-DOM scanners couldn’t see source intent. The CISNA Model’s adaptation layer was conceptually right but practically empty.

What changed wasn’t the research. What changed was JavaScript itself getting structured enough that source-level reasoning about behaviour became tractable — ES6 classes, modules, closures with predictable scope rules, and the parser ecosystem (Acorn, Babel) that could turn them into ASTs reliably. With that in place, the missing piece was a representation that captured what the program does, not just what was written. I already had one, in a folder I hadn’t opened in fifteen years.

The tools lineage, end to end

The naming lineage now reads as one continuous engineering project across two complementary branches — the runtime/AI branch and the source-level static-analysis branch — both descending from the same theoretical starting point and converging again at present-day practice.

  • CISNA Model— theory. W4A 2008, with Steve Green and Elaine Pearson (doi:10.1145/1368044.1368052). The five-layer model of accessible adaptive hypermedia. See /research/cisna-model.
  • Carnforth-Java— the doctoral Java implementation of CISNA, with the Action Language XML notation and a Forth-style threaded-interpreter execution engine. See /playgrounds/action-language for the in-browser worked examples ported to TypeScript.
  • Carnforth — 2024 Chrome DevTools extension; runtime DOM testing focused on WCAG 4.1.2 (Name, Role, Value). Bob-owned, GPL-3.0. The first surfacing of the Carnforth name in a shipping runtime tool. (Repo originally CarnforthGPL, renamed to carnforth in May 2026.)
  • automated-testing — Bob-owned GPL repository of AI-driven accessibility-testing demonstrations. Five PoCs covering classes of issue commercial tools cannot reach. (Repo and project originally named a11yAuto, renamed to automated-testing in May 2026 to make the content more legible.)
  • autoA11y— CNIB’s much more complete production rebrand and continuation of what was then called a11yAuto. CNIB-owned. The current commercial platform sold by CNIB Access Labs; in active development; integrated with Dictaphone for lived-experience analysis.
  • Paradise (this section)— source-level multi-model static analysis in TypeScript. Bob-owned; the modern Forth-loop closure on the same execution model that started in PolyForth at Metal Box in 1984.

One name across twenty years. Three Bob-owned open-source tools across three different testing approaches; one CNIB-owned production platform between them.

The boundary between Paradise and autoA11y

The runtime/AI branch and the source-level branch are complementary, not competitive. autoA11y operates at runtime: it observes the real DOM, real focus order, real dynamic content. Paradise operates on source: it reads the HTML, JavaScript, and CSS before the page renders. The two answer different questions, and an honest accessibility practice uses both. Paradise’s repository carries an integration plan (AUTO_A11Y_INTEGRATION_PLAN.md) that names the boundary explicitly.

The boundary line: if Bob left CNIB tomorrow, would this artefact go with him?Carnforth, automated-testing, and Paradise all answer yes. autoA11y and Dictaphone answer no. The first three are mine; the last two are CNIB’s. The site treats each at its appropriate framing — portfolio for the Bob-owned tools, practice for the CNIB-owned tools.

Where ActionLanguage came from

The Action Language Model from the PhD work is — almost unaltered — the IR Paradise builds for JavaScript. The shape carried over: tree of actions, sequenced children, typed attributes, abstract enough to collapse semantically-equivalent fragments to the same tree, annotated enough to recover line numbers for diagnostics. What was rebuilt was the transcoder — the part that takes input source and produces the tree. The original transcoder was for a small custom language designed for the PhD; the new transcoder accepts JavaScript up to ES6.

The reuse isn’t accidental. The whole point of Shlaer-Mellor-style action models is that they capture executable semantics in a way that’s neutral to the source language. A model that worked for the small algorithms in the adaptive-UI PhD was always going to transfer to JavaScript fragments — the only question was whether anyone would ever bother to do the work. I bothered.

What this is heading towards

Paradise is a platform, not a finished product. Through 2029 I’ll continue developing it as a vehicle for testing the more theoretical ideas the PhD-era framework gestured at — the adaptation layer of the CISNA Model put into actual practice; semantic analysis of behaviours hidden in complex client-side JavaScript; perhaps the full Adaptation Model resurrected for runtime UI variation tuned to user capability. The plugins (the VS Code one now, a planned browser one to follow) are the user-facing release vehicles. The platform itself is where the research-and-tooling work continues to happen.

Reading on