Short answer: that PDF is in scope, by name, in the standards a VPAT reports against — it is not a grey area you can leave for later. The section where this goes wrong is the one covering non-web documents, and it goes wrong for a specific reason: whoever fills in a VPAT tests the product they use every day — the web app, the dashboard, the settings screen — and the export path is something they click once, glance at, and move on from. A VPAT template does not omit documents. Teams do.
What a VPAT actually is, and which one to send
The VPAT — Voluntary Product Accessibility Template — is published by the Information Technology Industry Council (ITI), and a filled-in copy is what buyers call an Accessibility Conformance Report (ACR). The current release is VPAT 2.5Rev, April 2025, published in four editions on ITI's VPAT page: 508 (Revised Section 508 alone), EU (EN 301 549 alone), WCAG (WCAG 2.0/2.1/2.2 alone), and INT, which folds all three standards into one document. Government contracts usually name the standard, which tells you the edition; if in doubt, the INT edition answers every audience at once.
Worth knowing before you download the wrong VPAT template: Section508.gov's own contractor-facing guidance still names 2.4 as "the current version," while ITI's site has moved on to 2.5Rev. Both are right in their own way — Section508.gov also says "any VPAT 2.x is acceptable" — but even federal reference pages lag the publisher, and the safest move is to fetch the template from itic.org rather than from whatever link a colleague bookmarked two years ago.
The vocabulary you're committing to
A VPAT does not let you describe conformance in your own words. Every criterion gets one of four terms, and the template itself defines them precisely:
- Supports — "The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation."
- Partially Supports — "Some functionality of the product does not meet the criterion."
- Does Not Support — "The majority of product functionality does not meet the criterion."
- Not Applicable — "The criterion is not relevant to the product."
There is a fifth term, Not Evaluated, reserved for WCAG Level AAA criteria only — it is not a way to skip a criterion you simply haven't checked at Level A or AA. And ITI's instructions are direct about who owns the answer: "It is the vendor's responsibility to maintain the integrity of the data in the report."
Documents are named, not implied
Two standards make the scope explicit, and neither treats "documents" as an afterthought to the web.
EN 301 549
EN 301 549, the EU's ICT accessibility standard published by ETSI (the version currently referenced in the VPAT's EU edition is V3.2.1 (2021-03)), gives non-web documents their own clause. Clause 10.0 states the scope in plain terms: it covers "documents that are not web pages," documents "not embedded in web pages," and — this is the part exporters miss — documents "provided with web pages but... neither embedded nor rendered together with the web page from which they are provided," which the clause glosses as simply "downloadable documents." A PDF invoice your product generates and lets a user download is precisely what clause 10 is written for.
Section 508
Section 508 reaches the same PDF from two directions in the Access Board's ICT standards. E205 scopes "electronic content" that is public-facing or used for official business, requiring it to meet WCAG 2.0 Level A and AA. And 504.2, in the software chapter, reaches further back — to the tool that made the document: "Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0... to file formats supported by the authoring tool." If your product exports PDFs, your product is, in the standard's own terms, an authoring tool. The VPAT's document row is not asking about a PDF a customer happened to upload — if export is a feature, it is asking about your export path.
What our own measurement shows about that path
We validated 59 Word-exported public-sector PDFs — the census is described in our earlier piece on Word's own accessibility checker — against PDF/UA-1 with veraPDF 1.30.2 (build 2026-06-03). You do not need a terminal to see the same failures on your own export: any PDF/UA validator reports them, including the checker linked at the end of this piece.
The exact command, if you want to reproduce the run
~/.local/share/verapdf/verapdf -f ua1 --format json document.pdf
None of the 59 conformed. The three most common failures were:
| Failure | Share of files |
|---|---|
| No PDF/UA identifier in the metadata | 71% |
No dc:title in the XMP metadata stream |
68% |
| Fonts not embedded | 64% |
A missing title is the document-level analogue of WCAG 2.4.2 Page Titled — it is why a screen reader announces a filename instead of a document name. Unembedded fonts undermine reliable text extraction, which is what most of clause 10's "Perceivable" and "Robust" requirements ultimately depend on. A product whose default export path produces files like these has no honest way to write Supports on the non-web-document rows of its VPAT. The accurate entry is Partially Supports at best, with the specific failure named in the Remarks and Explanations column — which the template requires whenever the answer isn't a clean Supports.
How a Supports claim actually gets checked
Nobody at ITI tests your product before you publish a VPAT. The template has no certifying body behind it: nobody signs off on the claims before you publish them, and the honesty stays unverified until someone downloads one of your files.
Two mechanisms exist for that verification, and both put the burden on the buyer. First, every VPAT requires an Evaluation Methods Used field, describing "the testing performed" — whether it was manual, automated, or by testers who know the product. A row of Supports backed by "we ran an automated scanner" and one backed by "tested with NVDA and JAWS by a tester unfamiliar with the product" are not the same claim, even though the cell says the same word. Second, Section508.gov's own procurement guidance tells federal buyers not to stop at the document: "Trust but verify: before awarding a contract... conduct accessibility testing to validate that the technology products and services in question are fully accessible," because "an expert review of Section 508 conformance claims may provide an indication of accessibility, [but] rigorous testing is required to validate these claims." Some federal contract clauses go further and require the vendor to run that testing itself and hand over the results before award.
In practice: a VPAT that reads well on paper gets tested on the actual files it claims to cover, sooner or later, by someone who downloaded your product's PDF output and opened it in a screen reader or a validator. Careful buyers open that file early, and the gap between the claim and the file is usually the first thing they find.
What a VPAT genuinely can't tell a buyer
Two limits are worth stating plainly, because a sales-facing document has every incentive to skip them.
PDF/UA-1 — the standard our own measurement above tests against — is not the same test as the WCAG-based criteria that EN 301 549's clause 10 and Section 508's E205 actually specify. The two overlap heavily on structure, titles and reading order, but they are not interchangeable: a file can satisfy PDF/UA-1's mechanical checks and still miss a WCAG-worded criterion clause 10 asks for, or the reverse. A "Supports" backed only by a PDF/UA pass is evidence, not proof, for the row it's written against.
And a VPAT describes one version of one product's default behaviour at one point in time. It says nothing about the next release, and — for any product where a user supplies the content, rather than the product generating a fixed report — it can't promise that every document a customer creates with it will match the sample that was tested. That caveat rarely survives into the sales conversation, but it belongs in how a buyer reads the document, not just in how a vendor writes it.
Where to start
Before anyone on your team writes a word in the documents row, export the file your product actually produces and look at it the way a buyer eventually will. Our PDF accessibility checker runs a structural check — tagging, title, language, alt text — against a file you drop in, without uploading it anywhere, and the PDF/UA error reference explains what each failure means if you want to go clause by clause. Treat that as the starting point, not the answer: a structural pass tells you the file is not obviously broken, and the Supports row still wants what the buyer's guidance asks for — someone opening the file in a screen reader.
Further reading, if the question came from a different direction: the US legal picture beyond the VPAT is on our Section 508 and ADA compliance page, and the EU equivalent — a public accessibility statement rather than a procurement form — is our companion piece on the accessibility statement's documents paragraph.
