Mission

Access should not disappear at the screen.

BaseLayer Digital exists to push back against rigid digital systems that leave people less independent than the services they replaced.

This is about lived use, not paper comfort

Digital systems now sit between people and ordinary tasks: getting food, checking in for an appointment, paying for something, finding the right desk, reading an account page, or using a public service. When those systems are rigid, the person loses access at the exact point where the service is meant to become easier.

BaseLayer Digital was formed to address that directly — by building digital systems that can adapt in front of the user instead of forcing the user to adapt to the system.

What we are arguing against

Self-service screens that replace a member of staff but not the accommodation that staff provided
Websites that technically pass but still force everyone through one visual model
Interfaces that cannot adjust when a person is fatigued, overwhelmed, or simply unable to read the default presentation
Digital handovers that remove human help without providing another workable route

Real-world failure points

Ordinary places, real barriers

The problem shows up in deli screens, hospital terminals, and self-service kiosks — places people should be able to use independently without asking for help.

The deli ordering screen

A supermarket can move from a person behind a counter to a self-service display and call it progress. If that screen cannot adapt for low vision, reading difficulty, glare, or fatigue, the customer has not gained convenience — they have lost the independence they had before.

The hospital sign-in terminal

If a patient used to arrive, speak to a person, and move through the building independently, but now needs another person to operate the sign-in system and find the department, the digital change has made the service worse.

The public self-service handover

The same pattern appears in kiosks, account portals, ticket machines, and check-in points. The issue is not that they are digital. The issue is that they are fixed and built around the assumption that the user will adapt instead.

The legal and standards baseline

Standards set a floor

The current legal and technical framework matters. But it does not remove the need for practical accommodation in everyday use — and too many teams stop at the floor and call it done.

Equality Act 2010

In the UK, service providers still have a duty to make reasonable adjustments. That matters because digital systems are now part of the service, not separate from it.

Public Sector Accessibility Regulations 2018

Public bodies have named accessibility duties for websites and mobile applications. That sets a baseline for public digital services, especially where a person has no realistic alternative route.

WCAG 2.2

WCAG remains the technical benchmark most teams work to. It is useful and necessary, but it is still not the same thing as building a system that can respond to the person in front of it.

What works in reality

Four layers that hold together

Structure, live user controls, service continuity, and longer-term support tools work in sequence. Miss one and the system still fails the people who depend on it most.

Layer 1

Solid baseline build

Semantic HTML, keyboard support, sensible contrast, readable defaults, and clean structure still matter.

Layer 2

Live user controls

Users need direct control over text, contrast, spacing, motion, and how the page looks and feels to them.

Layer 3

Service continuity

If the digital route still fails, the person needs a visible and workable path to human help without starting from zero.

Layer 4

Longer-term support tools

That is where apps, navigation tools, and support platforms come in. The website is only the starting point.

Where this goes next

Growth in phases

The company builds in stages so the work stays grounded in each domain before moving to the next. Website work, then public systems, then apps, then wider partnerships.

Web phase

Establish the company through website work, engine integration, blueprint adoption, and live examples that show the model working in a real service layer.

Public systems phase

Move the same thinking into kiosks, sign-in terminals, map systems, and service touchpoints where people need adaptation inside the system itself.

App phase

Build device tools, navigation products, support platforms, and connected services that can stand alone or work together — outdoor and indoor navigation, accessible venue finders, and practical daily support tools.

Grow partnership reach

Work with councils, charities, healthcare settings, venues, and public service providers so the model moves into the systems people depend on every day.

How the company grows

One purpose, several routes

Website work, public systems, apps, and support infrastructure all follow the same core model. The direction changes as the company grows; the underlying thinking stays the same.

Website builds

Custom website builds for businesses — four package tiers from £750, with the accessibility engine integrated as standard on every custom build. Service plans keep the site moving after launch.

Public systems

Integration and adaptation for kiosks, sign-in points, directories, and other public-facing systems that currently fail people at the point of use.

Apps and navigation tools

Outdoor and indoor navigation, accessible venue discovery, practical support finders, and connected tools that carry the same adaptive logic into daily life.

Support infrastructure

A one-stop public layer for charities, accessible venues, facilities, and everyday support routes — connected to the same data backbone that feeds the apps and tools.

Why back this work

The business case is straightforward.

Better demonstrations, broader implementation, faster product development, richer user testing, and more meaningful collaboration with the organisations already working in disability, care, public services, and community support.

Our packages See the engine