Skip to content

Website Accessibility Services

ADA Website Compliance Services for US Business Websites

Worried about what the ADA expects from your business website? We audit your WordPress site against WCAG 2.2 AA, fix the barriers in your theme, plugins, forms and content, retest every fix and keep a dated record. We are not lawyers and will never call your site compliant, but the technical work and documentation give your own compliance effort something solid.

  • Tested against WCAG 2.2 AA
  • Keyboard and screen-reader checks by a person
  • Plain-language reports
  • No compliance or lawsuit promises
On this page

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Retest and record. Each fixed item is retested, marked resolved or still open, and logged with a date.
  6. 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

  1. Are you testing to WCAG 2.2 AA or something else, and does each finding cite its success criterion?
  2. How much of your testing is manual, and which screen readers and browsers do you use?
  3. Which pages and journeys will you test, and how did you choose them?
  4. Will you fix the issues in our theme and plugins, or only report them?
  5. What will you not claim? (If the answer includes “ADA compliant” or “lawsuit protection,” be careful.)
  6. Does your solution depend on a script or toolbar, and what happens if we stop paying for it?
  7. How do you handle problems inside third-party embeds we cannot edit?
  8. 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:

What's included

What You Receive

  • Scoping of key templates, forms and user journeys
  • Automated scans plus manual keyboard and screen reader testing
  • Prioritized issue list tied to WCAG 2.2 AA success criteria
  • Fixes in theme, child theme, plugins and page content
  • Retest of every fixed item using the same method
  • Dated fix log showing what changed, where and why
  • Open-items list covering third-party widgets and vendors
  • Monthly rechecks after updates and new content

Who this is for

  • Businesses open to the public with a WordPress website
  • Clinics, law and accounting offices that take bookings or inquiries online
  • Restaurants, retailers and service companies with online ordering or forms
  • Owners who were offered an overlay widget and want a real alternative
  • Marketing managers who need a clear, documented plan to show leadership
  • Nonprofits serving the public through their website

Common barriers

Problems This Service Deals With

  • Menus that ignore the keyboard

    Dropdowns open only on hover, so anyone who cannot use a mouse never reaches the inner pages.

  • Forms that fail silently

    Errors show as a red border with no words, and screen reader users never learn what went wrong.

  • Low contrast brand colors

    Light gray text or pale buttons fall below the 4.5:1 ratio and are hard to read for many visitors.

  • Images with no text alternative

    Product photos, menus saved as images and icon links carry meaning that some visitors cannot get.

  • A widget instead of fixes

    An overlay toolbar was installed, but the underlying code problems are all still there.

  • No record of what was done

    Work happened at some point, yet nobody can show which issues were fixed or when.

How it works

How the Work Runs

  1. Agree scope: key pages, forms and journeys

  2. Audit against WCAG 2.2 AA, automated and manual

  3. Fix blocking issues first, then templates, then content

  4. Retest each fix and log it with a date

  5. Hand over report, fix log and open items

  6. Recheck monthly as the site changes

FAQ

ADA Website Compliance: Common Questions

Questions people ask about ada website compliance.

No. Title III contains no web rules, and DOJ has not issued a rule fixing a technical bar for private business sites. Plaintiffs' firms, settlement terms and auditors fill the gap with WCAG at Level AA, usually the 2.1 or 2.2 version, which is why our testing follows WCAG 2.2 AA. How the law applies to your specific business is a question for an attorney.

No, and we would be wary of anyone who offers that. No government body issues an ADA seal for websites. What we give you is an audit report, a dated log of every fix and its retest, and a list of anything still open. Those records describe the state of the site honestly, which is more useful to you and your counsel than a badge.

We cannot promise that, and nobody honestly can. Letters are sometimes sent regardless of how much work a site owner has done. Removing barriers makes the site usable for more customers and gives you a factual record of your effort. If a letter does arrive, your lawyer handles the response and we supply the technical detail.

We test the full journey, including embedded tools, and report barriers wherever they sit. If the problem is inside a vendor's widget that we cannot edit, we document it with the relevant success criterion, describe what the vendor would need to change, and suggest a workaround where possible, such as an alternative way to book by phone or email.

You do not have to, but many sites slip within months as plugins update and new content goes up. Monthly checks catch those regressions while they are small. Some owners keep the checks running all year; others ask for a recheck after big changes such as a redesign or a new plugin. We will tell you honestly which suits your site.

It is a short plain-language document: which pages and journeys were tested, on what dates, against WCAG 2.2 AA, which barriers were found, which have been fixed and retested, and what is still open, including vendor-owned widgets. It states facts about the site and the work. It does not assess legal risk or argue a position, because that is your attorney's job, not ours.

Still have a question? We are happy to help.

Ask Us Directly

We are a WordPress team, not a law firm, and nothing on this site is legal advice. We test against WCAG 2.2 Level AA, fix what we find and document it; we do not certify sites, promise that a site is "ADA compliant" or that it will not receive a demand letter or lawsuit. For legal questions, speak to a lawyer.

Start With a Free Accessibility Check

Send us your website address. We look at a few key pages the way a keyboard or screen-reader user meets them and tell you, in plain words, what is in the way and what to fix first.