What the ADA requires of your website in 2026

The short answer

ADA website accessibility requirements depend on who you are. State and local governments have a specific rule: their websites and mobile apps must meet WCAG 2.1 Level AA, and as of 2026 the compliance dates are April 26, 2027 for governments serving 50,000 or more people and April 26, 2028 for smaller ones. Private businesses open to the public fall under Title III of the ADA, which has no detailed technical rule for websites, but the Department of Justice says the ADA applies to goods and services offered online, and courts see thousands of website lawsuits each year.

For a private business, the practical target is WCAG 2.1 Level AA, with WCAG 2.2 as the current best practice. This article is general information, not legal advice; confirm your obligations with your attorney.

Title II: the rule for state and local governments

In April 2024 the Department of Justice published a rule under Title II of the ADA. It covers state and local governments, their agencies, special districts and public transit, and it requires their web content and mobile apps to meet WCAG 2.1 Level AA. It also applies to content that private contractors build or run for a government, such as a county’s park reservation site.

The original deadlines were April 24, 2026 for larger governments and April 26, 2027 for smaller ones. On April 20, 2026, DOJ issued an interim final rule that pushed both back by one year:

• Population of 50,000 or more: April 26, 2027.
• Population under 50,000, and special district governments: April 26, 2028.

The extension changed only the timing. The technical standard, WCAG 2.1 AA, stayed the same. DOJ also signaled it plans further review, so check the current status before you plan around these dates.

The rule has limited exceptions, including archived content that is no longer updated, some documents posted before the compliance date, and content posted by third parties. Even then, governments must still provide effective communication on request.

Why private businesses should pay attention

If you build, host or run a website or app for a city, county, school district or other public body, your work likely has to meet WCAG 2.1 AA under the contract. Expect it to show up in requests for proposals and contract language.

Title III: the rule for private businesses

Title III covers businesses open to the public: stores, restaurants, medical and dental offices, law firms, hotels, gyms and many others. DOJ’s web guidance says the ADA’s requirements apply to all the goods, services and privileges a business offers, including on the web, but that DOJ “does not have a regulation setting out detailed standards.” Businesses have flexibility in how they comply, and DOJ points to WCAG and the federal Section 508 Standards as helpful guidance.

In practice, lawsuits and settlements set the bar. Most cite WCAG 2.1 Level AA. According to Seyfarth Shaw’s annual count, 3,117 federal lawsuits about inaccessible websites were filed in 2025, up 27% from 2024, and that number does not include state court cases or demand letters settled privately.

State laws can add to the federal picture. In California, for example, courts have applied the state’s Unruh Civil Rights Act to inaccessible websites, and that law allows money damages that the ADA’s Title III does not. If you sell to customers in several states, your exposure is not limited to where your office is.

Businesses most often targeted include online stores, restaurants, hotels and service businesses with online booking, but any public-facing site can draw a claim.

WCAG 2.1 vs WCAG 2.2: which should you follow?

WCAG is published by the World Wide Web Consortium. Level AA is the middle of three levels and the one laws and lawsuits use.

• WCAG 2.1 is the standard in the Title II rule and the one most legal claims cite.
• WCAG 2.2 was published in October 2023 and adds nine success criteria, such as larger touch targets, focus that is not hidden behind sticky headers, and login steps that do not rely on memory puzzles.
• WCAG 2.2 is backwards compatible. A site that meets 2.2 also meets 2.1 and 2.0.
• WCAG 3 is still an early draft and not something to build to yet.

Decision rule: if you are building or redesigning now, aim for WCAG 2.2 AA. It costs little extra and covers 2.1.

What WCAG AA asks for, in plain English

• Text alternatives. Images that carry meaning have alt text; decorative images are marked so screen readers skip them.
• Keyboard access. Every menu, button, form and pop-up works with a keyboard alone, with a visible focus outline.
• Color contrast. Body text has at least a 4.5:1 contrast ratio with its background.
• Forms. Every field has a label, errors are explained in text, and required fields are clear.
• Headings and structure. Pages use real headings in order so screen-reader users can skim.
• Video and audio. Captions for video; transcripts for audio.
• Resizing. Text can be zoomed to 200% and the page still works on a narrow screen.
• Link text. Links describe where they go, not “click here.”
• Documents. PDFs and other files people need are accessible too, or offered in an accessible format.
• Time limits and motion. Users can pause carousels and extend time limits.

How to check and fix your website

1. Run an automated scan. Free tools such as WAVE or Lighthouse catch issues like missing alt text and low contrast. Automated tools find only part of the problems, so do not stop here.
2. Test by hand. Tab through your key pages with the keyboard only. Try a screen reader on your contact form and checkout.
3. Prioritize the paths that matter. Home page, main service or product pages, contact and booking forms, and checkout.
4. Fix the templates. Most problems repeat across pages, so fixing the header, footer and page templates fixes many pages at once.
5. Publish an accessibility statement. Say what standard you aim for and how people can reach you if something does not work.
6. Retest after changes. New content and plugins can undo good work. Check after each redesign and periodically after that.

Not sure where your site stands? Book a free 30-minute call. We’ll look at your site and tell you what we’d fix first, no obligation.

Questions to ask your web developer

Whether you are redesigning or keeping your current site, these questions show quickly whether accessibility is being handled or assumed:

• Which standard are you building to: WCAG 2.1 AA or 2.2 AA? Will that be written into the contract?
• How do you test: automated tools only, or also keyboard and screen-reader testing by a person?
• Are the theme, page builder and plugins you use known to produce accessible output?
• Will our forms, booking tools and checkout be tested, including third-party widgets?
• How will our team keep new pages, images and PDFs accessible after launch?
• What do you deliver at the end: a list of issues found and fixed, and an accessibility statement?

Third-party tools deserve special attention. Chat widgets, booking calendars, payment pages and embedded maps are often where barriers hide, and they are part of the experience your customers have on your site.

Do accessibility overlays make you compliant?

Overlays are scripts that add an accessibility toolbar to a site. They can help some visitors adjust text size or contrast, but they do not fix the underlying code, such as missing form labels or keyboard traps. Plaintiffs have sued businesses that used overlays. Treat an overlay as optional extra, never as a substitute for fixing the site.

Where JLB USA fits

JLB USA performs Section 508 accessibility audits and builds custom WordPress and e-commerce sites with accessibility in the templates from the start. If your current site needs work, we can audit it, fix the templates and forms, and show you how to keep new content accessible. See our web design services and before and after examples. For legal questions about your obligations, talk to your attorney.

Related services

• Web design services
• Website before and after
• Hosting and support