Your sofa arrives on Thursday 22 October.
Need another day? Call us on +1 555 0142, Monday to Friday, 9am to 5pm.
``` 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. ## After: an email address beside the phone number ```htmlYour sofa arrives on Thursday 22 October.
Need another day? Email delivery@birchwood.example with the day that suits you, and we'll reply within one working day. Or call us on +1 555 0142, Monday to Friday, 9am to 5pm.
``` 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. ## After: a contact form on the page ```htmlYour sofa arrives on Thursday 22 October.
We reply within one working day. Or call us on +1 555 0142, Monday to Friday, 9am to 5pm.
``` The request is written on the page itself, already tied to the order, with the reply time beside it. When it is sent, the status message says so ("Request sent. We'll reply by email within one working day."), so a screen reader user hears it went. The form only works as a way in if it stays accessible itself: every field labelled, no CAPTCHA, and errors said in words. ## After: welcome relay calls, when the phone stays the only route ```htmlYour sofa arrives on Thursday 22 October.
Need another day? Call us on +1 555 0142, Monday to Friday, 9am to 5pm. We welcome calls through relay services: in the US, dial 711 and give the operator our number.
``` A relay service lets someone who is deaf or can't speak make a phone call by typing or signing through an operator, and a captioned phone shows a caller who is hard of hearing the words as they are spoken. Saying calls are welcome tells relay users the team will take the call rather than hang up on the operator. It still needs a relay service, during opening hours, in a live conversation, so customers who don't use one, and those for whom a call is the barrier, are no better off. ## Which option to use 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. ## Implementation decisions 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](/learn/accessible-form-errors) 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](/learn/consistent-help) explains, and list every route, with its reply time, in the site's [accessibility statement](/learn/accessibility-statement). ## Verify the fix 1. On every page that sends people to support, such as the order, returns and help pages, find a written way to reach support beside the phone number, without going to another page. 2. Send a message by each written route with only a keyboard, and again with a screen reader, and confirm it is sent and that a form says so. 3. Confirm the reply comes within the stated time, from someone who can make the change asked for, without asking you to phone. 4. Make a test call through a relay service and confirm it is answered and dealt with like any other call. 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. --- Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)