How to become ADA compliant
Becoming ADA compliant takes 30-90 days for a typical small business site: get a WCAG 2.1 AA audit, fix the critical issues in your source code, install a widget for visitor customization, document your work, then maintain with quarterly audits.
There's no "one-click ADA compliance" product — despite what some vendors claim. Real compliance is a process with distinct phases. Here's how to actually do it.
This guide assumes you're running a US commercial website and want to reduce your ADA lawsuit exposure while making your site genuinely usable for people with disabilities.
Phase 1: Baseline audit (Week 1)
You can't fix what you don't know. Start with a thorough assessment.
- Run automated scanners: Lighthouse, WAVE, axe DevTools. Free, finds ~30% of issues.
- Get a manual audit: Hire a WCAG specialist. They'll test with screen readers (NVDA, VoiceOver), keyboard-only navigation, and zoom. Expect 3-5 days for a 5-page audit.
- Inventory your content types: List every unique page template, component, and dynamic behavior. Accessibility issues often live in components, not pages.
- Document the baseline: Save your audit report. You'll need it if you're ever questioned about your remediation efforts.
Our free 5-page WCAG 2.1 AA audit covers Phase 1 at no cost. It's real manual testing by specialists, not an automated scan.
Phase 2: Prioritize your fixes (Week 2)
Not all issues are equal. Prioritize by severity and effort:
- Critical (fix first): Keyboard traps, missing form labels, completely inaccessible checkout. These block users entirely.
- Serious: Missing alt text on meaningful images, color contrast failures, missing ARIA on custom components.
- Moderate: Heading structure issues, missing landmark roles, unclear link text.
- Minor: Decorative alt text, slightly-off contrast, minor ARIA enhancements.
If an issue would prevent a blind, deaf, or motor-impaired user from completing a core user journey (browse, add to cart, checkout), it's critical. Fix those first.
Phase 3: Source-code remediation (Weeks 3–8)
This is where real compliance happens. Fix issues in your actual code — HTML, CSS, JavaScript, components.
- Component-level thinking: Fix your Button component once, not on every page. Modern frameworks make this easy.
- Add proper semantic HTML: Use <nav>, <main>, <article>, <button>, <label>. Avoid <div>-soup.
- ARIA only when needed: Don't sprinkle ARIA everywhere. Use it when semantic HTML doesn't convey meaning.
- Test after each fix: Use a screen reader to verify. Automated scans won't catch logic issues.
- Update your component library: If you have a design system, update it so future features are accessible by default.
Phase 4: Deploy the accessibility widget (Week 9)
After source-code fixes, add a widget to provide ongoing visitor customization and catch common issues automatically.
- What widgets do well: Font size adjustment, contrast modes, keyboard focus indicators, screen reader mode, dyslexia-friendly font.
- What widgets can't do: Fix broken keyboard navigation, add missing form labels to source, restructure bad heading hierarchy.
- Pick a widget that: Has honest marketing (no "100% compliant" claims), is lightweight, uses Shadow DOM to isolate styles, respects user OS settings, and doesn't break existing assistive tech.
Phase 5: Document everything (Week 10)
If you're ever sued or receive a demand letter, your documented accessibility efforts are your primary defense.
- Publish an accessibility statement: Include your conformance level, accessibility features, and feedback mechanism.
- Archive your audit reports: Keep every audit, scan, and remediation record.
- Track your fix history: Git commits, ticket numbers, completion dates for each WCAG issue addressed.
- Set up ongoing monitoring: Automated weekly scans + quarterly manual re-audits.
Include: compliance level (e.g., "partial conformance to WCAG 2.1 AA"), known limitations, ongoing efforts, and a contact email for accessibility feedback. Don't claim "100% compliant" — no honest statement does.
Phase 6: Maintenance (Ongoing)
Accessibility regresses. Every new page, image, or feature can introduce issues. Plan for ongoing work:
- Monthly automated scans: Catch regressions early.
- Quarterly manual audits: Spot deeper issues automated tools miss.
- Pre-launch checks: Before shipping new features, run axe DevTools.
- Content team training: Make sure anyone adding images knows to add alt text.
- Annual deep audit: Full WCAG 2.1 AA re-audit every year.
Start Phase 1 with a free 5-page audit
48-hour turnaround, no credit card. See what your site actually needs.
Frequently asked questions
Can I become ADA compliant in a week?+
No honest vendor will tell you this. Real compliance requires source-code changes, which take 30–90 days for a typical small business site. Anyone promising "instant compliance" is selling an overlay.
Do I need developers to become compliant?+
For deep structural issues, yes. Simple fixes (alt text, color contrast) can be done by a content editor. But keyboard flows, ARIA patterns, and form logic need developer time.
How long does it take if I use a widget alone?+
A widget installs in 5 minutes. But that's not compliance — it's one piece of a compliance program. Expect real compliance (widget + audits + remediation + documentation) to take 30–90 days initially.
Do I need to redo everything every year?+
No. Once you have good accessibility practices, maintenance is about 5-10% the effort of the initial remediation.
Key takeaways
- Real compliance takes 30-90 days for a typical small business site
- Follow the 6-phase process: audit → prioritize → remediate → widget → document → maintain
- Source-code fixes are where real compliance happens, not widgets
- Documentation is your legal defense — keep records of everything
- Ongoing monitoring prevents regression — plan for it