Accessibility and Assistive Technology

Measures built around an assumed way of working misrepresent anybody working differently. In this field the misreading has specific and predictable shapes.

The friction described in “Accessibility and Assistive Technology” becomes easier to prioritise when the team can separate active work from waiting and repeated handling. An organisation evaluating the original source can record time against the affected workflow and compare the effort before and after a change, while ticket and device records remain the evidence of the technical event itself.

For an independent benchmark, compare this approach with W3C Web Accessibility Initiative; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

How the measures go wrong

Users of reading software take longer on tasks by the nature of the interaction, which registers as poor performance rather than as a different method.

Voice input produces input patterns that idle detection misreads.

Magnification and high-contrast modes add rendering load, worsening device metrics.

Assistive software is extra installed software, which counts against application sprawl measures.

And task duration measures penalise anybody for whom the interface is harder.

Why it compounds

A low score attributed to the person rather than the setup.

Equipment prioritisation driven by scores sends the best hardware to people already having an easy time.

And accessibility software flagged as unused or unapproved by the same analysis that cleans up application sprawl.

Each of these has happened, and each is foreseeable.

What to do about it

Exclude assistive technology from software rationalisation, explicitly and in writing.

Do not use composite scores for anybody using it, or flag those cohorts so that the score is not read as performance.

And ask, rather than inferring, because the measures were not built for this and will not become accurate by tuning.

The accessibility of the tooling itself

Self-service portals, chatbots and knowledge bases are frequently the least accessible things IT publishes.

Which means the deflection strategy deflects everybody except the people who find the alternative hardest.

Test them with assistive technology before deployment, not after a complaint.

The experience that nobody measures

Waiting for assistive software to be approved, procured and installed, which in many organisations takes weeks.

Adaptations that break at every upgrade.

Having to explain the requirement again to each new support agent.

These are the real experience problems for this group and no agent reports any of them.

Involving people

A small group of colleagues using assistive technology, consulted when the programme is designed and when tooling changes.

They will identify problems nobody else sees, including in the measurement itself.

And they are the people most affected by decisions the data drives, which is reason enough.

The general principle

Every measurement encodes assumptions about its subject.

Here the assumption is a sighted person using a keyboard and mouse at typical speed.

Knowing that is what lets you notice when a decision is about to be made about the people who do not fit it.

What to check

Is assistive software excluded from rationalisation, in writing?

Are your self-service tools tested with reading software?

How long does it take to get an adaptation approved and installed?

And has anybody using assistive technology been consulted about the programme?

The point

Every measurement encodes assumptions about its subject.

Here it assumes a sighted person using keyboard and mouse at typical speed.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.