Accessibility statement
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-motionsupport (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
- 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.