Search topics
Support that can only be reached by phone
A shop's order page says that the only way to change a delivery is to call, so customers who can't hear or speak on the phone have no way to ask.
<a href="tel:+15550142">+1 555 0142</a> The problem
Customers who are deaf, hard of hearing or can't speak, and anyone for whom a phone call is the barrier, can't change their order, because a call is the only way to ask.
Birchwood Home, an online furniture shop, books a delivery day for each order. Its order page shows the day and says what to do if it doesn't suit: "Need another day? Call us on +1 555 0142, Monday to Friday, 9am to 5pm." The help page says the same, and there is no email address or form anywhere on the site.
A customer who is deaf finds they will be out on the day their sofa arrives. Everything they need is in the order page, apart from a way to ask. They can't hear the person who would answer, so the number is no use to them. They are left asking a friend to call, or waiting in on the wrong day.
EN 301 549 12.2.3 says that support services "shall accommodate the communication needs of individuals with disabilities either directly or through a referral point", and Section 508 603.3 asks the same of help desks and call centres. A support line that can only be reached by voice doesn't accommodate anyone who can't hear or speak, so it fails both. The clauses don't name a channel. What they ask is that support works for the person asking, and for many people that means writing.
No WCAG success criterion asks for a particular contact channel. WCAG 3.2.6 asks only that help, where a site offers it, is in the same order relative to the rest of the page on each page that repeats it, so a site that shows its phone number on every page in the same spot meets it and still fails here.
A phone call needs hearing, speech and a live, unplanned conversation at the hours the line is open. Anyone missing one of those is shut out, and the notes show how. Whoever can't get through usually gives up on the change, not the call.
4 of 10 groups affected
- No vision (not affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (affected)
- Hard of hearing (affected)
- No speech (affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without hearing A deaf customer can't hear the person who answers, so a phone number alone leaves them no way to move the delivery.
- Without speech Someone who can't speak can dial the number but can't say what they need, and someone with a severe stammer may not get the words out before the call moves on, so the call goes nowhere.
- Limited hearing A customer who is hard of hearing may catch some of a call, but dates, times and order numbers are exactly what gets misheard on a phone line.
- Limited language, cognitive and learning abilities Someone who finds live conversation hard, such as many autistic people or people with anxiety or aphasia, needs time to say things in writing that a call doesn't give.
A tel: link is valid, named and focusable, so axe and similar checkers pass it, and no WCAG rule asks what other ways to reach support there are. This audit looks across all the pages it was given and sends a review lead when it finds a phone number as a tel: link but no email link, no form with a message box and no chat button on any of them, unless a contact link points to a page it wasn't given, since that page may hold a form. It can't tell whether anyone answers the email, or whether the person who answers can make the change.
AI tools asked to write a help or contact page can copy the shape of the ones they have seen, which may put the phone number first and alone. They can't know whether the team behind it reads email.
Try it
Imagine you can’t hear or speak on the phone. Ask the shop to deliver your sofa on another day.
Use what the order page offers. The panel under the shop says what happened.
Broken Can you fix this?
Change your delivery
Your sofa arrives on Thursday 22 October.
Need another day? Call us on +1 555 0142, Monday to Friday, 9am to 5pm.
(Ask for another day)
The fix
Wherever the site sends people to support, give a way to write beside the phone number, with a reply time.
- 1Give a written route beside every phone number, where the task needs support.
- 2Say how soon a reply comes, and make sure whoever replies can make the change.
- 3Keep the route itself accessible: a plain email link, or a labelled form with no CAPTCHA.
<h2>Change your delivery</h2><p>Your sofa arrives on Thursday 22 October.</p><p>Need another day? Call us on <a href="tel:+15550142">+1 555 0142</a>, Monday to Friday, 9am to 5pm.</p>An email address beside the phone number
<h2>Change your delivery</h2><p>Your sofa arrives on Thursday 22 October.</p><p>Need another day? Email <a href="mailto:[email protected]?subject=Change%20delivery%20for%20order%204821">[email protected]</a> with the day that suits you, and we'll reply within one working day. Or call us on <a href="tel:+15550142">+1 555 0142</a>, Monday to Friday, 9am to 5pm.</p>The page sends people to support, and support can only be reached by voice, so customers who can't hear or speak on the phone have no way to make the change.
The customer can write at any hour and in their own time, and the subject line already says which order it is about. The reply time tells them when to expect an answer, and the phone number stays for those who prefer to call.
The email address: it does the same job as the form with nothing that can itself break, no fields to label, no CAPTCHA, no script, and the customer keeps a copy of what they asked. A form passes too, and suits a shop that needs the request tied to an order in its own system, as long as the form stays accessible. Welcoming relay calls is worth saying whichever you choose, but on its own it leaves out everyone who doesn't use a relay service.
Put the written route where the task is, not only on a contact page. Someone changing a delivery is on the order page, and that is where they need it, as plainly as the phone number, not in a smaller line under it.
Each written channel has its own catches.
- Email needs an address that someone reads. A no-reply address, or an inbox checked weekly, makes the reply time a promise nobody keeps.
- A form must work with a keyboard and a screen reader, never sit behind a CAPTCHA, and keep what was typed if it fails, as form errors that don't say how to fix them explains.
- A chat widget counts only if a keyboard and screen reader user can open it, read the replies and type, and only if a person takes over when the bot can't make the change. Many third-party widgets don't meet all three.
- Text messages (SMS) or a messaging app help customers who live on their phones, but they need the same reply time and the same person behind them.
Make sure whoever answers in writing can do what a phone agent can. If the reply to "please move my delivery" is "please call us to arrange this", the route is there but support is still phone-only.
Train the team to take relay calls. Relay operators often say "this is a relay call" first, and calls are sometimes hung up on as spam. In the UK, Relay UK users dial 18001 before the number; in the US, 711 reaches a relay service. In Japan, the public telephone relay service (電話リレーサービス) connects deaf and speech-impaired callers through an operator.
Keep the help in the same place on every page, as help links that move from page to page explains, and list every route, with its reply time, in the site's accessibility statement.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after any change to the help pages, the contact routes or the team that answers them.
Limits
This guide covers how customers can reach support from a website. It doesn't cover the support staff's own training beyond relay calls, sign language interpreting, or documentation in accessible formats (EN 301 549 12.2.4, Section 508 602.4), and it is not legal advice on what a business must offer in each country. A written route only helps if someone answers it: test the whole journey, from the page to the reply, with the people who will use it.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.