A vendor emails a screenshot of your homepage covered in red error icons. A business down the street gets a letter about its website. A regular customer phones because his screen reader keeps skipping the date field on your appointment page. Any of these leads to one question: what does the Americans with Disabilities Act actually expect from a business website, and what can you do about it without guesswork?
This page explains what our ADA website compliance services are and are not. We are a small WordPress team, not a law firm, so nothing here is legal advice, and we never tell a client their site is now “ADA compliant.” What we do is the technical part: find the barriers on your site, fix them, prove what was fixed, and keep checking so the next plugin update does not quietly undo the work. That technical record is what your own compliance effort, and any lawyer you work with, can stand on.
What the ADA asks of a business website, in plain terms
Title III applies to “places of public accommodation,” which in everyday language means businesses open to the public. The list is long: restaurants, retailers, clinics, hotels, gyms, law and accounting offices, banks, theaters and many more. The statute was written in 1990, before anyone had a business website, so it does not mention the web at all.
That gap is why the topic feels murky. Judges in different parts of the country have reached different conclusions about websites, and the split is sharpest for companies with no storefront. The DOJ’s position, repeated over many years, is that a public accommodation’s web content falls under Title III, and its March 2022 web guidance, written for businesses as well as state and local governments, restated that view. You can read the DOJ’s own materials at ada.gov.
What you will not find is a Title III rule from DOJ naming a technical standard for private business sites. Nobody has issued an official checklist that says “do these things and you are done.” So when people talk about ADA compliance for websites, they almost always mean something more practical: can a person with a disability find information, use the menus, fill in the forms and buy or book what everyone else can?
For the longer background on how the federal pieces fit together, the ADA requirements for websites guide compares the public accommodation rules with the government and federal-agency ones. For the specific question of which businesses Title III reaches and the arguments about online-only companies, see Title III and public accommodation websites.
Why WCAG 2.2 AA is the working yardstick
Because the ADA gives no technical rules for business sites, everyone reaches for the same reference: the Web Content Accessibility Guidelines, published by the W3C. Open almost any demand letter, settlement agreement or professional audit report and you will find WCAG Level AA cited, either version 2.1 or the newer 2.2.
WCAG is organized as testable success criteria. A few examples you will see in any report:
- 1.1.1 Non-text Content: images that carry meaning need a text alternative.
- 1.4.3 Contrast (Minimum): body-size text should reach 4.5:1 against whatever sits behind it, while big headings can drop to 3:1.
- 2.1.1 Keyboard: everything you can do with a mouse must be possible from the keyboard.
- 2.4.7 Focus Visible: when you press Tab, you can see where you are on the page.
- 3.3.2 Labels or Instructions: form fields tell people what to enter.
The W3C finalized version 2.2 in October 2023. Next to 2.1 it brings nine new success criteria, 2.4.11 Focus Not Obscured (Minimum) and 3.3.7 Redundant Entry among them, and it drops 4.1.1 Parsing. We work to 2.2 AA since it is current, and leaving aside that retired item, nothing 2.1 AA expects is missing from it.
The law and the standard are different things, and mixing them up causes a lot of confusion. Our explainer on the difference between ADA and WCAG goes through that relationship, and our introduction to WCAG itself covers how the guidelines are built.
What our ADA website compliance services include
A typical engagement has four parts. You can start with the first and decide on the rest later.
An audit against WCAG 2.2 AA
We run automated scans across your key templates, then test by hand: keyboard only, a screen reader (usually NVDA, plus VoiceOver on an iPhone and a Mac), zoom to 200 percent and reflow at a narrow width, and a read-through of headings, link wording, images and documents. Scanners flag only a slice of real problems, which is why the hands-on pass produces most of the findings that matter. The WCAG audit service page describes the method and the report in detail.
Fixes in the theme, plugins, forms and content
Then we fix what the audit found, starting with whatever blocks a task outright: a menu that cannot be opened by keyboard, a checkout button with no accessible name, a contact form whose errors are announced to nobody. We work in the theme or child theme, adjust or replace plugins that produce poor markup, and correct content in the editor. The remediation service page explains how we handle code changes, plugin conflicts and retesting.
A retest and a written record
Every fix gets checked again with the same method that found it. You get a list of what changed, where, when and against which success criterion.
Monthly checks afterward
WordPress sites change constantly. New pages, new plugins, theme updates, a marketing popup someone added on Friday. Our ongoing accessibility monitoring catches those regressions before they pile up again.
How an engagement runs from first look to monthly care
- Scoping. We look at your site, agree on which templates and user journeys matter most (home, services, contact, booking, cart and checkout, account pages, key PDFs), and write down what is in and out of scope.
- Baseline audit. We test those templates and journeys and give you a prioritized list of issues, each tied to a success criterion, with steps to reproduce it.
- Fix plan. We agree an order with you. Blocking issues on money and contact pages first, then site-wide template problems, then content clean-up.
- Fixes on staging where possible. If you have a staging copy, we work there first and move changes to the live site once they pass.
- Retest and record. Each fixed item is retested, marked resolved or still open, and logged with a date.
- Monthly cycle. We recheck the key journeys, scan new content, review what plugin and theme updates changed, and report.
Some issues will stay open for a while, and that is normal. A third-party booking widget or payment iframe may be outside what we can change. In that case we document it, tell you what the vendor needs to fix, and suggest a workaround if one exists.
What we will say about your site, and what we will not
Honest wording matters here, because loose claims can hurt a business more than they help. This table sets out the line we hold.
| Topic | What we can tell you | What we will never claim |
|---|---|---|
| Legal status | Which WCAG 2.2 AA criteria the tested pages meet and which they do not | That the site is “ADA compliant” or legally safe |
| Lawsuits and letters | That fixing barriers and documenting the work is a sensible step | That you will not receive a demand letter or be sued |
| Coverage | Exactly which pages, templates and journeys we tested | That untested pages are fine |
| Tools | What the scanners found and what manual testing found | A score or badge that “proves” accessibility |
| Third parties | Which barriers sit in vendor widgets we cannot change | That embedded services are covered by our fixes |
If you need a view on your legal exposure, talk to an attorney who handles ADA matters. We are happy to work with them and give them whatever technical detail they need.
The documentation you end up holding
A business that takes accessibility seriously should be able to show what it did. At the end of the first cycle you have:
- The audit report, with each issue described in plain language, its location, the success criterion, its severity and how we found it.
- A fix log: date, page or template, what was changed, who changed it, and the retest result.
- An open-items list, including anything blocked by a third party and what was asked of that vendor.
- A short summary you can share internally or with counsel.
- If you want one, a draft accessibility statement for your site that describes your effort honestly and gives people a way to report problems.
Monthly reports then add to that history. Over a year, the record shows a pattern of regular checking and correction, which is far more meaningful than a one-off scan.
Access and information we ask for at the start
- A WordPress administrator login made just for us, so it can be deleted cleanly when the project ends.
- Hosting or file access if theme code needs changing, or contact with whoever controls it.
- A staging site if you already have one. If not, we can discuss whether to set one up.
- Your list of key pages and forms: the ones customers actually use to call, book, buy or ask for help.
- Logins for any third-party tools embedded on the site, such as booking or payment systems, so we can test the journey end to end.
- Any complaint or feedback you have received from users, which tells us where to look first.
- A contact for decisions, because some fixes change how a page looks and someone needs to approve that.
If a lawyer is already involved because of a letter or complaint, the process is a bit different. Our page on website fixes after an ADA demand letter describes how we work alongside counsel.
How to judge whether the site really got better
You do not need to be a developer to check the result. Try these yourself after the first round of fixes:
- Put the mouse away. Press Tab from the top of the homepage and keep going. Can you always see where you are? Does the dropdown open? Can you get into the inquiry form, complete every field and send it?
- Zoom the browser to 200 percent. Does text still fit, or does each line run off the right edge?
- Submit a form with a required field empty. Is the error explained in words, next to the field, or just a red border?
- Turn on VoiceOver or NVDA for five minutes and listen to the main menu. Do the links make sense on their own, or do you hear “link, link, link”?
Then compare the retest results with the original audit. A good provider shows you the same issue before and after, not just a new and better-looking score. If the report only lists automated warnings, the manual work probably did not happen.
Common missteps businesses make with ADA and their website
- Installing an overlay widget and calling it done. Toolbars sold as an automatic fix draw strong criticism from disability advocates and from many people who do this work. Owners who installed one have been sued anyway. The FTC also moved against one overlay company, accessiBe, in 2025 over advertising the agency said was misleading. Our explainer on what accessibility overlays actually do goes into the details.
- Treating a free scan score as the answer. A clean automated result can sit on top of a menu nobody can open by keyboard.
- Fixing the homepage only. People rarely get stuck on the homepage. They get stuck in the booking form, the cart or the PDF menu.
- A one-time project with no follow-up. Six months of content updates can bring back most of the old problems.
- Overpromising in an accessibility statement. Writing “this site is fully accessible” invites exactly the scrutiny you were trying to avoid. Describe the effort, not a finish line.
- Ignoring the person who complained. A user who tells you something is broken is giving you the most useful test result you will get. Reply, fix it and thank them.
Doing it in-house compared with bringing in outside help
Some of this work suits a capable office manager or marketing person. Some of it needs a developer who knows WordPress and accessibility well. Here is a fair split.
| Task | Reasonable to do yourself | Usually needs a specialist |
|---|---|---|
| Alt text, headings, link wording | Yes, with a short guide | Only for large backlogs |
| Free scans with WAVE or similar | Yes, as a first look | Interpreting false positives and gaps |
| Keyboard and zoom spot checks | Yes | Full, documented testing of every journey |
| Screen reader testing | Basic listening is possible | Reliable judgment of forms, menus and widgets |
| Theme and plugin code fixes | Rarely | Yes |
| Audit report and fix log for counsel | Not usually | Yes |
A sensible mix: we do the audit and code fixes, your team takes over content habits with a short guide, and we keep monthly checks running so nothing slips.
Questions to ask anyone selling ADA website compliance services
- Are you testing to WCAG 2.2 AA or something else, and does each finding cite its success criterion?
- How much of your testing is manual, and which screen readers and browsers do you use?
- Which pages and journeys will you test, and how did you choose them?
- Will you fix the issues in our theme and plugins, or only report them?
- What will you not claim? (If the answer includes “ADA compliant” or “lawsuit protection,” be careful.)
- Does your solution depend on a script or toolbar, and what happens if we stop paying for it?
- How do you handle problems inside third-party embeds we cannot edit?
- What happens after the project ends? Who notices when an update breaks something?
Any provider worth hiring should be comfortable answering all eight in writing.
Keeping accessibility alive on a maintained WordPress site
Accessibility on WordPress behaves a lot like security: the work is never really finished, because the site keeps changing underneath it. A theme update can strip out focus styles. A new page builder widget can add headings in the wrong order. A form plugin release can change how error messages are announced.
That is why we tie accessibility checks into normal maintenance. When updates are applied, someone retests the key journeys. When new content goes up, someone checks headings, images and links. If you already have monthly WordPress maintenance with us, accessibility checks can sit inside the same routine and the same report.
If you are still working out where to begin, our accessibility checklist for small businesses is a practical first pass, and you can see how this page fits with the rest of our website accessibility services for US businesses, from audits to forms to redesigns.
ADA, the law and risk: Guides
Step-by-step guides on the individual tasks behind this service:
- ADA Compliance for Websites: What US Businesses Need
- Is My Website ADA Compliant? A 30-Minute Self Check
- ADA Website Lawsuits Explained for Business Owners
- What to Do After an ADA Demand Letter About Your Site
- ADA Title III Website Accessibility: Who It Covers
- DOJ Website Accessibility Guidance in Plain Words
- Does a Small Business Website Need to Be ADA Compliant?
- Accessibility Overlays: What They Do and Cannot Fix
- ADA vs WCAG: How the Law and the Standard Connect
- Does Accessibility Help SEO? The Honest Overlap
- Website Accessibility Cost: What Drives the Effort
- Website Accessibility Myths Owners Still Believe