The RFP Line Nobody Explained
A small software vendor wins its first federal contract and celebrates for about a week. Then someone on the team actually reads the RFP requirements in full and finds a line requiring a completed VPAT before the contract can be signed. Nobody on the team has heard the term before. A quick search turns up a wall of government jargon — Section 508, EIT, ICT, EN 301 549 — and no clear starting point.
This is a common moment for a growing vendor, and it's a solvable one. Section 508 is not a mysterious, separate accessibility universe. It's a specific federal legal framework that, for the technical parts that matter most, maps closely onto WCAG — the same standard covered throughout the rest of this blog. Here's the actual shape of the requirement, and what to do about it.
What Section 508 Actually Is
Section 508 is an amendment to the federal Rehabilitation Act of 1973. It requires federal agencies to make their electronic and information technology (referred to as ICT — Information and Communication Technology) accessible to people with disabilities. That scope is broad: websites, software applications, internal tools, PDFs and other documents, and electronic content that a federal agency produces, procures, maintains, or uses.
The critical phrase there is "produces, procures, maintains, or uses." Section 508 applies directly to federal agencies as the legal obligation-holder — but it reaches private businesses indirectly, and significantly, through procurement. Any vendor or contractor selling ICT products or services to the federal government is contractually required to meet Section 508 standards as a condition of winning and keeping that contract. It stops being a government policy question and becomes a sales-cycle requirement the moment your product shows up in front of a federal buyer.
The 2018 Refresh: Section 508 and WCAG Converged
For years, Section 508 had its own separate, government-specific technical standard, distinct from WCAG. That changed with the "Section 508 Refresh," which took effect in January 2018. The refresh updated the technical standard to directly incorporate WCAG 2.0 Level A and AA success criteria by reference, rather than maintaining a parallel set of government-only rules.
The practical upshot: Section 508 conformance and WCAG 2.0 Level AA conformance are now largely the same technical bar. In practice, many federal agencies and the vendors selling to them now aim higher — WCAG 2.1 or 2.2 AA — as current best practice, since those later versions are strict supersets that only add coverage rather than removing anything. If your organization is already targeting WCAG 2.1 or 2.2 AA for other reasons (ADA risk, EU market access, general product quality), you are, for practical purposes, already targeting the current substance of a Section 508 requirement too.
What a VPAT Actually Is
The VPAT — Voluntary Product Accessibility Template — is the standard document vendors complete to describe how a specific product conforms to Section 508's technical criteria. The name is a source of real confusion: despite "voluntary" sitting right there in the name, a VPAT is frequently a required part of a federal bid or RFP response in practice, not an optional nicety. If an RFP asks for one, it isn't optional for that bid.
Once a vendor fills out a VPAT with actual findings, the completed document is often referred to as an ACR — an Accessibility Conformance Report. A VPAT/ACR walks through each relevant success criterion and marks it as "Supports," "Partially Supports," "Does Not Support," or "Not Applicable," along with explanatory remarks justifying that determination.
That last part is where a lot of vendors get into trouble. Filling out a VPAT honestly requires the same underlying work as any real WCAG audit — actually testing the product against each relevant criterion, not guessing or copying a competitor's boilerplate. A VPAT is a reporting format. It is not a substitute for the remediation and testing work it's supposed to summarize.
Beyond Federal Agencies
Section 508's reach doesn't stop at direct federal contracts. It also extends to organizations receiving federal funding in some contexts, and many state and local governments have adopted their own procurement standards modeled directly on Section 508 and WCAG. A vendor selling into state government IT contracts may encounter language that looks and functions exactly like a Section 508/VPAT requirement, even without the federal government being the direct buyer.
This matters for planning purposes: if your product is starting to show up in public-sector RFPs at any level, it's worth assuming a VPAT-style question is coming, rather than being surprised by it the way the vendor in the opening scenario was.
A Practical Starting Point
If your organization is facing a Section 508/VPAT requirement for the first time, the sequence that actually works is straightforward, if not fast:
- Run a genuine WCAG audit. Test the real product — not a marketing site, the actual application a federal user would use — against WCAG 2.1 or 2.2 Level AA, criterion by criterion. Automated scanners alone won't get you a defensible VPAT; manual keyboard and screen reader testing is required for a meaningful chunk of the relevant criteria.
- Remediate the highest-impact failures first. The same Tier 1 priorities that apply to any WCAG remediation effort apply here: keyboard access, form labeling, color contrast, and visible focus indicators tend to be the failures that block the most users and draw the most scrutiny.
- Complete the VPAT based on actual test results. Fill in each criterion's status honestly, based on what your testing actually found — not on an optimistic assumption of "probably fine." An inaccurate VPAT creates both reputational risk (a federal accessibility office catching a discrepancy) and contractual risk (a claim your product doesn't actually support what the VPAT states).
- Keep it current. A VPAT reflects the product at a point in time. If the product changes meaningfully, the VPAT should be revisited — an outdated VPAT handed to a new buyer is functionally the same risk as an inaccurate one.
Get It Right Before the Bid Is Due
The vendor from the opening scenario didn't need to panic — they needed an actual audit, not a guess dressed up as a compliance document. A VPAT built on real testing is a genuine asset in a federal sales process: it signals the organization did the work rather than checked a box. A VPAT built on assumptions is a liability waiting to surface at the worst possible moment, usually during a security or accessibility review well into the deal.
If a Section 508/VPAT requirement just landed on your desk, don't start by filling out the template — start with a real WCAG audit so the VPAT you eventually submit is something you can actually stand behind.