Chatbot Accessibility for Less Tech-Savvy Customers: A Practical Guide

Chatbot Accessibility for Less Tech-Savvy Customers: A Practical Guide

To make a support chatbot accessible, use plain language, short messages with one question at a time, voice input where the channel allows it, and a way to reach a human at any moment. Chatbot accessibility for less tech-savvy customers means that older adults, people with disabilities and people with little digital experience can get what they need without asking someone else for help. That is decided when you design the conversation flow, not in a last-minute adjustment.

Key takeaways

• One message, one idea, one question. Long texts and many options at once make people abandon the conversation.
• Everyday language beats internal company vocabulary. Acronyms, technical terms and industry jargon push customers away.
• Voice messages help people who struggle to type, but they require reliable transcription, confirmation of what was understood and care with personal data.
• A person should be able to ask for a human in a simple way, without going through a maze of menus and without having to guess a magic word.
• Test with real people from the audience you serve. A review done only by the internal team misses exactly what blocks the customer.

Who we are trying to serve and what usually blocks them

Customers with little digital familiarity are not a single group. They include older people who use WhatsApp every day to talk to family but distrust any robot. They include people with visual impairments who use a screen reader, people who are deaf or hard of hearing and prefer text, people with motor difficulties who type with effort, and people with limited schooling or little reading practice. They also include any customer who is tired, in a hurry or using a phone with a cracked screen.

The same blockers show up from one group to another:

• Long messages, with several paragraphs, that require scrolling.
• Numbered menus with many options, where the person cannot find theirs.
• Exact commands, such as typing a specific word to go back to the start.
• Questions that mix two requests in the same sentence.
• Answers sent as an image or PDF without the same content in text.
• A machine tone: curt sentences, words like protocol, parameterization or flow, and errors with no explanation.
• No clear path to talk to a person.

The design logic that fixes most of this is the same: reduce the load the person has to carry at each step.

How to write short messages in plain language

Plain language is not talking down to people. It means choosing the word the person already uses and putting what matters at the start of the sentence. The chatbot's text should be something a person can read aloud without stumbling.

Rules that work well in practice:

• One question per message. Instead of asking for name, date and time together, ask for one piece of information at a time.
• Short sentences in direct order: who does what. Avoid the passive voice and sentences with several chained clauses.
• Common words. Write appointment instead of outpatient service, and copy of the bill instead of invoice reissue.
• Say what happens next. For example: I'll show you the open times, and you pick one.
• Offer only a few options at a time, in buttons or a list, and always include an option to talk to a person.
• Confirm before acting: do you want to move Thursday's appointment to Friday morning? You can answer yes or no.
• Accept imperfect answers. Yes, y, sure, that's right and a thumbs-up should all have the same effect.
• Use emojis sparingly. Screen readers often read out the emoji's name, and a string of them becomes noise.
• Do not leave essential information only in an image. If you send a photo of an address or a quote, repeat the content in text.

Here is a before and after, as an illustrative scenario. Before: “Hello! To proceed with the reissue of your invoice, please provide the account holder's tax ID and select one of the menu options below.” After: “Hi! I'll help you get a copy of your bill. First, can you tell me the tax ID of the person who pays?” The second version has one action, one question and no term that needs explaining.

The agent's behavior instructions need to record these rules explicitly, with examples of good and bad use. It is worth reading how to write instructions for a support agent to turn this tone guide into something the system actually follows.

When to use voice and how to handle what the person says

In Brazil, many people prefer sending a voice message to typing, especially older people, people with motor difficulties and people who feel unsure about writing. A chatbot that ignores voice messages or replies “I didn't understand, please type your message” creates an unnecessary barrier.

The common approach is to transcribe the incoming audio and treat the text as a normal message. A few precautions make this safe:

• Confirm what was understood when the request involves an action: I understood that you want to cancel tomorrow's visit, is that right?
• Handle names, dates, amounts and addresses with extra care, because those are where transcription makes the most mistakes.
• If the transcription is unclear or the audio is noisy, politely ask the person to repeat it, or offer to bring in a human. Do not guess.
• Tell the person, in plain language, that the audio will be transcribed to help with the service, and define how long it will be kept. Audio can contain personal data and sometimes sensitive data, so it becomes part of the company's data protection routine. The Brazilian data protection authority (ANPD) is the official reference for LGPD guidance.
• Replying with audio is optional and depends on the channel and the tool. When it is not possible, keep the text short and readable.

For accuracy, cost and privacy in transcription, there is a more technical follow-up in transcribing WhatsApp voice messages with AI.

How to design the option to talk to a person

The human option is the most important accessibility feature of a chatbot. It covers everything the robot does not anticipate: a strong accent, an emotional question, a disability the flow does not account for, or a person who simply does not want to talk to a machine.

A decision guide for the design, in list form:

• The person asked for a human, using any similar word: transfer right away, without trying to convince them to stay with the robot.
• The person repeated the same thing twice or answered something unrelated to the question: offer the human explicitly.
• The audio was not understood: ask once for a repeat and, if it persists, transfer.
• The subject involves a complaint, money in dispute, health, bereavement or urgency: route it with priority.
• The message suggests confusion, irritation or fear: tone down the automated style and transfer. For signs of mood in a conversation, see sentiment analysis and when to hand off to a human.
• Outside business hours: explain when someone will answer and record the request so the person does not have to start over.

