Website Accessibility: What ADA Compliance Actually Requires

Updated August 2026. This article previously recommended an accessibility overlay widget. It no longer does. Overlays do not make a website compliant, and in 2025 the U.S. Federal Trade Commission took enforcement action over marketing claims that an AI-powered accessibility overlay could make websites WCAG-compliant. What follows is the approach we actually use.

Ever wonder what the legal accessibility — or “ADA compliance” — requirements are for websites? It matters because people with disabilities should have equal access to information. After working with a number of government clients, I kept running into this question, so I took a deeper dive.

The short answer: there is no plugin that makes your website compliant. Accessibility is a property of how a site is built, not something you can bolt on. The longer answer is below.

What the ADA actually says about websites

The Americans with Disabilities Act was signed in 1990, before the web was a mainstream way of doing business, so it does not name websites directly. What has changed is how the Department of Justice interprets and enforces it.

Two different rules apply depending on who you are:

• State and local government (ADA Title II). In April 2024 the DOJ published a final rule adopting WCAG 2.1 Level AA as the technical standard for web content and mobile apps, with compliance dates in 2026 and 2027 depending on the size of the entity. If you are a public agency, the requirement is now explicit and dated.
• Private businesses (ADA Title III). There is still no federal rule naming a specific technical standard. The DOJ’s position is that the ADA applies to the websites of places of public accommodation, and its web accessibility guidance points to WCAG. In practice, WCAG 2.1 AA is the benchmark used in settlements and demand letters.

So for most businesses the honest answer is: no statute names a number, but WCAG 2.1 AA is the standard you will be measured against if anyone ever asks.

The standard to build to: WCAG

The Web Content Accessibility Guidelines are published by the W3C. WCAG 2.1 Level AA is what regulations cite; WCAG 2.2 is the current version and is backwards compatible, so building to 2.2 keeps you ahead.

WCAG is organised around four principles, usually shortened to POUR. Content must be Perceivable, Operable, Understandable and Robust. Nearly every practical check below maps back to one of those.

Why overlays and plugins do not solve it

An overlay is a script you paste before the closing body tag that adds a floating accessibility button and tries to patch problems in the browser. The appeal is obvious: one snippet, no rebuild. The problem is that it cannot repair the things that actually block people.

• Automated tooling can only detect a minority of WCAG success criteria. Things like whether alt text is meaningful, whether link text makes sense out of context, or whether a custom component is usable by keyboard require human judgement.
• An overlay cannot restructure your headings, fix your colour contrast decisions, add real labels to form fields, or caption your videos.
• Many screen reader users report that overlays interfere with the assistive technology they already use and have configured.
• Installing one does not remove legal exposure. Businesses using overlays have still received demand letters.

None of that makes the vendors villains, and an overlay is not automatically harmful. It just is not compliance, and it should not be sold as such.

A practical accessibility checklist

This is roughly the order we work through on a build. None of it requires a plugin.

• Images. Every meaningful image has alt text describing its purpose. Decorative images get an empty alt="" so screen readers skip them.
• Headings. One h1 per page, then h2 and h3 in a logical order. Do not pick heading levels for their size — style them instead.
• Colour contrast. At least 4.5:1 for body text and 3:1 for large text and meaningful icons. This is the single most common failure we find, and it is usually a brand palette problem rather than a code problem.
• Colour is never the only signal. Errors, required fields and states need text or an icon too, not just red.
• Keyboard. Every interactive element reachable and operable with Tab, Enter and arrow keys. Nothing traps focus. The focus indicator stays visible — never remove outlines without replacing them.
• Forms. Real <label> elements tied to inputs. Placeholder text is not a label. Errors explain what went wrong and how to fix it.
• Links and buttons. Text that means something on its own. “Read more” five times on a page tells a screen reader user nothing.
• Media. Captions on video, transcripts for audio. Nothing auto-plays with sound.
• Motion. Respect prefers-reduced-motion, and give users a way to pause anything that moves or loops.
• Structure and language. Set the page language, use landmarks and lists correctly, and make sure the page still makes sense at 200% zoom and on a phone.

How to actually test it

Automated scanners are useful for catching the obvious mechanical failures, and useless for everything else. Use them first, then test by hand:

• Run a scanner such as axe DevTools, WAVE or Lighthouse to clear the easy failures.
• Unplug your mouse and navigate the whole page with the keyboard alone.
• Turn on a screen reader — VoiceOver on Mac and iOS, NVDA on Windows — and listen to your own homepage and contact form.
• Zoom the browser to 200% and check nothing is cut off or overlapping.
• Check contrast on your actual brand colours, not on a template’s defaults.

The W3C’s evaluation guidance covers this in more depth if you want a formal process.

Where this leaves you

If you are a government organisation, treat WCAG 2.1 AA as a dated requirement and plan for it. If you are a private business, treat it as the standard you will be judged against, and as something worth doing regardless — an accessible site is easier to use, works better on phones, and tends to be better structured for search engines as a side effect.

What you should not do is paste in a widget and consider it handled.

This article is general information, not legal advice. If you have a specific compliance obligation or have received a demand letter, talk to a lawyer.