Try the live assistant
answerrails.com / accessibility

Accessibility statement

Prepared 30 July 2026, revised 5 August 2026 (plugin v0.0.63) · Applies to the AnswerRails visitor chat widget and the plugin’s WordPress admin screens · Maintained in the plugin repository; this published copy is refreshed with each release that changes accessibility behaviour.

AnswerRails embeds in our customers’ websites, so its accessibility is part of their site’s conformance. We treat that as a product obligation: an inaccessible chat widget would degrade the host site’s WCAG / EN 301 549 position under the European Accessibility Act, and we do not consider that an acceptable thing to ship.

Standards targeted

  • WCAG 2.2 Level AA (W3C)
  • EN 301 549 — the harmonised European standard EU audits test against
  • W3C ARIA Authoring Practices Guide patterns (dialog, log, live regions)

What the widget provides

  • Screen-reader announcements: every completed message (visitor, assistant and system) is announced exactly once, speaker-prefixed, via a dedicated live region; transient states — “typing”, errors, moderation notices, session end — are announced via a separate status region. Answers arrive as complete units (no token streaming), so announcements are calm and complete.
  • Correct semantics: the chat window is a labelled dialog with a real heading; the conversation is a navigable log region; every control (launcher, send, input, minimize, new-conversation, consent checkbox, edit-consent) has a proper accessible name; citation links are real links that state when they open in a new tab.
  • Full keyboard operability: open → consent → converse → follow a citation → start a new conversation → close, with no pointer. Escape closes; focus returns to the launcher. On phones the full-screen chat is a true modal: focus stays inside until it is closed.
  • Consent flow coherence: where the site owner enables a consent notice, screen-reader users land on a concisely-labelled checkbox with the full notice read as its description — before any data is captured. Withdrawing consent is a native button (“Edit consent”) inside the chat window that moves focus to the same checkbox — withdrawal is as operable as consent.
  • Visible focus and reduced motion: a consistent, high-visibility keyboard-focus outline on every control, and full prefers-reduced-motion support (animations disabled, state kept visible).
  • Contrast-guarded theming: the theme engine chooses text colours by actual WCAG contrast ratio, and the admin colour settings warn site owners — with a one-click fix — whenever a chosen combination falls below the 4.5:1 AA minimum. Owners retain final control (a warning, not a lock).

Testing

Verified with NVDA on Windows (Chrome) against a live WordPress site using a scripted protocol (open, consent, multi-turn conversation, citations, failure states, close), with speech-output logs retained as evidence. Verified with VoiceOver on iOS Safari (real devices, remote device lab) using the same protocol, with session-video caption timelines retained as evidence; VoiceOver verification included characterisation testing that located and fixed an announcement defect specific to modal dialogs on iOS. JAWS is not currently part of the tested set.

Known limitations

Stated here rather than discovered later. Everything below is a limitation we know about and have not fixed.

  • Resizing the desktop chat window is pointer-only. No content or function is exclusive to resizing — the window is fully usable at its default and preset sizes, and docking/floating has a non-drag alternative (double-click the header). Keyboard resizing is a planned enhancement.
  • The widget inherits the host page’s font sizing and zoom behaviour; extreme user stylesheets on the host site are outside our control.
  • On iOS, VoiceOver gives priority to a user who is actively typing: a courtesy announcement (the welcome message, or an error notice) that arrives mid-keystroke may not be spoken until the user pauses. The same information is always visible in the conversation itself, and completed replies to a sent message are announced reliably.

Feedback

Accessibility issues in AnswerRails are treated as bugs, not feature requests. Report them to support@answerrails.com and they will be triaged into the next release cycle. If something on this website is the problem rather than the plugin, tell us that too — the claim at the foot of every page applies to the site as well.

canonical: /accessibility/ · this page is part of the assistant’s knowledge base on this site