The short answer
Most website accessibility laws point to WCAG as the benchmark: the ADA in US courts, California's Unruh Act, the European Accessibility Act through EN 301 549, and Ontario's AODA. In practice that means text alternatives for images, labelled form fields, keyboard access with a visible focus, 4.5:1 text contrast, captions, a set page language and touch targets of at least 24 by 24 pixels.
Key takeaways
- WCAG 2.2 AA is the current W3C benchmark (October 2023). It adds focus visibility and target size requirements to WCAG 2.1.
- The ADA Title III has no DOJ web rule for private businesses; courts and DOJ guidance use WCAG as the measure.
- In California, an ADA violation is also an Unruh Act violation, with $4,000 minimum statutory damages.
- The European Accessibility Act has applied to consumer services such as e-commerce since 28 June 2025. Microenterprises providing services are exempt.
- On paid audits, SafeLaunch tests your live pages against WCAG 2.2 AA in a real browser and maps each failure to the law of every market you choose.
On this page
01
Which accessibility laws apply to my website?
| Law | Where | Applies to | Benchmark |
|---|---|---|---|
| ADA Title III | United States | Businesses open to the public, including many websites and apps | WCAG, through courts and DOJ guidance |
| Unruh Civil Rights Act | California | Businesses serving Californians | WCAG 2.1 AA; $4,000 minimum damages per violation |
| European Accessibility Act | European Union | E-commerce, banking, e-books, communications, transport and audiovisual services for consumers | EN 301 549, in practice WCAG 2.1 AA |
| AODA | Ontario, Canada | Organisations with 50+ employees and the public sector | WCAG 2.0 AA |
| WCAG 2.2 AA | Everywhere | Every website and app | The current W3C standard |
02
The 9 checks that catch most accessibility problems
| Check | WCAG | How to test in 2 minutes |
|---|---|---|
| Images have text alternatives | 1.1.1 | Every meaningful image has alt text; decorative images have alt="" |
| Form fields have labels | 1.3.1, 3.3.2 | Click each label: focus should move to its field. Placeholders aren't labels |
| Page language is set | 3.1.1 | The html element has a lang attribute, such as lang="en" |
| Text contrast at least 4.5:1 | 1.4.3 | Check light grey text and text on images with a contrast checker |
| Everything works with a keyboard | 2.1.1 | Unplug the mouse: Tab through sign-up and checkout to the end |
| Focus is visible and not hidden | 2.4.7, 2.4.11 | You can always see where you are; sticky headers don't cover the focused element |
| Touch targets at least 24×24 px | 2.5.8 | Small icon buttons and close buttons are big enough, or spaced apart |
| Video has captions | 1.2.2 | Pre-recorded video with speech has accurate captions |
| A way to report barriers | DOJ guidance; EAA Art. 13 | An accessibility statement with a contact |
03
A fix prompt for the most common failure
Unlabelled form fields are one of the most common failures on AI-built sites, because generated forms often lean on placeholder text. One prompt fixes them across the app:
Make this change without altering the visual design.
Give every input, select and textarea a visible <label> connected with
htmlFor/id (keep placeholders only as examples, not as labels). Mark required
fields in text, not only with colour. Make error messages text that a screen
reader announces (aria-live="polite") and link each one to its field with
aria-describedby.
Done when:
- Clicking any label moves focus to its field.
- Every field is announced with its label by a screen reader.
- Submitting an empty required field announces the error.04
Do I need an accessibility statement?
Under the European Accessibility Act, in-scope services must publish information on how they meet the accessibility requirements (Art. 13(2) and Annex V). Elsewhere it's good practice and gives users a way to report barriers, which the DOJ's guidance encourages. Launch Fix drafts an accessibility statement from your test results as part of the compliance pack.
05
How SafeLaunch checks accessibility
- Real browser (paid audits): your page is opened and tested with axe-core against WCAG 2.2 AA, in the same visit as the cookie test. The free scan checks what the page source shows.
- Code: form fields, alt text, language and interactive elements are checked in your repository or upload.
- Law: each failure is cited to the ADA, Unruh, EAA or AODA for the markets you choose.
- Fixes: before-and-after code and a prompt for your AI builder for every finding.
Automated testing finds many WCAG failures but can't establish full conformance; include keyboard and screen-reader testing of your key journeys. Start with a free scan.
One free fix in your inbox each week
A new copy-paste prompt for Lovable, Cursor or Claude Code every week, with the rule behind it and how to check it worked. No spam, unsubscribe in one click.
By signing up you agree to get this weekly email. We send it with Kit, and you can unsubscribe at any time. What we share with Kit is in our privacy notice.
FAQ
Frequently asked questions.
Sources and further reading
- W3C: WCAG 2.2
- W3C: What's new in WCAG 2.2
- ADA.gov: guidance on web accessibility and the ADA
- European Accessibility Act, Directive (EU) 2019/882
This article is general information, not legal advice. SafeLaunch is automated software, not a law firm; a report records what was checked on one version and is not a certificate of compliance. Read the disclaimer.
From the founder
SafeLaunch is built by Raghav R Handa, a lawyer-turned-builder in New Delhi. He writes about this topic in plain English:
See what SafeLaunch finds on your product.
Paste a link and get your score, the most serious problems and what already passes, in about a minute.
Keep reading