Superintelligent Customer Agents Must Be Accessible: A Starting Checklist

An accessible AI customer service agent is one that customers can use with a screen reader, a keyboard, enlarged text or plain language, and that always offers a clear way to reach a person. Getting there starts with the chat surface itself: labeled controls, announced replies, readable text and a handoff that works on the first attempt. This article is a starting checklist for business owners and operations leaders who need to decide what to build first.

Key takeaways

• Accessibility covers the whole conversation, from the chat window to the handoff, not only the visual design.
• Replies should give the answer or next step first, in plain sentences, with no meaning carried only by color, icons or images.
• The route to a human must be visible, reachable and tested before the agent goes live.
• Permissions and escalation triggers belong in writing, so the agent never has to guess whether it may act.
• Test with assistive technology and real customer scripts, and repeat the test after every change.

What makes a customer agent accessible in practice

Accessibility for a chat agent depends less on the model than on the surface it runs in. A screen reader announces what the page structure exposes: the label of an input, the role of a button, the order of messages. If a new reply appears without being announced, a customer using assistive technology may never know the agent answered. Keyboard users need to reach the message box, send control and handoff button without a mouse, and customers who enlarge text need the layout to keep working.

Before any prompt work, check the surface against these points:

• Every input, button and link has a text label that makes sense out of context.
• New agent messages are announced to assistive technology, and the latest message is not hidden below a scroll.
• Every control can be reached and operated from the keyboard, in a logical order.
• Status, error and urgency are shown with text, not only with color.
• The chat stays readable at large zoom and respects the browser's text size settings.
• No essential information lives only inside an image, a scanned PDF or an embedded third-party widget.

Ask your web or product team to test these points, not only the vendor. Written demos seldom show what a screen reader actually does with the page.

How should an agent write replies that work for everyone?

Plain language helps a screen reader user, a customer reading in a second language, a person who is tired or anxious, and someone reading on a small phone. The common thread is that the customer should know what happened and what to do next without rereading. Google's guidance on helpful, people-first content asks writers to satisfy the reader's need directly, and the same discipline fits agent replies.

Write these rules into the agent's instructions:

• Put the answer or next step in the first sentence.
• Ask for one thing per message.
• Spell out abbreviations the first time they appear.
• Describe controls by their label, not by position or shape. Write 'Select Confirm address' rather than 'Tap the green button on the right'.
• Do not use emoji, symbols or ASCII art as bullets, because some screen readers read them aloud as words.
• Read back times, addresses and reference numbers in full so the customer can check them.

Consistency matters as much as brevity. If one step says 'Select Confirm' and the next says 'Tap Continue', a customer has to relearn the flow at every message. Keep the wording of controls stable across the whole conversation so the customer learns where to look.

Where should the route to a human appear, and when should it trigger?

A handoff is part of accessibility. A customer who cannot finish a task through the agent needs a path that is labeled, visible and reachable from every step, and that carries enough context that the customer does not have to repeat the story. Many chat designs bury the human option under a menu, which makes the exit hardest for the people who most need it.

Illustrative scenario: a small appliance repair company uses an agent to reschedule visits. A customer using a screen reader asks twice to move a visit to the afternoon, and the booking system rejects both requests. The agent recognizes the repeated failure, says plainly that it cannot change this booking, and offers to pass the conversation to the office with a summary. The office sees the address, the requested time and both attempts, so the customer does not start over.

Set handoff triggers in writing. Useful triggers include:

• The customer asks for a person, in any wording or language.
• The same step fails twice.
• The request involves a refund, a complaint, a contract term or a legal question.
• The customer mentions a safety issue, distress or an urgent problem at a property.
• The agent cannot find the record it needs to answer accurately.

Test the handoff from the customer side. Confirm that the human option is exposed to assistive technology, that focus moves to it predictably, and that the person who receives the case sees the summary inside the working process you already run. For the approval logic behind these stops, see Where should your AI agent stop and ask?.

What should the agent be allowed to do, and what should it say when it cannot?

An accessible agent is also honest about its limits. One of the worst experiences for any customer is a confident reply that is wrong, followed by a long chat that cannot be corrected. Keep permissions narrow and make the agent say so when a request falls outside them.

Permissions should be enforced by the systems the agent calls, not by a sentence in the prompt. OWASP's authorization guidance makes the general point that access decisions belong in code and policy checked on every request, not in the interface or in instructions given to a model. A prompt can tell the agent to refuse a refund, but only the refund service can stop it from issuing one.

Build the permission set in four steps:

• List the actions a customer may ask for, and mark each as read only, reversible, or requiring a person.
• Map each action to the system and account it uses, with a named owner.
• Write the fallback wording the agent uses when it is blocked, and check that the wording names the next step.
• Review the list when a new tool or policy appears, not only when something breaks.

Staff also need a way to pause or override the agent without waiting for a vendor. For that side of the design, see Human Override for AI Agents: A Staff Path You Can Test.

How do you test accessibility before customers find the gaps?

Agent behavior changes when prompts, tools or pages change, so a single review is not enough. Anthropic's engineering guidance on evaluating agents describes turning realistic tasks into repeatable checks with a clear success condition. Apply the same thinking to accessibility: each script should describe a customer goal, the way the customer reaches it, and the outcome that counts as success or as a safe stop.

A starting plan:

• Collect a small set of real conversations where customers got stuck, asked for a person or left the chat.
• Turn each one into a script that states the goal, the input method or assistive technology, and the expected end state.
• Run each script with a screen reader, with keyboard only, and at large text size.
• Record whether the customer reached the goal, reached a person, or stopped at a clear message.
• Assign every failure to an owner, with a fix the team has agreed to.
• Rerun the whole set after every change to prompts, tools, pages or policies.

Be Human's managed approach handles this inside the first engagement rather than as an afterthought. The engagement names the customer-facing role, writes its approval boundaries and handoff triggers as explicit permissions, and defines a test set that includes assistive technology scenarios. Managed operations then keep that test set running after changes, review permissions on a schedule, and handle incidents when a customer reports being stuck.

A starting plan for the next month

Start with one customer task that is frequent, low risk and easy to verify, such as checking an appointment, answering a question from a published policy or collecting details for a callback. Put that single flow through the checklists above before you widen it. The NIST AI Risk Management Framework offers a useful vocabulary for naming owners, documenting risks and deciding who reviews a change, and it suits a company of any size.

Keep a short record of what the agent does, who can see it and how long it is kept, and collect only the personal data needed to review failures. Tell customers when they are talking to an AI agent, using wording that screen readers can announce clearly. Should You Tell Customers They Are Talking to an AI Agent? walks through the choices.

If you want to find the first customer task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Do we need an accessibility specialist to launch a customer agent? You do not need a specialist for every decision, but someone who uses assistive technology should test the chat before launch. A web or product team can check labels, focus order and announcements with a screen reader and the keyboard. Ask any vendor to show you test results for these checks rather than a demo video.

Is an accessible agent automatically compliant with accessibility law? No. Accessibility obligations vary by market and by the kind of service you provide, and passing a checklist does not settle legal questions. Ask your counsel which standards apply to your customers, and keep a written record of the checks you ran and the fixes you made.

Should the agent tell customers it is an AI? In most cases it is wise to say so clearly at the start of the conversation and again when a person takes over, because customers need to know who they are talking to. The disclosure should be plain text that a screen reader can read, not an icon or a graphic.

How do we start if we already have a chatbot on our website? Begin with the same surface checklist and the handoff test, because those problems are common in older chat widgets too. Pull a sample of recent conversations where customers left or asked for a person, and use them as your first test scripts. Only after that should you change prompts or add new tools.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.