Your site is ADA compliant only if it meets the technical requirements of WCAG 2.1 AA and you can show a good‑faith effort to keep it that way.
Your site is ADA compliant only if it meets the technical requirements of WCAG 2.1 AA and you can show a good‑faith effort to keep it that way. In practice, you can get a reliable first picture in about fifteen minutes by running a free automated scan and then running through a short manual checklist. If the scan finds no failures and the manual checks pass, you are on solid footing; any remaining issues will need deeper review.
The Americans with Disabilities Act (ADA) Title III applies to places of public accommodation, including websites. There is no federal notice‑and‑cure period for web sites, so a complaint can lead directly to litigation. The CDC reports that more than one in four U.S. adults lives with a disability, meaning a large share of your visitors rely on accessible design. Failure to provide access can result in lawsuits, loss of customers, and damage to brand reputation. In Europe, the European Accessibility Act (Directive (EU) 2019/882) has been enforceable since 28 June 2025, and each member state can impose penalties for non‑compliance. Meeting WCAG 2.1 AA therefore reduces legal risk and opens your site to a broader audience.
Reminder: This article provides general information and is not legal advice.
Run a free automated scan. Enter your URL in our free scanner. It uses headless Chromium with axe‑core to test the rendered page for the most common Level A and AA criteria, such as:
The report appears within seconds. Note any failures; you will address them in the steps below.
Check keyboard navigation. Open your site and press Tab repeatedly. Focus should move to every interactive element in a logical order, and it should always be visible (WCAG 2.4.7) and not hidden behind sticky headers or banners (2.4.11). If you can't see where focus is, add an outline:
:focus-visible {
outline: 3px solid #0066ff;
outline-offset: 2px;
}
Validate alt text. Every <img> that conveys meaning needs an alt attribute (1.1.1). Decorative images should have an empty alt (alt=""). If you use CSS background images for content, provide a text alternative elsewhere.
<!-- Meaningful image -->
<img src="product.jpg" alt="Red hiking boots with waterproof membrane">
<!-- Decorative image -->
<img src="decorative-line.svg" alt="">
Confirm color contrast and target size. Use a contrast checker (one is built into Chrome and Firefox dev tools) to make sure text meets 4.5:1 (1.4.3) and UI components meet 3:1 (1.4.11). Interactive targets should be at least 24 × 24 CSS pixels (2.5.8); 44 × 44 is the stricter AAA guideline and a good goal for mobile. If a button is too small, increase its padding.
.cta-button {
min-width: 44px;
min-height: 44px;
padding: 10px 16px;
}
Review form labels and ARIA attributes. Every form control needs an associated <label> (3.3.2). The label can be explicit (for attribute) or implicit (wrapping the control). Avoid ARIA that conflicts with native semantics; for example, don't add role="button" to a native <button>.
<!-- Explicit label -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" required>
<!-- Implicit label -->
<label>
<input type="checkbox" name="subscribe">
Subscribe to newsletter
</label>
| Step | Approx. time |
|---|---|
| Automated scan | 1 minute |
| Keyboard test | 2 minutes |
| Alt‑text review | 3 minutes |
| Contrast & target size | 4 minutes |
| Form & ARIA check | 5 minutes |
If you get through all five steps without finding failures, you have a strong baseline. Any failures reported by the scanner should be fixed using the code examples above or similar adjustments.
These shortcuts may look cheap, but they do not satisfy WCAG and can increase legal exposure.
/statement/[siteId] lists the WCAG level you target, the date of the latest scan, known limitations, and a contact method. This demonstrates good‑faith effort without claiming certification. Running the free scanner gives you an immediate snapshot of the most common failures. After you address those, the hosted statement lets you publicly show the date of your last scan and a contact method. For ongoing monitoring, see our plans. The tools work with modern stacks (React, Next.js, Shopify, WordPress), so you can keep accessibility in the code, not as an after‑thought overlay.
An automated scan catches many technical failures, but it only covers about 57 % of issues by volume according to Deque’s study. Human testing for keyboard use, screen‑reader experience, and content clarity is still needed.
The ADA does not reference a specific version of WCAG, but most courts and regulators expect at least WCAG 2.1 AA. Meeting those criteria is a strong defense and aligns with the European Accessibility Act’s EN 301 549 mapping.
No. The FTC’s 2025 enforcement action against accessiBe shows that marketing an overlay as a compliance fix can be deceptive. Overlays do not fix 1.1.1, 2.1.1, or contrast failures.
Legal risk rises each time a new page or feature is added. A weekly automated scan plus a quarterly manual review is a practical cadence for most small‑to‑medium sites.
List the WCAG level you target (e.g., WCAG 2.1 AA), the date of the most recent scan, known limitations, and a contact email or form for barrier reports. Do not claim certification or legal immunity.
By following the five quick steps, running a free scan, and committing to regular monitoring, you can check whether your website is ADA compliant in about fifteen minutes and keep it that way.
Accessibility overlays don't fix your site's code, so the barriers plaintiffs scan for are still there. What the FTC, the courts and practitioners say, and what to do instead.
The European Accessibility Act has applied since June 2025. Here's whether your US SaaS or store is covered, who enforces it, how fines work, and a practical plan.
A structured, calm triage guide for business owners who received an ADA Title III accessibility demand letter. Learn how to verify claims and protect your business.