Accessibility Tracker Platform was built on an accessibility audit foundation because audits are the only way to determine WCAG conformance. Scans flag approximately 25% of issues. The other 75% require a trained auditor evaluating content against WCAG criteria. Building a tracking and management platform on scan data alone would mean building on incomplete information, and every decision made from that data would inherit that gap.
That distinction shaped every design choice we made.
| Factor | How It Applies |
|---|---|
| Data Accuracy | Audit data covers all WCAG criteria, including those no automated tool can evaluate |
| Conformance Tracking | Only audit-identified issues allow you to track progress toward full WCAG 2.1 AA or WCAG 2.2 AA conformance |
| Remediation Prioritization | Risk Factor and User Impact prioritization formulas require accurate severity data from a real audit |
| ACR Generation | A VPAT cannot be completed accurately without audit results that map to specific WCAG criteria |
| Compliance Evidence | ADA compliance and EAA compliance documentation depends on auditor-verified findings, not scan output |
What Does "Audit-Based" Actually Mean?
Most accessibility platforms ingest data from automated scans. They present dashboards, scores, and progress charts derived from what a scanner detected. The problem is that scanners evaluate a narrow slice of WCAG criteria. Color contrast, missing alt text, form label associations. Important, but far from complete.
An audit-based platform starts with a different data source: the results of an accessibility audit conducted by a trained auditor. That auditor evaluates every applicable WCAG success criterion, including criteria that require human judgment. Keyboard navigation patterns. Screen reader announcement order. Whether error messages are programmatically associated with form fields. Whether focus management behaves correctly after dynamic content changes.
When the platform ingests that data, every issue it tracks, every remediation path it suggests, and every conformance status it reports is grounded in a complete evaluation. Not a partial one.
Scan Data Is Not Wrong, It Is Incomplete
Automated scans have a place in accessibility workflows. The platform uses scanning as a standalone monitoring feature inside Accessibility Tracker Platform. But scans and audits are completely separate activities.
Scans flag approximately 25% of issues. That means 75% of the accessibility issues on a digital asset go undetected by any automated tool. A platform built exclusively on scan data cannot tell you whether you conform to WCAG 2.1 AA or WCAG 2.2 AA. It can tell you whether the issues it is capable of detecting are present or absent. Those are very different things.
Organizations pursuing ADA compliance, Section 508 conformance, or EAA compliance need the full picture. A platform that only reflects scan results creates a false sense of progress.
How Audit Data Powers Better Remediation
Remediation is where most accessibility projects stall. Development teams receive a report, look at hundreds of issues, and struggle to decide where to begin. The quality of the underlying data determines whether prioritization is meaningful or arbitrary.
Accessibility Tracker Platform applies Risk Factor and User Impact prioritization formulas to every issue identified in an audit. Those formulas weight each issue by its effect on real users and by its legal or procurement risk. A keyboard trap on a checkout flow ranks differently than a missing decorative image description. But that ranking only works when the data feeding it is accurate and complete.
Scan-based platforms can only prioritize within the 25% they detected. They cannot rank an issue they never identified in the first place.
ACR Accuracy Depends on Audit Foundations
Generating an Accessibility Conformance Report (ACR) from a VPAT template requires mapping evaluation results to each WCAG criterion. If your evaluation only covered the criteria a scan can reach, the ACR will have gaps. Procurement reviewers know how to spot those gaps.
Because the platform is built on audit data, ACR generation within Accessibility Tracker reflects the full scope of an auditor's evaluation. Every criterion has a documented status. Every issue maps to a specific success criterion with a severity level and remediation note.
This is particularly relevant for organizations completing the WCAG edition of the VPAT or the EN 301 549 edition for European procurement.
Does This Mean You Need an Audit Before Using the Platform?
Yes. Accessibility Tracker Platform is designed to ingest a completed audit report. The audit is the starting point. From there, the platform becomes the management layer: tracking issues, assigning remediation tasks, monitoring progress, generating conformance documentation, and applying AI-driven remediation guidance.
The audit feeds the platform. The platform takes it from there. That workflow keeps the data source clean and the tracking accurate. It also means that when you update your ACR or produce a progress report for leadership, the numbers reflect reality.
Organizations that already have an audit report from another provider can upload it to the platform as well. The structure is flexible. The requirement is that the data comes from a real evaluation, not a scan export.
Why Other Platforms Chose Scans Instead
Cost and scale. Automated scans are inexpensive to conduct and can cover thousands of pages in minutes. For a software company building a subscription product, scan-based dashboards are easier to maintain and cheaper to deliver. They produce visually compelling charts and scores that feel like progress.
But the economics of the platform should not determine the accuracy of your compliance data. A dashboard that shows 95% conformance based on scan results is not the same as a dashboard showing 95% conformance based on a comprehensive audit. The first number reflects a fraction of the full standard. The second reflects the whole thing.
We chose audit-based architecture because the purpose of the platform is to help organizations reach and maintain WCAG conformance. That goal requires complete data.
What About Ongoing Monitoring?
Scanning still plays a role after the audit. Accessibility Tracker Platform includes scan-based monitoring as a separate feature, designed to catch regressions between audits. New content published, code deployments, CMS updates. These can introduce new issues that a periodic scan flags early.
The distinction is that monitoring supplements the audit. It does not replace it. And the platform keeps those two data streams separate so that conformance reporting always traces back to auditor-verified findings.
Can I use Accessibility Tracker without a specific audit provider?
Yes. You can upload an audit report from any qualified accessibility auditor. The platform accepts audit data in spreadsheet format. The key requirement is that the data comes from an evaluation against WCAG criteria, not from an automated scan export.
How does audit-based tracking affect the cost of accessibility compliance?
An audit costs more upfront than running an automated scan. But remediation guided by complete audit data is more efficient. Teams fix the right issues in the right order, avoid rework, and produce accurate ACRs on the first attempt. Over the full lifecycle of an accessibility project, audit-based tracking reduces total cost.
Does the platform support both WCAG 2.1 AA and WCAG 2.2 AA audits?
Yes. The platform maps issues to whichever WCAG version and conformance level the audit was conducted against. Most organizations are currently working to WCAG 2.1 AA, with growing adoption of WCAG 2.2 AA.
The platform was built this way because conformance is not a score or a percentage from a scanner. It is a verified status determined by a trained auditor. Every feature inside Accessibility Tracker Platform exists to move organizations from audit results to full conformance, and to maintain that conformance over time.
Contact Accessibility Tracker to see how audit-based tracking works for your organization.