Accessibility Audit Reports: Sample Structure

#a11y #wcag #digitalaccessibility #remediation

An accessibility audit report is only useful if the team can act on it.

For engineering and QA teams, a good report should feel similar to a high-quality defect record plus standards mapping plus user impact. It should not be a raw scanner export with a few screenshots attached.

Here is a practical structure to expect in a useful sample report.

Scope

Start with what was actually tested.

This should include:

Pages or screens
User journeys
Components
Documents or PDFs
Logged-in roles
Devices and browsers
Assistive technology assumptions
Standards used for review

Scope matters because a report cannot claim more than the audit covered.

Finding details

Each finding should give enough information to reproduce the issue.

At minimum, expect:

Issue title
Location
Steps to reproduce
Observed result
Expected result
User impact
Related standard
Severity
Remediation guidance

If the report does not explain the expected result, developers are left guessing.

Evidence

Evidence should be concrete.

Useful evidence might include a screenshot, selector, affected component, keyboard path, screen reader observation, document page number, or test note.

For example, "button is inaccessible" is weak.

"The modal close control is not reachable by keyboard after opening the account settings dialog" is actionable.

Severity model

Severity should map to real impact.

Consider:

Does this block a required task?
Does it affect a critical user journey?
Does it prevent screen reader or keyboard users from continuing?
Is it repeated across a design system component?
Does it affect a regulated or customer-facing workflow?

This helps teams decide which fixes need to happen first.

Standards mapping

For WCAG work, the report should map findings to success criteria.

For other contexts, the same issue may also need mapping to standards such as IS 17802, GIGW, Section 508, or EN 301 549.

This is useful for traceability because it connects the implementation issue to the audit basis.

Remediation guidance

Remediation guidance should describe the accessible behavior, not just the failed rule.

Examples:

Move focus into the modal when it opens.
Keep focus trapped inside the modal until it closes.
Return focus to the triggering control after close.
Expose the input label programmatically.
Preserve table header relationships.

This makes the report useful for engineering tickets.

Retest notes

The report should anticipate closure.

Retest notes should show what needs to be checked after remediation. For critical findings, the report should make it clear how a pass, fail, partial pass, or deferred status will be handled.