To compare two audit reports side by side, align the reports by WCAG success criteria, then map each identified issue from the first report to its current status in the second. Look for three things: issues that were resolved, issues that remain open, and any new issues introduced since the first audit. The goal is to measure remediation progress and confirm that fixes did not create regressions elsewhere. A spreadsheet or accessibility platform makes this work faster, but the comparison logic stays the same regardless of the tool.
This kind of comparison is standard practice after a remediation cycle, before a VPAT or ACR update, or when validating work completed by a development team.
| Comparison Element | What to Look For |
|---|---|
| Alignment method | Match issues by WCAG success criterion, page or screen, and element type |
| Resolved issues | Present in first report, absent or marked closed in second |
| Open issues | Present in both reports with no status change |
| New issues | Absent in first report, present in second |
| Regressions | Marked closed previously but reappearing in second report |
| Severity shifts | Same issue rated differently between the two reports |

Why Compare Two Audit Reports?
The most common reason is validation. After a development team completes remediation work, a follow-up audit confirms which fixes worked and which still need attention. Comparing the two reports gives leadership a measurable view of progress against WCAG 2.1 AA or WCAG 2.2 AA.
Comparisons also support ACR updates. When a product changes meaningfully, the previous audit no longer reflects the current state. Mapping the old report to the new one shows what carried over, what was fixed, and what changed.
What Should Match Across Both Reports?
For a side by side comparison to work, both reports need a shared structure. At minimum, each issue should be tied to a specific WCAG success criterion, a page or screen, and an element or component. Without this, you are comparing summaries rather than findings.
If you are working with reports from different providers, you may need to normalize the data first so the issues can actually be aligned.
Step by Step: How to Compare Two Audit Reports
Start with the first report as your baseline. Export both reports to a spreadsheet if they are not already in one. Then work through the comparison in a deliberate order.
- Sort both reports by WCAG success criterion.
- Match each issue in the first report to the corresponding location in the second.
- Mark each row as resolved, open, or new.
- Flag any issue that was previously closed but has reappeared.
- Note any severity changes for issues that remain open.
- Summarize totals by criterion and by severity.
The summary is what most teams actually use. It answers the question leadership asks: how much progress was made, and what still needs work.
Using a Platform vs. a Spreadsheet
A spreadsheet works for a one time comparison, especially if the audit reports are small. The downside is manual effort and the risk of misalignment when reports use different terminology or formatting.
The Accessibility Tracker Platform is built to manage this work continuously. Issues from each audit are tracked in one place, status changes are recorded as remediation happens, and progress reports can be generated on demand. Instead of comparing two static documents, you are looking at a living record of the project.
For teams managing accessibility across multiple products or conducting quarterly audits, the platform reduces the comparison work from hours to minutes.
Common Issues When Comparing Reports
Inconsistent severity ratings are the most frequent issue. Two auditors, or even the same auditor at different times, may rate the same finding differently. Treat severity as directional, not absolute, unless both reports were produced by the same team using the same rubric.
Scope mismatches are the second issue. If the first audit covered ten pages and the second covered twelve, the additional pages will appear as new issues even though they were never evaluated previously. Document scope clearly in the comparison so the numbers are read correctly.
The third issue is scan data contaminating audit comparisons. Scans only flag approximately 25% of issues, and they identify different findings than a manual evaluation. Never blend the two when comparing reports. Audits compare to audits.
What to Do With the Comparison
Use the comparison to plan the next phase of work. Open issues, especially those carried over from the first report, become the priority list. New issues get added to the queue. Regressions get flagged for the development team to investigate.
If you are updating a VPAT or ACR, the comparison feeds directly into the conformance claims. Issues that are now resolved move the relevant success criteria toward supports. Issues that remain open continue to inform the remarks and explanations column.
How often should audit reports be compared?
Typically after each remediation cycle. For products with active development, a quarterly cadence works well. For more static sites, comparing reports annually is reasonable.
Can I compare an audit report to a scan report?
No. Audits and scans are separate activities that identify different issues using different methods. A scan cannot determine WCAG conformance. Comparing the two produces misleading conclusions.
What if the two reports use different WCAG versions?
Map findings by success criterion number where they overlap. WCAG 2.2 AA includes the same criteria as 2.1 AA, with additional criteria layered on top. Note which criteria exist only in the newer version so the comparison reflects the actual scope.
Does Accessibility Tracker support multi audit comparisons?
Yes. The platform is designed to track issues across audits over time, including status changes, severity shifts, and progress against WCAG 2.1 AA or WCAG 2.2 AA. Multiple audits per project are supported.
Comparing audit reports is less about the format and more about the discipline. Consistent structure, honest severity ratings, and clear scope make the comparison useful. Without those, the numbers can mislead the people who depend on them.
Track issues across audits in one place with the Accessibility Tracker Platform. Contact Accessibility Tracker to see how the platform supports ongoing comparison and reporting.

