Search topics
Help chatbots with no way to reach a person
A shop's help chat is a bot that knows only a few topics, and nothing in it or elsewhere on the site leads to a person when a question falls outside them.
const fallback = 'Sorry, I didn’t get that. Try a topic below.'; The problem
People whose question the bot doesn't recognise can't get help, because it never offers them a person.
Birchwood Home, an online furniture shop, answers questions with a chatbot, Ask Birchwood, in the same corner of every page. It knows three topics, tracking, returns and delivery times, which cover most of what customers ask, and it never closes. A customer's new sofa arrives with one leg missing. They open the chat and write "My sofa came with one leg missing". The bot replies "Sorry, I didn't get that. Try a topic below." Track my order says the order was delivered on Thursday 22 October, which they know. Returns explains how to send the sofa back, which they don't want. They try "I need a new leg for my sofa", then "can I talk to someone", and get the same reply each time. The help page lists the same three topics, and nowhere on the site is there an email address, a form or a phone number.
The same dead end turns up in other forms:
- A way to reach a person that appears only after the bot has failed several times. Someone the bot misunderstands, rather than fails to understand, never sees it: a message such as "My delivery is missing a leg" gets the delivery times, and to the bot that was an answer.
- A Contact us link in the footer that opens the same bot.
No success criterion asks for a way to reach a person, and this page passes the one closest to it. Success criterion 3.2.6, Consistent Help, counts a chatbot as help, "a fully automated contact mechanism", and asks only that help repeated across pages sits in the same place on each of them. Ask Birchwood does. Its Understanding page says the criterion doesn't require a site to offer help at all, nor a person to be available at all times. So this guide is a best practice: it shows what the criterion's own guidance recommends, not a failure of it.
That guidance is plain about bots. The same Understanding page says chatbots can work for many people, especially people with cognitive disabilities, if they recognise misspelled words, give human contact details when they can't answer satisfactorily after three attempts, and can be closed in one step. W3C's cognitive accessibility guidance has a pattern for it, Provide Human Help: when someone gets stuck, a person is usually the most effective help, and a route to one that only people who can manage a complex system can reach shuts out the people who need it most.
The bot works as it was built. It looks for one of its words in the message, and anything without one gets the fallback. The fallback points back to the same three topics, so a question outside them goes round in a loop, and nothing in the panel leads anywhere else. Each reply, read alone, is polite and correct.
The questions a bot can't answer are the ones with no standard answer: a missing part, a charge that looks wrong, a delivery that didn't happen. They are also the questions that most need a person, and people who already find writing or typing hard meet the loop first.
3 of 10 groups affected
- No vision (not affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities People with a learning disability, dyslexia or aphasia often can't word a question the way the bot expects, or spell it the way it matches. The bot answers something else, or the same list again, and with no person to turn to they give up on the task.
- Without hearing Many Deaf people have a sign language as their first language, with a grammar of its own, and may not write English as fluently. A bot that matches set words misses their questions, and a phone line, where there is one, is no way round it.
- Limited manipulation Someone typing with a switch, an on-screen keyboard or dictation can spend minutes on each message. Every rewording the bot asks for costs that again, and a word dictation gets wrong is one more word the bot doesn't match.
No axe rule looks at what a chat says, and EaseWeb's audit has none either. A scan doesn't hold a conversation, the widget often runs in a vendor's frame, and whether anyone reads what is sent is a business arrangement no page shows. The audit's lead for chat widgets sends a person to the chat to check that its messages are read aloud; that is the moment to look for a way to a person too. A code assistant asked to build a support bot can write a fallback like the one here, listing the topics again, unless it is asked for a way to a person.
Try it
Your new sofa came with a leg missing. Ask the help chat to get one sent.
Send the message as written, or in your own words, and try the topics. Then look for a way to ask a person.
Broken Can you fix this?
Help
Ask Birchwood
Hi! I can help with tracking, returns and delivery times.
The fix
Offer a way to reach a person in the chat itself, from the first message.
- 1Show a way to reach a person in the chat from the start, not only after the bot has failed.
- 2When the bot doesn't understand, its reply names the way to a person.
- 3Every route to a person reaches staff, says when they reply, and never opens the bot again.
<section class="chat" aria-labelledby="chat-title"> <h2 id="chat-title">Ask Birchwood</h2> <div class="chat-messages" role="log" aria-label="Messages"> <p>Hi! I can help with tracking, returns and delivery times.</p> </div> <div class="chat-topics"> <button type="button">Track my order</button> <button type="button">Returns</button> <button type="button">Delivery times</button> </div> <form class="chat-form"> <label for="chat-message" class="visually-hidden">Message</label> <input id="chat-message" autocomplete="off"> <button>Send</button> </form></section>A Talk to a person button in the chat
<section class="chat" aria-labelledby="chat-title"> <h2 id="chat-title">Ask Birchwood</h2> <div class="chat-messages" role="log" aria-label="Messages"> <p>Hi! I can help with tracking, returns and delivery times.</p> </div> <div class="chat-topics"> <button type="button">Track my order</button> <button type="button">Returns</button> <button type="button">Delivery times</button> </div> <button type="button" class="chat-person" aria-expanded="false" aria-controls="person-form">Talk to a person</button> <form id="person-form" class="person-form" hidden> <p>Someone on our team will reply by email within one working day. This chat is sent with your message.</p> <label for="person-message">What do you need help with?</label> <textarea id="person-message" name="message"></textarea> <label for="person-email">Your email</label> <input id="person-email" name="email" type="email" autocomplete="email"> <button>Send to our team</button> <p class="person-sent" role="status"></p> </form> <form class="chat-form"> <label for="chat-message" class="visually-hidden">Message</label> <input id="chat-message" autocomplete="off"> <button>Send</button> </form></section>The chat itself is built well: its messages are a named log, its field is labelled and its topics are buttons. What it lacks is any way past them. A question without one of its three words gets the fallback, the fallback points back at the same topics, and nothing in the panel leads to a person.
The button is in the panel from the first message, under the topics, so nobody has to fail first to find it, and the fallback names it at the moment the bot gives up. It opens a form of two fields, the kind of short route the cognitive accessibility guidance suggests, says who replies and when, and sends the conversation with it, so nobody has to tell the story twice. The status line says it was sent. The form posts to a staff inbox; a button that opens a person route nobody reads fails the same people, only later.
Both put a person in the chat from the first message. The Talk to a person button keeps people in the chat, sends the conversation along, and needs no mail app, but it needs a form that posts somewhere and a team that reads it: choose it when you can change the chat, or the vendor offers a hand-over to staff. The email line is one line that any chat's footer, or the page beside it, can carry: choose it when the widget is a vendor's and its settings stop there.
Offering a person only after the bot has failed is a common middle ground, and Understanding 3.2.6 describes it, with three attempts. Treat that as the least a bot should do, not the design. A bot can't tell when its answer was wrong: delivery times given to a question about a missing leg are an answer to it, so a counter of failed replies never counts them. The cognitive accessibility guidance lists forcing people through several steps to reach a person among the things to avoid.
Each route to a person needs the same care in a different way.
- A chat with staff, handed over from the bot: say so when it happens, and when no one is online, offer the form or email address in its place, never a "no agents available" message on its own.
- A message form: two or three fields, a reply time, and a status message that says it was sent, as in the first fix. No CAPTCHA in front of it.
- An email address or phone number: written out as text, with a reply time or opening hours. A phone number alone is not enough, as support that can only be reached by phone explains.
A bot built on a language model may not say it didn't understand. It can answer fluently and wrongly, so a fallback that offers a person may never appear. The way to a person has to be in the panel from the start for these bots too.
Call it what it is. "Talk to a person" or "Email our team" is plain; "Escalate", "Live agent" or an icon of a headset is not. Some bots also answer "person", "human" or "agent" typed in the message field by offering the same route, which helps, but only beside the button or line, since people who don't know to type those words never find it.
Every other door to help should lead to the same people. A Contact us link that opens the bot again is the second form of this failure. Wherever the chat and the way to a person sit, keep them in the same place on every page, as help links that move from page to page explains. The chat's launcher and close button, and whether its messages are read aloud, are covered in chat buttons that Tab skips, and close buttons with no name and chat widgets that never announce their messages.
Verify the fix
5 checks, no mouse.
Test with: Keyboard, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after any change to the bot's topics, the widget or the support team's hours.
How screen readers handle role="status" and aria-expanded
Limits
This is a starting pattern, not a guarantee for every site. A way to reach a person helps only as far as the people behind it do: a reply that takes a week, or a team that can't change an order, fails the same customers later. This guide is about whether a person can be reached, not about how the bot itself is built; test the whole route, from the first question to the reply, with the people your customers include.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.