Playbook, healthtech app
A chat widget is part of the public facing service, and so are its answers
An accessibility question on a health product is rarely academic. Somebody is telling you that the route you have built does not work for them, and behind that is usually access to care rather than access to a page. Public facing health services face accessibility standards in many jurisdictions, and the assistant is part of that surface rather than an accessory to it.
Why this is not the general answer
The handling pattern for accessibility requests holds across every trade. What follows is the part that does not.
- The request is usually about reaching care rather than about reading a page, so failing it has a consequence that no other cell in this family carries.
- The useful answer almost always includes a non digital alternative, which is exactly the material organisations forget to index.
- An accessibility statement's known limitations are part of the honest answer, and omitting them turns a helpful reply into a misleading one.
- Some of these messages disclose a disability, which is personal information the assistant must handle rather than reflect back or record as a fact.
How it arrives
- is the app usable with a screen reader
- do you have an easy read version of this
- can i get this information in another language
- i cannot use the app, is there a phone option
- does it support larger text and high contrast
- can somebody help me set it up if i cannot do it myself
What has to be indexed for this to work
| The accessibility statement, including the limitations it admits | What has been tested, what conforms, and what is known not to. The limitations section is the part that makes the rest credible, and an assistant that quotes the claims while dropping the caveats has made your statement into something it is not. |
|---|---|
| Alternative format and translation routes | How somebody requests easy read, large print, another language or an interpreter, who provides it and how long it takes. Frequently this exists as a process nobody has written on a page, which is the same as it not existing. |
| Assisted and non digital access routes | The telephone route, the paper route, and whether somebody can act on another person's behalf. This is the answer to a person who has just told you the digital route does not work for them, and sending them back to it is the one unacceptable outcome. |
| Supported assistive technology notes | Which screen readers and platform accessibility settings have been tested against the product, and at which versions. Specific answers here are far more useful than a general commitment, and they are checkable. |
The reply
The accessibility statement covers screen reader support and lists the assistive technology the product has been tested with, along with the areas it states are known not to conform yet. Information can be requested in easy read, large print or another language through the alternative formats route, and there is a telephone route for anybody who would rather not use the app at all, with its hours on the contact page. If none of those fit what you need, tell me what would work and I will pass it to the team rather than sending you back to the app.
It quotes the statement including its admitted gaps, which is both more honest and more useful than a general claim of accessibility. It names three routes, one of which is not digital, because the visitor has already said the digital one is a problem. The closing line takes a request for an unmet need seriously without asking the person to explain or justify their disability to a chat box.
Where it stops
The trigger. The published routes do not meet the need, or the person needs an adjustment recorded so it applies to future contact.
If the published formats and the telephone route do not cover what you need, that should go to a person rather than stop here. Leave your name, how you would prefer to be contacted and what would work best for you, and the team will arrange it and record it so you do not have to ask again.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- A conformance claim that goes beyond what your own accessibility statement states.
- The tested claims without the known limitations that sit alongside them.
- Anything that treats a person's stated disability as a recorded fact about them or repeats it back as a category.
- A suggestion to use the digital route the person has just said they cannot use.
Questions
- Is the widget itself required to be accessible?
- Treat it as part of the public facing service, because that is how a reviewer will treat it. It is worth checking keyboard operation and screen reader behaviour on the page you embed it in, since the surrounding page contributes as much to the outcome as the component does.
- What is the most commonly missing document here?
- The non digital route. Organisations publish an accessibility statement and forget to publish the telephone or paper alternative, which means the assistant can describe conformance in detail and cannot tell somebody how to reach a person instead.
- Should it ask what the person's condition is?
- No. It should ask what would work for them, which is the only part that affects the answer. Asking about a condition collects health information through a public chat box, which is the wrong thing to do in a conversation that started as a request for a larger font.
Keep reading
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- Handling accessibility requests in generalTwo different things arrive as one message. A published accessibility statement answers the first. The second is a request, and it needs a person.
- Explaining how access works when the diary lives somewhere elseAccess often runs through an employer, insurer or health service, which decides the answer. What to clarify before anybody tries to book.
- Where a request should go depends on who is typing, and the widget cannot tellPatients, clinicians and buyers need three different destinations. How one question sorts them without the assistant claiming to know who is typing.
- The identity check is against the record, not against an email addressContact details bound to a verified identity, and a parent account that transfers on a birthday. Access questions where a record sits behind the door.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.