No tool by itself makes a website ADA compliant. The path to ADA compliance runs through WCAG 2.1 AA conformance, and that requires a combination of authoring tools, automated scanners, assistive technology for evaluation, and a (manual) accessibility audit conducted by a qualified auditor. Scanners flag approximately 25% of issues. The rest are identified through human evaluation. The best toolkit pairs the right software with the right process.
Below is a practical breakdown of the tools that actually contribute to building and maintaining an ADA compliant website, organized by what each tool does and where it fits in the workflow.
| Tool Category | Purpose |
|---|---|
| Automated scanners | Catch a portion of WCAG issues (approximately 25%) during development and monitoring |
| Screen readers | Evaluate how assistive technology users actually experience the site |
| Browser dev tools | Inspect semantic HTML, ARIA, color contrast, and focus order |
| Color and contrast checkers | Verify text and non-text contrast ratios meet WCAG 2.1 AA |
| (Manual) accessibility audit | The only way to identify the full scope of WCAG issues and determine conformance |
| Tracking platform | Manage issues from audit through remediation and validation |
Automated Scanners
Automated accessibility checkers run code-level checks against WCAG criteria. They are useful for catching obvious issues early: missing alt attributes, empty links, low contrast text, missing form labels, and invalid ARIA. Common tools include axe DevTools, WAVE, Lighthouse, and Pa11y.
These scanners are a starting point, not an endpoint. They detect approximately 25% of WCAG issues. The remaining issues, including most keyboard interaction problems, screen reader confusion, focus management, and content clarity, require human evaluation.
Use scanners during development to catch regressions and during monitoring to flag new issues as content changes.
Screen Readers for Evaluation
Screen readers are how blind and low vision users access the web. Evaluating your site with one is the fastest way to see whether your headings, landmarks, link text, form labels, and dynamic content actually work.
The three to know: NVDA on Windows (free), VoiceOver on macOS and iOS (built in), and JAWS on Windows (paid, widely used in enterprise).
Developers and designers do not need to become expert screen reader users. They do need enough familiarity to evaluate their own work and recognize when something is broken for an assistive technology user.
Browser Developer Tools
Chrome DevTools, Firefox DevTools, and the Accessibility Insights extension all expose the accessibility tree, ARIA roles, computed names, and focus order. These are the everyday tools developers use to verify semantic structure and debug accessibility issues at the code level.
Lighthouse, built into Chrome DevTools, runs an automated accessibility scan as part of its audit. Accessibility Insights goes further with guided checks that walk through tasks a scanner cannot automate.
Color and Contrast Checkers
WCAG 2.1 AA requires specific contrast ratios for text (4.5:1 for normal text, 3:1 for large text) and for non-text elements like form borders and icons (3:1). Color contrast issues are among the most cited problems in ADA website lawsuits.
Tools like the WebAIM Contrast Checker, Stark, and Colour Contrast Analyser let designers verify color choices before they reach production. Catching contrast issues at the design stage is far cheaper than fixing them after launch.
What Tool Determines ADA Compliance?
No tool determines ADA compliance. The U.S. Department of Justice has confirmed that websites are covered under the ADA and that WCAG 2.1 AA is the standard for ADA Title II web compliance. To demonstrate conformance with WCAG 2.1 AA, you need a (manual) accessibility audit conducted by a qualified auditor.
An audit evaluates every applicable success criterion across representative pages or screens. The audit identifies issues, severity, and remediation guidance. A scanner cannot replicate this. The audit is the document that tells you where you stand against the standard.
Accessible.org conducts fully manual WCAG audits and delivers detailed audit reports that map directly to remediation work.
Tracking and Remediation
Once an audit identifies issues, the work moves to remediation. A tracking platform keeps that work organized: which issues are open, which are in progress, which have been fixed and validated, and which are blocked.
Accessibility Tracker is built specifically for this. Audit issues are imported, prioritized using Risk Factor or User Impact prioritization formulas, assigned to developers, and validated as fixes are completed. AI helps developers understand each issue and apply the right fix faster.
Spreadsheets can work for small projects. For anything beyond a single small site, a dedicated platform pays for itself in time saved and issues not lost in email threads.
How These Tools Fit Together
The workflow is simple:
- Designers use contrast checkers and accessible design patterns from the start.
- Developers use browser dev tools, scanners, and screen readers as they build.
- A qualified auditor conducts a (manual) WCAG 2.1 AA audit on the completed work.
- Issues are tracked, remediated, and validated through a platform.
- Scanners and monitoring tools watch for regressions as content changes.
Each tool covers what the others cannot. Scanners are fast but shallow. Screen readers reveal real user experience. Audits identify the full picture. Tracking platforms keep the work moving.
Frequently Asked Questions
Can a single tool make my website ADA compliant?
No. ADA compliance for websites comes from conformance with WCAG 2.1 AA, which can only be determined through a (manual) audit. Scanners and plugins that claim instant compliance do not address the majority of issues and can introduce new ones.
Are free accessibility tools good enough?
Free tools like axe DevTools, WAVE, NVDA, and Lighthouse are legitimately useful and used daily by accessibility professionals. They are not a replacement for a (manual) audit, but they belong in every developer’s toolkit.
What is the difference between an accessibility checker and an audit?
A checker is an automated scan that flags approximately 25% of WCAG issues based on code patterns. An audit is a human evaluation conducted by a qualified auditor that covers every applicable success criterion and produces a report identifying all issues with remediation guidance.
How often should I evaluate my website for accessibility?
Scanners can run continuously through monitoring. A full audit makes sense at launch, after major redesigns, and on a recurring cadence (often annually) to keep pace with content and code changes.
The best toolkit is layered. Scanners and dev tools catch what they can during the build. A (manual) audit identifies everything else. A tracking platform keeps remediation on rails. That is how ADA compliant websites actually get built and maintained.
Contact Accessible.org to start a WCAG 2.1 AA audit for your website. Contact our team to get started.
