Before choosing a WordPress chatbot, request accessibility evidence for the exact product surface, assessed release and visitor journey you need. Then compare the supplier's statement with your theme, placement and recorded local findings. Keep unsupported scope, missing evidence and confirmed defects separate. A badge alone cannot answer those purchasing questions.
This accessible WordPress chatbot vendor evaluation guide gives you a supplier evidence request, a claim-versus-release matrix and conditions for a buying decision. It does not evaluate a product's conformance or provide a legal conclusion. All worked rows are hypothetical, not customer results.
Author: Achla AI, Organization. Reviewed: 14 October 2026. Prepared with AI assistance using official standards, supplier documentation and inspected product sources. The review date is not a publication date.
An accessibility claim is a starting point for a buyer decision
Make the required journey explicit before comparing suppliers. For a public website-answer widget, that journey might involve opening the interface, asking about a service, following a supporting page and returning to the website. A report about an agent dashboard would not, by itself, answer whether the visitor interface meets your requirements.
The user need is concrete: a WordPress forum question from someone working in higher education asks how to complete essential chatbot actions with a keyboard. This historical question is an audience signal, not a finding about every plugin today.
Your buying question is which evidence supports the required experience in your intended configuration. Set that requirement before a sales demonstration. Otherwise, a convincing demo may show a different theme, placement or product surface from the one you plan to buy.
Identify the product, release and host-site scope behind the claim
Ask the supplier to identify the component covered by its statement: public web widget, mobile SDK, admin interface or another surface. Record its release or build where available, assessment date, standard version and stated level. A report title and a familiar logo are useful leads; they still need scope.
WCAG's conformance-claim requirements specify a claim date, guidelines version and URI, level, covered pages and technologies relied upon. WCAG also addresses full pages and complete processes. A component statement therefore does not establish conformance of your entire WordPress site.
Keep supplier metadata separate from your installation record. The supplier may assess a hosted widget release; you must additionally identify your theme, editor, placement, branding and public pages. These extra fields form the procurement worksheet proposed here, rather than a new W3C certification requirement.
| Scope field | Supplier evidence | Your intended configuration |
|---|---|---|
| Product surface | Exact assessed component | Visitor widget or other required surface |
| Release and date | Assessed release/build and report date | Planned integration and review date |
| Standards | Version, level and report scope | Organization's evaluation requirement |
| Host context | Assumptions, prerequisites and exclusions | Theme, editor, placement and customization |
| Journey | Assessed pages or tasks | Public URLs and the complete required path |
If the supplier cannot identify the release behind a statement, record “release applicability unknown.” Do not silently attach its report to the newest version.
Read supplier statements for dates, exceptions and different surfaces
Current category pages illustrate why these distinctions matter. The examples below describe supplier statements observed on 14 October 2026; they are not independent conformance verdicts or a vendor ranking.
LiveChat's accessibility guide states WCAG 2.2 AA for its Chat Widget and links a VPAT. It distinguishes default colors from custom-color checking and identifies a limitation involving default eye-catchers. Request the report applicable to the configuration you intend to use, rather than extending its headline to every optional visual feature.
Intercom's Messenger FAQ says its Web Messenger was assessed in January 2026 and describes largely supported WCAG 2.2 AA with partially supported areas in its linked VPAT. It distinguishes that surface from its unassessed web app and mobile SDKs and warns that custom color combinations can worsen accessibility.
Zendesk's accessibility page lists separate reports for different products. At this review, its messaging Web Widget entry carries a September 2025 date, while the Classic Web Widget entry carries December 2019. Select the report for the actual product, not whichever document appears first.
A clear statement of exceptions is information to evaluate. It does not automatically make a supplier unsuitable; the decision depends on whether an exception affects your required journey and whether a verified resolution is available.
Send the scoped evidence request before choosing a widget
Use one request for all suppliers, including Achla. Ask for applicable evidence without presuming that every vendor has the same report format or that a missing document proves an inaccessible product.
- Identify the exact product and visitor journey being considered.
- Request the dated assessment, applicable release and standard/version/level.
- Request the evaluation scope, method, evaluator information and known exceptions.
- Ask which host settings or customizations can change the result.
- Agree who will resolve unanswered questions and what evidence will close them.
A practical request can say: “We intend to use the public widget on these WordPress pages with this theme and placement. Please identify the assessment covering that surface, the release it concerns, its exclusions and the evidence relevant to these tasks.”
Attach this worksheet to the request:
| Evidence requested | What the buyer needs to distinguish |
|---|---|
| Evaluator, dates and methods | Supplier assertion versus documented assessment findings |
| Product/build and page scope | Applicable release versus a different product or historical report |
| Browser and assistive-technology environment | Tested configuration versus an unspecified promise |
| Theme, placement and branding assumptions | Covered defaults versus customized host behavior |
| Known exceptions and prerequisites | Supported scope versus unresolved required tasks |
| Vendor and site contacts | Who answers product questions and who owns host changes |
| Retest triggers and record | Which changes reopen the purchasing decision |
W3C's evaluation report template includes scope, reviewers, process and findings, and points readers to updated reporting resources. Its conformance evaluation overview explains the relationship between evaluation and reporting: generating a report does not perform the evaluation. Ask for actual findings behind a document.
Keep claimed, observed and missing evidence in separate columns
A supplier claim describes its stated scope. A local finding describes what an evaluator observed in a particular environment. A purchase condition describes what you require before selecting or rolling out the product. Keep all three visible.
| Record | Vendor claim and source | Release/configuration binding | Local evidence | Owner and purchase condition |
|---|---|---|---|---|
| Surface coverage | Record exact statement and date | Confirm it covers the public widget | Not yet evaluated | Buyer requests applicable report |
| Custom branding | Record stated customization limits | Record chosen theme/colors/placement | Record findings or “not checked” | Site owner supplies scoped evidence |
| Required journey | Record supported scope and exceptions | Record pages and product release | Record outcome and evidence reference | Owner resolves any relevant blocker |
| Changed release | Preserve previous statement | Record new version and changed settings | Retest pending | Buyer reopens affected conditions |
These rows are blank decision structures, not completed evaluations. Populate them from real documents and observations; do not turn “not checked” into a passing result.
Use distinct statuses. Missing evidence means you have not obtained the needed assessment or local finding. Out of scope means the supplied material concerns another surface or configuration. Mismatch means the evidence and claim do not describe the same release or requirement. Confirmed defect requires an actual reproducible finding. Each status prompts a different next step.
For example, an admin-interface report supplied for a visitor-widget requirement is out of scope. A current widget assessment with no local evidence for your customized theme is a local evidence gap. Those are hypothetical classification examples, not allegations about a named vendor.
Name the defect owner and the condition for a retest
Make ownership concrete enough to act on. Assign product behavior to a named supplier contact, host-template or styling changes to the site maintainer, evaluation findings to the evaluator, and the purchasing verdict to the buyer. A shared defect can involve several people, but one person should coordinate the next decision.
Record the affected task, evidence reference, relevant release and proposed acceptance condition. “Vendor will improve accessibility” is not a condition you can verify. A useful condition identifies which previously blocked journey must become usable in the specified environment and which reviewer will record the result.
W3C's accessibility-statement guidance recommends contact information, known limitations and tested environments. That supports transparent communication; an accessibility statement is not itself a technical assessment. Use it to find the right contact and compare disclosed boundaries with the supporting report.
Reopen the applicable matrix rows when a relevant widget release, theme, placement or customization changes. Preserve the previous evidence and add the new result rather than rewriting history. A promised fix, release note or screenshot of an unrelated page cannot close an unresolved purchasing condition.
For hands-on keyboard, screen-reader and viewport procedures, refer to the existing search-bar accessibility guide. This worksheet governs supplier evidence and acceptance ownership.
Decide evaluate, request evidence, hold or reject scope
Choose a bounded verdict and state its reason:
- Evaluate: supplied evidence concerns the intended surface, and the remaining site-specific work has a responsible owner.
- Request evidence: a material scope, date, exception or assessment question is unanswered.
- Hold: a confirmed blocker affects a required journey and its resolution is not yet verified.
- Reject the proposed scope: it cannot meet a requirement the buyer needs, or the supplier cannot offer an appropriate evaluable configuration.
These verdicts are procurement recommendations, not a conformance scoring scheme. Unknown support remains unknown. An attractive price should not quietly remove a required journey from the decision.
Record the pages, configuration and evidence used for the verdict. A limited evaluation decision does not approve all future releases or every page on the site. Have the buyer sign off on that scope and retain the conditions that remain open.
Apply the same evidence request to Achla
Inspect the WordPress connector and installation documentation to define the product surface and placement you would evaluate. Achla documents cited answers from public website content and a connector with one global placement mode. The inspected documentation does not establish an Achla WCAG audit, conformance claim or certified compatibility with your theme.
Use troubleshooting documentation for documented behavior questions. Review current plans separately from accessibility evidence. The site-search overview provides broader category context; it cannot substitute for an applicable report.
If public cited answers fit the job, use onboarding to explore that product within your evidence conditions. Keep selection, evaluation and eventual launch approval as explicit decisions with the responsible owner.