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. Automotive teams facing the same widget risk can also see our automotive dealership accessibility specialty.
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 the W3C ARIA Authoring Practices Guide and WCAG 2.2 criteria covering name/role/value, focus order, status messages, and contrast — including the Understanding Status Messages and Understanding Name, Role, Value notes.
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. That aligns with how ADA.gov web guidance treats websites and apps as covered services — including third-party components you embed.
Managing Chatbot Vendors on Accessibility
- Request the vendor’s VPAT before renewal — its absence is itself a finding (see Section508.gov VPAT guidance)
- 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.
Need a Chatbot Accessibility Review?
Third-party widgets are still your legal responsibility under the ADA. Get a component-level accessibility audit, pair findings with accessibility remediation, or review broader dealership work under our automotive dealership accessibility specialty. Not sure where to start? Book a consultation, compare accessibility audit pricing, or browse our services — the same scoping path this client used.
Prefer neighbouring proof? See our ADA website remediation (Siteimprove) and accessibility audit and remediation two-phase engagement case studies.
Why This Matters
Chatbots and other conversational interfaces are frequently overlooked in accessibility reviews because they sit outside a site’s main page templates and often ship from a third-party vendor. This engagement combined a written consultation on accessible chatbot design patterns — focus management, live region announcements, and keyboard operability — with hands-on assistive technology testing of the deployed widget using a screen reader and keyboard-only navigation. That combination is what a chatbot needs: guidance the product team can act on before launch, and verification with real assistive technology once it is live. The result: two separate engagements, a consultation and a full assistive-technology review, both closed out at a 5.0 rating.