# Accessibility Audit Report Format

For product and engineering teams, an accessibility audit report is useful only if it helps people fix issues.

A scan export is not enough for serious remediation. Teams need scope, evidence, expected behavior, actual behavior, severity, standard mapping, and retest status.

## What the report should cover

Start with context:

- What was tested?
- Which standard was used?
- Which journeys were included?
- Which tools and manual checks were used?
- Which environments were tested?
- What was excluded?

This prevents confusion after delivery.

## Write findings like defects

An accessibility finding should be reproducible.

Include:

- Page or screen.
- Component.
- Steps to reproduce.
- Expected result.
- Actual result.
- User impact.
- WCAG criterion.
- Severity.
- Suggested fix.
- Retest status.

This is the format implementation teams can use.

## Explain severity

Severity should not be arbitrary.

It should reflect user impact, task criticality, frequency, workaround availability, and remediation urgency.

For example, a keyboard trap inside checkout is not the same as a minor decorative image issue.

## Support remediation

Good reports explain the expected accessible outcome.

They help teams decide whether the fix belongs to design, engineering, content, documents, or a vendor-controlled component.

## Include retest closure

After fixes are deployed, the report should show whether each issue was retested and what the result was.

That makes the audit trail stronger.

## Conclusion

A good audit report format makes accessibility work easier to prioritize, assign, remediate, and verify.

The report should be structured for action, not only documentation.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/accessibility-audit-report-format-websites-web-apps