Accessibility for Chatbots: A Build and Test Guide

TL;DR: An accessible chatbot works by keyboard, screen reader, voice and plain text, with no loss of function. Make the whole interface accessible, not just the chat. Announce new messages, keep answers short and sourced, say it's AI, and build a handoff to a person that you've tested end to end. Test with real assistive technology users, not scanners alone. Designing this in from the start costs far less than fixing it later.

An accessible chatbot is one people can open, use, understand and leave with a keyboard, a screen reader, voice input or plain text. Nothing is lost compared with a mouse user. That covers the chat window, the wording of the answers, how errors are handled and the way to a human when the bot gets stuck. In Australia it also ties back to the Disability Discrimination Act 1992 (Cth).

This guide covers what to build, what to test, and where AI chatbots create problems that old rule-based bots never had.

The short version

• Make the whole interface accessible, not just the conversation. A smart bot inside a widget you can't reach by keyboard still fails.
• Design for keyboard, screen reader and voice use from the first sketch.
• Test with real assistive technology users, not just scanners.
• AI answers need extra care: plain language, visible sources, clear errors and a clear signal that it's AI.
• Build a handoff to a person that works, then test it end to end.
• Fixing this after launch costs far more than building it in.

What accessibility means for a chatbot

Most accessibility advice is written for pages and forms. A chatbot is different. It's a live, changing conversation. New content appears with no page load. The user types or speaks freely. The system decides what to say next. Each of those can block someone.

The W3C makes a point that's easy to miss. Accessibility needs the entire interface to be accessible, not just the conversational part. If the launcher button can't be reached by keyboard, the quality of your language model doesn't matter.

Who needs it to work

The Australian Human Rights Commission notes that 5.5 million Australians live with disability. For a chatbot, that includes:

• Blind and low-vision users, who rely on screen readers or magnification.
• Deaf and hard-of-hearing users, who need text for any audio or video.
• People with motor impairments, who use a keyboard, switch device or voice control.
• People with cognitive or learning disabilities, who need short, predictable replies and enough time.
• Users with low digital confidence, or accents and speech patterns the bot wasn't tested on.

The same features help everyone else. Think of someone on a noisy train, someone with a broken wrist, or someone reading in their second language.

What Australian rules and guidance say

There's no chatbot-specific accessibility law in Australia. The duty comes from the general law and from guidance on how to meet it.

• The Disability Discrimination Act 1992 (Cth) applies to providers of goods and services. In 2025 the Commission published its guidelines on equal access to digital goods and services. Read them before you scope a build.
• The Australian Government's digital portal standard says chatbot interfaces should work with screen readers, keyboard navigation and voice commands.
• The AI Technical Standard expects agencies to tell users when they are dealing with an AI system and to offer human oversight and other channels, such as the phone.

If you sell to government, expect these to show up in tender documents. If your bot sits inside a regulated product, accessibility is one of several compliance threads. Our overview of AI software compliance shows how they fit together. Get legal advice for your own situation.

Designing the chat interface

Start with the shell around the conversation. Most failures happen here, and it's the cheapest part to fix. Our guide to conversational UI design covers the parts of a chat interface. Here are the accessibility checks.

Launcher, focus and keyboard use

1. The launcher is a real button with a name like "Open chat". Tab reaches it. Enter or Space opens it.
2. Focus moves into the chat when it opens, and back to the launcher when it closes. Escape closes it.
3. No keyboard trap. A user can always tab out or close the window without a mouse.
4. Every control has a visible focus ring: input, send button, suggestion chips, attachment and close.
5. Tab order matches the visual order, even after new messages arrive.

Announcing new messages

The most common failure is silence. The bot replies and a screen reader user hears nothing. New messages must be exposed as live updates, so they're announced without moving focus. WCAG 4.1.3 covers this: status updates must be coded with the right roles so assistive tech can pick them up.

Two points from our own builds:

• Streaming needs care. Reading out every token of a streamed answer gives a stream of fragments. Announce a short "Assistant is replying" status, then expose the finished message.
• Typing indicators are visual. Give them a text version, and don't repeat it every second.

Visual design

Check colour contrast for text, buttons and focus rings, including dark mode. Don't use colour alone to tell user and bot messages apart. Label the speaker in text. Let text resize without clipping. Test on small screens, where fixed-height windows often hide the input behind the on-screen keyboard.

Input options

A text box alone shuts some people out. A voice-only bot shuts out others. Offer more than one way in. The MITRE chatbot accessibility playbook calls for functionally equivalent experiences across visual and non-visual routes. In practice:

• Add suggestion buttons for common tasks. They help users with motor or cognitive difficulties too.
• Support voice input where you can, but never make it the only way in.
• Give captions or transcripts for audio, and text descriptions for images the bot sends.
• Label upload and form-style steps properly, and show errors in text next to the field.

If you're weighing a spoken channel, our notes on AI voice agents for business cover how voice differs from text.

Making the conversation itself accessible

A compliant widget can still hold a conversation nobody can follow. Content design matters as much as code.

Plain language and short turns

• Keep replies short. One idea at a time, answer first.
• Skip jargon and idioms, or explain them.
• Use lists sparingly. Long bullet blocks are tiring through a screen reader.
• Don't let emoji carry meaning. Screen readers read them out literally or skip them.
• Let users ask for a simpler version, and give it.

Time and control

Don't time out a chat while someone is writing a reply. If a session must expire, warn them and let them extend it. Let users go back, restart, skip a question or say "I don't understand".

Errors and dead ends

The worst reply is the same "Sorry, I didn't get that" over and over. Government guidance lists missed accents and a lack of simple, actionable pathways among the common problems. A better pattern:

