Client & Context
A chatbot accessibility review is one of the most requested — and most revealing — checks in modern accessibility work, because chat widgets concentrate every hard problem in one component: live regions, focus management, dynamic content, and third-party code. Ken Garff engaged HalfAccessible in April–May 2026, first for a scoping consultation and then for a dedicated access review of their customer-facing chatbot.
The Challenge
Chat interfaces fail assistive technology users in ways automated tools rarely catch: new messages that screen readers never announce, focus that jumps unpredictably when the widget opens, unlabelled icon buttons, and keyboard traps inside the conversation pane. The review had to assess the real experience — not just the markup — and produce findings the vendor and the in-house team could each act on.
Inside the Chatbot Accessibility Review
We tested the full conversation lifecycle with NVDA, JAWS, and VoiceOver, plus keyboard-only navigation: opening the widget, receiving and sending messages, interacting with quick-reply buttons, and closing without losing page context. Each behaviour was assessed against W3C ARIA Authoring Practices and WCAG criteria covering name/role/value, focus order, status messages, and contrast.
Findings were split by ownership — issues the chatbot vendor needed to fix versus configuration and integration items the website team controlled — so nothing stalled in a responsibility gap.
The Results
- Complete accessibility assessment of the customer-facing chat widget
- Findings separated by vendor vs. integration ownership for fast action
- Practical consultation that scoped the work before a dollar was spent on it
- Both engagements rated 5.0 out of 5.0 on Upwork
The Criteria Chat Widgets Fail Most
WCAG 4.1.3 Status Messages is the quiet killer: when the bot replies, sighted users see the message appear, but unless the widget uses a correctly configured live region, screen reader users hear nothing at all — a conversation where only one side knows the other has spoken. Close behind are 2.4.3 Focus Order (the widget opens but focus stays on the page behind it), 4.1.2 Name, Role, Value (icon-only send and close buttons with no accessible name), and 1.4.11 Non-text Contrast on the floating launcher button itself.
Because most chatbots are third-party products, teams assume accessibility is the vendor’s problem. Legally, it is not: ADA exposure attaches to the business deploying the widget, and courts have shown no interest in the subcontracting chain behind a barrier.
Managing Chatbot Vendors on Accessibility
- Request the vendor’s VPAT before renewal — its absence is itself a finding
- Test the embedded widget in your context; vendor demos rarely match production configuration
- Separate findings by ownership so vendor tickets and internal fixes move in parallel
- Retest after every widget version bump, since vendors ship silently
The consultation-first structure this client chose is one we recommend often: thirty minutes of scoping prevented weeks of unfocused testing, and the follow-on review landed exactly on the flows that mattered to their customers.
Frequently Asked Questions
Can a third-party chatbot ever be fully accessible? Yes — several vendors now ship solid live-region and keyboard support, but configuration and embedding choices on your site can still break it, which is why in-context testing matters.
What does a chatbot accessibility review cost compared to a full audit? A fraction — it is a component-scoped engagement, typically days rather than weeks, like this one.
What if the vendor refuses to fix their side? The findings document gives you leverage at renewal — and grounds to evaluate alternatives with accessibility as a selection criterion.
Is Your Chat Widget Excluding Customers?
Third-party widgets are still your legal responsibility under the ADA. Get a component-level audit, ask about our consultation services, or book a 30-minute consultation like this client did.
