AI for Accessibility Toolkit

An open toolkit for building apps that adapt to each person’s accessibility needs.

What it is · Key terms · Who it’s for · Try it · Contributing · Docs

---

Not a developer? The browser extensions built on this toolkit are in the extension repository, with an install guide that needs no coding. There’s also a plain-language overview in docs/TLDR.md.

What it is

The toolkit is a set of parts a developer can use to make an app adapt to a person. It can:

• learn what a person needs, e.g., larger text or fewer animations,
• keep those needs in a profile on the person’s device,
• and turn the profile into skills, which are sets of adaptations that change the app for that person.

You choose which parts to use and how your app uses them.

flowchart LR
  accTitle: How the toolkit fits
  accDescr: A person says what they need. Inside the toolkit, a profile stores those needs and a skill says which adaptations fit. The host application applies the adaptation on its own surface. The person approves, corrects or undoes it, and the profile learns from that. A developer takes whichever toolkit components suit their application.
  subgraph T[The toolkit: take the components that fit your application]
    direction LR
    A[Profilethe person's own, shared onlywith their permission] --> S[Skillwhich adaptations, at what settings]
  end
  P[A personsays what they need] --> A
  S --> D[Adaptationthe host application applies it,on its own surface]
  D --> V[The person approves,corrects or undoes]
  V -- the profile learns --> A

A person says what they need, the profile picks skills that fit, your app applies the adaptations, and the person can approve, correct or undo each one. The profile learns from those choices.

The same profile works across platforms. For example, a profile with larger text (textSize 1.5), a dark theme and reduced motion becomes these settings in the renderers in toolkit/surfaces/:

The mobile settings use the same names as the accessibility settings in iOS and Android. The XR renderer gives text size as an angle at the eye, since a font size doesn’t mean much in a headset. A person only needs to set up their profile once to use it on all three.

Key terms

These four words are used throughout the docs. The code uses its own names for them, listed in the last column. See docs/GLOSSARY.md for every term and docs/architecture.md for how the parts fit together.

What it isn’t

• Not an auditor. An auditor scans a site and gives the developer a report. This toolkit changes an app for the person using it, based on their profile.
• Not an overlay. An overlay is added by a site owner and gives everyone the same widget. With this toolkit, each person’s own profile decides what changes, and site owners don’t install anything.
• Not assistive technology. It doesn’t replace a screen reader, a magnifier or anything else a person relies on.
• Not an app or a browser project. The core has no user interface. We started with the browser because it was the easiest way to get feedback from people, but web, mobile, XR, desktop and server apps are all supported.

Status

This is a research prototype (pre-alpha), and things may break or change without notice. The adaptations in the catalog are demos and haven’t been formally validated with the people they’re meant for. The presets are starting points based on published research (see docs/PROFILE-CARDS.md).

The toolkit comes from the AI for Accessibility Collective. The current research phase ends in November 2026, and plans after that aren’t decided yet. Open work is listed in ROADMAP.md.

Who it’s for

• People who want pages adapted to them: use the browser extensions in the extension repository, and tell us how they work for you.
• Developers building an app on the web, mobile, XR, desktop or a server: use any mix of the core, the skills and the catalog.
• Developers extending the toolkit: add skills, adapters, auditors and presets (see CONTRIBUTING.md).
• Researchers working on AI agents: use the design principles and the architecture, and share benchmarks, evaluation methods and findings.

Try it

No install, API key or browser needed. From a clone of the repository:

node toolkit/hosts/xr-demo/demo.js      # a profile made on the web is shared with an XR app
node toolkit/hosts/skill-demo/demo.js   # finds, builds, checks and saves a skill
node examples/cross-surface.mjs         # one profile turned into web and XR settings

docs/QUICKSTART.md walks through the code, and toolkit/API.md lists every method.

Building on it

There are four ways to use the toolkit:

1. Use the core directly in any JavaScript runtime. createToolkit({ ports }) returns { datastore, librarian }. Implement the ports for your platform, starting from the Node version in toolkit/platforms/node/. There’s also a Chrome version in toolkit/platforms/chrome/.
2. Call the hosted service from any language. Run server/ locally or on Cloud Run, and call the same Librarian methods over HTTP with a bearer token (see server/README.md).
3. Use the catalog. The skills, adapters, auditors and presets in tools/ and the registry in toolkit/registry/ work with or without the core.
4. Use one of the experimental parts: a Controller that drives apps by text or voice, an example onboarding service, or a command-line tool (CLI).

docs/COMPONENTS.md has more on each.

What your app needs to provide

• Ports: a KVStore is required, and Clock, Scheduler and Consent have defaults.
• An actuation port, if your app applies changes to a live page or screen.
• An LLM caller, if you want the AI features.
• An onboarding step that records a person’s needs in their profile.

Note: the default Consent does nothing, so if you don’t connect your own, the toolkit’s suggested profile changes are never shown to anyone.

Without an AI provider, everything except the AI features still works, and adapters return fewer results instead of failing. See docs/COMPONENTS.md for details, including the two places AI plugs in.

Contributing

CONTRIBUTING.md explains how to set up the repository and open a pull request. The main ways to contribute are:

• Share feedback on the toolkit or the extensions
• Write a skill (no code needed)
• Add an adapter
• Add an auditor
• Build an example app

If you’re building an app with the toolkit, it’s still your job to make the app accessible. Adapters fix problems after the fact, so it’s better to plan for accessibility from the start. The W3C guide to planning accessibility is a good place to begin.

Security and license

To report a vulnerability, see SECURITY.md. It also lists what to know before deploying, e.g., how API keys and profile ids are handled.

Only the Librarian writes to a person’s profile, the toolkit doesn’t keep notes on sensitive kinds of sites (finance, health and government by default), and other apps can read a profile only with a grant the person can revoke.

Licensed under Apache 2.0 (LICENSE).

Repository layout

toolkit/     Platform-agnostic core: Librarian, datastore, ability model, grants,
             skill engine, ports, sync, protocol, surfaces, the tools registry,
             reference platform bindings, and the runnable demo hosts
tools/       Developer catalog: adapters, auditors, validators, profiles, utils,
             and the ArtInsight knowledge module under insights/
controller/  Optional text/voice control surface: ControlPort, grammar, mounts,
             remote transport, web UI, demo (a sibling; the core never depends on it)
server/      Hosted HTTP service exposing the core to any language/runtime
cli/         Experimental Python CLI: try the catalog on a live page from a terminal
onboarding/  Example web service: /chat, /onboarding, /controller on one port
examples/    A runnable, dependency-free example
docs/        Quick start, glossary, components, architecture, design docs
scripts/     Repository checks (the packed-package fixture)

The paths that changed when the extensions moved to their own repository are listed at the top of docs/README.md. Who built this and how: docs/HOW-THIS-WAS-BUILT.md.

---

AI for Accessibility Collective