Validating accessibility fixes after remediation means re-evaluating each previously identified issue against the WCAG success criterion it was tied to, then marking the issue as passed, partially addressed, or still open. The auditor who conducted the original evaluation reviews the developer's fix in context, confirms the corrected behavior across assistive technologies, and updates the status inside a tracking record. Validation is not a fresh audit. It is a focused pass on known issues, scoped to the work that was completed, and it produces the documentation needed to support a WCAG conformance claim or ACR update.
Validation closes the loop on remediation. Without it, fixes exist in code but not in the record.
| Step | What happens |
|---|---|
| Developer marks fix complete | Each remediated issue is flagged ready for review inside the tracking record. |
| Auditor re-evaluates the issue | The original auditor reviews the fix against the WCAG success criterion and confirms behavior with assistive tech where relevant. |
| Status updated | Issue marked passed, partially addressed, or still open with a note explaining the decision. |
| Documentation refreshed | Conformance claim, ACR, or internal report reflects the updated status. |
What validation actually covers
Validation is scoped to the issues the audit identified. If the original audit report listed 42 issues across 18 success criteria, validation reviews those same 42 issues against the developer's fixes. Nothing more, nothing less.
This matters because remediation can introduce new issues. A developer fixing a color contrast issue might adjust a button state that now lacks a visible focus indicator. Validation reviews the original issue but flags anything obvious that surfaces during the re-evaluation. Anything outside that scope belongs in a follow-up audit, not in the validation pass.
Who should conduct validation?
The auditor who conducted the original evaluation. They already understand the context, the user flows they reviewed, and the reasoning behind each issue. A different auditor would need to re-learn the report before they could meaningfully verify anything.
This is one reason single-vendor audit and validation workflows produce cleaner records. The auditor's notes, the developer's fixes, and the final status all live in one place.
How validation works inside a tracking platform
The Accessibility Tracker Platform was built around this workflow. Each issue from the audit report sits in its own record with the WCAG success criterion, severity, location, description, and recommended fix. When a developer completes a fix, they update the status to ready for review. The auditor sees the queue, re-evaluates the fix, and updates the issue to passed or back to open with a note.
This replaces the older approach of emailing spreadsheets back and forth, which loses version history and creates confusion about which status is current. Inside the platform, every status change is timestamped and attributed.
Re-evaluating with assistive technology
Visual fixes can be confirmed by inspection. Fixes that affect screen reader output, keyboard navigation, or focus management require the auditor to re-evaluate the page or screen with the relevant assistive tech.
For example, a fix to an ARIA label needs to be confirmed by listening to how a screen reader announces the element. A fix to a modal's focus trap needs to be confirmed by tabbing through the page. Validation that skips this step records fixes that look correct in code but still produce the original issue for users.
What to do with partially addressed issues
Not every fix fully resolves the issue. A developer might address the primary instance of a problem on one template but miss recurring instances elsewhere. Validation should mark these as partially addressed with a clear note describing what remains.
Partial status is more accurate than forcing a binary pass or fail. It also gives the team a clear queue for the next remediation cycle without losing the work that was already completed.
Updating documentation after validation
Once validation is complete, the conformance record needs to reflect the new state. For SaaS companies, this typically means updating the ACR to show the current pass and partial counts against each applicable WCAG success criterion. For organizations preparing for an ADA compliance review or EAA compliance deadline, this means a refreshed audit report and tracking record that show the issues that were verified as resolved.
Documentation produced from validation carries more weight than developer claims alone because it reflects an independent re-evaluation against the original criteria.
Common mistakes to avoid
Treating a scan as validation. Scans flag approximately 25% of issues and cannot confirm whether a WCAG success criterion has been met. They are useful for catching regressions on automatable checks, not for verifying a remediation pass.
Skipping the re-evaluation step and trusting developer status updates. Developers fix what they understand the issue to be. The auditor verifies whether the fix actually addresses the criterion as written.
Letting validation lose freshness. Fixes shipped months ago without validation create a record that no longer matches the live product. Validation should run on a defined cadence tied to remediation cycles.
FAQs
Do I need a new audit after remediation, or is validation enough?
If the work is scoped to fixing issues from a recent audit, validation is the right pass. A new audit is appropriate when significant time has passed, the product has changed substantially, or you are evaluating areas the original audit did not cover.
How long does validation take?
Validation is faster than a full audit because the scope is defined. The time depends on issue count and how many require assistive tech re-evaluation. A report with 40 issues can often be validated within a few business days when fixes are clean and well documented.
Can validation be done in-house?
It can be when the in-house team includes an auditor with the training to evaluate against WCAG success criteria. For most teams, the cleaner path is to have the same vendor that conducted the audit also conduct the validation pass.
What happens if an issue still fails validation?
The issue stays open with notes explaining what was identified during re-evaluation. It returns to the developer queue for another remediation cycle, then back through validation. The tracking record shows the full history.
Validation is the step that turns remediation work into documented conformance. The Accessibility Tracker Platform keeps that work organized so every fix is reviewed, recorded, and reflected in the documentation your team relies on.
Contact the Accessibility Tracker team to see how the platform supports audit, remediation, and validation workflows: Contact Accessibility Tracker.