Write back before you write anything else. A request for a VPAT is four questions wearing one word, and until you know which product, which edition, which release and which deadline the customer has in mind, anything you produce is a guess with your signature on it. The reply that buys you the most room is the one that asks.
That is not stalling, and nobody on the buying side will read it as stalling. The organization that publishes the template gives suppliers the same advice, which is that where a solicitation is unclear about what it requires, you go back to the entity that issued it and ask. Procurement teams write these requests in a hurry too, so a supplier who comes back with four precise questions usually reads as the one who has done this before.
This page covers the hour between the email arriving and the work starting. For the document itself, the four editions and how a report gets filled in honestly, the VPAT and ACR guide is where that lives. For what a finished report structurally cannot say, what a conformance report cannot tell you is written from the buyer's chair and is worth reading before you send one. This one is triage.
The short version
A VPAT is a blank template. An ACR is your filled-in report. Nobody certifies either one, nobody approves one, and there is no submission process and no logo. So there is no shortcut to buy, and the only real question in front of you is what evidence you already hold and what you are going to have to go and test.
Eight Questions to Settle Before You Promise Anything
This is the triage sheet. Eight rows, and most of them can be answered inside a day, four from your own files and four by asking the customer. Work down it in order, because the later rows change meaning depending on how the earlier ones came out. The whole sheet exists to stop one specific failure, which is agreeing to a deadline before you know how much testing sits behind it.
| What to establish | Why it decides the answer | Where the answer comes from |
|---|---|---|
| Which product, exactly | A request naming your company names nothing testable. A report covers one product at one version, so a customer who wrote "your platform" has to be asked which part of it their people will actually be given. | The customer, in writing. If they cannot name it, ask which of their teams will use it and for what task. |
| Whether it is yours to report on | Either the reseller or the original manufacturer may complete a template, so both answers are permitted. The testing, though, tends to belong to whoever wrote the code. | Your own contracts. Where you resell somebody else's component, ask them for their report before you write around the gap. |
| Which release, and on which platform | A web application, a native mobile app, a desktop client and your support documentation are four separate bodies of evidence. A web audit answers for one of them and says nothing about the other three. | Your release notes, plus a straight look at what the customer is actually being sold. |
| Which standard, and which version of it | The edition you pick decides the WCAG version you report against. The 508 edition reports against WCAG 2.0, the EU edition against 2.1, and only the WCAG and INT editions reach 2.2. | The solicitation or the email. Where it names two standards at once, say so plainly and ask which one governs. |
| Whether the item is off-the-shelf or built for them | Federal buyers ask different things of each. An off-the-shelf item needs a report on what exists today. A customized item needs a report describing how the build will meet the requirements the solicitation named. | The shape of the contract. Ask if the request does not make it obvious. |
| Whether a complete report is a condition of the deal | Federal guidance tells agencies to state that an incomplete report is not considered for award. Where that language is in play, a partial answer is worth nothing rather than something, which changes what you should spend the week doing. | The instructions attached to the solicitation. Ask for them if they were not attached. |
| Whether they want a third party to have done the testing | The template's own publisher says a report should not need third-party review, and then says to follow the solicitation, which may require one as a term. Both of those are true at once, and only the buyer knows which applies to you. | The customer. This is the single question suppliers most often answer by assumption, and it is the most expensive one to get wrong. |
| What evidence you already hold, and what it covered | This is the row that sets your timeline. An audit from last year against pages nobody has touched since is worth a great deal. A scanner export is worth much less, and a report with no scope note is worth less than it looks. | Your own files, read honestly. Start with the scope statement naming which pages were opened and what was left out. |
The last row is the one people skip, and it is the one that decides everything downstream. Go and open the evidence before you estimate anything, because what you remember commissioning and what the report actually covers are rarely the same document.
What Counts as Evidence, and What Only Looks Like It
Four things get called accessibility evidence and only two of them will survive a follow-up question. Sorting your files into these four now saves you writing a row you cannot defend later.
- A scanner export. Useful for regression checking and close to useless as an answer to a procurement question, because by our own count a machine fully settles only 10 of the 356 WCAG techniques and documented failures we graded, and hands the rest to a person. An export tells a buyer which of a small set of machine-decidable defects were absent on the day, and nothing about the rest.
- An audit report. This is evidence, as long as it names three things. What was tested, including how many pages and what was left out. How it was tested, naming the tools, the browsers and the assistive technology. And who tested it. A report missing the scope statement cannot be sized by anybody reading it.
- A conformance claim. A stronger thing than a report and a rarer one, because the standard sets out five components it has to carry. The date, the guidelines by title and version with a link, the level met, a description of the pages covered including whether subdomains are in, and the technologies the content relies on. The conformance requirements set out what each of those has to say.
- An ACR. Your report against the template, one row per requirement. It is a self-declaration rather than a certificate, and what it is worth is exactly the testing underneath it.
Notice what the first item cannot become by being longer. A scan and an audit differ in kind rather than in thoroughness, so no quantity of automated output turns into the second row of that list. If the only file you hold is an export, treat your evidence inventory as empty and plan from there.
Three Replies That Beat a Guess
Most suppliers stall at this point because the three obvious replies all feel bad. They are all better than the fourth one, which is a confident answer nobody can support. A procurement officer who checks one row and finds it false discounts every other row on the page, and that is a much worse day than the one where you said you had not tested something yet.
- We hold current evidence and here it is. Send the report, the scope statement and the date, and say which of the customer's requirements it reaches. Where it does not reach all of them, say which ones it misses in the same message rather than waiting to be asked.
- We hold partial evidence and we are testing the rest. Name what is covered, name what is not, and say what you are doing about the gap. A supplier who can describe the boundary of their own evidence is describing a real testing process, and buyers can tell.
- We have not tested this yet. Say so, say when the testing starts, and say what you will send when it finishes. This is a respectable answer and it is the one that keeps your other answers worth reading. What makes it work is the second half, because a gap with a plan attached is a different object from a gap.
Why Reports Come Back, and How to Read the Rejection
A rejected report usually fails on its form rather than on its findings, which is good news, because form is cheap to fix. There is no universal acceptance rule and every buyer runs their own process, so treat the following as the eight things worth checking first rather than as a list of what any particular customer will do.
| What came back | What the buyer was looking at | What fixes it |
|---|---|---|
| Wrong edition | You reported against WCAG 2.2 to a buyer whose rule set is WCAG 2.0, or the other way round. The edition carries the version, so this is not a detail their team can wave through. | Reissue on the edition their standard names. The findings mostly carry over, since content meeting 2.2 also meets 2.1 and 2.0. |
| A row left blank | The template wants an answer in every row, so a blank reads as an unfinished document rather than as a modest one. | Test the criterion and answer it. There is no honest shortcut here and the buyer knows it. |
| Not Evaluated used below Level AAA | That term is permitted only in the Level AAA section, so using it at A or AA makes the report defective by the template's own rules and tells the reader you did not test. | Test those criteria and give them a real verdict. This is usually the row that sets your real timeline. |
| No date, or a date older than the release | The date is the first thing read. A report against a version the customer is not being sold answers a question nobody asked. | Retest against the shipping version and reissue. Say in the covering note which release it covers. |
| Nothing says which pages were tested | The template has no field for scope, so a report covering a four-thousand-page application and one covering a marketing site look identical on the page. | Put the scope in the covering note. Name the pages, the journeys and what was left out. |
| Evaluation methods say almost nothing | That field is required and unbounded, so "evaluated with automated tooling" satisfies the template and tells an experienced reader the judgment calls were skipped. | Name the methods, the platforms, the browsers and the assistive technology, specifically enough that somebody could repeat it. |
| The report arrived on its own | Federal buyers require a second document alongside it, carrying the evaluation methods, the features that help, how to install and configure the product accessibly, and a plain list of core functions a disabled person cannot use. | Write that second document. The last item is the one that takes courage and the one buyers value most. |
| The definitions were changed | The template lets a vendor deviate from the standard definitions where the change is noted. A quietly widened Supports means every green row underneath it says something other than the reader assumed. | Restore the template's definitions, or note the deviation where the template requires it and expect to be asked why. |
The Reply You Can Send Today
Four short paragraphs, and you can write them before any testing starts. Acknowledge the request and name the deadline you have understood. Ask the four questions from the triage sheet you cannot answer yourself, which are usually the product, the standard and version, the platforms in scope, and whether third-party testing is required. State what evidence you already hold and what it covered. Then say what happens next and when they will hear from you.
That message costs you twenty minutes and it converts an open-ended demand into a scoped piece of work. It also puts on record, at the start, that you asked. Where the answer later turns out to be narrower than the customer hoped, the exchange that established the scope is the one you will be glad to have in writing.
One honest limit
No rule says what any given customer must accept. The requirements described here bind US federal agencies, and a bank, a university or an enterprise buyer runs its own process and can ask for whatever it likes. What travels everywhere is the underlying position. Your report is a statement you signed, and it is worth what the testing behind it is worth. We sell the testing and the report, never a certificate, because no such thing exists. What we charge is published.