The remarks and explanations column in a VPAT is where you justify the conformance level assigned to each WCAG success criterion. For Supports, briefly confirm how the product meets the criterion. For Partially Supports and Does Not Support, describe the specific issues, where they occur, and any planned remediation. For Not Applicable, explain why the criterion does not apply. Each entry should be concise, factual, and tied to evidence from the underlying accessibility audit.
| Conformance Level | What the Remarks Should Cover |
|---|---|
| Supports | Brief confirmation of how the criterion is met. Optional note on the technique used. |
| Partially Supports | Description of the specific issue, where it occurs in the product, and the impact. |
| Does Not Support | Clear statement of the issue, location, user impact, and any planned remediation. |
| Not Applicable | Reason the criterion does not apply, such as no audio, no video, or no input fields. |
| Not Evaluated | Reserved for AAA criteria when the report covers Level A and AA only. |
Why the Remarks Column Matters
The conformance level alone does not give a procurement reviewer enough information. A buyer reading an ACR wants to know what works, what does not, and what the gap looks like in practice.
The remarks column is where that context lives. Done well, it turns a checkbox document into a credible record of the product’s accessibility posture.
Procurement teams, government buyers, and enterprise reviewers read this column closely. Vague entries raise red flags. Specific entries build trust.
What to Write for Supports
When the product fully meets a criterion, keep the remark short. One sentence is often enough.
Examples that work: “All non-text content has appropriate text alternatives.” “Page titles describe the topic or purpose of each screen.” “Form fields have programmatically associated labels.”
Avoid copying the success criterion text back into the remarks. That adds length without adding meaning. Confirm the behavior in plain language.
What to Write for Partially Supports
Partially Supports is the most common conformance level for products that have not been fully remediated. The remark needs three things: what the issue is, where it appears, and the user impact.
Example: “Most images have appropriate alt text. Decorative icons in the dashboard header are missing alt attributes, causing screen readers to announce file paths.”
That entry tells a reviewer the scope of the issue (limited to the dashboard header), the technical problem (missing alt), and the consequence for users. It also signals that the rest of the product meets the criterion.
What to Write for Does Not Support
Does Not Support means the criterion is not met across the evaluated scope. The remark should describe the issue clearly and avoid softening language.
Example: “Color is the only visual means used to indicate required form fields. Users who cannot perceive color differences cannot identify which fields are required.”
If remediation is planned, note it. “A text indicator will be added to required fields in the next release” is a fair addition. Do not promise a date you cannot meet.
What to Write for Not Applicable
Not Applicable is appropriate when the criterion has no relevance to the product. The remark should explain why in one sentence.
Examples: “The product contains no pre-recorded audio content.” “The product contains no live video.” “The product contains no time limits on user actions.”
Do not mark a criterion Not Applicable to avoid evaluating it. Reviewers who know the product can spot that quickly, and it damages credibility for the entire ACR.
How Detailed Should Each Entry Be?
The right level of detail depends on the audience. Procurement reviewers want enough information to assess risk. Engineering teams reading the document later want enough to act on.
A useful target is two to four sentences for Partially Supports and Does Not Support entries. Shorter for Supports. One sentence for Not Applicable.
The remarks column is not the place for a full audit report. It summarizes findings. The audit report behind the ACR carries the full technical detail.
Common Mistakes to Avoid
Vague language is the most frequent issue. Entries like “some issues exist” or “mostly accessible” tell a reviewer nothing.
Marketing language is the second issue. The remarks column is a factual record, not a sales document. Avoid phrases like “committed to accessibility” or “prioritizes user experience.” State what the product does and does not do.
Inconsistency between the conformance level and the remark is the third. If the level is Supports but the remark describes an issue, the document contradicts itself. Match the language to the level.
Frequently Asked Questions
Should the remarks column reference the audit report?
It can, but it does not need to. The ACR stands on its own as a procurement document. If the audit report is shared alongside the ACR, the remarks can stay focused on the conformance summary and let the audit carry the detailed findings.
Can AI fill in the remarks column?
AI can draft remarks when paired with audit data, and the output still needs human review. Accessible.org Labs is actively researching how AI can support VPAT preparation by drawing from audit findings, with a qualified auditor verifying every entry before the ACR is finalized.
What if an issue affects only one page or screen?
Note the location in the remark. “Issue affects the checkout page only” gives a reviewer scope. The conformance level is still Partially Supports for the criterion overall.
Do remarks differ between VPAT editions?
The format is consistent across the WCAG, Section 508, EN 301 549, and INT editions. The criteria covered differ, but the approach to writing remarks is the same.
An ACR with thoughtful remarks reads as the work of a team that understands its own product. That is the standard worth aiming for.
For VPAT and ACR services backed by a fully manual accessibility audit, Contact Accessible.org.
