An accessible customer support message lets the customer understand the decision and complete the next action without depending on one format. Put essential facts in text, explain attachments, and offer another route when the original creates a barrier.
Do not guess a disability or declare a channel universally accessible. Ask what format works and verify the result. This is practical advice, not certification or legal assessment.
Start with the action the customer must complete
Before choosing text, audio, an image or a document, write the action in one sentence. The customer may need to confirm an appointment, identify an order, approve a change or send one missing fact. If the action is unclear to the agent, adding formats will not fix the reply.
Put the action and deadline in text that can stand alone. “Reply with the preferred delivery date by Thursday” is more usable than “See the details above.” Explain unfamiliar abbreviations.
The W3C accessibility principles explain that information should be perceivable and understandable through text alternatives and clear language. Apply that principle while separately testing the channel with assistive technology.
Keep the essential answer outside one format
A voice note can add warmth, an image can show damage, and a PDF can preserve a document. None should be the only place where the action appears. The guide to WhatsApp voice messages and audio files covers audio. The broader rule is that the answer survives when sound, vision or an attachment is unavailable.
- ActionState what the customer needs to do in text.
- AlternativePreserve every fact needed to finish the task.
- OwnerKeep one responsible person when the format changes.
| Format used | Keep available another way | Check before sending |
|---|---|---|
| Voice note | Accurate text with every required action | Names, dates, amounts and transcript limits |
| Image | Short description and the fact the image proves | Crop, privacy and whether colour carries meaning |
| PDF or document | Plain summary and an accessible copy or alternative route | Reading order, headings, labels and download access |
| Colour status | Written status such as approved or pending | Meaning remains clear without colour |
A filename such as scan04.pdf is not an alternative. Say what the file is and why it matters. A brief caption cannot explain a diagram with several decisions.
Write alternatives that preserve the same decision
An alternative should carry the information required to finish the task. For a delivery photograph, state what is shown, where it was placed and which uncertainty the image addresses. Do not claim that it proves more than it shows.
For prerecorded audio, W3C guidance calls for an equivalent alternative. The audio-only accessibility explanation gives the formal web-content context. A short summary may not equal a transcript. Label it honestly and include every required name, number, date and instruction.
Across languages, the support translation glossary guide preserves approved terms, while multilingual routing finds a qualified owner. An automatic transcript or translation does not prove understanding.
Ask for a usable preference without making assumptions
If a customer says a format does not work, acknowledge the barrier and offer concrete choices. Ask, “Would plain text in this chat or an accessible document work better?” Avoid requesting a diagnosis, asking the customer to justify the need, or making them restart the case in another queue.
Record only the preference needed for the service under the organisation's privacy rules. A useful support case note can state format, action, owner and due time without speculative health information.
Do not assume one preference is permanent. Confirm the route for the current task, especially for a deadline, payment or account change.
Keep ownership when the format changes
Changing from audio to text should not create a new unowned ticket. One person or team should remain responsible for the answer, ensure the alternative reaches the customer, and confirm that the action can now be completed.
The shared inbox ownership model separates visibility from responsibility. DripTell history, assignments and private notes can retain context. They do not certify accessibility, repair a third-party file or decide legal requirements.
Test replies with sound off, images hidden and attachments unavailable. Test the inbox with keyboard and screen-reader users where relevant. Automated checks cannot prove that a person can complete the task.
Frequently asked questions
Is plain text always accessible
No. Text can still be unclear, poorly structured, in the wrong language or trapped in an interface the customer cannot use. Keep sentences direct, name links and files, preserve reading order, and offer another channel when the current one remains blocked.
Can an agent send only a transcript of a voice note
A checked transcript can be useful, but verify names, dates and numbers. If the transcript is automatic, say so. Give the customer a concise written action as well, rather than making them search a long transcript for the decision.
Should a team store a customer's accessibility need
Store only the service preference the organisation is authorised to keep, for a defined purpose and period. The team inbox can keep an approved note beside the conversation, but access, privacy and deletion rules still need an accountable owner.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
