Accessibility Is a Diagnostic

 It is easy to assume the subject belongs to a specialist team and has little to do with the rest of the organisation.

In reality, accessibility is not a specialist concern sitting off to one side. It is a diagnostic signal that reveals how effectively value moves through systems, for everyone who depends on them.

Journeys Don’t Fail All at Once, They Fail at Specific Moments

Consider three people trying to get something done today.

They are not edge cases or rare scenarios. They are ordinary people, and their experiences are the predictable outcome of everyday design, procurement, and policy decisions.

Across most digital journeys, from awareness through to completion and support, breakdowns tend to cluster in the same places: when people try to understand information, complete a form, provide evidence, or ask for help. These are the moments where systems either hold or fail.

Meet Margaret, Jayden, and Aisha.

Margaret, 67, Low Vision, Community Member

Margaret uses screen zoom and high-contrast settings on her device. She rarely contacts support unless a problem blocks something critical. Most of the time, she simply leaves.

An email about an important service update arrives with low contrast and poor scaling. The information is difficult to read before she even reaches the website. When she attempts to complete an online form, the page breaks under zoom and times out before she can finish. She loses her progress and starts again. Eventually, she gives up.

None of this appears in reporting as an accessibility issue.

It appears as drop-off.

The cost is real: reduced uptake, avoidable support demand, and trust that quietly erodes over time.

Margaret did not fail the service. The service failed Margaret, repeatedly and predictably, without anyone noticing.

Jayden, 29, ADHD and RSI, Employee

Jayden works in a large organisation and spends most of his day moving between internal systems.

The tools he relies on are heavily mouse-dependent, even though using a mouse causes him pain. Keyboard shortcuts do not exist. Focus order changes unexpectedly. Multiple competing windows demand attention at once, with no clear hierarchy or workflow.

Jayden is not underperforming.

The system is.

When internal tools are inaccessible, productivity rarely collapses overnight. Instead, it leaks away through slower task completion, higher cognitive load, increased errors, and eventually burnout.

None of this appears in operational dashboards as an accessibility problem. It is more likely to be interpreted as a performance issue, a training issue, or a workforce issue.

In reality, it is operational drag created by inaccessible systems.

Aisha, 38, Blind, Screen Reader User

Aisha depends on digital services to participate independently in everyday life.

Important documents arrive as scanned PDFs with no accessible text layer. Self-service portals contain unlabeled buttons. Verification codes are delivered as images. Support teams respond by sending screenshots she cannot read.

Tasks that should take minutes become impossible without assistance.

This is not a minor inconvenience.

It is a loss of independence.

There is also a less obvious consequence. When independent access becomes impossible, people create workarounds. They ask family members for help, share personal information, or rely on others to complete tasks they cannot complete alone. In many cases, this extends to sharing passwords or login credentials so someone else can access systems on their behalf.

This creates a direct conflict with security policy. People are explicitly told never to share passwords, yet inaccessible systems effectively force blind users and others who rely on assistive technology to do exactly that in order to function. The security model assumes credentials are never shared. Inaccessible design makes that impossible in practice.

The risk is not created by the user.

It is created by systems that were never designed with accessibility in mind.

Different People, Same Failure Pattern

Margaret, Jayden, and Aisha occupy very different contexts, but the pattern is remarkably consistent.

A surface issue appears to be an individual problem. The root cause traces back to a design, procurement, or policy decision. The business impact surfaces somewhere else entirely.

Margaret

Surface Issue: Service abandonment

Root Cause: Design and development decisions

Business Impact: Reduced uptake and increased support demand

Jayden

Surface Issue: Staff burnout

Root Cause: Internal tooling and process design

Business Impact: Operational drag

Aisha

Surface Issue: Loss of independence

Root Cause: Product and service design

Business Impact: Legal, reputational, and customer experience risk

The Perspectives

Margaret’s experience may be reported as low engagement.

Jayden’s experience may appear as a performance issue.

Aisha’s barriers may emerge as customer service complaints.

Accessibility issues rarely announce themselves as accessibility issues.

They show up as extra calls, slower throughput, staff exhaustion, rework, churn, and risk.

By the time they appear on a dashboard, they are often being measured under an entirely different name.

If It Touches a Journey, It Owns Accessibility

The responsibility for accessibility does not sit in a single team.

It sits with anyone whose decisions shape how a system is designed, funded, procured, or operated.

If you approve funding, you influence what gets built.

If you design a process or policy, you define what people must navigate.

If you own performance or risk, you inherit the consequences when systems do not work for the people using them.

Accessibility is not a compliance function. It is an organisational property created through thousands of everyday decisions.

The most useful question is not whether accessibility has been “covered”.

It is whether the decisions being made make it easier or harder for people to succeed.

A Different Question to Ask

Many organisations begin with a compliance question: are we compliant?

Compliance matters, but it is fundamentally about risk management. It sets a minimum standard and focuses on avoiding harm.

A more valuable question is whether people can actually complete what they came to do.

That shifts the focus from compliance to effectiveness.

It asks whether systems work for the full range of people who rely on them, not just those who fit an assumed average.

Compliance helps organisations avoid failure.

Accessibility helps organisations create success.

The Uncomfortable, Useful Question

Imagine a live dashboard showing every point where people abandon a journey and every place where staff compensate for broken systems. It would reveal workarounds, duplicated effort, unnecessary complexity, and the invisible labour required to make inaccessible systems function.

Most organisations already have that dashboard.

It is just not labelled “accessibility”.

It is labelled drop-off rate, average handling time, error rate, rework, attrition, complaints, and support demand.

Accessibility is not primarily a moral issue or a compliance obligation.

It is a diagnostic capability that shows where systems are working, where they are failing, and who is left carrying the cost.

The real question is not whether organisations can afford to address it.

It is whether they can afford not to see what it is already telling them.