Writing a VPAT That Actually Helps: A Technical Author's Guide

What Is a VPAT and Who Reads It?

A VPAT (Voluntary Product Accessibility Template) is a standardized document that reports how well a product conforms to accessibility standards. Despite the name, there's nothing voluntary about it for government contracts — Section 508 procurement officers require VPATs before purchasing any ICT product.

Your VPAT has three audiences: procurement officers (checking boxes), accessibility SMEs (evaluating claims), and legal teams (assessing risk). A good VPAT serves all three by being honest about non-conformances while demonstrating a clear remediation path.

The Five Most Common VPAT Mistakes

After reviewing 200+ VPATs for federal procurement, these failures appear repeatedly:

• Blanket 'Supports' with no remarks — procurement teams immediately distrust VPATs where every criterion says 'Supports' with empty remarks columns. Real products have partial conformances.
• Testing only the login page — vendors test one page and extrapolate. Procurement officers test the whole product. Your VPAT will be contradicted in evaluation.
• Confusing 'Does Not Support' with 'Not Applicable' — if a criterion doesn't apply to your product (e.g., 'captions' for a text-only tool), mark it N/A. 'Does Not Support' means it applies and you fail.
• No remediation timeline — for 'Partially Supports' or 'Does Not Support' items, include when you plan to fix them. '2.1.2 Keyboard trap in date picker — fix scheduled for Q3 2026' builds trust.
• Outdated version testing — if your VPAT references v3.2 but you're shipping v4.1, it's useless. Update VPATs with every major release.

VPAT Structure: ITI Format 2.5

The current standard format is VPAT 2.5, published by the Information Technology Industry Council (ITI). It has four reporting chapters depending on which standards apply to your product:

Chapter 1: WCAG 2.x (Level A, AA, AAA). Chapter 2: Revised Section 508 (for US federal). Chapter 3: EN 301 549 (for EU/EAA). Chapter 4: Platform-specific (iOS, Android, desktop apps). Most web applications need Chapters 1 and 2 at minimum, plus Chapter 3 if selling to EU public sector.

Writing Effective Remarks

The 'Remarks and Explanations' column is where credibility lives or dies. Good remarks are specific, honest, and actionable. Bad remarks are vague or defensive.

Bad: 'The product supports this criterion.' — This says nothing. Good: 'All form inputs have programmatically associated labels via <label for> or aria-labelledby. Custom date picker uses aria-label. Tested with NVDA 2024.2 and Chrome 124.'

For partial conformances, include: what works, what doesn't, which pages/components are affected, and remediation timeline. Example: 'Partially Supports. Main navigation and all form pages conform. Data visualization charts lack programmatic text alternatives — remediation planned for v5.2 (September 2026).'

Automating VPAT Evidence Collection

The biggest time sink in VPAT creation is evidence collection — testing each criterion against your product and documenting the result. RegLayer automates this for testable criteria (roughly 60% of WCAG SC).

Workflow: Run a full-site scan → export results grouped by WCAG criterion → each criterion gets a conformance level (Supports/Partially/Does Not Support) based on violation count and severity → paste into VPAT template with specific page URLs as evidence.

For the remaining 40% requiring manual testing (meaningful alt text, logical reading order, etc.), use the scan results as a starting point — they tell you which pages to manually test first based on automated issue density.