Running it

A chat window is not accessible by default, and nobody checks

An assistant added to a website is a new interface, and it inherits none of the accessibility work done on the rest of the site. Organisations that take access seriously everywhere else will install a widget nobody has operated with a keyboard, tested with a screen reader, or read at a different text size - because it came from a vendor and looked finished.

Four checks anyone can run in ten minutes

Open it with the keyboard alone and close it again. Tab through it and watch where the focus goes. Zoom the page to two hundred per cent and see whether it still fits. Turn it on with a screen reader and listen to what a new message announces. None of that requires a specialist, all of it finds something, and most organisations have never done the first one.

The announcement problem is specific to chat

A conversation updates part of a page without reloading it, which is exactly the pattern screen readers handle badly unless the interface says so explicitly. A reply that appears silently is invisible to someone who cannot see it arrive. This is a question to put to a vendor in those words - how is a new message announced - and the answer distinguishes a widget built with care from one built quickly.

Plain language is an accessibility feature, not a style preference

The assistant's own wording matters as much as its markup. Long sentences, hedged qualifications and administrative vocabulary exclude people with cognitive differences, people reading in a second language and anybody using a screen reader at speed. Short sentences, one idea each, the answer first - the same discipline that makes an answer quotable makes it usable.

The human route has to be reachable the same way

If the fallback from the assistant is a telephone number, it is not a fallback for everyone. Offer at least one route that is not voice - an email, a form, a text channel - and make it visible in the conversation rather than buried on a contact page. An accessible assistant with an inaccessible escalation is a corridor to a locked door.

Frequently asked questions

Is the widget our responsibility or the vendor's?
Legally it is usually yours, because it is on your site and serving your users. Practically the fix is the vendor's, which is why the questions belong in the purchase rather than in a later audit. Ask before signing; afterwards you are asking a supplier for a favour.
What should we ask a vendor about accessibility?
Whether it can be operated by keyboard alone, how a new message is announced to a screen reader, whether it works at two hundred per cent zoom, and whether anybody has tested it with assistive technology rather than against a checklist. Four questions, and the quality of the answers is itself informative.
Does the assistant's own wording really matter for this?
More than most of the markup. A technically perfect widget delivering dense bureaucratic prose has made information available and not usable. Requiring short, answer-first replies improves accessibility, comprehension and the chance of being quoted correctly, all at once.
Should we offer an alternative to the chat entirely?
Yes, and it should be as easy to find as the chat. Some people will not use a conversational interface, for reasons ranging from assistive technology to preference, and a published page answering the same questions costs nothing extra - you already wrote the content the assistant is reading.
How often should we re-check?
After any change to the widget and once a year regardless, which is the same cadence as the rest of your access testing. A vendor update can break keyboard focus without anybody noticing, because the people who notice are the people who were already struggling and have stopped reporting it.

Get in touch

Leave your details and we will reply. You do not need a sales call to get an answer.