ADA Website Compliance: What the Law Actually Says and the Audit Our Developers Run

What ADA website compliance means in plain English

ADA website compliance means a person who is blind, deaf, has low vision, cannot use a mouse or has a cognitive disability can find information and complete the same tasks on your site as anyone else. Booking, buying, calling, filling a form and reading your policies all count.

The Americans with Disabilities Act was written in 1990, before business websites existed. Courts and the Department of Justice have since treated websites as part of how businesses serve the public. According to the Department of Justice web accessibility guidance on ADA.gov, a website with inaccessible features "can limit the ability of people with disabilities to access a public accommodation's goods, services, and privileges."

That is the whole idea. The law cares about access to your goods and services, not about a badge or a score. A site can pass a scanner and still block a screen reader user from submitting a quote request. A site can also have minor technical errors that never stop anyone. The goal is real access, and the way you show it is a recognized standard plus evidence that you tested against it.

Who has to follow ADA website compliance rules

Two parts of the ADA matter for websites. Title III covers businesses open to the public. Title II covers state and local governments. The rules for each are different, and many business owners mix them up.

Businesses: flexibility, not freedom

DOJ's guidance lists retail stores, banks, hotels, hospitals and medical offices, restaurants, and theaters as examples of public accommodations. It says plainly that DOJ "does not have a regulation setting out detailed standards," and that businesses have flexibility in how they comply. It points to WCAG and the Section 508 standards as helpful guidance.

Flexibility cuts both ways. You get to choose how you make the site accessible, but you still have to make it accessible. In practice, almost every audit, settlement and accessibility statement we read measures against WCAG Level AA, so that is the target we build to.

Governments: a firm rule with new dates

DOJ's 2024 rule for state and local governments sets WCAG 2.1 Level AA for their web content and mobile apps. According to the Title II web rule fact sheet, an interim final rule published April 20, 2026 extended the compliance dates: April 26, 2027 for governments serving 50,000 or more people, and April 26, 2028 for smaller governments and special districts. If you sell software or build content for a city, county or school district, those dates apply to what you deliver.

WCAG 2.1 vs 2.2: which version to build to

Build new work to WCAG 2.2 Level AA. It includes almost everything in 2.1, adds a few criteria that help mobile and older users, and became a W3C Recommendation on October 5, 2023. If a contract or regulation names 2.1, meeting 2.2 AA covers it.

WCAG is organized under four principles: content must be perceivable, operable, understandable, and built so assistive technology can read it reliably. Each success criterion has a level. Level A is the floor, Level AA is the standard almost everyone means, and Level AAA is a stretch goal that is not realistic for whole sites.

What WCAG 2.2 added at Level A and AA

The W3C summary of what is new in WCAG 2.2 lists nine new criteria. These six apply at Level A or AA:

WCAG 2.2 also removed 4.1.1 Parsing as obsolete. Small business sites trip over target size and focus most often: tiny social icons in the footer and sticky headers that hide the focused link.

The 14-check ADA website compliance audit we run

Our audit pairs an automated scan with a person working through the site using only a keyboard, then a screen reader, then 200% zoom on a phone. The scan finds the easy-to-detect errors quickly. The manual passes find the barriers that actually stop people. DOJ's own guidance warns that a "clean" report does not necessarily mean everything is accessible.

We run these 14 checks on a sample that covers every template (home, service, location, blog post, contact) plus every page with a form, booking flow, checkout or login. The criterion numbers refer to the WCAG 2.2 specification.

What the scan alone misses

Automated tools are good at missing alt attributes, low contrast and empty links. They cannot tell whether alt text is accurate, whether the reading order makes sense, whether a booking calendar works by keyboard, or whether an error message is announced. Those are the problems that turn into lost customers and complaints, which is why half our audit time is manual.

Why accessibility overlays are not ADA website compliance

An overlay is a script that adds a toolbar or "AI" layer on top of your existing site. It does not fix the underlying code, so it cannot make a site conform to WCAG by itself. Many disabled users already have their own assistive technology and find overlays get in the way.

Regulators have taken note. In January 2025 the Federal Trade Commission ordered one overlay vendor to pay $1 million over claims that its AI tool could make any website compliant with WCAG. The order bars the company from making those claims without evidence. That does not mean every widget is useless, but it does mean you should never treat a widget as your compliance plan.

The fix lives in the templates, the content and the components. A missing form label has to be added to the form. Low contrast has to be fixed in the CSS. A booking widget that traps keyboard focus has to be replaced or repaired. This is one of the reasons we explain why we hand-code sites with no page builders: we control the markup, so we can fix accessibility at the source instead of layering scripts on top.

