VPAT certification: what procurement actually asks you to provide

There is no VPAT certification

If a solicitation asked you for a “VPAT certification,” or a prospect asked whether your product is “VPAT certified,” the honest answer is that no such credential exists. The Information Technology Industry Council publishes the Voluntary Product Accessibility Template, and its own FAQ answers the question directly: “No, there is no VPAT certification.” Asked a second way, the same FAQ says “There is no certification for VPAT.” Asked whether it checks what vendors publish: “No, ITI does not review or approve VPATs. ITI provides the VPAT templates as a free resource for anyone to use.” (ITI VPAT FAQ).

There is no badge either. ITI: “there’s no certification or conformance logo required or even available to those who have filled out the VPAT.”

So what are buyers really asking for? A document you write about your own product. You test the product against the template, you record a conformance level for every applicable provision, and the completed file has a different name: an Accessibility Conformance Report. That report is a claim, not a credential, and it is judged on whether the evidence behind it holds up. For the wider map of what each accessibility proof in this market actually attests, see nobody certifies a website: what each US accessibility proof means.

The rest of this guide is about the thing that does exist: producing an ACR strong enough that a federal contracting officer or an enterprise procurement reviewer accepts it without a second round of questions.

What procurement teams want

GSA describes the document to federal buyers as “a document that explains how information and communication technology (ICT) products such as software, hardware, electronic content, and support documentation meet (conform to) the Revised 508 Standards for IT accessibility,” and recommends that vendors “generate an ACR for any ICT that’s intended to be marketed to the Federal government” (Section508.gov).

Buyers expect accuracy over perfection. They look for evidence that the product was actually tested, not paraphrased. They want the report written or reviewed by people who understand the criteria rather than guessed at by whoever had a spare afternoon. They check the edition and the standard, because the requirement in the solicitation is what the report has to answer.

Everything in the report should be internally consistent, with no contradictory answers between related criteria. Here is the reviewer’s checklist in practice:

• The report names one specific product and version, not a product family.
• The Evaluation Methods Used field names the actual tools, assistive technologies and manual procedures.
• Every applicable criterion carries a conformance level and a remark that explains how you reached it.
• The edition matches the standard the solicitation cites: 508, EU, WCAG or INT.
• The date is recent enough to describe the product that is shipping now.
• Exceptions come with a remediation plan and a date.

Why VPATs get rejected

Because the vendor is the author, an experienced reviewer starts from skepticism. The eCampusOntario Digital Accessibility Toolkit puts the problem plainly: “Since they are written by the vendor, VPATs may exaggerate the accessibility of any given product,” and adds that “a VPAT is not an audit report, though the vendor must have performed an audit to complete the VPAT” (eCampusOntario, Interpreting Vendor Claims).

That toolkit also lists what makes a reviewer distrust a report. Each of these is a rejection risk you can remove before you submit:

• A stale version or date. A VPAT 1.x report signals the vendor has not maintained its documentation. A report dated well over a year ago suggests the product has moved on without it.
• Non-standard language. Using “Passes” and “Fails” instead of the defined conformance levels tells the reviewer the author did not know the template.
• One report covering several products, or a product description too vague to identify what was tested.
• ”Supports” on everything. The toolkit calls a product that supports every criterion “incredibly rare,” and reads a clean sweep as a sign the author did not confirm the answers.
• An empty Remarks column. That column exists to show how you reached each conclusion, and a reviewer who finds it blank has nothing to check.
• Automated testing alone. On coverage, the same source states: “Automated testing can only test for approximately 30% of conformance, but it cannot be relied upon alone.”

What a defensible ACR contains

Nothing in the list below is certified by anyone. Each item is something a reviewer can verify, which is the property that actually wins the contract:

1. Accessibility testing. Manual testing, assistive technology checks and code review: JAWS, NVDA, VoiceOver, color contrast tools and keyboard-only navigation.
2. Findings documentation. Each criterion in the relevant standard matched with a real, tested result.
3. Report writing. Accurate, specific statements for every applicable provision, in the template’s own vocabulary.
4. Independent review, where the contract asks for it. An outside evaluator does not certify anything, but a second set of eyes catches the optimistic answers before a buyer does.
5. The finished ACR. This is the file procurement teams read, and the one you publish or hand over on request.

