Anatomy of an Accessibility Audit Report (Bug Report & ACR/VPAT)

Finding accessibility issues is only half of an auditor's job. The other half — which often determines professional standing — is the ability to document and communicate those findings in a way that is immediately actionable for the technical team receiving them.

"This button doesn't work with a screen reader" is a user complaint. "The div element with an onClick event listener lacks role=\"button\", tabindex=\"0\", and onKeyPress event handling, causing failure on WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A)" is a professional auditor's report.

This article teaches you how to write the second.

---

Two Primary Output Documents

A professional accessibility auditor produces two main types of documents:

1. Bug Report: An internal or project document listing specific issues found, reproduction steps, and remediation recommendations. This is the day-to-day communication tool with developer teams.
2. ACR (Accessibility Conformance Report) / VPAT: A formal document summarizing a product's conformance level against accessibility standards (typically WCAG 2.1/2.2 and Section 508). This is required in government procurement, enterprise contexts, or as legal evidence.

Every Access Squad member must be capable of producing both.

---

Anatomy of a Well-Written Bug Report

Each entry in an accessibility bug report must contain these components:

1. Issue Title

A good title immediately describes the problem and the affected component.

• ❌ Poor: "Image is not accessible"
• ✅ Good: "Product image on the PDP page lacks a descriptive alt attribute"

2. Location

The specific URL, screen name (for mobile), or navigation breadcrumb path to locate the issue.

• Example: https://example.com/product/running-shoe or App → Home → Product Card → Main Image

3. Steps to Reproduce

Instructions a sighted developer can follow to replicate the exact same issue.

Example:

1. Open https://example.com/product/running-shoe using NVDA + Chrome.
2. Press G to jump to the first image element.
3. Listen to what NVDA announces.
4. Expected Result: NVDA announces a meaningful description, e.g., "Photo of red running shoe model XR-200 from the side."
5. Actual Result: NVDA announces the filename, e.g., "img_prod_12345_final_v2.jpg" — meaningless to the user.

4. WCAG Mapping

Every issue must be mapped to a specific WCAG Success Criterion. This is what separates a professional auditor from an ordinary user.

Most Frequently Cited Success Criteria:

Success Criterion	Level	Brief Description
1.1.1 Non-text Content	A	All non-text content (images) must have a text alternative.
1.3.1 Info and Relationships	A	Information structure (heading, list, table) must be expressed via markup.
2.1.1 Keyboard	A	All functionality must be achievable via keyboard.
2.4.3 Focus Order	A	The navigation focus order must be logical and meaningful.
2.4.6 Headings and Labels	AA	Headings and labels must be descriptive.
4.1.2 Name, Role, Value	A	All UI components must have a name, role, and value that can be programmatically determined.
4.1.3 Status Messages	AA	Status messages must be programmable so they can be determined by assistive technology without a focus change.

5. Severity Assessment

Each issue has a different level of impact. Auditors must assess severity so developers can prioritize fixes.

Level	Description	Example
🔴 Blocker	A blind user cannot at all complete a critical task.	The "Pay Now" button cannot be focused via keyboard.
🟠 Critical	A blind user faces a major barrier that forces a far more difficult workaround.	A checkout form doesn't announce error messages, forcing the user to manually search the page.
🟡 Major	Experience is significantly impacted, but the task can still be completed.	Product images lack alt text — user can still purchase but loses product context.
🟢 Minor	A deviation from best practices that reduces experience quality.	Some links use "Click Here" text — identifiable from context, but not ideal.

---

Anatomy of a Professional ACR/VPAT

A VPAT (Voluntary Product Accessibility Template) is a standard template developed by ITI (Information Technology Industry Council). When a company wants to sell its product to the US government or large enterprise organizations, they are required to provide a completed VPAT.

An auditor fills in the VPAT on behalf of their client. Each row contains:

• Criterion: A reference to the WCAG Success Criterion.
• Conformance Level: One of: Supports, Partially Supports, Does Not Support, Not Applicable.
• Remarks: A concrete description of how the criterion is or is not met, with examples.

Example VPAT row:

Criterion	Conformance Level	Remarks
1.1.1 Non-text Content	Partially Supports	Product images on PDP and category pages lack alt text. Navigation icon images have appropriate alt text.
2.1.1 Keyboard	Does Not Support	The "Image Zoom" component triggered on hover cannot be accessed or dismissed via keyboard.

---

Key Tips for Access Squad Members

1. Always record versions. Note the application/OS version and screen reader used. Bugs can behave differently across versions.
2. Include screenshots (for your team). While you may not see them yourself, your sighted team members can capture screenshots for visual documentation that speeds up developer triage.
3. Avoid emotional language. Good reports are factual and neutral: "This component fails SC 4.1.2", not "This button is broken and useless."
4. Recommend, don't just report. Reports that include simple remediation suggestions will be far more valued by clients and developers.

---

Conclusion

The ability to write accurate and professional Bug Reports and ACR/VPATs is the skill that elevates an Access Squad member from "ordinary tester" to trusted accessibility consultant. This is the language understood by the corporate, legal, and technology worlds — and mastering it opens doors to far wider career opportunities.

References

- W3C. Understanding WCAG 2.1/2.2 Success Criteria. https://www.w3.org/WAI/WCAG21/Understanding/ - ITI. VPAT 2.x Template. https://www.itic.org/policy/accessibility/vpat - Lazar, J. et al. Ensuring Digital Accessibility Through Process and Policy.