A chatbot can pass every automated accessibility scan on the market and still be unusable for someone navigating it with a screen reader.

It probably sounds obvious, but it’s worth saying that automated audits check a page that already exists. Of course – how are they supposed to check a page that doesn’t exist yet?

Chatbots don’t have a “page” until someone types, which means tools built to catch accessibility failures are generally incapable of spotting those inside chatbots. More than 1 in 4 adults in the United States report living with a disability, but conversational interfaces like these, which are often the only option for someone looking for support on a site, often still don’t work for many members of this group. Some of the accessibility failures in these systems are solvable today with existing techniques, but others aren’t yet because nobody has agreed on how to even test them.

Automated accessibility audits

The WebAIM Million project scans the home pages of the top one million websites every year and finds detectable WCAG failures on the overwhelming majority: often things like missing alt text, low-contrast text, empty links, unlabeled form fields. Our own accessibility analysis of 6,554 websites found the same pattern.

In order to get these stats, an accessibility scanner loads a URL, parses the DOM, and compares what’s there against a known rule set. A chatbot has no “there” to compare against. The reply hasn’t been generated yet when the page loads, and it won’t exist in any fixed form until the model finishes producing it. An automated scanner generally has nothing to say about what happens after someone types, because it was never asked.

There aren’t many published studies yet that test chatbot accessibility, and those that do exist have been published in the last couple years as of the time of writing this article. It’s a new and emerging field of study.

But the chatbots that exist today aren’t okay. The tools just haven’t yet looked for the problems, and real users are running into those problems every day. A clean WebAIM scan or a passing automated audit says nothing about whether a screen reader user can follow a conversation.

All this to say that the absence of chatbot-specific findings in mainstream accessibility reporting represents a blind spot in current research, not the absence of accessibility issues in those systems.

Chatbot interfaces never hold still

Screen reader users build a mental map of a page once, then navigate it by landmark: jump to the heading, jump to the form, jump to the results. That map only works if the page holds still, and chatbots don’t.

New content appears mid-scroll, prior messages shift position, and the “page” a screen reader mapped thirty seconds ago no longer matches what’s rendered now, which is exactly the kind of dynamic content behavior the W3C’s Web Accessibility Initiative has flagged as unresolved for assistive technology. The practical result is that, after nearly every reply, someone using a screen reader has to reorient from scratch just to find what changed, a step a sighted user skips with a glance. That reorientation repeats every turn, and it stacks.

How do we know when a chatbot will finish thinking?

Some replies land instantly. Others take ten seconds or more while the model “thinks,” and nothing about the interface tells a screen reader user which one is coming.

A sighted user gets a spinner, three dots, a typing indicator. That visual cue rarely gets announced to assistive technology, so the wait is silent with no sound, no update, no way to distinguish a slow response from a broken one. If you’re listening instead of watching, you have no idea whether the system is working or your connection died.

The problem isn’t the delay; it’s not knowing whether the reply is still coming. Imagine trying to chat with an AI agent (or a human, for that matter) and having to guess when it’s your turn. Or imagine sitting and waiting for something to load but having no indication of how long it might be until it does.

Every time a switch or voice-control user uses these systems, they face the same blind guess: timing an input to a target that keeps moving.

A consistently slow chatbot can be planned around, but a randomly slow one can’t. It’s frustration at every turn.

Every new reply in a chatbot erases where a keyboard user just was

Focus on a page is supposed to land somewhere predictable after an action, the way it settles on a confirmation message once a web form submits. But in a chatbot a reply generates and focus doesn’t return anywhere predictable, so someone tabbing through the page has to re-navigate from the top of an ever-growing conversation just to find what’s new. WCAG’s focus order requirements exist precisely because this shouldn’t happen, and chatbot interfaces routinely ignore them anyway.

The problem gets worse the longer a conversation runs. Ten exchanges in, the newest content sits ten exchanges further from any anchor a keyboard user can rely on, so each turn costs more than the last.

“Bot” detection pre-conversation

Organizations routinely put a reCAPTCHA, a Cloudflare Turnstile challenge, or an SMS verification step in front of the chatbot itself, before any conversation can begin. Organizations bolt that gate onto an interface that already has structural problems of its own, and it fails a different group for a different reason:

  • Blind users hit visual-only challenges with no usable alternative.
  • People with cognitive or attention-related disabilities face puzzles built around time pressure.
  • Where an audio option exists, it’s frequently broken, missing, or nearly as hard to pass as the image it’s meant to replace.

The W3C Web Accessibility Initiative’s CAPTCHA guidance has documented these exact failures for years and WCAG’s input assistance guidance covers them as well, and yet most chatbot deployments continue to ignore them.

Problems for blind and low-vision users

A sighted person can glance at a reply and know its shape (three sentences or three paragraphs, an apology or an answer, worth reading closely or safe to skim, etc.) before reading a word, but someone using a screen reader gets none of that. A screen reader user has to hear the whole response, start to finish, before knowing its length, tone, or relevance.

That linear playback recreates the problem discussed above of not knowing whether a system has gone quiet because it’s still working or because something broke. Here the uncertainty sits inside the content itself, not just around it, so a person has to keep listening past a good answer just to confirm there isn’t a better one buried in sentence four.