A report with no evidence behind it is the one that gets sent back.

Related reading: Learn how WCAG guidelines feed VPAT reporting, and see our comprehensive audit guide.

How to produce a VPAT that passes procurement

Passing procurement starts with a report that tells the full truth. Follow the steps below to document your testing and your remediation approach.

Step 1: Conduct a complete accessibility audit

Run a proper audit against the criteria in the standard the buyer cites. It should combine automated and manual testing.

A complete manual audit gives you the evidence-based results a defensible report needs:

• WCAG 2.2 AA testing
• Screen reader testing
• Keyboard-only navigation
• Color contrast and UI issues
• Mobile and responsive checks
• PDF and document accessibility

Related reading: why automated scans are not enough on their own: WCAG checkers cannot save you from lawsuits.

Step 2: Fix high-impact issues first

Every issue you fix before you write is one you do not have to explain afterward. Work in this order:

• Blockers first. Anything that stops a keyboard or screen reader user from completing a core task: sign-in, search, checkout, form submission.
• Then the issues that repeat. A single broken component in a design system fails the same criterion on every page that uses it, and fixing it once moves several answers at the same time.
• Then the cheap wins. Missing labels, contrast failures, page titles, language attributes.
• Leave the rest for the roadmap, with an owner and a date, and report it honestly in the remarks.

Step 3: Write the report with evidence

Each entry should state the testing methods you used and note any limitations you hit. Include the assistive technologies your product supports, and give a short, plain description of each issue you found. Make sure the conformance level you record is accurate and easy to check.

Keep each remark clear and concise so a reviewer can grasp your accessibility status quickly. Here is a completed VPAT report, on the older 2.4 template, to show the level of detail.

Example (good): Partially Supports: Form labels are accessible except on the custom dropdown component, which lacks ARIA attributes. Keyboard navigation works as expected.

Example (bad): Supports: All forms work.

Step 4: Independent review, and when it is required

This is the step vendors misunderstand. A third party cannot certify your report, and ITI does not expect one to be involved by default: “VPATs shouldn’t require a third party review,” because the owner who completes it will likely hold the most accurate information about the product’s features. ITI treats outside review as optional, “something you can choose to do as part of an extra compliance check, but is not required.”

The exception is the one that matters to anyone selling into government. ITI’s own caveat: if you are completing a VPAT in response to a government or other solicitation, follow the directions in that solicitation, “which may require a third party audit or review as part of its terms.” When the contract asks for independent testing, the contract is the authority, not the template. If the wording is ambiguous, ITI’s advice is to ask the entity that issued the solicitation for clarification.

Where an outside evaluator is worth engaging, the deliverable is an audit and a review, not a credential:

• An independent audit of your product against the cited standard
• A written record of findings the buyer can trace to a test
• Reviewer-friendly formatting
• Conformance levels checked against the evidence
• The finished ACR plus a remediation roadmap

Having the report prepared or reviewed by an experienced accessibility team builds buyer confidence and can shorten the approval cycle. Book a VPAT consultation with our team.

Step 5: Provide a remediation timeline

Procurement teams expect a clear remediation plan wherever you report an exception. Give them an estimated timeline inside the report, which demonstrates accountability.

Example: “ARIA updates for dropdown menus scheduled within 30 days.”

What a procurement-ready report looks like

It uses the edition that covers the standards in the solicitation, which for a report spanning Section 508, EN 301 549 and WCAG means the INT edition. Conformance levels are consistent across related criteria, and every remark records the assistive technology used and the method behind the answer. The formatting is professional, the product and version are named, and the date is current. Where the contract required independent testing, the report says who did it.

Use the current terminology

Two vocabulary details cost vendors credibility, and both are free to fix.

First, the current template is VPAT Version 2.5Rev (April 2025), published in four editions: 508, EU, WCAG and INT.

