Engine

The interface changes. The structure stays intact.

The engine updates presentation through tokens and shared rules so people can change text, contrast, spacing, motion, and comfort — without breaking the product underneath or requiring a page reload.

Audit reality

Some accessibility tools help. Some make things worse.

We do not build for a badge. We build for the person actually using the page. Good tools help expose real experience gaps. Bad tools push developers into fake fixes, noisy ARIA, and hidden nonsense that ends up hurting blind and low-vision users in the real world.

Lighthouse
- Audits what is actually rendered instead of bullying teams into naming hidden junk.
- Works as a strong baseline for route-level accessibility, structure, and performance.
- Closer to what a real visitor sees or hears than checkbox-first scanners.
axe-core / axe DevTools
- Catches real code and semantic failures without forcing as much garbage into hidden UI.
- Useful when paired with rendered-state testing and developer judgment.
- Better at exposing actual structural problems than vanity-score chasing.
NVDA, VoiceOver, TalkBack testing
- Real assistive technology reveals friction that automated tools miss entirely.
- Shows whether the spoken experience is human, usable, and calm instead of chaotic.
- Human testing is where fake accessibility gets exposed fast.

WAVE
- Too often pushes developers toward labelling hidden or inactive elements just to clear warnings.
- That creates noisier screen-reader output and actively worse real-world accessibility.
- It encourages score worship over interaction truth, which is exactly the wrong priority.
Overlay widgets sold as a fix
- They market a shortcut instead of demanding proper structure, semantics, and runtime discipline.
- Most of them sit on top of the problem instead of repairing the product underneath.
- They make organisations feel compliant while users still hit the same barriers.
Tick-box accessibility culture
- Passing an audit is not the same thing as making a service usable.
- Bad process makes teams optimise for the scanner instead of the human being.
- If a fix pleases the tool but confuses a blind user, it is not a fix.

We still use audits, but we use them as signals, not truth. If a tool demands a change that would make voice output noisier, branch logic less clear, or hidden controls louder than active ones, the tool is wrong. Real accessibility is measured in use, not in whether a scanner can be appeased.

Principle

Default design. Adaptive delivery.

The branded interface stays intact. The engine reshapes presentation at runtime through tokens and shared rules — no DOM rewrites, no page reloads, no layout collapse.

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/
  assets/
  contact/
  engine/
  mission/
  packages/
  pricing/
  scripts/
  styles/
    base/
    components/
    layout/
    themes/
  understanding/

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 interface 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

State, storage, and tokens

One state object holds user preferences. One token bridge maps them live to the interface. One storage route keeps them across sessions — and optionally syncs them to a signed-in profile later.

{
  appearance: "default",
  palette: "red",
  contrast: "plus-2",
  depth: "reduced",
  font: "legible",
  tint: "warm",
  filterStrength: "medium",
  readingMode: "focused",
  readingGuide: "3",
  talkbackMode: "focus",
  speechRate: 100,
  fontScale: 120,
  lineSpacing: 130,
  paragraphSpacing: 140,
  letterSpacing: 4,
  wordSpacing: 6,
  boldText: "level-2",
  motion: "reduced",
  transparency: "reduced",
  focusBoost: "medium",
  underlineLinks: "medium",
  highlightControls: "high",
  dimMedia: "default"
}

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

Brand design and genuine adaptability. You should have both.

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.

Package detail Engine licensing

The reasoning behind it

More than compliance

A lot of accessibility work still stops at technical compliance. Labels exist, contrast passes on paper, and the site is declared finished even when the spoken output feels robotic, the controls feel rigid, and the person using the system still has to do most of the adapting.

The engine is built around a different idea. The system should carry more of the burden. If someone needs larger text, calmer motion, stronger contrast, clearer spacing, more helpful narration, or a cleaner reading path, the interface should respond without making them fight for it.

Why that matters now and later

Many older people today still avoid digital services unless they are forced into them. That does not mean the issue is small. It means a lot of services have already taught them that the digital route is tiring, confusing, or unreliable.

Over time that pressure will grow. Future generations of older adults will expect to manage everyday life through websites, apps, bookings, account tools, and public-facing systems. As sight, stamina, contrast sensitivity, and reading comfort change with age, those systems will need to adapt far better than they do now.

How to get the engine on your site

Three ways to start

The engine is already part of every custom build we do. For businesses starting from scratch, it comes included. For sites that already exist, we can scope integration separately.

Get a build from us

The engine is included as standard in every Static, Premium, and Pro build. You get the site and the engine as one finished system — no separate configuration, no extra cost.

Add it to an existing site

If a site already exists and the engine needs to be integrated into it, we scope and quote this separately. The existing design stays intact — the engine works above it without a rebuild.

Developer self-implementation

The Blueprint starter skeleton is available for teams that want to implement the engine themselves. It includes the token structure, core wiring, and engine setup — the brand and content stay entirely with the team.

See our build packages View pricing

Download the blueprint

Blueprint-0.04-Alpha-2 is available now for early adoption.

This is the base-layer skeleton we are currently giving away for personal research, verification, and analysis.

It includes the engine, token structure, and shared wiring, but it does not tell a team how their site must look. Their site. Our engine.

Download blueprint

Preview of the Blueprint-0.04-Alpha-2 download card.

Where it belongs

Any screen, any setting

Adaptive access should be present anywhere a person is expected to complete a task independently — websites, kiosks, terminals, maps, sign-in points, and partner-facing tools included.

Public service websites

Government, councils, utilities, banking, and service websites where the person still needs a clear route through the page.

Hospital and clinic terminals

Check-in and wayfinding systems that should help a person arrive, sign in, and move through the building independently.

Retail and self-checkout

Ordering screens, self-checkout tills, and POS systems where glare, contrast, and text size can decide whether the task is possible at all.

Map and information systems

Transport maps, digital directories, visitor information boards, and route systems where clarity matters at speed.

Sign-in and access points

Building terminals, queue systems, and appointment screens that should not block a person at the first point of contact.

For organisations and partners

Disability organisations, age-focused charities, carers, and community support groups where digital barriers are already being reported every day.

Current platform limits

Where control gets harder

Some environments still resist consistent adaptive control. Older kiosk platforms, third-party CMS constraints, and native app limitations can reduce how deeply the engine can reach.

The person arrives at a terminal, kiosk, or map system and is expected to work with whatever the default view happens to be. If they cannot, the task stops there.

The person opens a clear accessibility menu, changes what they need, and carries on with the task. The system adapts around them instead of sending them away to find help.

What current testing shows

Desktop browsers and Android currently allow far more of the in-browser talkback model to behave as intended. On iOS, browser-level speech behaviour and interaction control are more tightly restricted, so the full talkback layer is not yet as reliable there.

Why that matters

This is not just a single-browser annoyance. It shows how accessibility is still being shaped by fractured platform rules, vendor limits, and uneven support for user-controlled adaptation.

The wider point

If accessibility depends too heavily on one operating system vendor allowing it, the result is still fragile. A serious accessibility layer should not be blocked by platform gatekeeping when the user needs help right now.

Work with us The wider mission