How to fix what the audit finds, in priority order

Fix the barriers that block a task first, then the barriers that slow people down, then the polish. A screen reader user who cannot submit your contact form is blocked. A slightly vague link label is an annoyance. Both matter, but not equally.

Template fixes go furthest

Because most sites reuse a handful of templates, one fix to the header menu or the form component can clear the same issue on hundreds of pages. On large sites we fix the components first and rerun the sample, then turn to page content. Our web development team handles template and component work; content fixes such as alt text and captions can often be done by your own team once the templates are sound.

PDFs and third-party tools

PDF menus, intake forms and price sheets are frequent problems. Where you can, publish the content as a real web page instead. Third-party booking, chat and payment tools are your responsibility from the customer's point of view, so ask vendors for their accessibility documentation and test them yourself before you embed them.

A worked example: auditing a small medical office site

Here is how the audit plays out on a typical site, using a hypothetical 40-page medical office website with a home page, ten service pages, a location page, a blog, an online intake form and an embedded appointment widget.

1. Sample. We test one page of each template plus the intake form and booking flow: about eight pages in all, which covers every pattern on the site.
2. Scan. The automated pass flags low contrast on the teal buttons, 60 images with missing alt attributes and two empty links in the footer.
3. Keyboard pass. The mega menu opens only on hover, so keyboard users cannot reach the service pages. The appointment widget traps focus after the date picker.
4. Screen reader pass. The intake form fields have placeholder text but no labels, so a screen reader announces "edit text" eight times. Errors appear in red with no text.
5. Zoom and phone pass. At 200% zoom the sticky header covers a third of the screen and hides the focused field.

The fix order follows the priority table: intake form labels and error text first, then the booking widget (repair or replace), then the menu and sticky header in the template, then button contrast, then alt text across the content. The scan found the contrast and alt text. Only a person found the four problems that actually stopped patients from booking.

Keeping ADA website compliance from slipping

A site that passes an audit in March can fail by June. Every new page, blog image, PDF, video, plugin and embedded tool can add barriers. ADA website compliance holds only when accessibility is part of how you publish, not a one-time project.

The publishing checklist we give clients

• Every new image gets alt text written by a person who knows what it shows.
• Every video goes up with edited captions.
• Headings come from the editor's heading styles, never bold text sized up.
• Links say where they go: "see our pricing policy," not "click here."
• New forms reuse the accessible form component instead of a new plugin.
• Any new third-party widget is tested by keyboard before it goes live.

A light ongoing routine

• Monthly: automated scan of the full site, with new issues assigned.
• Quarterly: a keyboard and screen reader pass on the money paths: contact, booking, checkout.
• After any redesign, plugin or vendor change: a full template audit.

Our website care plans include monitoring like this so issues are caught when they are small. Speed and accessibility often share fixes, too: clean markup and fewer scripts help both, which we cover in our Core Web Vitals guide and our technical SEO checklist.

The accessibility statement and your paper trail

An accessibility statement tells visitors what standard you aim for, what you know is not yet fixed, and how to get help or report a problem. It does not make a site compliant, but it gives people a way to reach you and shows the work is real.

What a useful statement includes

1. The standard you are working toward, such as WCAG 2.2 Level AA.
2. The date of your most recent audit and what it covered.
3. Known limitations and when you expect to fix them, including third-party tools.
4. A phone number and email that a real person monitors, with an alternative way to complete key tasks.
5. The date the statement was last updated.

Keep the records

Save each audit report, the list of issues, who fixed what and when, and the retest results. If anyone ever questions your site, a record of steady, documented progress is far more useful than a badge in the footer. Keep the statement honest. Claiming full conformance you have not tested is its own risk, and the FTC case above shows that regulators look at accessibility claims.

Fix the current site or rebuild for ADA website compliance?

Fix the current site when the problems are content and a few components. Rebuild when the theme or page builder generates inaccessible markup you cannot change, or when the site needs a rebuild for other reasons anyway.

Our website improvement service handles the first column: an audit, a prioritized fix list and the code changes. When a rebuild makes more sense, our web design and development team builds accessibility into the templates from the start, inside our wider websites practice. Accessible forms and clear pages also tend to lift leads, which is the subject of our guide to improving website conversion rate.

We work with businesses across the country from New Jersey and South Florida, including web design in New Jersey and web design in Fort Lauderdale. If you want to know where your site stands, send us your URL and we will tell you what a full audit would cover and which issues look most urgent. Large sites are where process matters most: for Nusbaum Medical Centers we manage 3,066 live pages, the kind of scale where a fix made once in a template reaches every page built on it.

ADA website compliance questions, answered