ADA accessibility for AI-built apps

As of October 10, 2026, no ADA regulation sets a technical standard for private businesses' websites, but the Department of Justice says the ADA applies to web content, and plaintiffs filed 3,117 website accessibility lawsuits in federal court in 2025, by Seyfarth Shaw's count. The yardstick in practice is the Web Content Accessibility Guidelines (WCAG) at Level AA. Most failures are ordinary: faint text, images with no description, unlabeled form fields, unnamed buttons and controls that need a mouse. A Lovable app is made of the same parts as any website. You can find most problems yourself in an hour with free tools and a keyboard, and fix many with plain prompts. An overlay widget is not a fix.

This guide is for US founders with a live or nearly live Lovable app: what the law says, which standard to aim for, how to test, prompts for common fixes, and why overlays do not work. Facts come from the DOJ, the W3C, the FTC, WebAIM, Seyfarth Shaw and the tool makers' own documentation, listed under Sources. This is general information, not legal advice.

Does the ADA apply to my website or app?

The DOJ thinks so. Title III of the ADA covers businesses open to the public, which the law calls public accommodations. The DOJ's guidance on web accessibility, published in March 2022, says the department has consistently taken the position since 1996 that the ADA applies to web content. It also says businesses have flexibility in how they comply, and points to WCAG and the federal Section 508 Standards as helpful guidance.

Its list of common barriers reads like an app bug list: poor color contrast, information shown only by color, images without text alternatives, videos without captions, unlabeled forms and mouse-only controls.

One rule does fix a standard, but not for private businesses. In April 2024 the DOJ adopted WCAG 2.1 Level AA for state and local government websites and mobile apps, under Title II. An interim final rule of April 20, 2026, moved the deadlines to April 26, 2027, for governments serving 50,000 people or more, and April 26, 2028, for the rest. It matters if you sell to them: the rule covers content a government provides through a contractor or vendor.

How many businesses get sued over website accessibility?

Thousands a year. Seyfarth Shaw's Kristina Launey and Minh Vu reported in March 2026 that plaintiffs filed 3,117 website accessibility lawsuits in federal court in 2025, up 27% from 2,452 in 2024. Those cases were 36% of all federal ADA Title III lawsuits that year. New York led with 1,021, then Florida with 961 and Illinois with 585.

Two limits: the count covers federal court only, not state courts, and the authors built it from keyword searches of Courthouse News Service data, noting that some cases may have been missed.

Which accessibility standard should my app meet?

Aim for WCAG 2.2 Level AA. The W3C published WCAG 2.2 as a Recommendation on October 5, 2023, and the current edition is dated December 12, 2024. Content that conforms to 2.2 also conforms to 2.1 and 2.0, so meeting 2.2 AA covers the 2.1 AA level the DOJ chose for governments. These are the criteria that matter most in a typical app:

What usually fails in an AI-built app?

The same things that fail across the web. WebAIM's 2026 scan of the home pages of the top one million websites found detectable WCAG failures on 95.9% of them, an average of 56.1 errors per page. The most common: low-contrast text on 83.9% of pages, missing image alt text on 53.1%, missing form labels on 51%, empty links on 46.3%, empty buttons on 30.6% and a missing page language on 13.5%. WebAIM adds that automated tools cannot detect every failure, so a clean scan does not prove a page is accessible.

Lovable builds apps with React and Tailwind CSS. In an app built that way, these are the places to check first:

• Icon-only buttons, such as a close X or a trash can, with no text name. A screen reader announces just "button".
• Clickable cards and rows built from plain containers, which Tab and Enter cannot reach.
• Focus outlines removed for looks with no visible replacement, which fails 2.4.7.
• Light gray text on white, and placeholder text standing in for a label.
• Form errors shown only as a red border, or in a toast that disappears.
• Pop-ups and drawers built by hand rather than from a dialog component, so keyboard focus wanders behind them.
• Headings picked for their size rather than their place in the page outline.
• Images, including AI-generated ones, with no alt text.
• Layouts that overflow or cut off text at 200% zoom.

Dialogs are the good news. Radix UI, which shadcn/ui components can be built on, says its Dialog traps focus inside while open, closes on Escape and needs a Title for screen readers. If your project's dialogs import from @radix-ui, that behavior comes built in. Hand-built modals are where it breaks.

How do you test your app's accessibility yourself?

1. 01Run Lovable's own reviewIn the editor, open More, then SEO & AI search, and run a review. Lovable's docs say it flags missing alt text, skipped heading levels and accessibility labeling issues, and its Lighthouse checks include accessibility. Running a review is free on all plans; applying fixes uses credits.
2. 02Run Lighthouse in ChromeOpen your live site in Chrome, open DevTools, choose Lighthouse and run the accessibility category. The score is a weighted average of automated pass-or-fail audits. Checks such as keyboard focus, logical tab order and trapped focus are listed as manual and do not affect the score, so 100 does not mean accessible.
3. 03Run WAVE or axe DevToolsWebAIM's WAVE extension for Chrome, Firefox and Edge evaluates the rendered page, works on password-protected pages, and sends nothing to WebAIM's server. Deque's free axe DevTools extension does a similar scan; Deque says it catches 57% of accessibility issues, which leaves the rest for a person to find.
4. 04Put the mouse awayUsing only Tab, Shift+Tab, Enter, Space and Escape, sign up, do the main task and pay. At every step you should see where focus is, open and close every menu and dialog, and land back where you started when a dialog closes.
5. 05Zoom to 200%Zoom the browser to 200% and repeat the main flow. Nothing should overlap, vanish or need sideways scrolling.
6. 06Ask a real userIf you can, ask someone who uses a screen reader daily to try your main flow. They will find things no tool does.