1. Say what the bot couldn't do, in plain words.
2. Offer two or three next steps, as buttons and as text.
3. After a second miss, offer a human or another channel. Don't make the user ask.

A handoff that works

A handoff is part of accessibility, not an escape hatch. Check these:

• The option to reach a person is visible from the first message.
• The handoff carries the chat history, so nobody repeats sensitive details.
• The human channel is accessible too: live chat, a phone number, or email with a clear reply time.
• If nobody's available, the bot says so and says what happens next.

Test it end to end. A handoff button that leads to a closed queue is common and easy to avoid.

Problems specific to AI chatbots

Generative bots add risks a decision-tree bot never had. Answers vary between sessions. They can be long, confident and wrong. For users who can't easily scan, verify or compare, that costs more.

Say it's AI

Users should know they're talking to an AI. The government standard asks for visual cues and disclaimers. Make the disclosure text, not just an icon, so a screen reader user gets it too.

No black box

Government scaling guidance warns that vague, untraceable answers create a "black box" and recommends explainability and traceability from the start. For a retrieval-based bot, show which source an answer came from, in text, with a link a keyboard user can follow. Set the bot to say "I don't know" rather than guess. Our piece on AI agent guardrails covers how to enforce that.

Be clear about data

People with disability often share health, money or support needs with a bot. Explain what happens to their data in a few plain lines, before they type.

Control length and format

Language models like long answers with heavy formatting. Set output limits in your prompts. Test how markdown renders in the widget. Raw asterisks and pipes read badly through a screen reader, and a table that looks fine can be unreadable when announced.

Accents and speech

If you take voice input, test a spread of Australian accents, including regional ones and accents from the languages your customers speak. Test slow or atypical speech too. Speech recognition that works for your dev team may fail your real users.

Our take

We build AI agents, chatbots and knowledge systems. The pattern is the same every time. Accessibility gets treated as final polish, then turns out to touch everything. The widget, the prompt, the retrieval layer, the escalation rules and the analytics all decide whether someone with disability can finish their task.

Three early decisions drive most of the outcome:

• Pick the interface layer on purpose. Off-the-shelf widgets are hard to fix when they fail. A custom front end on your own agent is often easier to make properly accessible than fighting a vendor's markup.
• Put accessibility into the prompt and the test set. Reply length, reading level, no emoji and "say you don't know" are all behaviours you can specify and check on every release.
• Treat the handoff as a product feature. It needs an owner, hours, a success rate and its own tests.

We'd rather ship a system more of your customers can use than a demo that looks good on one laptop. Chatbots also drift as content and models change. Accessibility needs the same ongoing checks as accuracy. For the wider picture, see our guide to enterprise chatbots. The difference between chatbots and AI agents also helps when you're scoping.

How to test a chatbot for accessibility

The Digital Inclusion Standard advises you to combine automated tools with real-user feedback. Scanners catch missing labels and contrast problems. They can't tell you if a conversation made sense. Use four layers:

A short test script

1. Reach and open the chat using only the keyboard.
2. Ask a simple question. Confirm a screen reader announces the reply once, in full.
3. Cause an error on purpose with nonsense input. Check the recovery options.
4. Ask for a person and finish the handoff.
5. Zoom to 200 per cent and rotate the phone, then repeat steps 1 to 4.
6. Ask the same question five times. Compare length, format and consistency.
7. Try a strong accent or typos, if you accept voice or free text.

Track task completion and handoff success for assistive technology users, with consent. Read the transcripts of failed chats. They show you what the scanner can't.

Build it in from the start

Put accessibility in the brief, whoever builds the bot:

• The standard you're working to, with the Commission's 2025 guidelines as the Australian reference.
• Keyboard, screen reader and voice requirements, written as tests someone can pass or fail.
• Prompt rules: reading level, length, format and AI disclosure.
• Retrieval rules: sources shown in text, and a refusal when evidence is missing.
• Handoff rules: hours, channels, history transfer and failure handling.
• A test plan with assistive technology users, repeated before each major release.
• A named person who owns accessibility issues after launch.

Adding chat to an existing product? Our guide on how to add AI to an existing app shows where it plugs in. New to the idea? Start with conversational AI for business.

Work with Devwiz on an accessible AI chatbot

Devwiz builds AI agents, chatbots and knowledge systems as production software, not demos. We're based in Australia and have shipped 200+ apps, including work for the NSW Government. Tell us what the bot needs to do and who needs to use it. We'll show you how accessibility fits from the first sprint.

See our AI app development service, or AI platform development if the chatbot is part of a bigger system.

Frequently asked questions

Are chatbots covered by Australian disability discrimination law?

There's no chatbot-specific law. But the Disability Discrimination Act 1992 (Cth) applies to providers of goods and services, and that includes services delivered through a chatbot. The Australian Human Rights Commission's 2025 guidelines on equal access to digital goods and services explain how to meet those duties. Get legal advice for your own situation.

What are the most common chatbot accessibility failures?

A launcher or widget you can't use by keyboard, replies a screen reader never announces, and dead-end error messages. For AI bots, vague answers with no source and a handoff to a human that doesn't work are also common. Testing with real assistive technology users finds these fast.

Can an AI chatbot make a website more accessible?

It can help some people find information without working through complex menus. It doesn't replace an accessible site. The chatbot has to be accessible itself, and the rest of the site still needs to meet the standards. Treat it as an extra route, not a fix.

How should I test a chatbot for screen reader users?

Run the chat with a screen reader on desktop and mobile. Check that the launcher has a name, that each reply is announced once and in full, and that you can reach the handoff. Then repeat with disabled participants doing real tasks. Scanners alone won't catch conversational problems.