skip to content

ADA Website Compliance

ADA website compliance means your website works for people with disabilities, and that you can show it. In plain words: what the Act asks of a website, which title applies to you, the WCAG 2.2 AA standard courts keep pointing to, what non-compliance costs, and how compliance is actually achieved and documented.

A man in a wheelchair working at a desktop computer, with a city street visible through the window behind him.
Which title covers you decides the deadline you work to and the standard you are judged against.

The law

Which part of the ADA applies to you

The ADA splits into titles. Two of them decide how a website is judged, and the difference matters because only one currently has a fixed deadline and a named technical standard.

Title II: public bodies

State and local government, public universities, transit authorities and the bodies they fund. The DOJ rule of April 2024 names WCAG 2.1 Level AA and sets compliance deadlines by population size.

Title III: businesses

Private businesses serving the public: retail, hospitality, banking, healthcare, education and online-only sellers. No published technical rule, so courts apply WCAG as the working standard.

Section 508: federal

Federal agencies and the vendors selling to them. Procurement usually asks for a VPAT, an accessibility conformance report written against the standard.

Outside the USA

EN 301 549 in Europe, AODA in Ontario and the Equality Act in the United Kingdom all point back to WCAG, so one body of work satisfies several jurisdictions.

A developer in a wheelchair at a desk with two monitors showing lines of code.
WCAG is written as testable criteria, which is exactly why courts and procurement teams keep pointing to it.

The standard

WCAG 2.2 Level AA, and what it asks for

WCAG is the standard every one of these laws points to. It is organised under four principles. The accordion below explains each one in ordinary words, with the failures I find most often on real client sites.

Perceivable: people must be able to take the information in

Content cannot depend on one sense alone. Images need text alternatives that say what the image conveys. Video needs captions, and audio needs a transcript. Colour cannot be the only way meaning is carried, and text must have enough contrast against its background: 4.5 to 1 for normal text, 3 to 1 for large text.

Most common failures I find: decorative images given long descriptions while meaningful images get none; pale grey helper text at 2.8 to 1; form errors shown only in red with no words; sliders with text baked into the image.

Operable: people must be able to use the controls

Everything that works with a mouse must work with a keyboard alone, in a sensible order, with a focus ring you can actually see. Nothing may trap the keyboard. Time limits need a way to extend them. Motion and flashing must be controllable.

Most common failures I find: custom dropdowns built from divs that a keyboard cannot reach; focus outlines removed for looks; carousels that auto-advance with no pause; modal dialogs that let focus wander behind them.

Understandable: people must be able to make sense of it

The page language must be declared. Navigation must stay in the same place from page to page. Form fields need visible labels that remain visible while typing, and errors must say what went wrong and how to fix it.

Most common failures I find: placeholder text used instead of a label, so the prompt vanishes the moment you type; error messages that say only “invalid”; a menu that reorders itself between templates.

Robust: it must work with assistive technology

Markup must be valid, and every component must expose its name, its role and its current state to a screen reader. Status messages must be announced without stealing focus.

Most common failures I find: buttons made from spans with no role; accordions that never announce whether they are open; live regions missing, so a cart update is silent; ARIA added on top of broken HTML, which usually makes things worse.

A person in a wheelchair facing a large screen, with a lit city skyline behind them.
Most businesses meet the ADA through a letter rather than a plan. Arriving the other way round costs far less.

The risk

What non-compliance actually costs

Most businesses hear about ADA compliance through a letter, not through a plan. It helps to know what that path looks like before you are on it.

  • A demand letter. A law firm writes claiming your site is inaccessible and offers to settle. Typical settlements run into five figures, and the letter usually arrives with a short deadline attached.
  • A federal lawsuit. Thousands of website accessibility cases are filed in United States federal courts every year, concentrated in retail, food service and healthcare. Defending one costs more than fixing the site.
  • Lost customers. Roughly one in four adults in the United States lives with a disability. A checkout a screen reader cannot complete is revenue you never see, and you never find out why.
  • Weaker search results. Headings, alternative text, link names and semantic structure serve Google as well as screen readers. Sites that fix accessibility routinely see search performance improve alongside it.
A wheelchair user working on a laptop at a cafe table.
ADA compliance is judged by whether a disabled visitor can finish the task, not by an automated score.

The route

How compliance actually happens

Four steps, all documented in writing, so at any moment you can show what was found, what was fixed and what remains. This is the same sequence I follow for a government portal or a small shop.

  1. Audit

    Every template and key user journey tested by hand with JAWS, NVDA, VoiceOver, TalkBack and keyboard alone, at 200 and 400 percent zoom and in forced colours. You receive a report listing each barrier, the criterion it fails, where it appears and how to fix it.

  2. Prioritise

    Barriers are ranked by user impact and legal exposure, not by how easy they are. Anything blocking a purchase, an enquiry or a login is fixed first.

  3. Remediate

    Your developers apply the fixes, or I apply them. Every change is described in writing so nothing depends on a conversation somebody half remembers.

  4. Re-test and record

    Fixes are verified, the report is reissued showing before and after, and you get an accessibility statement you can publish. That document is what turns work into evidence.

