Making a website ADA compliant means bringing it into conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 AA, the standard courts and regulators reference when evaluating digital accessibility under the Americans with Disabilities Act. The process starts with a (manual) accessibility audit that identifies issues, followed by remediation, validation, and ongoing monitoring. There is no shortcut. Scans only flag approximately 25% of issues, so an automated checker cannot confirm ADA compliance on its own. The work is human, deliberate, and rooted in WCAG criteria applied to every page template and interactive component.
| Element | What It Means |
|---|---|
| Standard | WCAG 2.1 AA is the reference standard for ADA website compliance. |
| Audit | A (manual) audit conducted by a trained auditor identifies issues across representative pages and templates. |
| Remediation | Developers fix issues based on the audit report, prioritized by user impact and legal risk. |
| Validation | The auditor confirms fixes resolve the original issues without introducing new ones. |
| Maintenance | Ongoing monitoring, training, and periodic audits maintain conformance as the site changes. |
What standard do you use for ADA compliance?
The Department of Justice has referenced WCAG 2.1 AA in settlement agreements and in the recent ADA Title II rule covering state and local government websites. For private businesses under Title III, courts and plaintiff firms also point to WCAG 2.1 AA as the working standard. WCAG 2.2 AA is gaining traction as more clients request the newer version, but 2.1 AA remains the most common reference point.
The guidelines cover four principles: perceivable, operable, understandable, and robust content. Each criterion has a specific technical requirement, and a website meets the standard only when every criterion at Level A and Level AA is satisfied across the site.
Step one: conduct a WCAG audit
An audit is the foundation. A trained auditor reviews each page template and interactive component against every Level A and AA criterion using assistive technology, keyboard-only navigation, and code inspection. The output is a report listing each issue, the WCAG criterion it violates, the location, and recommended fixes.
Automated checkers cannot replace this work. They can flag missing alt text or low color contrast on detectable elements, but they cannot evaluate whether alt text is meaningful, whether a custom component is operable by keyboard, or whether a form error message is announced correctly by a screen reader.
Step two: remediate the issues
Once the audit report is delivered, developers work through the findings. Most teams use a prioritization approach based on Risk Factor or User Impact prioritization formulas. Risk Factor weights issues by how often they appear in ADA lawsuits. User Impact weights them by how much they affect people using assistive technology.
Remediation is rarely a one-week project. A mid-sized site typically takes weeks of developer time spread across templates, components, and content. Treating it as a sprint rather than a single push gives the team space to fix issues properly instead of patching symptoms.
Step three: validate the fixes
After remediation, the auditor re-evaluates each issue to confirm the fix resolved the original problem and did not introduce new ones. Validation is where shortcuts get exposed. A developer might mark an issue as fixed because the code looks right, but the auditor checks behavior with a screen reader and keyboard to verify the fix works in practice.
Step four: maintain conformance
Websites change. New pages, new templates, new third-party scripts, and new content can all introduce accessibility issues. Maintaining ADA compliance over time requires a combination of developer training, scanning for known issue types between audits, and a follow-up audit when significant changes ship.
What about an accessibility statement?
An accessibility statement on the website signals commitment and gives users a contact path if they encounter an issue. It is not a legal shield, but it is a meaningful piece of documentation that demonstrates good faith effort. The statement should reference the standard the site targets (WCAG 2.1 AA), describe ongoing work, and list contact information for accessibility feedback.
Frequently Asked Questions
How long does it take to make a website ADA compliant?
An audit typically takes two to four weeks depending on scope. Remediation depends on the number of issues and developer availability, often six to twelve weeks for a mid-sized website. Validation adds another one to two weeks. End to end, three to four months is a reasonable expectation for a focused project.
How much does ADA website compliance cost?
Audit costs depend on the number of unique page templates and components in scope. Remediation cost depends on internal developer time or an outside vendor. For most small to mid-sized websites, the full process can be budgeted in the low five figures when scoped carefully.
Can a scan tell me if my website is ADA compliant?
No. Scans detect approximately 25% of issues and cannot evaluate context, meaning, or behavior. A scan is useful for catching regressions between audits, but it cannot confirm WCAG conformance or ADA compliance on its own.
Do I need a new audit every year?
Not necessarily. The right cadence depends on how often the site changes. A site with frequent template updates or new functionality benefits from an annual audit. A stable site with minor content updates can go longer between full audits if scanning and internal review are in place.
ADA website compliance is a process, not a status. The work is technical, the standard is specific, and the path runs through a real audit, real remediation, and real maintenance.
Contact Kris Rivenburgh to discuss your ADA website compliance project.