Most accessibility compliance platforms retain a history of resolved issues as part of their core record-keeping function. This history typically includes the original issue description, its WCAG reference, the date it was logged, the person who marked it resolved, the remediation notes, and any validation steps taken. Some platforms also retain code snippets, screenshots, and audit metadata. The depth and accessibility of this record varies significantly between platforms, which is why the resolved-issue log is one of the more useful features to evaluate during a platform comparison.
| Element | What It Captures |
|---|---|
| Issue record | Original description, WCAG success criterion, severity, and location. |
| Resolution data | Date resolved, person responsible, fix description, and validation notes. |
| Audit trail | Status changes, comments, file attachments, and timestamps for each update. |
| Reporting use | Supports progress reports, ACR preparation, and conformance documentation. |
What a Resolved Issue Record Typically Contains
A resolved issue is not deleted from the platform when it is marked complete. It moves to a closed or resolved state and remains part of the project record. The data attached to that record is what makes the history useful later.
Most platforms retain the original issue description as written by the auditor, along with the WCAG success criterion it maps to (for example, 1.3.1 Info and Relationships at Level AA). The record also stores the page or screen where the issue was identified, the severity or priority rating, and any screenshots or code references captured during the audit.
On the resolution side, the record stores who marked the issue resolved, when it was closed, what fix was applied, and any notes from the validation review. Platforms with stronger workflow features also retain the full comment thread, so the discussion around the fix is preserved alongside the outcome.
Why This History Matters
The resolved issue history serves several functions beyond bookkeeping. It documents that remediation work was completed, which is useful evidence when preparing an Accessibility Conformance Report or responding to a procurement questionnaire. It also creates accountability within a development team, since each resolved item is tied to a person and a date.
For ongoing conformance programs, the history becomes a reference. If a similar issue appears on a new page months later, the team can look back at how the original was resolved and apply the same approach. This shortens remediation time and improves consistency across a product.
The history also supports continuity when team members change. New developers or accessibility coordinators can review past work without relying on institutional memory.
How Platforms Differ in Retention and Access
Not all platforms treat resolved issues the same way. Some considerations to evaluate:
- Retention period: How long resolved issues stay accessible, and whether older records are archived or purged.
- Export options: Whether the history can be exported to CSV, PDF, or another format for external reporting.
- Filtering and search: Whether resolved issues can be filtered by WCAG criterion, date range, page, or assignee.
- Audit trail depth: Whether every status change is timestamped, or only the final resolution date is recorded.
- Reopening workflow: Whether a resolved issue can be reopened if a validation review later identifies the fix was incomplete.
Platforms built around audit data tend to retain richer historical records than those built around automated scan output, because audit records carry more context per issue from the start.
Using Resolved Issue Data in Reports
The history of resolved issues feeds into the progress reporting most platforms generate. A progress report typically shows how many issues were identified, how many remain open, and how many have been resolved over a given time period. The resolved set is what drives the conformance trend.
When an Accessibility Conformance Report is prepared, the resolved issue history provides supporting documentation for each success criterion marked as Supports. Reviewers can see what was identified, what was fixed, and when. This level of detail strengthens the credibility of the ACR.
For organizations operating under ADA Title II obligations or preparing for procurement requirements, this documented history is also part of the conformance record that demonstrates ongoing effort rather than a one-time evaluation.
What to Look for When Evaluating a Platform
If access to resolved issue history is important to a team, the evaluation should confirm that the platform retains complete records, allows filtering and export, preserves the audit trail of status changes, and ties each resolution to a person and date. A platform that only shows current open issues without a complete closed-issue view will leave holes in any long-term conformance program.
The resolved history is a quiet feature, but it carries most of the weight when a team needs to prove the work was done.