Seen from behind, a person in a wheelchair working at a desk with code on two screens.
Most of what people believe about ADA compliance comes from sales pages, not from the law.

Common questions

Myths worth clearing up first

“We are small, so nobody will notice us”

Firms that file these claims work from automated scans of thousands of sites at a time. Size is no shield, and small businesses receive demand letters constantly. A small site is also cheaper to fix, which is the better argument for doing it now.

“Our developers already made it accessible”

Good developers help enormously, but automated tools catch roughly a third of real barriers, and most teams have never watched someone use their site with a screen reader. The gap is almost never in intent; it is in testing.

If you want to see the difference, read the published case studies and look at what was found on sites that were already considered done.

“We will add an accessibility widget”

Overlays do not fix the code underneath, and they have not prevented lawsuits. Some businesses have been sued while running one. If a vendor promises instant compliance from one line of JavaScript, treat that as a warning.

“We will do it after the redesign”

That is the right instinct if the redesign is soon, because building on an accessible theme avoids paying twice. If the redesign is a year away, an audit now still pays for itself, because the barriers you fix are mostly in content and templates you are keeping.

A technician in a wheelchair working on a laptop in a server room.
Audit, prioritise, remediate, verify. The same sequence for a government portal or a small shop.

Working together

What I do, and what it costs

I am Shivaji Mitra, a DHS Trusted Tester certified accessibility consultant, running M/S. Anblik since 2003 with IAAP certified colleagues. I work in writing rather than meetings, which keeps a clear record for you and your lawyer.

Accessibility audit

A full manual audit against WCAG 2.2 AA with a report you can hand to developers or to counsel. Pricing depends on how many templates and journeys are in scope, and I quote in writing within one working day.

Remediation

The fixes applied and confirmed, either by my team or alongside yours, with every change documented.

VPAT and Section 508

An accessibility conformance report for procurement, written against Section 508 and EN 301 549.

Monitoring

Periodic re-testing so a plugin update or a new landing page does not quietly undo the work.

A man in a wheelchair working on a laptop at a table in a busy cafe.
These are the questions business owners ask before they commission anything.

FAQ

ADA website compliance – frequently asked questions

Does the ADA actually apply to websites?

The ADA does not name websites in its text, because it was written in 1990. Courts and the Department of Justice have consistently treated websites as covered, and in April 2024 the DOJ issued a rule under Title II that names WCAG 2.1 Level AA as the technical standard for state and local government. For private businesses under Title III, courts have repeatedly held that a website connected to a place of public accommodation must be accessible. In practice, if the public can buy from you, book with you or apply to you online, plan on being covered.

What is the difference between Title II and Title III?

Title II covers state and local government bodies, including public universities, transit authorities and anything they fund. It now has a fixed deadline and a named standard. Title III covers private businesses that serve the public: shops, restaurants, banks, clinics, hotels, online retailers. Title III has no published technical rule, so courts use WCAG as the yardstick.

Which WCAG version should we build to?

Build to WCAG 2.2 Level AA. The Title II rule names 2.1 AA as the floor, but 2.2 is the current W3C recommendation and adds criteria that matter on real sites, such as visible focus, dragging alternatives and consistent help. Meeting 2.2 AA means you also meet 2.1 AA.

Will an accessibility overlay or widget make us compliant?

No. Overlays sit on top of your code and cannot fix the underlying markup. They have not stopped lawsuits, and thousands of accessibility practitioners have signed a public statement against them. Some businesses have been sued after installing one. Real remediation changes the code.

What happens if we receive a demand letter?

Do not ignore it and do not reply promising a fix you have not scoped. Get an independent audit so you know the real position, then send your lawyer a documented remediation plan with dates. Most matters settle, and settling is far cheaper when you can show work already underway.

How long does it take to become compliant?

For a typical brochure or small e-commerce site, an audit takes one to two weeks and remediation four to eight weeks depending on how much is broken and how quickly your developers can act. Large sites and complex applications take longer, and the honest answer only comes after the audit.

Is compliance a one-time project?

No. Every new page, plugin, theme update or third-party script can introduce a barrier. Compliance is a state you keep, which is why monitoring and periodic re-testing exist.

Next step

Find out where you actually stand

Send your website address. Within one working day you get a written reply naming the barriers I can already see, which ADA title applies to you, and what putting it right involves.