Retesting accessibility issues should feel like verifying production defects.
The goal is not to confirm that code changed. The goal is to confirm that the user-facing barrier is gone.
Link to the original issue
Every retest row should include:
- Original issue ID.
- Affected screen.
- Component or workflow.
- WCAG criterion.
- Original severity.
- Original reproduction path.
This keeps the retest traceable.
Repeat the failing path
Use the same failure path from the original report.
For example:
- Navigate with keyboard only.
- Open and close the modal.
- Trigger the form error.
- Use the screen reader path.
- Download the fixed PDF.
- Submit the payment or test transaction.
If the original path still fails, the issue is not fixed.
Record a useful status
Do not use only "done."
Use statuses such as:
- Fixed.
- Partially fixed.
- Not fixed.
- Deferred.
- Unable to verify.
- Out of scope.
These are more useful for sprint planning and risk reporting.
Check regressions
Fixes can create new accessibility bugs.
Check related states:
- Error.
- Loading.
- Disabled.
- Expanded.
- Collapsed.
- Mobile.
- Zoomed.
- Reused component instances.
Capture evidence
Evidence can include screenshots, recordings, browser details, assistive technology notes, app version, document version, or retest notes.
Choose evidence based on the issue type.
Conclusion
A WCAG retest report should prove closure with behavior, evidence, and status.
That is what makes remediation auditable.
Read the original guide on IAAP Audit: https://iaapaudit.com/blog/accessibility-retest-report-after-remediation