Re-verifying like this isn’t free. A screen reader user re-listens to the reply, rewinds to the part that mattered, and cross-checks it against the question before deciding it’s finished: three separate actions a sighted glance replaces in under a second.

That effort for many represents chronic fatigue. Standard accessibility testing rarely simulates fatigue or runs more than one session with one tester, another reason why none of this shows up in the results.

Fabricated answers

I’ve never liked the term “hallucinated” as it applies to LLMs. It feels like we’re giving these systems too much credit.

A chatbot that contradicts itself mid-conversation or invents information that doesn’t exist creates a burden that has nothing to do with screen readers or keyboards. That inconsistency removes the ground cognitive disability users were relying on. For someone with an anxiety disorder or OCD, an ambiguous or contradictory answer can be worse: it’s the kind of open loop that invites repeated re-checking rather than a settled answer.

The response itself is the problem before the interface even enters the picture. Verbose, qualifier-stacked replies routinely violate the plain-language guidance the W3C’s COGA task force has published for exactly this kind of user, and the same reply usually falls short of WCAG’s own readable content standards, regardless of whether the surrounding page passes a screen-reader check.

Mainstream accessibility conversation still centers on blindness and screen reader compatibility (and, for that reason, so has much of this article). Cognitive and psychiatric disability barely register in chatbot testing or design review by comparison, at least based on what gets built and shipped. Nobody’s auditing for re-verification spirals. Nobody’s measuring how many times a hedge forces a user back to the same question.

For this group, consistency is an accessibility requirement, not a nicety layered on top of clarity. Current chatbot design treats variation in tone and content as a feature to celebrate, not a barrier to fix. Novelty sells demos, but it doesn’t help someone who needs the same answer twice.

Some chatbot accessibility failures are fixable today

What’s solved

Keyboard operability, a text alternative for any voice-only feature, user control over auto-scroll and forced pacing, and conversation state that survives a page reload are not open questions. These are implementation choices, and every one of them has an existing, well-documented technique behind it.

What isn’t

Identical queries can return different responses on different occasions, and that alone breaks the premise a standard audit depends on: a consistent, testable artifact to check against. There’s no agreed method yet for auditing conversational AI the way WAI methodology audits a static page, and that’s a genuine gap in tooling, not a solved problem waiting for wider adoption. Early WCAG 3.0 drafts gesture toward outcome-based testing that could eventually stretch to cover this, but nothing usable exists yet. Plain language helps cognitive accessibility, but these models default to hedged, qualifier-heavy phrasing. Plain language and default model behavior are currently incompatible, and nobody has fixed that yet.

Choosing or building an accessible chatbot starts with refusing to make it the only option

The single most actionable rule is the simplest: Never make a chatbot the only way to reach help. And:

  • Keep a form, an email address, a phone line alive and staffed alongside it.
  • Test with people who actually use screen readers, switch access, or voice control day to day, on their own hardware, not with an automated scanner standing in for a person. 
  • A free accessibility checker can catch the static-page failures, but it won’t catch any of the chatbot-specific problems. 
  • Give users control over pacing: no forced auto-scroll, no timeout that erases a half-finished conversation, always a way to pause and come back.

Before adopting or shipping a chatbot, ask two questions: 

  1. Is there a text alternative to every voice feature, and 
  2. Can someone leave the conversation and return without starting over? 

If you can’t answer yes to both, stop.

LLMs aren’t going anywhere, and neither are the chatbots built on top of them. We all need to do better to make sure these systems work for everyone.

References

  1. CDC. (2025). Disability and health data system (DHDS) overview. In Disability and Health Data System (DHDS). https://www.cdc.gov/dhds/about/overview.html
  2. Inaccessibility of Captcha. (2019). In W3.org. https://www.w3.org/TR/turingtest/
  3. Plain Language | Volume 38, Number 3 | Adding Plain-Language Standards to the WCAG 3. (2021). Plain language | volume 38, number 3 | adding Plain-Language standards to the WCAG 3. Umn.Edu. https://publications.ici.umn.edu/impact/38-3/adding-plain-language-standards-to-the-wcag-with-julie-rawe-and-lisa-seeman-horwitz-
  4. Tobin, J., Nelson, P., MacDonald, B., Heywood, R., Cave, R., Seaver, K., Desjardins, A., Jiang, P.-P., & Green, J. R. (2024). Automatic speech recognition of Conversational speech in individuals with disordered speech. Journal of Speech Language and Hearing Research, 1–10. https://doi.org/10.1044/2024_jslhr-24-00045
  5. Understanding WCAG 2.2 | WAI | W3C. (n.d.). In www.w3.org. Retrieved July 20, 2026, from https://www.w3.org/WAI/WCAG22/Understanding/
  6. U.S. access board – W3C publishes working draft of the W3C accessibility guidelines (WCAG) 3.0. (2021). AccessBoard. https://www.access-board.gov/news/2021/01/21/w3c-publishes-working-draft-of-the-web-content-accessibility-guidelines-wcag-3-0/
  7. WebAIM. (2024). WebAIM: The WebAIM million – an annual accessibility analysis of the top 1,000,000 home pages. In webaim.org. https://webaim.org/projects/million/