Accessibility Conformance Reports (ACR/VPAT): The EU Procurement Guide for Vendors and Buyers
Somewhere in your next enterprise deal, a procurement officer is going to ask: "Can you send us your accessibility conformance report?" If your answer is a blank stare, a vague PDF from 2022, or a link to your marketing page, the deal is in trouble.
A completed VPAT/ACR has become the de facto requirement to sell to government, education, healthcare, and enterprise buyers, even when no single statute names the document by name. The European Accessibility Act, in force since June 2025, has accelerated this shift in the EU market. Buyers now need proof - not promises - before they sign.
This guide explains what an Accessibility Conformance Report is, how it differs from an accessibility statement, which template edition to use for EU deals, and how to produce one that holds up under scrutiny. If you're on the buyer side, there's a checklist at the end for evaluating what vendors send you.
First: ACR vs. accessibility statement - they are not the same document
Before going further, let's clear up a confusion that costs vendors deals and buyers clarity.
An accessibility statement is a public-facing document required under the European Accessibility Act and the Web Accessibility Directive. It tells consumers how your product or service meets accessibility requirements, lists known gaps, and provides a feedback mechanism. It lives on your website. It is a legal obligation under Article 13 of the EAA.
An Accessibility Conformance Report (ACR) is a procurement document. It maps your product, criterion by criterion, against a recognised accessibility standard. It is addressed to buyers and procurement teams, not end users. It travels with RFP responses, contract renewals, and supplier qualification packs.
The two documents serve completely different audiences and answer completely different questions. Publishing an accessibility statement does not replace an ACR. Producing an ACR does not satisfy your obligation to publish an accessibility statement. You need both.
What is a VPAT, and what is an ACR?
The VPAT - Voluntary Product Accessibility Template - is a free, standardised template published by the Information Technology Industry Council (ITI). It provides a structured format for reporting how an ICT product or service conforms to accessibility standards. Once a vendor fills in the template based on actual testing, the completed document is called an Accessibility Conformance Report (ACR).
The distinction matters in practice: when a procurement team asks for your "VPAT," what they actually need is the ACR - the filled-in, product-specific report. The VPAT is the blank form; the ACR is your evidence.
VPAT 2.5 is the current version, released in November 2023 and last updated in April 2025, aligned with WCAG 2.2 across its four editions. There is no timeline from ITI for a VPAT 2.6; plan around 2.5 as the working standard for at least the next 18-24 months.
The four VPAT editions - and which one to use for EU deals
VPAT 2.5 comes in four editions, each targeting a different regulatory environment:
| Edition | Standard covered | WCAG version | Use when… |
|---|---|---|---|
| WCAG | WCAG only | 2.0, 2.1, 2.2 | Private-sector SaaS, global commercial buyers |
| Section 508 | Revised Section 508 (US) | 2.0 | US federal procurement |
| EU (EN 301 549) | EN 301 549 | 2.1 | EU public sector, EAA-regulated procurement |
| INT (International) | WCAG + 508 + EN 301 549 | 2.0, 2.1, 2.2 | Global products sold across US, EU, and commercial markets |
For EU procurement, use the EU edition or the INT edition. The EU edition maps directly to EN 301 549 - the harmonised standard behind EAA conformance. The INT edition is the right choice if your product is sold globally and your buyers span US federal, EU public sector, and commercial markets, since it covers all three standards in a single document.
The EU edition of VPAT 2.5 references WCAG 2.1, because EN 301 549 v3.2.1 (the current published version) incorporates WCAG 2.1 Level AA. However, EN 301 549 v4.1.1 - which will incorporate WCAG 2.2 - is expected to be published in the Official Journal in late 2026. Once that happens, it becomes the binding technical standard for both the Web Accessibility Directive and the EAA. Vendors who are already building to WCAG 2.2 now will not need to re-audit when the standard updates.
Always state in your ACR which version of EN 301 549 you evaluated against. Buyers need to know whether your report reflects v3.2.1 or the forthcoming v4.1.1.
Anatomy of an ACR: what the tables actually contain
The body of an ACR is a series of tables. Each row covers one success criterion from the applicable standard. Each row has three columns:
- Criterion - the specific requirement (e.g., WCAG 1.1.1 Non-text Content, or EN 301 549 clause 9.1.1.1)
- Conformance Level - one of four permitted values
- Remarks and Explanations - the evidence column
The four conformance levels, as defined by ITI, are:
- Supports - the product meets the criterion without known defects, or provides 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 this product
There is a fifth value - Not Evaluated - reserved for WCAG Level AAA criteria that were not tested. Do not use "Not Evaluated" for Level A or AA criteria; doing so signals an incomplete evaluation.
The Remarks and Explanations column is where an ACR earns or loses credibility. When marking "Partially Supports" or "Does Not Support," you must identify which features have issues and describe exactly how they fail to meet the criterion. Vague remarks like "generally accessible" are a legal risk and a procurement red flag. Specific remarks - "keyboard navigation works throughout the main interface, but the data export modal traps focus and cannot be dismissed without a mouse" - tell buyers what they need to know and demonstrate that real testing happened.
Honesty is a competitive advantage. A report where every criterion reads 'Supports' with no remarks is a red flag to experienced procurement teams — no real product is fully conformant across every criterion. A well-documented 'Partially Supports' with a clear remediation note is more credible, and more defensible, than a blanket 'Supports' that falls apart the moment a buyer runs their own screen reader test.
How to write an ACR that survives scrutiny
1. Start with real testing - not documentation review
The biggest mistake vendors make is writing an ACR from feature documentation without actually testing the product. Automated scanners (axe, WAVE) catch roughly 30-40% of accessibility issues. Before any criterion gets "Supports," you need automated scanning and manual testing with assistive technologies: NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android, and keyboard-only navigation throughout.
Document what you tested, on which platforms, with which assistive technologies, and on which date. This methodology statement goes at the top of your ACR.
2. Scope the product precisely
Your ACR must state exactly what was evaluated: product name, version number, the specific URLs or app builds tested, and the date of evaluation. A web app, a mobile app, a desktop client, and downloadable documentation may each need their own ACR section - or separate reports entirely. Mixing platforms in a single undifferentiated report makes it impossible for buyers to assess the parts of your product they actually intend to use.
3. State the standard version explicitly
Write out the full standard reference: "EN 301 549 v3.2.1, incorporating WCAG 2.1 Level AA." Buyers need to know whether your report is current. A report that simply says "EN 301 549" without a version number cannot be properly evaluated.
4. Date the report and commit to refresh cycles
An ACR documents conformance at a single point in time and should be updated whenever the product changes materially, whenever the relevant standard moves, and at minimum once a year. A stale ACR is a liability in procurement - buyers may treat outdated claims as inaccurate ones. If your product ships regular UI updates, plan for annual ACR refreshes as a minimum, with interim updates after major releases.
5. Consider third-party evaluation
Self-assessed VPATs carry an inherent conflict of interest. Procurement teams increasingly treat self-assessed documentation as a starting point for scrutiny, not a final answer. A third-party audit - conducted by an independent accessibility specialist - adds credibility that internal teams cannot provide themselves, and it gives you a defensible paper trail if conformance claims are ever challenged.
The buyer-side checklist: evaluating a vendor's ACR
When a vendor sends you an ACR as part of an RFP response, here is what to check before accepting it at face value.
Beyond the checklist, ask vendors these questions directly:
- When was the product last tested for accessibility? (Not when the ACR was written - when the testing happened.)
- Who performed the evaluation - internal team or independent third party?
- What assistive technologies were used, and on which operating systems and browsers?
- What is your remediation roadmap for criteria marked "Partially Supports" or "Does Not Support"?
- How often do you refresh the ACR, and what triggers an update?
A vendor who cannot answer these questions fluently has probably not done the underlying work.
Common mistakes that kill deals and invite disputes
Overclaiming conformance. Claiming "Supports" across every criterion without evidence is the fastest way to lose credibility when a buyer runs their own screen reader test. Experienced procurement evaluators know that no real product is fully conformant across every criterion - a report that says otherwise is a red flag, not a reassurance.
Submitting a stale report. An ACR based on a product version from 18 months ago does not reflect the current state of a product that ships regular updates. Buyers may treat outdated claims as inaccurate ones.
Using the wrong edition. Submitting a Section 508 edition to an EU buyer, or a WCAG-only edition to a public-sector buyer who needs EN 301 549 coverage, signals that you do not understand the procurement context.
Using an outdated VPAT template. Submitting a VPAT 2.0 or 2.3 in 2026 looks careless. Buyers expect VPAT 2.4 or 2.5. Always download the current template from itic.org before starting an evaluation.
No methodology statement. An ACR with no description of how testing was conducted provides no basis for trusting its claims. Document what you tested, how, and when.
Confusing "Not Evaluated" with "Not Applicable." These are not the same. "Not Applicable" means the criterion genuinely does not apply to your product (e.g., a text-only tool has no video, so caption criteria are not applicable - but explain why). "Not Evaluated" means no testing was done. Submitting an ACR with Level A or AA criteria marked "Not Evaluated" is an admission that the evaluation is incomplete.
ACRs and EAA compliance: what the relationship actually is
The EAA does not mandate a VPAT or ACR by name. What it requires is that vendors maintain technical documentation demonstrating conformance with EN 301 549, and that this documentation be available to market surveillance authorities on request.
An ACR structured against EN 301 549 is the established method for meeting this documentation obligation in B2B and procurement contexts. It is also strong evidence in a vendor's technical file if conformance is ever challenged. But it is only as good as the testing behind it - a self-assessed ACR with no methodology statement and no assistive-technology testing is not meaningful evidence of anything.
For buyers, an accurate ACR from a vendor helps you meet your own EAA obligations across the supply chain. If you procure an inaccessible product and deploy it to EU consumers, your EAA exposure does not disappear because the vendor said "Supports." Verify the claims.
The version to watch: EN 301 549 v4.1.1
EN 301 549 v4.1.1, which incorporates WCAG 2.2 and updates Real-Time Text requirements, is planned for publication in the Official Journal of the European Union in late 2026. Once published as a harmonised standard, it becomes the binding technical baseline for EAA conformance.
For vendors: if you are producing an ACR now, evaluate against EN 301 549 v3.2.1 (WCAG 2.1 AA) and note in the report that you are also tracking WCAG 2.2 criteria in preparation for v4.1.1. This positions you ahead of the curve when buyers start asking for v4.1.1 coverage.
For buyers: start asking vendors whether their products meet WCAG 2.2 now, even before v4.1.1 is formally published. Content that meets WCAG 2.2 also meets WCAG 2.1 - there is no downside to requiring the higher standard.
Summary: what a defensible ACR looks like
A procurement-ready ACR for the EU market includes:
- Product metadata: name, version, evaluation date, evaluator identity
- Standard reference: EN 301 549 v3.2.1 (or v4.1.1 when published), incorporating WCAG 2.1 (or 2.2) Level AA
- VPAT edition: EU or INT, version 2.5
- Methodology statement: automated tools used, manual testing approach, assistive technologies tested, platforms and browsers covered
- Conformance tables: honest, criterion-by-criterion ratings using the four permitted levels
- Remarks column: specific, evidence-based explanations for every "Partially Supports" and "Does Not Support" entry
- Refresh commitment: a stated review cycle and the conditions that trigger an update
An ACR produced this way is not just a procurement checkbox. It is a documented, defensible record of your product's accessibility posture - one that wins deals, de-risks EAA exposure, and holds up when buyers look closely.
Do I need an ACR to comply with the EAA?
The EAA does not require a VPAT or ACR by name. What it requires is technical documentation demonstrating conformance with EN 301 549, available to market surveillance authorities on request. An ACR structured against EN 301 549 is the established format for meeting this obligation in procurement contexts — but it is not the only possible form of documentation.
Which VPAT edition should I use for EU procurement?
Use the EU edition (which maps to EN 301 549) or the INT edition (which covers EN 301 549, Section 508, and WCAG in a single document). The INT edition is the better choice if your product is sold globally across US and EU markets. Do not submit a Section 508-only edition to EU buyers.
How often should I update my ACR?
At minimum, once a year. Also update after any major product release that changes UI, navigation, or interactive features, and whenever the relevant standard is updated. A stale ACR — one that no longer reflects the current product — is a liability in procurement and may be treated as inaccurate by buyers.
Can I write my own ACR, or do I need a third party?
You can write your own ACR — the VPAT template is freely available from ITI. However, self-assessed ACRs carry an inherent conflict of interest, and procurement teams increasingly scrutinise them more carefully. A third-party audit adds credibility and produces a more defensible document. At minimum, ensure your internal team has genuine expertise in WCAG success criteria, assistive technology testing, and how procurement teams read these documents.
What is the difference between an ACR and an accessibility statement?
An accessibility statement is a public-facing, consumer-addressed document required under the EAA and Web Accessibility Directive. It describes your conformance status, known gaps, and how users can report issues. An ACR is a procurement document addressed to buyers and procurement teams, mapping your product criterion-by-criterion against a standard. You need both — they serve different audiences and answer different questions.
What happens when EN 301 549 v4.1.1 is published?
Once EN 301 549 v4.1.1 is published in the Official Journal of the EU (expected late 2026), it becomes the binding harmonised standard for EAA conformance, incorporating WCAG 2.2. Existing ACRs evaluated against v3.2.1 will need to be updated. Vendors who are already building to WCAG 2.2 now will have a much shorter re-audit path.
Related reading
Web Accessibility Directive vs European Accessibility Act: Two EU Laws, One Compliance Programme
The EU has two distinct digital-accessibility regimes: the WAD for public sector bodies and the EAA for private-sector products and services. Many organisations are subject to both. Here's how to tell them apart - and how to satisfy both at once.
Cognitive Accessibility and the EAA: Why WCAG Compliance Isn't Enough
WCAG 2.1 AA is the EAA's legal floor - but it only partially covers people with cognitive and learning disabilities. Here's what teams must do beyond the standard.
Accessible Forms: The Developer's Fix-First Guide to WCAG 2.2 Compliance
Forms are where accessibility fails most and where the EAA bites hardest. A technique-level guide to labels, errors, grouping, autocomplete, redundant entry, focus, and keyboard - with code examples.