"Provide Evidence of Section 508 Conformance": What the Agency Reviewer Is Actually Looking For

The solicitation line is short. Offeror shall provide evidence of conformance with the Revised Section 508 Standards. Or, after award: Contractor shall submit accessibility test results for each deliverable prior to acceptance.

Many vendors answer it with the thing they have to hand — an automated scan report showing a high score, or a VPAT filled in with “Supports” all the way down. Both regularly come back. Not because the product is necessarily inaccessible, but because neither is evidence in the sense the reviewer means.

This post is about what they mean.

Who is reviewing, and what do they need to decide?

In most agencies the reviewer is a Section 508 program office staff member, a contracting officer’s representative, or an accessibility specialist supporting the acquisition. Their job is not to admire your product. It is to decide, defensibly, whether a deliverable conforms, and to be able to explain that decision later if a complaint arrives.

FAR Subpart 39.2 requires agencies acquiring information and communication technology to meet the accessibility standards at 36 CFR Part 1194, subject to documented exceptions. So a reviewer is effectively asking one question: if we accept this and it turns out not to conform, will the record show we had a reasonable basis for accepting it? What FAR 39.2 requires of vendors covers the obligation itself; this post is about the paperwork that satisfies it.

What does a reviewer expect to see?

Five things, whether or not the solicitation names them.

1. A conformance report against the right standard. For federal work that means an Accessibility Conformance Report built on the Section 508 edition of the VPAT (or the international edition, which includes it), covering the parts of the Revised 508 Standards that apply to the product. For web content and electronic documents, that is WCAG 2.0 Level A and AA, incorporated by reference. For software there are additional requirements in Chapter 5, and for documentation and support services, Chapter 6. The Chapter 3 functional performance criteria apply too. A report that addresses only WCAG, for a product that also has installable software or help documentation, is incomplete. What a VPAT is and how to fill one in honestly goes through the editions.

2. A named, repeatable test method. The single most useful thing you can write in an ACR is how you tested. Many federal agencies use the DHS Trusted Tester process, which is aligned to the ICT Testing Baseline developed under the federal CIO Council to give agencies a standard way to evaluate conformance with the Revised 508 Standards. Agencies that have adopted the Trusted Tester process generally accept results only from testers certified in it. Other agencies accept other documented methodologies. What they rarely accept is no methodology — a report whose conclusions cannot be traced to any repeatable procedure.

3. A defined scope. Which version, which build, which pages or screens, which user roles, which documents, on what date. A reviewer who cannot tell what was tested cannot tell whether the deliverable in front of them is the thing that was tested. Scope that says “the application” is a red flag; scope that lists the tested flows and states what was excluded, and why, is credible.

4. Honest conformance levels with remarks. Supports, Partially Supports, Does Not Support, Not Applicable — each with an explanation where it is anything other than a clean pass. A column of “Supports” with no remarks is the most common reason a reviewer starts testing themselves, because real software almost never conforms perfectly and the reviewer knows that. “Partially Supports — two data tables in the reporting module lack header associations; fix scheduled for release 4.3” is far more persuasive than an unexplained “Supports”.

5. The underlying defect record. Many reviewers want the test results behind the summary: the failures found, the success criterion each maps to, where it occurs, severity, and status. For deliverables such as documents or training modules, this is often a per-file log.

Why does an automated scan not count?

Because a scan answers a narrower question than the reviewer is asking.

Automated tools reliably detect some failures — missing alt attributes, empty links, certain contrast problems, missing form labels. They cannot decide whether alt text is accurate, whether reading order makes sense, whether a keyboard user can complete a task, whether an error message is announced, or whether a document’s tag structure reflects its meaning. A large share of WCAG success criteria require human judgement. Automated scan vs manual audit covers exactly where the line falls.

A scan report is useful supporting evidence that you ran a baseline check. Offered as the evidence, it tells an experienced reviewer that manual testing has not been done.

What about documents, training and translated deliverables?

This is where vendors most often underestimate the requirement.

Electronic documents delivered under a contract — reports, forms, training materials, slide decks — are ICT content and fall under the same standards. A reviewer will expect each PDF to be tagged with correct reading order and structure, each Word file to be built with real headings and table headers, and each video to be captioned and, where needed, audio-described.

When deliverables are translated, a reviewer who knows the standard will also check that each language version declares its language correctly (WCAG 3.1.1) and that passages in other languages are marked (3.1.2). A Spanish version that a screen reader reads with English pronunciation fails, even if the English original passed. Our post on translated documents and language of parts explains why this is so often missed.

How to put together evidence that holds up

Decide the method before you test. If the agency uses Trusted Tester, find out early, because it governs who can produce acceptable results.

Test the deliverable, not a demo. The version in the evidence should be the version you are submitting.

Write remarks for every non-pass. Include the planned fix and timing where there is one. Candour builds credibility; it also protects you if a defect is later found.

Keep the working files. Test logs, screenshots, assistive technology and browser versions, and dates. If the reviewer asks a question six months later, you want to answer it from the record.

Re-test after fixes. A conformance report is a snapshot. Deliverables accepted on a later build need evidence for that build.

Where Taika fits

We produce the document side of the evidence: remediated, tagged and screen-reader-tested PDFs, Word, PowerPoint and Excel files, with a per-file conformance log mapped to WCAG success criteria — in English and in every language your contract requires. We meet and exceed ISO 17100, 9001 and 27001 standards. We do not promise an acceptance outcome; we give the reviewer something testable.

Facing a 508 evidence requirement on a current solicitation or contract? Send us the clause text, the deliverable types and approximate page or file counts, the languages required, and your submission date — then request a quote. Our Section 508 remediation page covers how we scope federal document work.