ADA and WCAG Accessibility for US Business Websites and Apps

Businesses open to the public (Title III)

DOJ's guidance on web accessibility and the ADA, published March 18, 2022, says the ADA's requirements apply to all the goods, services, privileges and activities of public accommodations, including those offered on the web. It gives businesses flexibility in how they comply, but says they must still make what they offer online accessible to people with disabilities. It names existing technical standards, WCAG and the Section 508 Standards, as helpful guidance. No Title III regulation sets a specific web standard.

State and local governments (Title II)

DOJ's 2024 rule for state and local government web content and mobile apps adopts WCAG 2.1 Level AA as the technical standard. An interim final rule published April 20, 2026 extended the compliance dates: April 26, 2027 for entities with a total population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments.

If you sell software or digital services to cities, counties, school districts or public universities, this rule reaches you through procurement. Expect contracts and RFPs to ask for WCAG 2.1 AA conformance and evidence of testing.

Which WCAG version to build to

WCAG 2.2 became a W3C Recommendation on October 5, 2023. W3C's summary of what is new in WCAG 2.2 lists nine added success criteria, six of them at Levels A and AA, and removes 4.1.1 Parsing as obsolete; otherwise the 2.0 and 2.1 criteria are essentially the same. Building new work to WCAG 2.2 AA covers nearly everything 2.1 AA asks for, plus practical additions such as a minimum target size for controls.

Accessibility overlays promise compliance through one line of JavaScript. In January 2025 the FTC announced an order requiring accessiBe to pay $1 million over allegations that it misrepresented its AI tool's ability to make any website WCAG-compliant; the order became final in April 2025. The lesson for buyers is practical: a script layered on top cannot repair inaccessible markup, missing form labels or a checkout that traps keyboard users. Those fixes live in your code.

A design and development checklist for the most common failures:

• Text alternatives: meaningful alt text for informative images, empty alt text for decorative ones.
• Color contrast: at least 4.5:1 for normal text and 3:1 for large text, and never color alone to show an error or a status.
• Keyboard access: every link, button, menu and form control reachable and usable with the keyboard, in a logical order, with no traps.
• Visible focus: a clear focus indicator that sticky headers and cookie banners do not hide.
• Forms: visible labels, instructions before the field, and error messages that say what went wrong and how to fix it.
• Structure: a unique page title, headings in order, and landmarks for navigation and main content.
• Media: captions for video and transcripts for audio.
• Target size: controls at least 24 by 24 CSS pixels, or spaced so they do not crowd each other, under WCAG 2.2.
• Authentication: no login step that depends on memorizing or retyping a code unless there is help, such as allowing paste or a password manager.
• Mobile apps: labels for VoiceOver and TalkBack, support for larger system text, and a simple alternative to every complex gesture.
• Documents: PDFs and downloadable forms tagged and readable, or offered as accessible HTML instead.

Use three layers, because each catches different problems:

• Automated scanning with tools such as axe, Lighthouse or WAVE, run on every build. They find missing labels, contrast failures and structural errors quickly, but many WCAG criteria need human judgment.
• Manual review by someone trained: keyboard-only walk-throughs of key journeys, zoom to 200% and 400%, and screen reader passes with NVDA or JAWS on Windows, VoiceOver on Mac and iOS, and TalkBack on Android.
• Testing with disabled users on the journeys that matter most to revenue: sign-up, search, checkout, booking and account management.

Record results against specific WCAG success criteria, with screenshots and steps to reproduce. If you sell to businesses or governments, that record becomes the basis of an Accessibility Conformance Report, which buyers often request in the ITI VPAT format.

Start with what is shared. Most sites are built from a few dozen templates and components, and fixing a button, form field or navigation component once fixes every page that uses it. A workable order:

• Audit a representative sample: home page, a listing page, a detail page, every form, checkout or booking, account pages and the most-downloaded PDFs.
• Fix shared components and templates first.
• Fix the revenue-critical journeys next.
• Fix content: alt text, link text, headings and captions. Train the people who publish content, or the problems come back.
• Add automated accessibility checks to your build pipeline, and accessibility acceptance criteria to every new user story.
• Publish an accessibility statement with a way for users to report problems, and answer those reports.

As a rough planning range, an audit and component fixes for a mid-sized marketing site take 4–8 weeks. A large web application with complex forms takes longer and is best handled in releases.

Accessibility costs least as a design requirement, not a retrofit. In UI/UX design, that means a design system with accessible color pairs, focus styles and component states defined before any screen is drawn. In web application development, it means semantic HTML first, ARIA only where native elements cannot do the job, and accessibility checks in code review and continuous integration.

DipanshuTech designs and builds web and mobile applications from Greater Noida, India, and has delivered projects in 15+ countries. We can design to WCAG 2.2 AA and test against it. We do not give legal opinions and do not hold an accessibility certification, so pair our work with your counsel's advice on legal risk.

Is there a legal web accessibility standard for private businesses?

Not in DOJ regulations, as of October 2026. DOJ says businesses must make online goods and services accessible, and points to WCAG and Section 508 as helpful standards.

Does WCAG 2.2 replace WCAG 2.1?

It extends it. The 2.1 criteria carry over almost unchanged, 4.1.1 Parsing is removed and nine criteria are added. Build new work to 2.2 AA.

Will an accessibility widget protect us?

A widget cannot fix inaccessible code. The FTC's 2025 order against one overlay vendor shows the risk of relying on claims that it can.

Do mobile apps count?

The Title II rule covers mobile apps explicitly. For businesses, DOJ's guidance covers goods and services offered on the web; hold your apps to the same standard.

We sell software to a city government. Does Title II apply to us?

The rule binds the government entity, which meets it partly through the products it buys, so expect WCAG 2.1 AA requirements in your contract.

If you need an audit of an existing site or app, or want accessibility designed into a new build, get in touch. After a short discovery call we will send a written scope and a fixed quote.