Strong VPAT remarks and explanations are specific, factual, and tied directly to the success criterion being evaluated. They name the issue, identify where it occurs, and avoid vague claims. A good remark tells a procurement reviewer exactly what works, what doesn’t, and what the user experience looks like. A weak remark uses generic phrases like “mostly accessible” or “meets requirements” without evidence. The strongest ACRs read like an auditor’s notes: plain language, observable behavior, and no marketing.
| Quality Marker | What It Looks Like |
|---|---|
| Specificity | Names the page, component, or interaction where the issue appears |
| Observable behavior | Describes what assistive technology encounters, not what was intended |
| Conformance language | Uses Supports, Partially Supports, Does Not Support accurately |
| Plain phrasing | No marketing language, no hedging, no filler |
| Tied to the criterion | Remark addresses the specific WCAG requirement, not adjacent issues |
What Makes a VPAT Remark Strong?
A strong remark answers three questions for the reader: where does the non-conformance / issue occur, what happens when a user encounters it, and how does it map to the success criterion.
Procurement teams read remarks to assess risk. Vague language raises flags. Specific language builds trust. The goal is not to make the product sound good. The goal is to give an accurate picture so the buyer can make an informed decision.
Good remarks are concise, but provide sufficient depth.
Examples of Good VPAT Remarks for “Supports”
When a product fully meets a success criterion, the remark should confirm conformance and briefly note how it was verified.
1.1.1 Non-text Content (Level A) — Supports
“Informative images include descriptive alt text that conveys the purpose of the image in context. Decorative images are marked with empty alt attributes so assistive technology bypasses them. Icon-only buttons expose accessible names through aria-label, and complex images on the reporting dashboard include short alt text paired with a longer text description in adjacent body copy. CAPTCHA and test images were not present in the evaluated build.”
2.1.1 Keyboard (Level A) — Supports
“All interactive elements, including custom dropdowns, modals, date pickers, and the data grid, are reachable and operable with the keyboard alone. Tab and Shift+Tab move forward and backward through the focus order, Enter and Space activate controls, Escape dismisses overlays, and arrow keys move within composite widgets. No keyboard traps were identified in any view.”
1.4.3 Contrast (Minimum) (Level AA) — Supports
“Body text, form labels, link text, and interactive control text meet or exceed a 4.5:1 contrast ratio against their backgrounds. Large text and bold text at 18.66px or larger meet or exceed 3:1. Disabled controls, decorative graphics, and inactive logo elements are exempt under the success criterion. Contrast was measured in both the default and high-density themes.”
Examples of Good VPAT Remarks for “Partially Supports”
Partially Supports is a commonly used conformance level. The remark needs to be specific about where each criterion is supported and not supported.
4.1.2 Name, Role, Value (Level A) — Partially Supports
“Native form controls, standard buttons, links, and most custom components expose accurate name, role, and value information to assistive technology. The custom multi-select component on the user management page does not announce selection state when an option is added or removed, and the toast notification component on the dashboard exposes a generic role of ‘group’ instead of ‘status’ or ‘alert,’ so screen readers do not announce notifications when they appear.”
1.3.1 Info and Relationships (Level A) — Partially Supports
“Headings follow a logical hierarchy, lists use ul and ol elements, and form fields are programmatically associated with their labels across most of the product. The data table on the analytics reporting page is built with div elements and ARIA roles that do not establish row and column relationships, so screen reader users cannot navigate the table by cell, row, or header. Section landmarks on the settings pages also rely on visual headings without corresponding heading elements in the DOM.”
2.4.7 Focus Visible (Level AA) — Partially Supports
“Standard form fields, links, and primary buttons display a visible focus indicator that meets contrast and thickness expectations. The primary navigation tabs and the icon-only buttons in the toolbar have their default focus outline removed by a custom style override and no replacement indicator is provided, so keyboard users cannot determine which control has focus in those regions.”
Examples of Good VPAT Remarks for “Does Not Support”
Does Not Support means the criterion is not met in a meaningful way. The remark should be direct.
1.2.2 Captions (Prerecorded) (Level A) — Does Not Support
“Prerecorded video content in the in-app help center and onboarding tour does not include synchronized captions. No caption track is provided and the player does not expose a caption control. Audio dialogue and on-screen narration are inaccessible to users who are deaf or hard of hearing.”
2.4.3 Focus Order (Level A) — Does Not Support
“Focus order in the checkout flow does not follow the visual and logical sequence of the page. After the shipping address form is submitted, focus moves to a footer link rather than the payment step that follows the form. Within the payment step itself, focus moves from the card number field to the billing zip field before the expiration date and security code, which do not match the visual order of the inputs.”
What Does a Weak Remark Look Like?
Weak remarks share common traits: hedging, generality, and language designed to soften an issue rather than describe it.
Examples of remarks that should never appear on a credible ACR:
“The product is mostly accessible.” This tells a reviewer nothing about what was evaluated or what was found.
“Minor issues may exist but do not affect usability.” This hedges without naming the issues or their location.
“We are working toward full conformance.” This is a roadmap statement, not a conformance remark.
“This criterion is met to the best of our knowledge.” This signals uncertainty and a lack of thorough evaluation.
None of these remarks provide any tangible information to the reviewer. They are filler.
Frequently Asked Questions
Should every remark mention the WCAG success criterion by name?
No. The criterion is already identified in the row. The remark should describe behavior, not restate the requirement. Repeating the criterion wastes space and signals padding.
How long should a VPAT remark be?
However long it takes to sufficiently elaborate on the conformance level. This will be 2-3 sentences in many cases. A Supports remark can be left empty or may be a single sentence. A Partially Supports remark needs enough detail to identify the issue and its location. Anything longer usually means the remark is mixing in content that belongs elsewhere.
Can remarks reference future fixes or roadmap items?
Don’t. The ACR documents the current state of the product. Roadmap commentary belongs in an accessibility policy or response document, not inside a conformance row.
Who should write the remarks on an ACR?
The auditor or accessibility professional who evaluated the product or service. Internal product or marketing teams should not draft remarks without auditor input. Independently issued ACRs carry more weight in procurement review for this reason.
Strong remarks come from strong audits. The quality of an ACR is a direct reflection of the evaluation behind it.
To get an independently issued ACR, contact us.
