Most AI products are designed around one idea: make it fast. Cut the friction, get people to the answer sooner and let the interface fade away. For a lot of uses, that's the right call. For accessibility, it's often the wrong one.
What building for speed misses.
Building for speed assumes the hard part is finding information, and that the only thing between a person and a good outcome is the time from question to answer. In a lot of accessibility settings, that's wrong. The hard part comes after the answer arrives. People have to understand it and trust it before they'll feel able to act on it.
Think about someone with a cognitive disability using an AI health tool. A fast answer that's dense, full of probabilities or hedged with six caveats might be technically correct, but it doesn't help them. It can even do harm, by leaving them anxious with nowhere to go. The friction that matters is the mental effort of decoding an answer with no clear next step. A two-second wait barely registers next to that.
Or think about someone with low digital literacy using an AI-powered government service. For an experienced user, it might feel smooth and quick. For someone meeting this kind of interface for the first time, speed is how mistakes happen. The best thing the AI can do is slow down and check they've understood before moving on.
The form that takes longer on purpose.
One of the most instructive examples I've encountered is a digital form built for a community health organisation. The original form was built to be as frictionless as possible - minimal steps, quick completion, optimised for throughput.
The community it served were people navigating complex health needs in crisis. The form was fast, but completion rates were terrible. People abandoned midway. The data collected was incomplete. Staff had to follow up constantly.
When the organisation ran a co-design process with the community, what came back wasn't "make it faster." It was "give us more time. Let us know what's coming. Don't make us feel rushed." The redesigned form took longer to complete. It introduced more steps - not fewer. It added confirmation screens, plain-language explanations of why each question was being asked, and natural pauses between sections.
Completion rates went up significantly. Data quality improved. Staff follow-up calls dropped. The "slower" form was more effective because it met people where they were - rather than where a frictionless-interaction philosophy assumed they were.
What this means for AI design.
Format matters more than speed. An answer that turns up in two seconds but takes real effort to make sense of is less accessible than one that takes five seconds and arrives in a form the user can act on straight away.
Checking in is worth the time. For high-stakes decisions about health, safety, the law or money, slowing down is a feature. An AI that checks you've understood before it recommends anything is taking the decision as seriously as you are.
The user's confidence matters as much as the answer's accuracy. If an accurate answer leaves someone anxious, or they don't trust it, it hasn't done its job.
Co-design changes the requirements. Every example in this article comes back to the same thing. The teams who worked closest to the people who'd use the tool found requirements that a "remove all friction" mindset would never have turned up. I don't think you can build accessible AI any other way.
Optimise for something else.
What I'm arguing for is optimising for clarity and the user's confidence ahead of speed. When speed and clarity pull against each other, clarity should win.
If your organisation is building AI tools for people with complex or high-stakes needs, be clear about what you're optimising for. A fast tool isn't automatically a good one, and a frictionless one isn't automatically accessible. Sometimes the most useful thing an AI can do is ask again.