What can you ask Lovable to fix?

A lot, if you ask precisely. Paste these one at a time, and test with the keyboard after each:

• Keyboard: "Audit every interactive element. Replace any div or span with a click handler with a real button or link. Make sure every button, link, input and menu item can be reached with Tab and used with Enter or Space. Do not remove focus outlines; add a visible focus ring with at least 3:1 contrast against its background."
• Names: "Find every icon-only button and link, such as close, menu, delete, edit and social icons, and give each an accessible name that says what it does, for example 'Close dialog' or 'Delete invoice'."
• Forms: "Give every input a visible label connected to it. Do not use placeholder text as the only label. Mark required fields in text. When validation fails, show the error in text next to the field, connect it to the field with aria-describedby, and move focus to the first field with an error."
• Contrast: "Check all text and control colors against WCAG 2.2 AA: 4.5:1 for normal text, 3:1 for large text and for control borders and icons. Update the theme colors so muted, placeholder and secondary text still pass, and list every color you changed."
• Dialogs: "Make every modal, drawer and pop-up use the shadcn/ui Dialog or Sheet component, so focus stays inside while it is open, Escape closes it, focus returns to the button that opened it, and each has a title, visually hidden if needed."
• Structure: "Give every page exactly one h1 and use h2 and h3 in order without skipping levels. Set the page language to English. Add a 'Skip to main content' link as the first focusable element. Give decorative images empty alt text and meaningful images alt text that describes their purpose."
• Zoom: "Make every page work at 200% browser zoom and at 320 pixels wide without sideways scrolling or text being cut off."

Prompting cannot confirm the fix. A change to a shared component can break something else, so re-test the whole flow. Accurate alt text and video captions need a person who knows the content.

Do accessibility overlay widgets make you compliant?

No. An overlay is a script that promises to repair accessibility problems as the page loads, often with a toolbar of contrast and text-size controls. In April 2025 the FTC approved a final order requiring accessiBe, an overlay vendor, to pay $1 million. The FTC alleged that its claims that its accessWidget could make any website WCAG compliant were false, misleading or unsubstantiated. The order bars accessiBe from claiming its automated products can make any website WCAG compliant unless it has evidence to support the claim.

The Overlay Fact Sheet, signed by accessibility practitioners, explains why. Automated repair of alt text, form labels, error handling and keyboard access is not reliable, and component-based interfaces like React change the page in ways an overlay cannot keep up with. Its authors conclude that no overlay can make a site fully compliant with any accessibility standard, so none can remove legal risk. Fix the code instead.

When should you stop prompting and get help?

• You have received a demand letter or a lawsuit. Speak to a lawyer first, then fix the code.
• A government agency, school or large company asks for written evidence that your product meets WCAG 2.1 or 2.2 AA.
• Your app depends on complex controls, such as data tables, drag and drop, charts or rich text editors, that tools cannot judge.
• Accessibility fixes keep breaking other features, or the same issue comes back after three rounds of prompting.

Our vibe-coding rescue service takes on apps in this state, and the free production-readiness check shows your wider risks in a few minutes. Accessibility is one line of our business-side launch checklist for US founders, and our guide to testing an AI-built app covers how to keep fixes from regressing.

See pricing for what each plan covers.

Sources

All checked on October 10, 2026.

• U.S. Department of Justice: Guidance on Web Accessibility and the ADA, March 18, 2022, on Title III, flexibility and common barriers (ada.gov/resources/web-guidance).
• U.S. Department of Justice: Fact sheet on the Title II web rule, including the April 2026 interim final rule (ada.gov/resources/2024-03-08-web-rule).
• Seyfarth Shaw LLP, Kristina Launey and Minh Vu: Federal Court Website Accessibility Lawsuit Filings Bounce Back in 2025, March 27, 2026, as republished on JD Supra (jdsupra.com/legalnews/federal-court-website-accessibility-1182174).
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2, and What's New in WCAG 2.2, on dates, conformance and success criteria (w3.org/TR/WCAG22; w3.org/WAI/standards-guidelines/wcag/new-in-22).
• WebAIM: The WebAIM Million, 2026 report, on common failures (webaim.org/projects/million).
• Lovable documentation: Optimize your app for SEO and AI search, the changelog of May 18, 2026, and the Glossary (docs.lovable.dev/features/seo-aeo; docs.lovable.dev/changelog; docs.lovable.dev/glossary).
• Chrome for Developers: Lighthouse accessibility score, on scoring and manual checks (developer.chrome.com/docs/lighthouse/accessibility/scoring).
• WebAIM: WAVE browser extensions (wave.webaim.org/extension).
• Deque: axe DevTools browser extension (deque.com/axe/devtools/chrome-browser-extension).
• Radix UI: Dialog, on focus trapping, Escape and titles (radix-ui.com/primitives/docs/components/dialog).
• Federal Trade Commission: FTC Approves Final Order Requiring accessiBe to Pay $1 Million, April 22, 2025 (ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million).
• Overlay Fact Sheet, on automated repair and compliance (overlayfactsheet.com/en).