Engine

The accessibility engine works because it changes the interface without changing the structure underneath it.

Principle

The default design stays in place. The engine changes the presentation through tokens and shared rules.

Input

Default branded build

Designers and developers create the intended interface first, with semantic HTML and a clean token map.

Contract

Token-driven styling

Components reference variables for colour, type, spacing, surfaces, and layout instead of hard-coding them locally.

Runtime

State

JavaScript holds the user state, applies the matching data attributes, and updates CSS custom properties live.

Result

Adaptive interface

The same page changes around the user without DOM rewrites, page reloads, or layout collapse.

When components own their own colours, spacing, and typography, accessibility changes become expensive and fragile.

.panel {
  background: #ffffff;
  color: #223667;
  padding: 24px;
  border-radius: 12px;
}

.panel h2 {
  font-family: "Brand Sans", sans-serif;
}

Teams build against tokens and semantic structure so the engine can reshape the interface safely at runtime.

.panel {
  background: var(--colour-surface);
  color: var(--colour-text);
  padding: var(--space-lg);
  border-radius: var(--radius-md);
}

.panel h2 {
  font-family: var(--font-family-active);
}

Directory contract

frontend/
  styles/
    base/
    layout/
    components/
    themes/
  scripts/
  pages/
  assets/

Implementation order

Define the default brand tokens first
Keep layout, theme, and component rules separate
Mount the engine once at the root of the interface
Expose the settings surface without disturbing the page structure
Persist preferences locally now, with optional account sync later

Where it can be used

Static sites and marketing platforms
React, Vue, and server-rendered systems
Internal service interfaces and admin products
Future kiosk and interaction-platform front ends

State and storage

The model is simple on purpose: one state object, one token bridge, and one place to store preferences.

{
  appearance: "default",
  contrast: "contrast-light",
  font: "legible",
  filter: "warm",
  fontScale: 120,
  lineSpacing: 130,
  paragraphSpacing: 140,
  letterSpacing: 4,
  wordSpacing: 6,
  readingWidth: "focused",
  reducedMotion: true,
  reducedTransparency: true,
  focusBoost: true,
  underlineLinks: true
}

default build
  -> token contract
  -> runtime engine
  -> local preference store
  -> optional signed-in profile sync
  -> interface re-renders through CSS variables

The current implementation persists locally. Later, the same model can support signed-in profile sync without changing the front-end contract.

Why this matters to developers

Teams should not have to choose between a branded design and a genuinely adaptive interface.

The engine asks for discipline up front: tokens, structure, and clean component boundaries. In return, the system stays easier to maintain, easier to explain, and easier to adapt in use.

See the services page See the examples

How it can be used

The same model can be used in a custom build, fitted into an existing product, or supplied as a reusable starting point.

Custom build

We build the site, define the token map, and include the engine as part of the finished system.

Retrofit path

We audit an existing interface, replace brittle hard-coded rules, and install the engine in phases.

Reusable starting point

The engine can be supplied with templates, starter systems, and implementation guidance for teams that want a strong starting point.