The email usually arrives without warning. “Quick question: is our website ADA compliant?” Sometimes a competitor got a letter. Sometimes the client’s insurer asked. Sometimes their lawyer read an article. Either way, the client wants a yes, and you are not in a position to give one.
This post is about how to answer that email well: what to say on the first reply, what never to say, how to find out where the site really stands, and how to turn a worrying question into a piece of planned work. It is written for agencies and freelancers building WordPress sites for US clients.
General information, not legal advice. Accessibility law in the US is a legal area, and whether a particular business has obligations is a question for that business’s own attorney. Nothing here is a legal opinion, and you should not present it to a client as one.
What the question is really asking
The Americans with Disabilities Act is a civil rights law. It prohibits discrimination against people with disabilities by, among others, many businesses open to the public. The law’s text was written before business websites were common, and it does not contain a technical checklist for them. The US Department of Justice has published guidance saying that businesses’ websites should be accessible, and its official site, ADA.gov, is the right place to point a client who wants to read it for themselves.
In practice, when people talk about making a website accessible, they nearly always measure it against the Web Content Accessibility Guidelines, published by the W3C. If you need a refresher on how those guidelines are organised and what the conformance levels mean, our post on the WCAG standard behind accessibility checklists covers it in plain terms.
So when a client says “ADA compliant”, they usually mean one of three things:
- “Are we at risk of a complaint or a demand letter?” That is a legal question.
- “Can people using screen readers, keyboards or magnification actually use our site?” That is a technical question you can help with.
- “Can you give me something in writing that says we are fine?” That is a request you should decline, politely.
Your job is to separate those three, answer the second, and send the first and third to the right people.
What not to say
The fastest way to create a problem for your agency is a well-meant reassurance. Avoid all of these, even in casual messages:
- “Yes, the site is fully compliant.” You cannot know that without a thorough review, and even then you are not the one who decides compliance.
- “We built it to ADA standards.” There is no single published ADA technical standard for private business websites to have built to.
- “Install this plugin and you’re covered.” No plugin or widget can make a site compliant on its own. Many accessibility problems live in content, images, forms and theme code, which a script added on top does not rewrite.
- “You don’t need to worry about that, you’re a small business.” Whether the law applies is not your call.
Also avoid the opposite mistake of frightening the client. They asked a reasonable question and deserve a calm, specific answer.
A first reply you can adapt
Keep the first answer short. It should acknowledge the question, set the boundary on legal advice, and offer a concrete next step. Something like:
“Thanks for asking about this. It’s a sensible thing to look at. Whether the ADA applies to your business, and what it requires of you, is a legal question your attorney is best placed to answer, and we can’t give legal advice. What we can do is check how accessible the site is in practice, measured against the WCAG guidelines that accessibility reviews normally use. We’d start with a review of the main pages and the key tasks on the site, such as the contact form and booking, and send you a plain-English list of what we find and what it would take to fix. Would you like us to scope that?”
That reply does three useful things. It does not claim anything. It puts the legal question where it belongs. And it turns an anxious email into work you can estimate.
Finding out where the site stands
Before you can tell the client anything, you need to look. A reasonable first review has two parts, and you need both.
Automated checks
Browser-based checkers and accessibility testing extensions scan a page and flag things like missing image alternative text, poor colour contrast, empty links and form fields without labels. They are quick and good at finding the obvious. They are also limited: an automated tool can tell you an image has alt text, but not whether that text describes the image. Many important issues can only be found by a person.
Manual checks
Do these on the pages that matter most: the homepage, the main service or product pages, the contact form, checkout or booking, and any page with a video or downloadable document.
- Keyboard only. Put the mouse aside and use Tab, Shift+Tab, Enter and the arrow keys. Can you reach every link, menu item and form field? Can you see where the focus is? Does a pop-up trap you, or close?
- Screen reader basics. Use the screen reader built into the operating system on a few pages. Do headings make sense out of context? Do buttons announce what they do?
- Zoom. Zoom the browser well past normal. Does text reflow, or does the layout break and hide content?
- Forms. Submit the main form with mistakes. Are errors announced and explained, or does the field just turn red?
- Media. Do videos have captions? Do PDFs have real text, or are they scanned images?
Our practical accessibility checklist for small business sites is written for owners rather than agencies, but it is a handy list to send the client alongside your findings, because it explains each item in non-technical terms.
Reporting what you found
The findings document is where agencies earn trust or lose it. Write it for the client, not for a developer; the same rules you would use for explaining any technical issue to a non-technical client apply here. For each issue, give:
- Where it happens (page and element).
- Who it affects, in one line. “People who can’t use a mouse can’t open the main menu” is clearer than a guideline reference.
- The fix, in plain words.
- Who fixes it: the agency, the client’s content team, or a third party such as a booking widget supplier.
- Rough priority. Problems that block a key task (contact, purchase, booking) go first.
Then add one honest paragraph at the end: this review covers the pages listed, measured against WCAG; it is not a legal opinion; accessibility needs ongoing attention because every new page, image and plugin can add new issues.
Who owns which part of the fix
Accessibility work often stalls because everyone assumes someone else is doing it. A simple split helps.
| Area | Usually owned by |
|---|---|
| Theme templates, menus, focus styles, landmarks | Agency or developer |
| Form markup, labels and error messages | Agency or developer |
| Colour palette and contrast in the design | Agency and client together |
| Alt text for images, heading order in posts, link wording | Whoever writes the content, often the client |
| Video captions and accessible PDFs | Client, unless the agency is asked to produce them |
| Third-party embeds such as chat, booking or reviews | The vendor, with the client pressing them |
Put this table, adjusted to the client, in your proposal. It stops the remediation work turning into an open-ended promise.
Questions to ask the client
Before you scope anything, ask a few questions so the work fits their situation:
- Has anyone raised a specific complaint or sent a letter? If so, has their attorney seen it? (If yes, the attorney may want to direct the work, and you should ask before acting.)
- Which tasks on the site matter most to your customers?
- Who adds content day to day, and would they like short training on alt text and headings?
- Which outside tools are embedded on the site, and do you have contacts at those vendors?
- Is a redesign planned? Fixing an old theme and then replacing it may not be the best use of money.
Keeping it from slipping back
A site that was accessible at launch can drift within months. New blog posts go up without alt text, a marketing team adds a pop-up, a plugin update changes a form. If the client wants this to stay in good shape, suggest a light recurring check: a quick keyboard and contrast pass on new templates, a scan after major updates, and a reminder to content editors. It fits naturally into a maintenance arrangement.
It also helps to set your own house rule for new builds: accessibility checks happen before launch, not after a client asks. The W3C’s Web Accessibility Initiative publishes free introductions and tutorials that are worth sharing with designers and content writers on your team.
When the work is bigger than your team
Remediation on an older theme can be slow, fiddly work: rebuilding menus, fixing focus order, relabelling every form. If it arrives while your developers are already committed elsewhere, it is a reasonable job to hand to a partner, as long as the client hears about it only from you. Our overview of outsourcing WordPress work as an agency explains how that kind of arrangement usually runs.
And if you would like a team to work through the findings list on your client’s site under your name, the page on white label accessibility remediation explains what we fix and how we report back to you.
Next in this series: Who Should Own Client Hosting and Domains? An Agency Guide