Second, “Supports with Exceptions” is gone. ITI records that in an earlier update, “partially supports” replaced “supports with exceptions,” a change made at the request of representatives of the U.S. Access Board. The four levels are supports, partially supports, does not support, and not applicable. A report still using the retired phrase tells a reviewer it was copied from an old file.

Benefits of a defensible report

Producing an ACR you can stand behind delivers business results that a badge never could:

• Faster RFP approvals: fewer rounds of questions from procurement.
• Reduced legal exposure: fewer complaints about an inaccessible product, and no overstated claim to defend.
• Greater trust with government buyers: a specific, testable report signals professionalism.
• Better product accessibility long-term: the gaps you uncover benefit every user over time.

How ADACP helps with your VPAT and ACR

ADACP provides digital accessibility services to help organizations produce an accurate ACR and meet WCAG 2.2 AA. Our services include:

1. Full WCAG 2.2 AA testing: manual audit of websites, applications and digital content.
2. VPAT completion and remediation support: reports written against real test results.
3. Independent review of a report you already have, including one prepared in-house.
4. PDF, web, SaaS and mobile app testing across platforms and content types.
5. Document accessibility for corporate standard documents.
6. An accessibility roadmap for procurement, so exceptions come with dates.

Outcome: a reviewer-friendly ACR that a government or enterprise buyer can check. We do not issue certificates, because none exist to issue.

Red flags procurement reviewers watch for

Red Flag	Why It’s a Problem
”Supports” everywhere	A clean sweep across every criterion invites doubt about the testing.
No testing notes	Reviewers assume no testing was conducted.
Wrong edition for the solicitation	A WCAG-edition report does not answer a Section 508 requirement. Match the edition to the standard the buyer cited.
Retired conformance language	”Supports with Exceptions,” “Passes” or “Fails” signals the template was not read.
Missing organization details	An anonymous report is treated as unreliable.
Overly technical jargon	Reviewers prefer clear language over complexity.

Bonus tips for writing procurement-safe entries

A. Use “Supports” only when you are sure

Confirm you have done full manual testing and tested with assistive technology, that there are no functional problems, and that there are no usability barriers.

B. Do not be afraid of “Partially Supports”

It is the honest answer whenever a criterion holds in some places and not others, and a reviewer trusts it more than a blanket “Supports.”

C. Use short but specific notes

Example:

• Issue: Focus order skips the “Continue” button on the payment page.
• Impact: Users relying on screen readers may get stuck.
• Planned Fix: Update tab index. ETA 30 days.

D. Avoid marketing language

Statements like “best-in-class,” “fully compliant” or “certified accessible” create distrust, and the last one describes something that does not exist. Stick to facts.

E. Cross-check your answers

Example: if Keyboard is “Supports,” then Pointer Gestures should not be “Does Not Support.”

VPAT tools and templates

Accessibility documentation starts with the right template and the right tools. ITI offers the template free of charge, and ITI membership is not required to use it.

Templates available:

• VPAT 2.5Rev 508: the Revised Section 508 standards, the US federal accessibility standard, incorporating WCAG 2.0.
• VPAT 2.5Rev EU: EN 301 549, the European public procurement standard for ICT, incorporating WCAG 2.1.
• VPAT 2.5Rev WCAG: WCAG 2.0, 2.1 and 2.2.
• VPAT 2.5Rev INT: all three of the above in one report.

Accessibility testing tools:

• WAVE: online accessibility checker for web pages.
• Axe DevTools: browser extension for automated accessibility testing.
• ARC Toolkit: Chrome extension for detailed accessibility reports.
• Color Contrast Analyzer: checks text and background contrast.
• Accessibility Insights: for WCAG and Section 508 testing.

Tools cannot write your report, and no tool can grant a status the template does not confer. Book a free consultation to make sure your report answers what the solicitation actually asked.

Conclusion

Asking how to get “VPAT certified” is asking for something that was never created. What gives you the competitive edge is the document that does exist: an Accessibility Conformance Report built on thorough testing, written honestly, and kept current with the product it describes. Buyers can tell the difference, and so can their lawyers.

If you want your ACR to work as a sales asset with public-sector and enterprise clients, book a consultation with ADACP.