Your concierge can be used with a screen reader and a keyboard alone, by someone who can't see it or can't use a mouse. That isn't an add‑on or an overlay — it's how it's built, and a real person tested it that way.
In a scan of the web's top million home pages, 96% had detectable accessibility failures — most chat widgets are among them; yours is built and tested not to be. WebAIM Million, 2024
Standard on every build
A screen reader can use it
Replies are read aloudThe single most important thing in a chat widget: when the assistant answers, a screen reader announces it. Without that, a blind visitor is never told a reply arrived — they have to go hunting for it.
Announced as a dialogWhen it opens, a screen reader says it's a dialog and keeps the user inside it — so it reads as a real conversation, not stray text dropped onto the page.
Only the reply — nothing elseThe typing dots, the 👍/👎 buttons and the contact form stay silent. A lazier build announces all of it as noise on every single turn; this one speaks only the answer.
The keyboard can reach it — and leave it
One key to reach itThe launcher sits in the corner but is last in the page's code, so reaching it could mean tabbing past the whole site. A skip link puts the concierge one keypress away on every page.
Findable without tabbingIt's marked as a landmark, so a screen‑reader user can jump straight to it from their rotor — which is how most of them actually navigate — instead of tabbing through the page to find it.
Focus comes back on closeClose the panel and keyboard focus returns to the launcher — not to the top of the page, which would strand someone who has no idea where they were. (A subtle bug once made this silently fail; it's now caught by a test.)
It respects the person, not just the checklist
No keyboard trap — honestlyOn a phone it's full‑screen, so it holds focus. On a desktop, where it's a small corner panel with your site fully usable behind it, it does not pretend otherwise or trap you inside — a distinction most widgets get wrong.
Honors "reduce motion"If a visitor's device asks for less motion — because animation makes them dizzy or unwell — the entrance, the petals and the smooth scrolls all quietly switch off.
No keyboard ambush on mobileOpening it on a phone doesn't slam the on‑screen keyboard up over the conversation. Focus lands on the log, so the reply is read and reachable without a keyboard springing into the way.
Every detail — and it stays that way
Every form field is labelledThe contact form's fields each carry a proper name and the required ones are marked as required, so a screen reader announces what each box is for — not just an anonymous edit field.
The bot‑check keeps quietThe invisible spam guard is hidden from screen readers unless it actually puts a challenge in front of someone — so a genuine visitor never hears "verify" narrated at a form that isn't asking anything of them.
Tested by a person, not just softwareAutomated checkers miss most of what actually matters. So the concierge was driven start to finish with a real screen reader (VoiceOver) — that human pass found and fixed five issues no tool had flagged.
It can't quietly regressEvery one of these is checked automatically on each release — if a future change would strip the skip link, the announcer or the focus return, the build refuses to ship it. Accessibility fixed once tends to rot; this can't.
And what we deliberately don't do
We don't bolt on an accessibility "overlay." The one‑line widget that promises to make any
site accessible overnight is the accessibility equivalent of a bolt‑on — it sits on top of the page,
it's widely reported to make things worse for real screen‑reader users, and it has drawn a
wave of lawsuits of its own. We build the accessibility into the concierge's own markup instead. It's
the harder way, and it's the only one that actually works for the people it's meant to serve.
The international standard for accessible web content. The concierge is built to its Level AA success criteria — skip links, name/role/value, status messages, focus order and keyboard operability.
AODA ↗Accessibility for Ontarians with Disabilities Act
Ontario's accessibility law. Its information & communications standard is built on WCAG 2.0 Level AA — the same practices the concierge follows, and then some.
Also available
For businesses that need to demonstrate accessibility, not just have it:
A full accessibility audit of your surrounding website — not just the concierge — against WCAG 2.1 AA, with a screen‑reader pass by a person
Remediation of what that audit finds, prioritised by impact
A published accessibility statement for your site, worded to AODA expectations (we provide the template)
A plain‑English conformance summary you can hand to a procurement team or a complainant
And one limitation, up front
This describes the concierge we build and embed — not your whole website. Installing it
doesn't make the rest of your site accessible, and we'd never claim it does. If the site around it also needs
to meet the standard, that's the audit above — say so and we'll scope it.