Scan data and manual audit findings serve different purposes. A manual accessibility audit identifies WCAG conformance issues across every applicable success criterion. A scan flags surface-level issues a parser can detect, which is approximately 25% of issues. The two work together when the audit sets the baseline and the scan acts as a recurring signal between audits. Inside Accessibility Tracker Platform, scan results live next to audit findings so teams can see what has been confirmed by a human evaluator and what was picked up automatically. The audit drives conformance work. The scan supports monitoring.
| Source | Role in Your Workflow |
|---|---|
| Manual Audit Findings | Authoritative record of WCAG conformance issues. Used to drive remediation and confirm conformance. |
| Scan Data | Recurring signal between audits. Catches a portion of regressions and points to pages worth reviewing. |
| Together | Audit sets the baseline; scans flag new automated-detectable issues until the next audit cycle. |
What Each Source Actually Tells You
A manual audit evaluates every applicable WCAG success criterion against real content, real interactions, and assistive technology behavior. It identifies issues a scan cannot detect, including keyboard traps, focus order problems, ARIA misuse, color and contrast judgments tied to context, and meaningful sequence issues.
A scan parses the DOM and runs rule-based checks. It catches missing alt attributes, empty buttons, certain contrast ratios, label associations, and similar machine-detectable patterns. Scans only flag approximately 25% of issues. The rest require human evaluation.
The mistake teams make is treating scan output as a conformance signal. It is not. A clean scan does not mean a page conforms to WCAG. It means the rules the scanner runs did not trigger.
How Should Scan Data and Audit Findings Be Combined?
Start with the audit. The audit report becomes the issue list inside Accessibility Tracker Platform. Each finding has a WCAG reference, severity, location, and recommended fix. Remediation work flows from this list.
Once the audit is loaded, scans run on a schedule against the same pages or screens. Scan results sit beside the audit findings without overwriting them. If a scan flags an issue the audit already captured, the platform maps it to the existing finding. If a scan flags something new, it appears as a separate item to review.
This separation matters. Audit findings carry the weight of human evaluation. Scan items carry the weight of an automated rule. Mixing them into one undifferentiated list erases that difference and weakens the record.
Using Scans Between Audit Cycles
Between audits, scans act as a regression check. When a developer ships a new template or a content team adds a new section, the next scan may pick up a missing label or an image without alt text. That signal lets the team fix the issue before it compounds.
Scans cannot tell you the page is now conformant. They can tell you a previously clean check is failing again, or that a known issue is still present. Treat them as a heartbeat, not a verdict.
The audit cycle covers the rest. When a major release ships, when the design system changes, or when a year has passed, a fresh audit confirms conformance for the standard you are targeting, usually WCAG 2.1 AA or WCAG 2.2 AA.
Where Tracker Fits
Accessibility Tracker Platform was built for this pairing. Audit findings load as the source of truth. Scan data feeds in continuously and maps to the same pages and the same WCAG criteria. Teams see one view that respects the distinction between what a human identified and what a rule detected.
That distinction is what most accessibility software gets wrong. Scan-only platforms present automated output as if it were a conformance report. Audit-only spreadsheets lose freshness the moment a page changes. The platform keeps both records active and honest.
FAQ
Can scan data replace a manual audit?
No. Scans flag approximately 25% of issues. Conformance to WCAG can only be determined through a (manual) audit conducted by an evaluator who reviews the content, structure, and behavior against each success criterion.
How often should scans run?
Most teams run scans weekly or after each deployment. The cadence depends on how often the site or app changes. Stable marketing pages can run less often; active product surfaces benefit from frequent checks.
What happens when a scan flags an issue the audit did not?
Review it. The scan may have caught a new issue introduced after the audit, or it may be flagging a rule the auditor evaluated differently in context. Either way, the finding gets logged, reviewed, and resolved if valid.
Does combining scans and audits affect compliance documentation?
Compliance documentation, including ACRs and conformance statements, draws from the audit. Scan data supports the monitoring story but does not appear in the formal record of WCAG conformance.
Audit findings carry the conformance record. Scan data keeps the picture current between cycles. Used together inside one platform, they give a team something neither source provides alone.
Contact Accessibility Tracker to see how the platform pairs audit findings and scan data in one view. Visit Accessibility Tracker.