← Back to Accessalyze

How to Check If Your Website Is ADA Compliant

The Americans with Disabilities Act (ADA) does not name a specific technical standard for websites, but courts and the DOJ consistently reference WCAG 2.1 Level AA as the applicable benchmark. If your site meets WCAG 2.1 AA, you are effectively ADA compliant for web accessibility.

Here is a practical process for checking compliance from start to finish.

Step 1 — Run an Automated Scan

Automated tools catch roughly 30–40% of WCAG violations instantly. They are not a substitute for manual testing, but they surface the quick wins fast.

Step 2 — Test Keyboard Navigation

Unplug your mouse and use only the keyboard to navigate your site.

• Tab — moves focus forward through interactive elements
• Shift+Tab — moves focus backward
• Enter/Space — activates buttons, links, checkboxes
• Arrow keys — navigates within menus, sliders, tabs
• Escape — closes modals, dismisses menus

You must be able to reach and operate every interactive element without a mouse. If focus disappears, gets trapped, or certain controls are unreachable, you have a WCAG 2.1.1 / 2.1.2 violation.

Step 3 — Check Color Contrast

Color contrast failures are the most common WCAG violation. The minimum ratios under WCAG 1.4.3:

• Normal text (under 18pt or under 14pt bold): 4.5:1
• Large text (18pt+ or 14pt+ bold): 3:1
• UI components and focus indicators: 3:1 (WCAG 1.4.11)

Check contrast with the free WebAIM Contrast Checker or run Accessalyze to get all failures on your page automatically.

Step 4 — Audit Images for Alt Text

Every non-decorative image needs descriptive alt text. Open your browser DevTools and inspect each <img> tag:

// Images MISSING alt text — bad
<img src="team-photo.jpg">
<img src="chart.png" alt="">  // decorative OK, but not for charts

// Images WITH good alt text — good
<img src="team-photo.jpg" alt="The Genesis AI team at their 2026 offsite">
<img src="revenue-chart.png" alt="Bar chart showing 40% revenue growth Q1 2026 vs Q1 2025">

Step 5 — Review Forms

Every form input needs a programmatically associated label. Placeholder text does not count as a label.

// Bad — no label
<input type="email" placeholder="Enter your email">

// Good — explicit label
<label for="email">Email address</label>
<input type="email" id="email" autocomplete="email">

Step 6 — Test with a Screen Reader

Use a free screen reader for a real-world audit:

• NVDA (Windows, free) + Chrome or Firefox
• VoiceOver (Mac/iOS, built-in) — press Cmd+F5
• TalkBack (Android, built-in)

Navigate as a blind user would. Listen for: meaningful link text, proper heading hierarchy, announced form labels, status updates for dynamic content.

Step 7 — Validate HTML Structure

Malformed HTML causes unpredictable screen reader behavior. Run your pages through the W3C Markup Validator and fix any critical errors.

Common Violations to Prioritize

1. Missing or empty alt text on informational images
2. Color contrast below 4.5:1 on body text
3. Form inputs without associated labels
4. Interactive elements unreachable by keyboard
5. Focus indicator hidden with outline: none
6. Missing page <title> or duplicate titles
7. No skip navigation link
8. Heading levels skipped (h1 → h3, no h2)

← Back to Accessalyze · Next: WCAG Color Contrast Requirements →