What Section 508 VPAT Means and How Organizations Use It

If you sell software, websites, portals, or digital services to the U.S. federal government, you’ll eventually get asked for a “VPAT.” People treat it like a certificate you can buy once and forget.

A VPAT is a reporting format. When it’s filled out properly, it becomes an Accessibility Conformance Report (ACR) that procurement teams use to judge accessibility risk during buying decisions.

• Section 508 is a U.S. federal requirement for accessible ICT (information and communication technology).
• Federal agencies must consider accessibility when they develop, procure, maintain, or use ICT.
• A VPAT is the template used to document conformance. The completed document is an ACR.
• There is no VPAT certification. Nobody “certifies” you under Section 508 via a VPAT.

What Section 508 Actually Covers and Who It Applies To

Section 508 applies to U.S. federal agencies. The law requires agencies to provide comparable access to information and data for people with disabilities when agencies use electronic and information technology.

So why do private companies care? Because agencies can’t responsibly buy tools they can’t use. If you’re a vendor, you’re expected to explain how your product performs against the relevant accessibility requirements. That’s where the ACR comes in.

The Revised 508 Standards

The “508 Refresh” (Revised 508 Standards) is the modern baseline most people mean when they say “Section 508 compliant.”

Here’s the key part: the Revised 508 Standards incorporate WCAG 2.0 Level AA and apply those success criteria to both web and non-web electronic content.

That matters because Section 508 is not only about public web pages. It can include things like:

• SaaS apps and dashboards
• PDFs and downloaded documents
• in-app help content and support documentation
• UI components that run inside a web interface

Clarifying the VPAT and ACR: Precision Matters in Procurement

A common point of confusion is the conflation of the VPAT and the final report. The Voluntary Product Accessibility Template (VPAT) is the standardized questionnaire. The completed document, with your product's detailed assessment results, is the Accessibility Conformance Report (ACR).

When a procurement officer asks, "Do you have a VPAT?", they are requesting the actionable ACR for review. Understanding this distinction is a mark of professionalism.

A Note on Certification

It is essential to clarify: there is no such thing as "VPAT certification." The governing body, the Information Technology Industry Council, explicitly states this. Using the term "certified" can undermine credibility with informed buyers, making your claims appear uninformed or misleading.

That’s why wording matters. “Get certified” is the fastest way to make your content look uninformed, or worse, salesy in a way procurement teams hate.

What Federal Buyers Use an ACR For

A well-prepared ACR exists to efficiently answer a buyer's core due diligence questions:

• Which specific accessibility standards were applied in the assessment?
• What was the exact scope of the tested product (versions, components, key user paths)?
• For each requirement, what is the level of conformance: full support, partial support, or a barrier?
• Are any limitations documented transparently, with clear explanations of their impact?

As highlighted by Section508.gov, this clarity is why ACRs are a critical tool for contracting officers during market research and vendor evaluation, enabling informed and defensible procurement decisions.

Maintaining Credibility with Current VPAT Standards

The VPAT template evolves. Submitting a report based on an outdated version or reusing a stale assessment undermines your credibility from the outset. It signals a lack of awareness of current standards.

The official VPAT resources, including the latest templates and authoritative guidance, are maintained by the Information Technology Industry Council.

For federal procurement, your Accessibility Conformance Report must demonstrate contemporary knowledge. A clean, properly scoped ACR using the current template shows professionalism. Reports built on old formats or filled with vague claims are often dismissed during initial review.

The ADACP Approach: Deliverable-Focused Evaluation

A credible Accessibility Conformance Report requires more than automated scans. It is built on a foundation of expert-led testing, a precisely defined audit scope, and unambiguous documentation that states compliance levels and explains any limitations.

This defines our core service: We conduct manual accessibility evaluations against the relevant standards and deliver a finalized ACR. Our deliverable is designed for immediate utility in the procurement process, providing clear answers that facilitate decision-making and reduce back-and-forth.

What Federal Buyers Actually Look for in an ACR (and What Gets Ignored Fast)

A federal buyer’s goal is rarely to trap you. They need a straightforward answer: Will purchasing this product create preventable accessibility issues down the line?

A robust Accessibility Conformance Report (ACR) provides that answer with confidence. It resolves the buyer’s central concern. A vague or incomplete report, however, triggers a cycle of clarifying questions, procurement delays, or a straightforward rejection—often without explicit feedback.

1) Scope: What Exactly Does This ACR Cover?

The fastest way to lose trust is to make the report look “universal” when it’s actually about one product version and a handful of screens.

The fastest way to lose trust is to make the report sound “universal” when it actually applies to one product version and a handful of screens.

Product Name and Exact Version/Build

Always state the full product name and the specific version or build evaluated. If you don’t, buyers can’t tell whether the report matches what they’re actually buying.

Platforms Covered (Web App, iOS, Android, Desktop)

Be explicit about where the evaluation applies. If you imply it covers everything, it starts to look like “one ACR for everything,” which undermines credibility.

What’s in Scope: Core Flows, Templates, Key Screens

Clearly describe what was actually tested: primary user journeys, shared components, critical templates, and high-risk screens. If this isn’t defined, gaps show up during demos and immediately damage trust.

What’s Out of Scope (and Why)

