VPAT remarks and explanations should be specific enough that a procurement reviewer understands exactly how the product behaves against each WCAG success criterion, but concise enough to read quickly. One to three sentences per criterion is the working range. Each remark should name the conformance level, point to the relevant product behavior, and note any known issues with enough context to be actionable. Vague phrases like “meets standard” or “fully accessible” do not satisfy the purpose of an ACR. The goal is clarity for the buyer, the legal team, and the accessibility reviewer who will read it.
| Conformance Level | Expected Detail in Remarks |
|---|---|
| Supports | Brief confirmation of how the product meets the criterion. One sentence is often enough. |
| Partially Supports | Identify which areas conform, which do not, and the nature of the issue. Two to three sentences. |
| Does Not Support | Describe the issue clearly and where it occurs. Avoid generic phrasing. |
| Not Applicable | Brief statement explaining why the criterion does not apply to the product. |

What Belongs in a VPAT Remark
A useful remark answers three questions: What is the conformance status? What does the product do (or fail to do) related to this criterion? Where in the product does this behavior appear?
For a Supports rating, a short confirmation works. Something like: “All form fields have programmatically associated labels.” That sentence tells the reviewer what was evaluated and confirms the result.
For Partially Supports or Does Not Support, the remark needs more substance. Name the area of the product, describe the issue in plain terms, and avoid technical shorthand that requires the reader to interpret. A reviewer should not need to open the product to understand what is happening.
How Much Is Too Much?
Remarks that run five or six sentences usually contain repetition or scope creep. If a single criterion needs that much explanation, the underlying issue may belong in the audit report rather than the ACR. The VPAT is a summary document, not a defect log.
The audit report carries the full technical detail: element selectors, reproduction steps, severity ratings, and remediation guidance. The ACR distills that work into language a non-technical reader can act on. Detail belongs in both places, but the depth differs.
A good rule: if the remark reads like a bug ticket, it is too detailed. If it reads like marketing copy, it is not detailed enough.
Why Vague Remarks Cause Problems
Procurement teams reject ACRs that read as boilerplate. A remark that says “The product is accessible” under every Supports criterion signals that the evaluation was not rigorous. Buyers looking for a real conformance picture will push back, request a revised ACR, or move to a competitor with stronger documentation.
Legal reviewers face a similar issue. An ACR that hides issues behind generic language can become a liability if the product is later evaluated and found to have known issues that were not disclosed. Honest, specific remarks protect both the vendor and the buyer.
Examples of Detail Done Right
Supports example: “Headings follow a logical hierarchy across all primary screens. The H1 through H3 structure was verified during the audit.”
Partially Supports example: “Most interactive elements have visible focus indicators. The custom dropdown component on the dashboard does not display a focus ring and is scheduled for remediation.”
Does Not Support example: “The video player on the help center pages does not provide captions for prerecorded content. Captions are planned for Q2.”
Each of these tells the reader what to expect, where the behavior lives, and what comes next where relevant.
The Role of the Audit in Remark Quality
Strong remarks come from a thorough manual accessibility evaluation. Without one, remarks are guesses. Scans only flag approximately 25% of issues, so a VPAT built on scan data alone produces remarks that miss most of what matters.
An auditor who has worked through every WCAG success criterion against the actual product can write remarks that hold up under buyer scrutiny. The audit is the source material; the ACR is the translation. The quality of one determines the quality of the other.
Frequently Asked Questions
Should I write the same remark for every Supports criterion?
No. Repeating identical text across criteria signals a templated approach and reduces buyer confidence. Each remark should reference the specific behavior tied to that criterion, even if the explanation is short.
Can I list known issues in the remarks without committing to a fix date?
Yes. Disclosing an issue without a timeline is more credible than omitting it. If a remediation date is not set, write “under review” or “prioritized for upcoming release” rather than inventing a date you cannot meet.
How detailed should remarks be for Not Applicable criteria?
Brief but specific. “The product does not contain prerecorded audio content” is enough. Avoid leaving the field blank, which can read as oversight rather than intent.
Who should write the remarks?
The accessibility professional or auditor who evaluated the product. Marketing or product teams can review the language for tone, but the technical accuracy must come from someone who worked through the criteria firsthand.
Detail in a VPAT is not about length. It is about giving the reader enough to trust the document and act on it. Get that balance right and the ACR earns its place in the buyer’s review.
Contact Accessible.org for VPAT and ACR services backed by a full manual evaluation.