Most people find out their website has an accessibility problem one of two ways. A customer tells them, which is rare and generous. Or a demand letter shows up, which is neither.
There is a third way, and it is the one worth aiming for. You check on purpose, before anyone makes you.
Here is what that actually involves, without the marketing version.
Does my website need to be ADA compliant?
The Americans with Disabilities Act was signed in 1990 and it does not mention websites anywhere. That one fact is why this question keeps coming up, and why the answers you find online contradict each other so badly.
The practical situation is this. Courts have spent two decades applying Title III of the ADA to the websites of businesses open to the public, and they have largely agreed that it applies. The Department of Justice has taken the same position in its guidance on web accessibility. What does not exist is a federal regulation spelling out a technical standard for private businesses. There is no certificate. There is no official seal. Nobody can hand you a piece of paper that says you are finished.
What exists instead is a standard that courts, regulators, and settlement agreements all point back to. That standard is WCAG, and we will get to what it says.
If you run an online store, a restaurant, a law firm, a clinic, or anything else serving the public, the honest answer is yes, you are expected to make a real effort. The less honest answer, the one in a lot of agency marketing, is that you are one click away from being sued into oblivion. That part deserves a straight look, because knowing where the risk actually sits changes what you should do about it.
According to UsableNet’s midyear 2026 litigation data, web accessibility lawsuits are on pace to pass 6,000 this year, roughly twenty percent more than last year. They are not spread evenly. E-commerce accounts for about 79 percent of them. Food service is a distant second at 14 percent. Every other industry combined makes up the remaining 7 percent.
So if you sell online, the risk is immediate and you probably already knew that. If you are a local service business, the odds of a lawsuit in a given year are genuinely low. That is not a reason to skip this, and the next section is why.
For healthcare, this stopped being a risk question
If your practice takes Medicare or Medicaid, accessibility is no longer a judgment call about litigation odds. It is a regulation with a date on it.
In May 2024, HHS finalized a rule under Section 1557 of the Affordable Care Act requiring patient-facing websites, mobile apps, and kiosks to meet WCAG 2.1 Level AA. It applies to recipients of HHS financial assistance, which covers essentially any practice billing federal programs.
The deadlines moved once already. In May 2026, HHS issued an interim final rule giving covered entities an extra year, citing how many of them were not going to make it. The current dates are May 11, 2027 for organizations with 15 or more employees, and May 10, 2028 for those with fewer.
If you run a practice, that first date is close enough to plan around now. We wrote more about what this means for practices specifically on our medical practice website design page.
Everyone else should still read the rest of this, because the standard HHS chose is the same one the courts have been using all along.
What WCAG 2.1 Level AA actually means
WCAG stands for Web Content Accessibility Guidelines. Version 2.1 at Level AA is the version almost everyone means when they say a site should be accessible. It contains 50 testable success criteria organized under four principles, and the principles are more useful than they sound.
Perceivable. Someone has to be able to take the information in. Images need text alternatives. Video needs captions. Color cannot be the only way you communicate something, which is why “the required fields are in red” fails on its own.
Operable. Someone has to be able to use it. Every function that works with a mouse has to work with a keyboard. People need enough time to complete things. Nothing should flash in a way that triggers seizures.
Understandable. It has to make sense. Language is declared so screen readers pronounce it correctly. Navigation stays consistent between pages. When a form rejects an entry, it says what went wrong and how to fix it, rather than turning a box red and leaving.
Robust. It has to work with assistive technology, now and after the next browser update. In practice this means clean, semantic markup instead of a pile of divs styled to look like buttons.
That is the whole framework. Fifty criteria sounds like a lot until you realize most of them are things a careful developer does anyway. WebAIM publishes plain-language explanations of each one if you want to go deeper.
How to make your website ADA compliant
The work splits into things you fix once and things you have to keep doing. Most guides only cover the first kind, which is how sites end up compliant on launch day and broken six months later.
The structural work comes first. Semantic HTML so headings are actual headings in the right order. Every image gets meaningful alt text, and decorative images get empty alt text so screen readers skip them instead of reading a filename out loud. Form inputs get real labels, not placeholder text pretending to be labels. Every interactive element is reachable by keyboard, in a sensible order, with a visible focus indicator so the person can see where they are.
Then contrast. Text needs a 4.5 to 1 ratio against its background at normal size, 3 to 1 for large text. This is the single most common failure we find, and WebAIM’s annual analysis of the top million home pages finds the same thing year after year. It is usually the brand’s fault. Light gray on white looks elegant in a design file and is unreadable to a lot of people.
Then the pieces people forget. Video captions. Descriptive link text, because “click here” tells a screen reader user nothing about where it goes. Page titles that describe the page. A skip-to-content link so someone using a keyboard does not have to tab through your entire navigation on every page.
The ongoing part is where it falls apart for most businesses. Every new blog post can introduce an image without alt text. Every plugin update can change markup. Every new landing page built in a hurry can ship with a form that has no labels. Accessibility is not a project you complete, it is a standard you hold, which is why we fold it into ongoing website support rather than treating it as a one-time line item.
Why accessibility overlays do not count
You have probably seen the little accessibility icon in the corner of a website, the one that opens a panel offering high contrast mode and bigger text. Those are overlay widgets, and they are sold as a one-line fix. Paste in a script, become compliant, sleep well.
They do not work, and that is not our opinion.
In January 2025 the Federal Trade Commission ordered accessiBe, one of the largest overlay vendors, to pay $1 million for deceptive advertising. The company had claimed its product would “automatically comply” with WCAG 2.1 AA, and specifically that it made a site compliant with 30 percent of WCAG requirements immediately and the remaining 70 percent within 48 hours via AI. The FTC’s final order, approved in April 2025, bars the company from claiming its automated product can make any website WCAG compliant unless it can prove it.
The deeper problem is that overlays operate on the rendered page after the fact. They cannot fix markup that was wrong to begin with. They cannot write alt text that understands what your photo is actually showing. In some cases they interfere with the screen readers people already use, which is why several hundred accessibility practitioners and disabled users have signed the Overlay Fact Sheet opposing them.
We do not install them. If an agency quotes you accessibility and the deliverable is a widget, you are paying for the appearance of compliance, which is the one thing that helps nobody.
What ADA compliance costs
There is no flat number, and anyone quoting you one without looking at your site is guessing.
The cost is driven by what you already have. A small site built on clean, semantic markup might need contrast adjustments, alt text, and a few form fixes, and that is a modest amount of work. A large site built on a page builder with nested markup, sliders, custom-styled dropdowns, and a decade of accumulated content is a different conversation entirely, because the fixes are structural rather than cosmetic.
Two things reliably make it cheaper. Building it in from the start, which costs almost nothing extra because accessible markup is just good markup. And catching problems while there are ten of them instead of a thousand.
Two things make it expensive. Retrofitting a site that was never built with it in mind, and finding out on a deadline.
Is my website ADA compliant? How to check
You can get a rough answer in about ten minutes, for free.
Run a page through WAVE or Lighthouse in Chrome’s developer tools. Both will flag missing alt text, contrast failures, missing form labels, and heading structure problems. Start with your homepage, then check a contact page and one page with a form, because forms are where the serious failures usually live.
Then do the part the tools cannot do. Put your mouse away and tab through the page with your keyboard. Can you reach every link and button? Can you see where you are at all times? Can you open and close the navigation? Can you fill out and submit a form? If you get stuck or lose track of the focus indicator, so does everyone who navigates that way.
Here is the honest caveat, and it is the reason automated scores mislead people. Automated tools catch only a portion of WCAG issues, and Lighthouse says so in its own documentation. They can tell you an image has no alt text. They cannot tell you the alt text says “image1.jpg” or describes the wrong thing. They can flag a missing label. They cannot tell you your error message is useless. A perfect score means you cleared the machine-checkable portion, which is worth doing and is not the same as being accessible.
If you want a person to look at it, that is something we do. We will tell you what actually needs fixing and what can wait, and we will not sell you a widget.
One last thing
Accessibility has a reputation as a compliance chore, and the framing is backwards. The CDC estimates that about one in four US adults lives with some kind of disability. Most of them will not tell you your site did not work. They will just leave, and you will never see it in your analytics.
Build it so they do not have to.
