WCAG Retest Report Checklist

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