Accessibility Audit Checklist: What to Review Before You Buy a Tool
Most businesses choose an accessibility tool based on a vendor demo run on a controlled URL, not their actual site. The demo looks clean. The report sho..
Most businesses choose an accessibility tool based on a vendor demo run on a controlled URL, not their actual site. The demo looks clean. The report shows few issues. They sign the contract. What they have purchased is false confidence: automated tools detect between 30% and 57% of real WCAG violations, and a shallow ruleset does not reduce legal exposure under ADA Title III, the EAA, or Section 508. It only makes the exposure invisible.
Video: Accessibility Audit Checklist: What to Review Before You Buy a Tool
This checklist gives you the evaluation framework to avoid that outcome. Before comparing any paid platform, run your own site through a free website accessibility checker to establish a baseline issue set, then use that baseline to test what any trial actually catches.
What is an accessibility testing tool? An accessibility testing tool is software that scans websites for barriers violating WCAG (Web Content Accessibility Guidelines) and related legal standards: ADA, Section 508, EAA, and AODA. Tools range from free browser extensions to enterprise monitoring platforms. Critically, no automated tool detects 100% of real accessibility issues. The best detect between 30% and 57%.
Why Tool Selection Is a Legal Decision, Not Just a Technical One
Automated accessibility tools detect between 30% and 57% of WCAG violations. The rest require manual testing, keyboard validation, and screen reader review. A tool that reports “no critical issues” while missing 40-70% of actual failures does not reduce your legal exposure. It produces documentation of a partial picture and calls it compliance.
The legal stakes make this consequential. According to ADA.gov’s guidance on web accessibility, ADA Title III covers private businesses in the US and has no government-mandated compliance deadline. Enforcement is lawsuit-driven, and courts consistently apply WCAG 2.1 AA as the de facto standard. There is no safe harbour from selecting a tool that misses most of what courts will evaluate.
The evaluation problem compounds when you factor in how vendor demos work. A vendor who controls the demo URL can show you a site with few detectable issues. That tells you nothing about detection depth on a real-world CMS page with dynamic content, third-party widgets, and a form built by a plugin. The right response is not to find the tool with the best feature list. It is to evaluate every tool against the same criteria before committing. This accessibility audit checklist gives you that framework.
The 12-Point Accessibility Audit Checklist
Use this as a standardised evaluation scorecard. Apply it to every trial, demo, and vendor proposal before signing anything.
1. WCAG Version and Level Support Ask vendors which specific WCAG version and conformance level their tool tests against. The current global benchmark is WCAG 2.1 AA at minimum; WCAG 2.2 AA is preferred given the DOJ’s April 2024 final rule explicitly adopting WCAG 2.1 AA as the ADA Title II standard. Tools citing only WCAG 2.0 are testing against a 2008 standard that predates modern interface requirements, including mobile, touch, and complex interactive components. A bad answer: “We cover the WCAG standard” with no version specified.
2. Compliance Standard Coverage A WCAG compliance tool that only outputs WCAG findings is limited for buyers subject to multiple regulatory frameworks. The European Accessibility Act requires WCAG 2.1 AA compliance for businesses with 10 or more employees or €2M or more in turnover selling into EU markets. Enforcement is live as of June 28, 2025. Section 508 of the Rehabilitation Act applies to all federal agencies and federally funded organisations, currently at WCAG 2.0 AA with 2.1 alignment in progress. If your business operates across US, EU, or government-contract contexts, ask whether reports can be filtered by regulatory framework. A bad answer: findings labelled only as “WCAG violations” with no regulatory mapping.
3. Automated Detection Depth WCAG 2.1 AA has 50 success criteria. Ask the vendor how many their tool tests automatically and how many require manual review. This is the single most important question in any evaluation. A tool detecting 30% of issues on a vendor-controlled demo may detect far fewer on your site. Credible vendors provide a documented rule-coverage matrix with specific criterion numbers. “Comprehensive coverage” without specifics is not an answer. It is a warning sign. A bad answer: a coverage percentage with no breakdown of which criteria are and are not covered.
4. Manual Testing Guidance No tool closes the detection gap on its own. Focus management in interactive components, reading order in complex layouts, and meaningful alt text quality cannot be validated automatically. Ask whether the tool acknowledges its automation limits and provides structured guidance for manual checks. A tool that is honest about what it cannot do is more useful than one implying full coverage. For the manual checks that matter most, Screen Reader Testing: Beginner Checklist for NVDA, JAWS, and VoiceOver and Keyboard Accessibility: Test Your Site in 5 Minutes cover the methods no scanner replicates. A bad answer: no mention of manual testing at all.
5. Dynamic Content and SPA Handling Ask whether the tool scans JavaScript-rendered content, single-page applications, modal dialogs, and content loaded after user interaction. Static HTML-only scanning misses some of the most frequently litigated accessibility failures: inaccessible modals, live region announcements that fire incorrectly, and keyboard traps in dynamically rendered interfaces. Ask for a technical explanation of the mechanism. Does it inject a headless browser, replay user interactions, or execute JavaScript? A bad answer: “We support SPAs” without any description of how.
6. Whole-Site vs. Single-Page Scanning Can the tool crawl and scan your entire site automatically, or does it only analyse individual URLs you submit manually? A single-page scanner cannot produce a site-wide compliance picture, cannot identify which template changes introduced new failures, and cannot distinguish between isolated issues and systematic patterns. For legal documentation purposes, whole-site scanning with a documented scope is significantly more defensible than a collection of individual page reports. A bad answer: page-by-page submission with no crawling capability.
7. Continuous Monitoring and Regression Alerts A one-time audit is a compliance snapshot. A compliance programme requires scheduled rescans and alerts when new issues appear after a CMS update, content change, or plugin installation. Ask whether the tool runs automatic rescans and whether findings are retained with timestamps. This creates the ongoing documentation record that supports a good-faith legal defence if a demand letter arrives. A bad answer: monitoring described as “available on request” rather than automated.
8. Remediation Guidance Quality “Missing alt text” is detection. A fix instruction specifying what attribute to add, where to add it, and what the content should describe is remediation guidance. Ask what the tool’s issue reports actually include beyond the failure type. Non-technical teams, including compliance managers, content editors, and marketing staff, cannot act on WCAG criterion codes and DOM selectors alone. For a concrete example of the specificity good remediation guidance provides, see Accessible Forms: Labels, Errors, Required Fields, and Instructions. A bad answer: reports that flag issues without any fix guidance.
9. Audit Trail and Compliance Documentation Ask whether the tool generates timestamped, versioned, exportable reports. Ask whether you can retrieve a report from six months ago to demonstrate that you identified and began addressing issues before an ADA demand letter arrived. This single feature separates a compliance tool from a development utility. Without it, you have data. With it, you have evidence. A bad answer: reports that can only be viewed in the tool’s dashboard with no export or archiving capability.
10. Multi-Jurisdiction Reporting If your business operates across US, EU, or federal-contractor contexts simultaneously, ask whether reports can be filtered or labelled by regulatory framework: ADA, Section 508, EAA, AODA. A tool that blends all findings under generic WCAG references forces you to manually re-interpret every finding for each jurisdiction. That is a significant burden for any compliance team producing documentation for legal review. A bad answer: one unified report with no regulatory mapping options.
11. Reporting Clarity for Non-Technical Stakeholders Can a compliance officer, legal counsel, or operations manager read and interpret the output without a developer? Reports organised by severity (critical, serious, moderate, minor) and framed in terms of business impact and user effect serve compliance-oriented buyers far better than raw WCAG criterion codes. Ask for a sample report before any purchasing decision. A bad answer: a report that reads as a developer debugging log with no executive summary.
12. Trial Scope: Your Site, Not a Demo Can you run the trial on your actual live pages? Vendors who restrict trial access to controlled demo URLs are preventing you from evaluating real-world performance. Request access to test your own homepage, a form page, a product or content page, and a page with dynamic elements. A trial that does not touch your site tells you nothing useful about what the tool will find, or miss, after purchase. A bad answer: trial access limited to a vendor-provided example URL.
Red Flags That Should Stop Your Evaluation
A pattern that comes up repeatedly when reviewing tool demos across different platforms: vendors who lead with the issue count rather than the detection methodology. Low issue counts feel reassuring. They should trigger questions, not confidence. Beyond that, these specific claims are disqualifying.
“100% ADA/WCAG compliant” guarantees. No tool can guarantee compliance. Compliance is a legal determination involving human judgment, remediation effort, and context-specific testing that no automation can replicate. Any vendor making this claim is either uninformed or deliberately misleading. Neither is a basis for a purchasing decision.
Overlay-only solutions presented as complete compliance. JavaScript overlays that attempt to auto-fix accessibility issues on page load have been challenged in US federal litigation and have generated their own ADA lawsuits. An overlay does not fix underlying code. It is not an accessibility testing tool. Vendors presenting overlays as a compliance solution should be removed from your evaluation immediately.
Unspecified WCAG version. If a vendor cannot tell you which WCAG version and level their ruleset covers, they almost certainly cover fewer criteria than they imply. This ambiguity always favours the vendor, not the buyer. According to Section508.gov, even Section 508, which currently references WCAG 2.0, is progressing toward 2.1 alignment. Any tool still anchored to 2.0 without a roadmap is falling behind regulatory direction.
No published ruleset or VPAT. Credible vendors publish the list of WCAG success criteria their tool tests and maintain a Voluntary Product Accessibility Template documenting their own product’s conformance. Absence of either means you cannot independently verify what the tool actually covers.
Trial restricted to vendor demo URLs. If you cannot run the trial against your actual website, you are evaluating a prepared example, not your real compliance risk. This restriction exists to protect vendor metrics, not to help you make an informed decision.
No mention of manual testing limitations. Any vendor claiming that automation alone achieves full WCAG compliance is misrepresenting how accessibility standards work. Manual testing is required, not optional. A vendor who does not acknowledge this is not a credible compliance partner.
Questions to Ask Every Vendor Before You Sign
Which WCAG 2.1 AA success criteria does your tool test automatically, and which require manual review?
Credible vendors provide a documented rule-coverage matrix. If the answer is a percentage without a breakdown (“we cover 70% of WCAG”), ask for the specific list of criteria not covered. The uncovered criteria define your residual compliance risk. That is the number that matters in any legal exposure conversation, not the coverage percentage.
How does the tool handle dynamically loaded content and single-page applications?
Ask for a technical explanation: does it inject a headless browser, replay user interactions, or execute post-load JavaScript? “We support SPAs” without a mechanism description almost always means partial or unreliable support. Request a live test against a page from your own site that uses dynamic content before accepting any claim about SPA coverage.
What compliance documentation does the tool generate, and is it timestamped for legal audit purposes?
Ask whether reports are versioned and retained. Ask whether the output format is suitable for VPAT documentation. Federal contractors under Section 508 may require VPAT generation specifically. Confirm this before purchasing a tool that does not provide it, because retrofitting compliance documentation after the fact is significantly more difficult than generating it as a workflow output.
What is the tool’s false positive rate, and is there a dispute workflow for contested findings?
High false positive rates erode team trust and lead to tools being deprioritised or abandoned. Ask for benchmark data on precision. Ask whether there is a mechanism to mark a finding as intentional, exempt, or disputed. Without one, the report becomes unmanageable at scale and compliance reviews stall.
Does pricing scale by page, domain, or user, and what are the contract terms if my site grows?
Per-page pricing becomes expensive as sites scale. Per-domain models are generally more predictable. Understand the pricing structure and contract flexibility before your site doubles in size or you add subdomains. A tool that is cost-effective today may create budget friction at exactly the point when continuous monitoring matters most.
Accessibility Tool Types at a Glance
The table below maps each tool type to its realistic detection depth, monitoring capability, and legal documentation output: the three dimensions that matter most for compliance-oriented buyers.
| Tool Type | Best For | Auto Detection Depth | Continuous Monitoring | Legal Documentation |
|---|---|---|---|---|
| Free browser extension | Developer spot-checks, initial baselines | Low (~20-30% of WCAG criteria) | No | None |
| Standalone page scanner | Small sites, initial audit baselines | Medium (~30-50%) | Limited / manual | Basic export |
| Full SaaS platform | Growing sites, compliance teams | High (~50-70%+) | Yes, scheduled | Timestamped audit trails |
| Expert manual audit service | Legal defence, Section 508 VPAT | Complete (100% possible) | N/A | Full signed documentation |
No single tool type solves every need. Most compliance programmes combine a SaaS platform for continuous monitoring with targeted manual audit engagements at key milestones: site launches, major redesigns, or in response to a legal demand.
Frequently Asked Questions
What percentage of WCAG issues can an automated accessibility testing tool find?
Most automated tools detect between 30% and 57% of real WCAG violations, depending on the depth of their ruleset and how they handle dynamic content. The remaining issues, including context-dependent failures like meaningful alt text quality, logical reading order, and keyboard focus management in interactive interfaces, require human testing. A credible vendor will disclose their detection coverage openly, ideally with a published rule matrix, rather than implying total coverage through vague “comprehensive” language. If a vendor cannot give you a specific number or a breakdown of which WCAG 2.1 AA success criteria their tool does and does not test, treat that gap as a red flag.
Do I need a separate tool for ADA compliance versus WCAG compliance?
No. ADA compliance for websites is evaluated against WCAG 2.1 AA under the majority of current federal court decisions and the DOJ’s April 2024 final rule. According to ADA.gov, ADA Title III enforcement against private businesses is lawsuit-driven with no government-mandated compliance deadline. WCAG 2.1 AA is what courts apply. A tool that fully covers WCAG 2.1 AA addresses the primary ADA technical benchmark. Confirm the tool tests the correct version and level before purchasing.
Is a free website accessibility checker enough for my business?
For an initial baseline scan of a simple static site, a free checker identifies the most common detectable failures and gives you a starting point for any paid tool evaluation. For legal defensibility, ongoing monitoring, or sites with dynamic content, you need a platform with scheduled rescans, timestamped audit trails, and structured remediation guidance, not just a one-time report. The free scan is step zero, not the complete programme.
How often should I rescan my website for accessibility issues?
After every significant content update, template change, or new plugin installation, not on a fixed quarterly calendar. CMS-driven sites updated by non-developers on platforms like WordPress, Shopify, or Squarespace should have continuous automated monitoring to catch regressions the moment they appear. A quarterly rescan on a site updated weekly is not a compliance programme. It is periodic sampling with long gaps of undetected risk.
The accessibility audit checklist above is designed to be applied before any trial begins, not after you have already seen a vendor demo. Run your own site through the free website accessibility checker first. The issues it surfaces become your baseline test set, and every vendor you evaluate should be measured against what it finds and what it misses.
This article is for general informational purposes and is not legal advice.