Input
Default branded build
Designers and developers create the intended interface first, with semantic HTML and a clean token map.
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.
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.
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.
Before
Hard-coded interface decisions
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;
}After
Token-driven implementation
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 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.
State shape
What the engine stores
{
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"
}Storage route
How preferences move
default build
-> token contract
-> runtime engine
-> local preference store
-> optional signed-in profile sync
-> interface re-renders through CSS variablesThe current implementation persists locally. Later, the same model can support signed-in profile sync without changing the front-end contract.
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.
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.
What fails
A fixed screen with no practical adjustment path
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.
What should exist
Fast access to adaptive controls inside the system itself
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.