Most AI products are built and tested by a narrow group: fast typists, native speakers, people with good eyesight and new hardware. Then they are released to everybody else. If you are building or buying accessible AI tools, the fix is not a separate “special” version. It is a handful of habits applied while you build. The steps below are practical and ordered, so you can work through them on a real project this month.

Step 1: Write down who your imagined user is

Start by naming the person you are quietly designing for. Most teams, if they are honest, picture someone like themselves: young, fluent, on a laptop. Write that description in one paragraph. Then list four people who do not match it: an older customer, a user with a motor impairment who cannot use a mouse, someone writing in their third language, and a person on a cheap phone with a patchy connection.

This is not a diversity exercise for its own sake. It exposes assumptions that will otherwise be baked into prompts, interfaces and error messages.

Step 2: Make the output readable before making it clever

Model output is often long, dense and full of jargon. Set a house style for responses: short sentences, one idea per paragraph, the answer first and the reasoning after. Where the model must use a technical term, have it add a short plain explanation the first time. Test this by pasting a response into a readability check or simply reading it aloud. If you run out of breath, it is too long.

Plain output helps non-native speakers most, but it also helps the expert who is skimming between meetings. If you want a model of this tone, our beginner explainer on how machines recognise what is in a photo keeps jargon to a minimum and defines each term as it appears.

Step 3: Offer more than one way in

A text box is a single door. Add others where it makes sense: voice input, pre-written suggestion buttons for common questions, and the option to upload a file instead of typing a long description. Make sure each route ends in the same place, so no one gets a lesser result for choosing a different path.

Equally, offer more than one way out. A response should be copyable as text, readable by a screen reader and, where relevant, available as a short summary and a longer version. People should choose the format that fits their situation.

Step 4: Label everything in ordinary words

Buttons named “Run inference” or “Regenerate with temperature” mean nothing to most people. Use verbs people already use: “Ask”, “Try again”, “Make it shorter”. Every control needs a text label that a screen reader can announce, and every image the system produces needs a short description of what it shows.

When the system cannot do something, say so in a sentence a stranger could follow: what happened, why it matters and what to do next. “Something went wrong” is not an answer. “We could not read that file because it is empty. Please choose another one” is.

Step 5: Check the basics of the interface

1. Zoom the page to 200 percent and confirm nothing is cut off.
2. Tab through the whole screen with the keyboard and confirm every control can be reached and used.
3. Check that text has enough contrast against its background, including in dark mode.
4. Make sure moving or auto-updating content can be paused.
5. Load the page on a throttled connection and see what appears first.

None of this requires a specialist. A single afternoon with these five checks will uncover problems that months of feature testing never touch.

Step 6: Be honest about uncertainty

People with less time or less background are the ones most likely to take a confident-sounding answer at face value. Show when the system is unsure, and avoid presenting guesses as facts. A short line such as “This is a suggestion; please confirm important details” costs nothing and protects people who cannot easily verify for themselves. It also treats every reader as capable, which is a form of respect.

The same applies to business uses. Our piece on how automated analysis supports everyday business choices makes the point that tools inform decisions rather than replace judgement, and that applies doubly when users differ widely in experience.

Step 7: Bring real people into testing

Automated checks catch contrast problems and missing labels, but they cannot tell you whether a flow is confusing. Invite a few people who do not match your imagined user to try the tool on real tasks. Watch, do not coach, and note where they hesitate. Pay them for their time if the session is formal. Even three sessions will change your priorities.

Step 8: Publish what you did and what is left

An accessibility note on your site tells people what to expect and how to reach you if something fails. It is also a discipline: writing it forces you to check your claims. cmsGalaxy, a website development and SEO group that keeps an accessibility statement for its own pages, shows that this does not have to be elaborate. State what you tested, name known gaps, and promise only what you will actually do.

Step 9: Keep it in the routine

Add the five interface checks to your release checklist. Add one person from outside the imagined user group to each round of testing. Review error messages every quarter, because they drift into jargon faster than anything else. Small, repeated attention beats a big one-off audit.

When you design for the person at the edge, you tend to remove friction for everyone in the middle. The shorter answers, clearer labels and extra routes that help one user save time for hundreds. That is the practical case for accessible AI tools: they are simply better tools, and the work to build them is steps you can start this week.