Section 508 for federal contractors: how to read an Accessibility Conformance Report

Selling to the U.S. federal government? You will need an ACR/VPAT. Here is what each section of the document actually means, what evaluators check, and where contractors most often fail.

If you're selling software, content, or services to a U.S. federal agency, Section 508 of the Rehabilitation Act applies. The law requires that information and communication technology procured, used, or developed by the federal government be accessible to people with disabilities.

Practically, that means you'll be asked for a document called an Accessibility Conformance Report — usually based on a template called the VPAT (Voluntary Product Accessibility Template). These two terms are often used interchangeably; technically VPAT is the template format and ACR is the completed document.

The standard you must conform to

The Section 508 ICT Refresh of January 2018 harmonized U.S. federal accessibility requirements with WCAG 2.0 Level AA. The 2024 update (incorporating Revised 508 Standards from the U.S. Access Board) raised the bar to WCAG 2.1 Level AA. Federal procurement RFPs typically ask for an ACR conforming to whichever WCAG version the agency's policy requires — 2.1 AA is now the safe default; 2.2 AA is the forward-compatible choice.

What a VPAT/ACR actually contains

The current template is VPAT 2.5 Rev INT (the international revision). It has five chapters — federal procurement asks specifically for the “508” column.

Chapter 1: Application of 508

States which functional performance criteria apply to your product. For most web-based software this is “Web (E205.1)” and possibly “Software (E205.2)” or “Hardware” depending on what you ship.

Chapter 2: WCAG 2.x criteria

For each WCAG criterion at Level A and AA, you state one of:

• Supports — the product fully meets the criterion.
• Partially Supports — meets it in some places but not all. You must list the exceptions in the “Remarks and Explanations” column.
• Does Not Support — does not meet the criterion. Be honest here; evaluators are reading for deception, not perfection.
• Not Applicable — the criterion doesn't apply (e.g. you have no audio content, so audio-related criteria don't apply). Brief rationale required.
• Not Evaluated — you have not formally tested. Avoid this on AA criteria; it weakens your ACR considerably.

Chapter 3-5: Functional Performance, Hardware, Software, Documentation

Less-frequently used in pure-web procurement, but federal evaluators do read them. Functional Performance Criteria (FPC) describe end-to-end task completion by users with disabilities — “a user who is blind can complete the primary tasks without sighted assistance.” You attest with the same Supports / Partially Supports / etc. language.

What evaluators actually check

Federal accessibility evaluators (typically GSA's Office of Government-wide Policy or the agency's own 508 coordinator) will:

• Run automated scans on the product themselves to spot-check “Supports” claims that should be “Partially Supports.”
• Test the most critical functional flows with a screen reader (NVDA on Windows is the federal go-to) and keyboard-only navigation.
• Cross-reference your ACR's “Remarks” against observed behavior. Vague remarks (“Some images may lack alt text”) earn follow-up questions; specific remarks (“Decorative images in the dashboard sidebar lack alt text; remediation tracked in JIRA-1234, target Q3 2026”) earn confidence.

Where contractors most often fail

1. Claiming “Supports” on judgment criteria. Color contrast (1.4.3), focus visibility (2.4.7), name-role-value (4.1.2) — these have programmatic and judgment components. If your ACR says “Supports” for all of them and an evaluator finds even one button with insufficient contrast, your credibility for the whole ACR drops.
2. Filling in the ACR without ever testing with assistive technology. Federal evaluators can tell. ACRs based purely on automated scans miss the AT-specific failures that an actual screen-reader user would hit immediately.
3. Stale ACRs. An ACR is a snapshot. If yours is from 2022 and you've shipped four major releases since, the evaluator will ask for a current one. Update on each major release at minimum.

How to prepare

A defensible ACR comes from three workstreams running in parallel:

1. Automated scanning of the whole product, ideally on every release. This is what tools like Plumb are for: continuous regression coverage of the programmatic criteria.
2. Manual audit by a trained accessibility specialist on critical flows, at minimum once per major release. This is what an ACR's judgment-criterion claims must be backed by.
3. End-user testing with assistive technology users, at least annually. This is what raises an ACR from “passing” to “genuinely accessible.”

Plumb covers workstream #1, automatically and on a schedule. We don't replace workstreams #2 and #3 — but our reports are formatted to feed directly into your ACR's “Remarks” columns, with specific WCAG criterion mapping, page-level findings, and remediation guidance.