Question handling

Handling access questions without turning a request into an FAQ

One kind of message asks a factual question about your product or your premises: is there step free access, does the site work with a screen reader, is there a hearing loop. The other kind asks you to do something differently for the person writing. Only the first is answerable from published material, and treating the second as though it were is where this goes wrong.

What they are really asking

They are deciding whether to come, or whether to keep using the product, and guessing wrong costs them a wasted journey or an abandoned task.

  • is there step free access
  • is your website screen reader friendly
  • do you have an accessible toilet
  • can i get this in large print
  • do you have a hearing loop
  • can i bring my assistance dog
  • do you have a quieter time i could come in
  • can i have longer to fill in the form
  • does your app work with voiceover
  • who do i talk to about an adjustment

The material that answers it

An assistant is only as good as the document behind it, and for this question the document usually exists but is written in the wrong shape. What each one has to contain to be answerable:

Material that answers this question
A published accessibility statementThe document that makes half of this family answerable at all. A useful one names the standard you are working to, typically a WCAG conformance level, says how you assessed it, and is honest about the parts that do not yet meet it. A statement claiming perfection is less useful than one that lists known gaps, because the gaps are what people are asking about.
Physical access detail, written as directionsWhere the step free entrance is, whether the door is powered, how many steps if there are steps, lift dimensions, where the accessible parking is and how far it is from the door. Not a symbol on a page. The person asking needs to picture the route.
Alternative formats you can actually produceLarge print, plain text, a document that reads properly in a screen reader, captions, a transcript. List only what you can genuinely provide and how long it takes, because an unmet offer is worse than no offer.
Your assistance animal policyStated positively and without conditions bolted on, because in many jurisdictions refusing an assistance animal is unlawful and the question is being asked by somebody who has been refused before.
How to request an adjustment, and who receives itA named route, a person or team behind it, and a realistic response time. This is the material the second kind of message needs, and it is the piece most companies have never written down.

How to handle it

Split the two questions before answering either

Is there step free access is a fact about a building. Can you meet me at the side door because I cannot manage the ramp is a request for an adjustment. The assistant should answer the first from the statement and route the second to a person, and it must not answer a request with a quotation.

In practice the split is usually visible in the grammar: a question about the place or the product, against a question containing the word I or a description of a need.

Answer the published half with specifics

Access answers fail when they are approximate. Wheelchair accessible is not an answer. A level entrance from the car park, a lift to the first floor, an accessible toilet on the ground floor is an answer. The person reading is working out whether they can physically do this, and vague reassurance forces them to phone anyway, which is the outcome the widget was supposed to prevent.

Never infer an access fact from a related one

The assistant must not reason that because there is a lift there is probably a suitable toilet, or that because the site was rebuilt recently it probably works with a screen reader. If the material does not say it, the answer is that it is not published and here is who can confirm it. A wrong yes here does not waste a click, it wastes somebody's afternoon and their trust.

This is a good intent to run at the cautious setting, so that a weak match returns your fallback message rather than the nearest page about the premises.

Route the adjustment request to a named person, with a timescale

An adjustment request is a small negotiation: what is needed, what is possible, when. That is a human conversation and it should start quickly. The widget can collect the name, the address and the request itself and send it to whoever handles this, and the reply should say who will be in touch and roughly when.

Duties to make reasonable adjustments for disabled people exist in equality and disability law across many jurisdictions, and how far they reach depends on where you operate and what kind of organisation you are. That is a reason to give these requests an owner, not a reason to have the assistant explain the law.

When it stops being an answer

Every request for an adjustment, without exception

Not because it is difficult, but because it asks for something specific to a person and only a person can agree to it. An assistant that answers we aim to be accessible to everybody has refused politely without either party noticing.

A report that something is unusable

Somebody telling you that a form cannot be completed with a keyboard, or that a booking flow traps a screen reader, is doing free testing on a real barrier. That belongs with whoever can fix it, and it deserves an acknowledgement rather than a link to the accessibility statement they have already read.

Anything framed as discrimination

The moment a message says I was refused, I was told I could not, or this is discrimination, it has become a complaint with potential legal weight. It should reach a person immediately, and it should not receive a defensive answer composed by software.

How this one goes wrong

The confident maybe

The characteristic failure is an answer built out of adjacent material: the venue is on the ground floor, so probably fine. There is a lift, so it should be accessible. The assistant sounds helpful, the sentence contains a hedge, and the person reads it as a yes because they wanted a yes.

The cost lands entirely on them. They travel, they arrive, the door is not usable, and they leave. That is a considerably worse outcome than a refusal saying we do not publish this, please ring the front desk, and it is the reason this intent should be configured to refuse rather than to reach.

The same question, trade by trade

The pattern above holds everywhere. The wording, the escalation line and the material behind it do not, so there is a page per trade.

Questions

What is the one document that makes this answerable?
An accessibility statement that names the standard you are working to and is honest about known gaps. Without it the assistant has nothing but marketing pages to reason from, and those are exactly the wrong source.
Should the assistant explain what the law requires?
No. Duties differ by jurisdiction and by organisation, and a support widget improvising legal interpretation in your name is a risk with no upside. It should describe what you provide and how to ask for something you have not listed.
Is a chat widget the right channel for this at all?
For the published half it is often better than the alternatives, because it answers at the moment somebody is deciding whether to come, without them having to phone and explain themselves. The request half should always end with a person.

Keep reading

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.