The handoff only works if the human receives the context. The person taking over needs to see a summary of what has been said, what the robot understood and what is still pending. Asking the customer to repeat everything is one of the worst effects of a poorly designed service, and it weighs more on people who already struggled to get that far.

When a topic involves automated decisions about the person, it is worth knowing the right to review provided by LGPD. The article on LGPD automated decision-making and the right to review explains the point.

What specific precautions apply to each type of disability?

No flow covers every case, but a few precautions cover a lot:

• Visual impairment: the text has to work well in a screen reader. That means clear sentences, short lists, nothing essential only in an image, and buttons with labels that make sense when read on their own. Avoid “click here” and prefer “see available times”.
• Hearing impairment or deafness: always offer a text path, without requiring a call or audio. If there is human support, make clear that it also happens in writing.
• Motor difficulty: reduce typing. Quick-reply buttons, short answers like yes and no, and accepting voice messages help a lot.
• Intellectual disability, reading difficulty or memory difficulty: one step at a time, calm repetition of what has already been agreed, no rush and no short deadlines to respond. Do not let the flow expire abruptly.
• Low digital familiarity: explain what each step is, avoid technology terms (link, token, sign-up, login) when there is an alternative, and never ask the person to install anything.

These precautions do not replace talking to the people themselves. If the company already serves this audience by phone or at a counter, the staff know where they get stuck. Ask them before writing the first message.

Step by step: from mapping to the human

The order of the work matters as much as the text. The method we use in support projects follows four moves: map, limit, pilot and hand off. Applied to accessibility, it looks like this.

• Map: list the real reasons people get in touch, the questions that repeat most and where the customers with the most difficulty give up or call asking for help. Record the current situation as a baseline, without inventing numbers.
• Limit: choose a few topics the chatbot can handle safely (a copy of a bill, opening hours, order status, appointment confirmation) and make clear what it never does alone, such as canceling a contract, negotiating a debt or giving health guidance.
• Pilot: run a single flow with real people, including some who represent the audience with the most difficulty, with conversations logged and a success criterion agreed beforehand. It is worth reading how to measure an AI automation pilot to define that criterion.
• Hand off: make sure the transfer to a human works, with context, and then decide, based on what the pilot showed, whether to expand, adjust or stop.

The starting point should be the simplest and most frequent flow, not the most impressive one. Anthropic's guidance on building agents makes the same case: start with the simplest solution and add complexity only when there is a reason.

Illustrative scenario: rescheduling an appointment

Imagine, as an illustrative scenario, a small clinic. An older woman sends a voice message saying she cannot make it on Thursday and wants another day. The chatbot transcribes it and replies with short text: “Hi, Mrs. Maria. I understood that you want to reschedule Thursday's appointment. Is that right?” She answers “yes”. The chatbot asks: “Would you prefer morning or afternoon?” Then it shows only two times, as buttons. If she writes something unexpected, like “I'd like to talk to the doctor”, the chatbot does not insist: it says it will bring in someone from the front desk, sends the summary of the request and says when the front desk will reply.

In this flow, nothing required her to know how to type a command, read a long menu or understand what a robot is.

Checklist before publishing the flow

Use this list as a final review. If any item fails, the flow is not ready yet.

• Each message has one idea and, at most, one question.
• No internal term or acronym appears without an explanation.
• The person can ask for a human at any moment, using any reasonable word.
• Voice messages are accepted, and critical information is confirmed before any action.
• Essential information is never only in an image or PDF.
• The flow does not expire abruptly or pressure for a quick answer.
• The human receives a summary of the conversation when taking over.
• There is a clear notice that this is an automated service and how data is handled.
• Real people from the audience you serve tested the flow, and the text was adjusted based on what they said.
• Someone is responsible for reviewing conversations that ended badly and updating the text.

The review cycle matters more than the first version. Abandoned conversations and frequent transfers at the same point show where the flow is hard. To decide what to automate and what to keep with people, the article on AI customer support and what to automate helps draw that line.

Frequently asked questions

Do I need a special tool to have an accessible chatbot? Usually not. Most accessibility comes from the design of the conversation: simple text, short steps, voice support and a way out to a human. The tool matters when it limits buttons, transcription or handoff, so check those features before you sign up.

Is an AI chatbot better than an options menu for people with little digital familiarity? It depends on the flow. AI understands free-form sentences and voice, which lowers the barrier of finding the right option, but it can also make mistakes or invent answers. So combine free conversation with confirmations, clear limits on what the chatbot can do and an easy path to a human.

How do I know if the chatbot is working for this audience? Test with real people and read the conversations that ended without a solution. Watch where they give up, repeat the question or ask for a person. Define the success criterion before the pilot, so you adjust the flow based on what actually happened and not on the team's impression.

Can customer audio be transcribed with AI without LGPD problems? It can be done, as long as the company treats the audio as personal data: state the purpose, limit access, define how long it is kept and avoid using the content for another purpose. If there is sensitive data, such as health information, more care is needed. When in doubt, consult ANPD guidance and the company's legal team.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• Anthropic: Building effective agents
• NIST AI Risk Management Framework