Most conversations about AI accessibility get stuck in one of two places. Either it becomes a compliance discussion — screen readers, contrast ratios, WCAG conformance levels — or it becomes a marketing word that means "our product has a friendly onboarding flow." Both miss what matters to a company actually trying to use this technology.
The working definition we use is narrower and more useful: accessibility is the distance between a person's intent and the software acting on it. Everything else follows from measuring that distance honestly.
The distance problem
Consider a dispatcher at a service company who wants to know which jobs are at risk of running past their window today. That intent is simple, specific, and expressible in one sentence. The path to satisfying it usually is not: open the scheduling system, filter by date, cross-reference against technician locations, check which jobs have parts on backorder, compare against the customer's promised window, and then form a judgment.
The expertise required for the judgment is real. The six steps in front of it are not expertise — they are friction. An accessible AI system collapses those six steps and hands the dispatcher the judgment call. An inaccessible one asks the dispatcher to learn a new query syntax first.
Three things that make software inaccessible
Vocabulary tax. If a user has to learn your terminology before they can express what they want, you have added distance. "Prompt engineering" is a vocabulary tax. So is any interface that requires knowing the difference between a workflow, an automation and a trigger before anything useful happens.
Context transfer. Every time a person has to explain something the system could have known, distance increases. If the tool does not know who the customer is, what was promised, or what happened last week, the user becomes a data-entry clerk for their own assistant.
Verification burden. If the output cannot be trusted without being fully re-derived by hand, nothing was saved. Accessibility requires that a person be able to check the work quickly — which means showing the reasoning and the source, not just the answer.
Why this is the same work as disability accessibility
This is the part people find surprising. Reducing the distance between intent and action is not a different project from making software usable for people with disabilities — it is the same project, measured the same way.
A person using voice input, a person with limited fine motor control, a person with a cognitive disability, and a dispatcher with forty seconds between phone calls all have the same requirement: fewer steps, less precision demanded, more inference by the system, and a clear way to confirm what happened. Software built to the second requirement satisfies the first. Software built only for compliance usually satisfies neither well.
This is why accessibility certification sits on our roadmap as an engineering milestone rather than a legal one. If the product is genuinely accessible in the operational sense, formal conformance becomes documentation work rather than a redesign.
How to measure it in your own business
Pick one recurring task. Time it end to end, including the parts nobody counts — finding the right screen, waiting for a page, re-typing something the system already knew. Then count the steps that require judgment versus the steps that require only patience.
The ratio is your accessibility number. Most business software lands somewhere around one judgment step for every eight to twelve patience steps. That ratio, not a feature list, is what determines whether adding AI to your operation will actually change anything.
When we scope a pilot, this is the first measurement we take and the last one we report against. It is unglamorous, and it is the only number that consistently predicts whether people keep using the thing six months later.