Tools

A small family of accessibility-testing tools, all Bob-owned and open-source, that approach the same problem space from three angles: AI-driven, runtime DOM-based, and described-not-demoed. Each has its own scope and limits, and each is honest about both. Paradise — the source-level multi-model analyser — is intellectually the deepest work of this kind and lives at its own top-level entry. Three of the tools here are its companions. The fourth is a different kind of thing: not something for finding accessibility problems, but something built to be used by the people the field usually only tests for.

The tools

Carnforth

A GPL-3.0 Chrome DevTools extension that tests pages for accessible-name conformance against WCAG 4.1.2. Runtime testing against the rendered DOM, focused on one criterion in depth rather than a broad sweep. Demonstrated at a11yTO Accessibility Camp 2024.

Bob-owned. Open source. The runtime counterpart to Paradise’s source-level analysis.

Automated accessibility testing

Five proof-of-concept demonstrations of AI-driven accessibility testing applied to specific classes of issue commercial scanners cannot reach. Each demo lands with the verbatim Claude prompt, the captured response, and an honest discussion of what worked and what didn’t. Language detection, headings, positioning, interactivity, modal dialogs.

Bob-owned. Open source. Research-in-progress, not a tool catalogue — the framing matters.

Lived User Testing

Audio-and-video AI analysis of lived-experience tester recordings: a five-stage pipeline (FFmpeg splits / Deepgram transcription / pyannote speaker identification / Claude analysis with extended context) producing structured, WCAG-mapped reports with time-indexed callouts. The CNIB-owned production tool is described here; a Bob-owned research line adds Qwen 3.5 (Alibaba’s vision-language model, via API) for analysis of screen recordings of user interaction — the video/vision counterpart to Claude’s audio analysis.

CNIB-owned production tool; Bob-owned research line in development. Described, not demoed.

Blockly for Lego

A block programming environment for LEGO Education SPIKE Prime that a blind student can use on their own, with a keyboard and a screen reader. The official SPIKE app’s coding canvas cannot be operated without sight — it is built on a 2016 fork of Blockly that never received any of the accessibility work — so this replaces it: Blockly 13, which ships keyboard navigation and screen reader support, generating ordinary SPIKE MicroPython and sending it to the hub over the protocol LEGO publishes itself. No reverse engineering; the protocol is Apache 2.0.

Built for a university robotics club that wants blind and sighted students working on the same programs, in the same representation, at the same time — blocks for everyone, rather than a separate text track for the blind students. It comes with a hub simulator that narrates what the robot did in sentences meant to be heard, and a 3D view built from real LEGO parts for the rest of the room. Modelling the robot in three dimensions is what revealed that the driving base everyone had been calibrating against could not physically be built.

Bob-owned. Apache 2.0. Runs here against a real hub over Bluetooth; the simulator and the 3D view need the project running on your own machine, because a browser will not let a website reach them. Not yet tested by anyone who uses a screen reader daily.

Reading on

  • Paradise — source-level multi-model accessibility analysis; intellectually the deepest of the testing work and its own top-level entry.
  • Playgrounds — the interactive surfaces the tools feed into.
  • Paradise — lineage — the end-to-end tools lineage from the CISNA Model (2008) through to today.