List exclusions and explain the reasoning. If you don’t, those exclusions become unpleasant surprises during procurement and can turn into risk flags.

2) Testing Approach: “We Tested It” Is Not Enough

A good ACR doesn’t pretend the product is perfect. It shows how you evaluated it and what evidence you used.

A good ACR doesn’t pretend the product is perfect. It explains how the evaluation was done and what evidence supports the findings.

Manual Testing is Clearly Stated

Buyers expect to see that manual testing was performed. Weak ACRs say “we ran a tool” or vaguely claim the product was “tested for compliance,” which signals shallow review.

Assistive Technologies are Listed

Specify which assistive technologies were used, such as screen readers, keyboard navigation, or zoom. If you don’t mention the real user setup, it looks like no real-world validation happened.

Browsers and Devices are Documented Where Relevant

Note the environments used during testing. Statements like “works everywhere” without detail reduce credibility instead of building it.

Repeatable Method Is Described (with Enough Detail to Trust It)

Outline a structured, repeatable evaluation approach. If the method is vague or filled with buzzwords, buyers assume there’s no substance behind the claims.

3) The “Supports / Partially Supports / Does Not Support” Problem

This is where most ACRs quietly collapse. Writing “Supports” with no explanation means nothing.

If You Mark: Supports

Your remark should include short proof. Explain what was checked and where it applies. A red flag is simply writing “Supports” with zero notes.

If You Mark: Partially Supports

Explain what fails, where it fails, and how users are impacted. A red flag is calling issues “minor” without describing them.

If You Mark: Does Not Support

State the clear limitation. If a workaround exists, describe it. A red flag is writing “N/A” when it’s not actually not applicable.

4) "Remarks and Explanations" Is the Whole Game

Most buyers skim. The Remarks column is what they actually read. That’s where credibility is built or destroyed.

Good remarks look like this:

• Specific pages or components are named. For example: “Checkout form error summary.”
• Clear user impact is described. For example: “Error not announced to screen readers.”
• Boundaries are defined. For example: “Applies to web app only.”
• Honest limitations are stated, along with a planned fix if relevant.

Bad remarks look like this:

• Generic phrases like “Meets requirement.”
• Vague statements such as “Works as expected.”
• Overbroad claims like “Applies to all platforms” without evidence.
• Empty promises or statements with no detail.

5) Don’t Forget What 508 Actually Includes

Many vendors focus only on the UI and ignore everything around it. That’s exactly what causes problems in federal reviews.

PDFs and Downloadable Documents

Federal users still rely on documents every day. If your PDFs are inaccessible, that’s a compliance failure, even if your interface looks perfect.

In-App Help, Knowledge Base, and Support Articles

Accessibility issues here are still issues. Help content is part of the user experience, not a decorative extra.

Emails, Exported Reports, and Generated PDFs

These often become official records or part of operational workflows. If accessibility breaks at this stage, the problem is not theoretical, it’s procedural.

Third-Party Components Embedded in Your Product

Using external vendors does not transfer responsibility. “The vendor built it” is not a shield during procurement review.

6) VPAT Version and Freshness (Yes, People Notice)

Outdated templates and stale reports hurt credibility. Not always a dealbreaker, but enough to make buyers cautious.

VPAT Version Used (for Example, VPAT 2.5)

State the exact version of the VPAT template. This shows the report is current and maintained.

Report Date and Review Date

Include both. It signals that the document wasn’t copied from an old archive and forgotten.

Product Version Clearly Tied to the Report

The evaluated product version must be explicitly connected to the ACR. This prevents “wrong version” disputes during procurement.

7) Quick Self-Check: Would Your ACR Survive a 2-Minute Skim?

If a buyer reads only the first page and scans the Remarks column, will they leave confident or confused?

If the honest answer is “no,” start fixing these areas first:

Scope Is Unclear

Add the exact product version, platforms covered, and clearly define what is in scope and out of scope.

Testing Sounds Vague

Explicitly state that manual testing was performed and list the assistive technologies used.

Too Many Empty “Supports” Entries

Add short, specific remarks where it matters. A single line of real evidence is stronger than a silent checkbox.

PDFs or Support Content Are Ignored

Either include them in scope or clearly exclude them and explain why. Silence here looks like oversight.

Where ADA Compliance Professionals Fit into the Section 508 Process

For federal buyers, Section 508 compliance boils down to managing accessibility risk. Their central concern is whether your product can be deployed without creating barriers for their users or jeopardizing their mission.

Our process delivers the clarity procurement teams need:

1. We pinpoint exactly what's being reviewed - specific versions, platforms, and critical user workflows.
2. Our experts manually evaluate the product against Section 508 standards, using the same assistive technologies as end-users.
3. We transform complex findings into a clear, VPAT-based Accessibility Conformance Report (ACR). We distinguish between full support, partial support, and barriers, explaining any limitations in plain language.

Transparency is our priority. Vague or overly optimistic reports erode confidence. A strong ACR demonstrates your organization's awareness and control, giving buyers the evidence to proceed and your team a precise roadmap for improvements.

This is the practical reality of Section 508 compliance: thorough evaluation, honest reporting, and documentation designed to build trust under scrutiny. Our role is to ensure your product and your proposal are built on that foundation.