Section 508 VPAT: How to Document Accessibility Compliance for Federal Buyers

A “Section 508 VPAT” is one of the most searched (and most misunderstood) terms in accessibility compliance. If you sell software, websites, or digital services to the U.S. federal government—or to organizations that follow federal purchasing rules—you’ll likely be asked for a VPAT. The goal is simple: provide a standardized way to describe how your product supports accessibility requirements, where it falls short, and what evidence backs up your claims.

This article explains what a VPAT is, how it relates to Section 508 and WCAG, what an ACR is, and how to complete a VPAT in a way that procurement teams can trust.

What is a VPAT in Section 508?

VPAT stands for Voluntary Product Accessibility Template. It’s a document format created to help vendors report accessibility conformance in a consistent structure. When completed, the VPAT becomes an ACR (Accessibility Conformance Report).

Section 508 refers to U.S. federal accessibility requirements for electronic and information technology. In practice, a VPAT is how many buyers evaluate whether a product meets those requirements—especially during procurement and vendor due diligence.

VPAT vs. Section 508 vs. WCAG (how they connect)

• Section 508 is the U.S. legal/procurement requirement for federal agencies (and often for state/local agencies, universities, and contractors).
• WCAG (Web Content Accessibility Guidelines) is the technical standard most commonly used to evaluate web and digital content accessibility.
• VPAT/ACR is the reporting format used to describe how a product conforms to Section 508 and/or WCAG (depending on the VPAT edition).

In other words: WCAG tells you what to do; Section 508 tells you what’s required for certain buyers; and a VPAT/ACR tells them how your product measures up.

Which VPAT do you need? (508, WCAG, EN 301 549)

The VPAT is published in different “editions” so you can report against different standards. The most common are:

• Section 508 Edition: Focused on U.S. federal requirements.
• WCAG Edition: Focused on WCAG success criteria (often requested by private sector buyers too).
• EN 301 549 Edition: Used for EU/public-sector procurement and broader ICT accessibility requirements.

Many organizations choose a VPAT that covers multiple standards to avoid maintaining separate documents. Your buyer may specify which edition and version they accept, so confirm requirements early in the sales or procurement process.

Why buyers request a VPAT (and what they look for)

Procurement teams use VPATs to compare vendors, document risk, and ensure accessibility is considered before purchase. But they don’t just want “Supports” checked everywhere. They typically evaluate:

• Accuracy: Are claims supported by evidence and realistic limitations?
• Completeness: Are all applicable criteria addressed with meaningful remarks?
• Test methodology: Was there manual testing, assistive technology testing, and coverage across key user flows?
• Roadmap: If gaps exist, is there a credible remediation plan and timeline?

If you’re still unsure about your current level of accessibility, it helps to start with a baseline assessment—see Is Your Website Accessible? Here’s How to Find Out for a practical overview of discovery methods and early indicators.

How to fill out a Section 508 VPAT (step by step)

1) Define the product scope and conformance target

Be explicit about what the VPAT covers: public website, authenticated app, admin dashboard, mobile app, PDFs, help center, etc. Accessibility can vary drastically across modules, so scope clarity prevents misunderstandings later.

2) Identify supported platforms and assistive technologies

Document the environments used during testing (for example, Windows + Chrome + JAWS, macOS + Safari + VoiceOver, mobile screen readers). VPAT reviewers expect you to specify tested combinations, not just “works with screen readers.”

3) Perform testing: automated + manual + AT validation

A defensible VPAT requires more than automated scans. Automation can catch issues like missing labels or color contrast problems, but it cannot reliably evaluate keyboard traps, dynamic focus management, or the quality of alternative text. Consider combining:

• Automated audits for coverage and monitoring
• Manual inspection for semantics, forms, dialogs, and complex components
• Assistive technology testing for real user interaction patterns

Platforms like Corpowid (corpowid.ai) can help teams run automated accessibility audits and ongoing monitoring so common regressions don’t reappear between releases—especially useful when you’re maintaining a VPAT that must stay current as the product changes.

4) Use the correct conformance labels—and explain them

VPAT tables typically include response options such as:

• Supports: Fully meets the criterion as written.
• Partially Supports: Some aspects meet, others don’t (explain precisely).
• Does Not Support: Does not meet the criterion (document impact and plan).
• Not Applicable: The criterion doesn’t apply to the product (justify briefly).
• Not Evaluated: Not tested (use sparingly and be transparent).

The most important column is usually Remarks and Explanations. That’s where you describe what works, what doesn’t, known exceptions, and any workarounds. Vague notes like “planned” or “in progress” are red flags; buyers want specifics.

5) Provide evidence and reproduce steps

A strong VPAT includes reproducible details. For example: “In checkout, the coupon input lacks an associated programmatic label; screen readers announce ‘edit text’ without context.” This level of specificity helps procurement teams understand severity and helps your engineers remediate efficiently.

Common VPAT mistakes that create procurement risk

• Marking “Supports” everywhere despite known issues (this undermines trust and can backfire in audits).
• No keyboard testing for critical flows like login, checkout, or form submission.
• Ignoring documents and media (PDF accessibility and captioning are frequent gaps).
• Overlooking design-system components like modals, menus, tabs, and custom controls.
• Failure to update after major releases—VPATs can go stale fast.

Legal and reputational risk isn’t hypothetical. Accessibility enforcement and lawsuits affect both public and private organizations, as illustrated in Fashion Nova’s $5.15 Million Web Accessibility Settlement: What It Means for WCAG Compliance and the public-sector reminder in Louisiana Website Accessibility Case: Government Sites Are Not Exempt.

Inclusive design practices that make VPATs easier

VPAT completion is smoother when accessibility is built into design and development workflows. A few high-impact practices:

• Design with semantics in mind: Ensure components map cleanly to native HTML patterns and ARIA only when necessary.
• Plan for text alternatives early: Decorative vs. informative images, icon-only buttons, charts, and complex visuals need thoughtful alt text.
• Keyboard-first component QA: Verify focus order, visible focus indicators, and escape behavior for dialogs.

For design teams, strengthening alt-text workflows is a practical win—see Alternative Text in Figma: Designing Accessible UI with WCAG in Mind for guidance that translates directly into fewer VPAT exceptions.

How to keep your VPAT current over time

A VPAT is not a one-time deliverable. Products change, UI frameworks update, content editors publish new pages, and regressions happen. To keep your VPAT credible:

• Version your ACR alongside product releases and document what changed.
• Retest critical user journeys each release (authentication, navigation, forms, checkout, account settings).
• Track issues like bugs with severity, criteria mapping, and remediation owners.
• Monitor continuously for new issues introduced by content or code changes.

Corpowid (corpowid.ai) can support this maintenance approach by flagging accessibility issues through automated audits and monitoring, helping teams keep accessibility documentation aligned with the current state of the site rather than last quarter’s release.

Who benefits from Section 508 VPAT readiness?

VPAT readiness isn’t only for federal agencies. Government contractors, higher education institutions, healthcare, and many nonprofits also request accessibility conformance documentation as part of responsible procurement. If you work in the nonprofit space, the broader compliance and inclusion context in Digital Accessibility for NGOs & Non-Profit Organizations helps explain why accessibility documentation matters beyond “checking a box.”

Conclusion: treat the VPAT as a trust document

A Section 508 VPAT (ACR) is ultimately a trust document: it communicates how your product performs for people with disabilities and how seriously your organization takes accessibility risk. The best VPATs are scoped clearly, tested rigorously, written precisely, and kept up to date—supported by an accessibility program that continuously improves real user experience.