Accessibility Audits, VPATs and Conformance Reports: What Buyers Actually Check
A VPAT completed by guesswork is a written record of claims you cannot support. Here is how audits and conformance reports are meant to work — and what procurement teams look for.
A tender arrives with a line nobody on the bid team recognises: "Please provide your current VPAT." Someone downloads the template, opens a spreadsheet of forty-odd success criteria, and — under deadline — writes "Supports" in almost every row. The bid is submitted. In doing so, the organisation has created a written record of conformance claims it cannot evidence.
This article explains what these documents are, how a real audit produces them, and what experienced buyers actually check.
The vocabulary, cleared up
- WCAG 2.2 AA — the technical standard. What you conform to.
- EN 301 549 — the European harmonised standard, which wraps WCAG and extends it to documents, hardware and real-time communication.
- Section 508 — the US federal procurement requirement, which references WCAG.
- VPAT — the blank template used to report conformance, published by ITI in editions for WCAG, EN 301 549 and Section 508.
- ACR — the Accessibility Conformance Report: the completed, published document. This is what a buyer is really asking for.
What a credible audit involves
Scope, defined honestly
An ACR is only meaningful against a stated scope: which product, which version, which platforms and assistive technology combinations, which user journeys. A report claiming conformance for "the website" with no version or date is treated by experienced buyers as unserious.
Automated testing — necessary, insufficient
Automated scanning catches roughly a third of issues: missing alternative text, contrast failures, absent labels, invalid ARIA. It cannot judge whether alternative text is meaningful, whether focus order matches reading order, or whether an error message tells a user what to do next.
Manual testing — where the real findings live
A defensible audit includes keyboard-only completion of each journey, screen reader testing across at least two combinations, 400% zoom and reflow at 320 CSS pixels, testing with animation and motion preferences enabled, and verification that time limits, drag interactions and authentication flows have accessible alternatives — the areas WCAG 2.2 specifically strengthened.
Evidence, retained
Every conformance claim should trace to a test record: what was tested, how, with what technology, on what date, with what result. When a buyer or a regulator questions a claim, retained evidence is the difference between a defensible position and an embarrassing one.
How to write conformance claims that survive scrutiny
| Claim | Correct use | Common misuse |
|---|---|---|
| Supports | Criterion met across the entire evaluated scope | Applied because no automated tool flagged it |
| Partially supports | Some functionality fails; remarks name what and where | Used vaguely to avoid admitting a specific failure |
| Does not support | Criterion not met | Avoided entirely out of fear it loses the bid |
| Not applicable | Criterion genuinely cannot apply to the content type | Used to skip criteria that are inconvenient |
The remarks column carries more weight than the label. "Partially supports — the date picker in the booking flow cannot be operated by keyboard; a text input alternative is available, full remediation scheduled Q4" tells a buyer you know your product. "Partially supports" alone tells them you do not.
The five credibility mistakes we see most
- All-'supports' reports on complex applications. No non-trivial product fully conforms across every criterion. A perfect report invites the question of who tested it.
- No version or date. Instantly discountable.
- Third parties silently excluded. If your product embeds a payment iframe, a chat widget or a mapping component, its conformance is part of the user's experience and must be addressed.
- Automated-only methodology, undisclosed. Stating the tools used and omitting manual testing tells a competent reviewer exactly how much the report is worth.
- Never refreshed. An ACR from three releases ago describes software that no longer exists.
From audit findings to a report you can defend
The sequence that works: audit against WCAG 2.2 AA with combined automated and manual testing; remediate the design system first so one fix clears findings across every template; retest the affected journeys; then write the ACR against the remediated product with honest partial-support entries and dated commitments for what remains. Publish it, and diary the refresh.
Done this way, the document stops being a bid-team liability and becomes what it was designed to be: evidence that you understand your own product.
Producing an ACR you would be comfortable defending
An honest conformance report backed by real testing is faster to produce than most teams expect — and considerably faster than explaining an optimistic one after a contract has been awarded.
Kinematic Digital runs WCAG 2.2 AA audits combining automated scanning with manual keyboard and screen reader testing, then fixes the defects at design-system level so one correction propagates across every template. See our UX and accessibility services and web development practice, or request an accessibility audit.
Frequently Asked Questions
What is the difference between a VPAT and an ACR?
A VPAT is the blank template; an Accessibility Conformance Report is the completed document produced using it. Buyers ask for a VPAT but what they need is a truthful, evidence-backed ACR.
Can we complete a VPAT without an audit?
You can, and it is the most common mistake in the process. A VPAT completed from optimistic assumption becomes a written record of inaccurate claims — far worse in a procurement or legal context than an honest report showing partial support.
What do 'supports', 'partially supports' and 'does not support' actually mean?
They are conformance claims per success criterion. 'Supports' means the criterion is met throughout the evaluated scope. 'Partially supports' means some functionality fails and must be explained. 'Does not support' means the criterion is not met. Remarks matter more than the labels.
How often should an ACR be refreshed?
At least annually, and after any significant release or redesign. An ACR describing a version of your product that no longer exists is a liability, not an asset.
Does a good ACR win contracts?
It removes a disqualifier and builds credibility. Buyers who compare reports notice which vendors documented real limitations with remediation dates — that reads as competence, whereas an all-'supports' report on a complex application reads as either careless or untrue.