Partially Supports means a product meets a WCAG criterion in some places but not others. In a VPAT, the Remarks and Explanations column is where you describe exactly what works, what does not, and where the issue occurs. A strong explanation names the issue, identifies the affected component or page area, and notes any user impact. Avoid vague phrasing. Auditors and procurement teams use this column to gauge risk, so specificity is the goal.
| Element of the Explanation | What to Include |
|---|---|
| The Issue | A short description of the accessibility issue that prevents full conformance. |
| Location or Scope | Which screens, components, or content types are affected. |
| User Impact | How the issue affects users of assistive technology. |
| Workarounds or Plans | Any alternative paths available and any remediation timeline if appropriate. |
What Partially Supports Actually Means
The ITI VPAT defines Partially Supports as functionality of the product that meets the criterion with exceptions. In practice, it signals that the criterion is met in most cases but has known issues somewhere in scope.
This conformance level is the most common in real ACRs. Few products fully support every applicable criterion, and few fail every requirement of a given success criterion. Partially Supports reflects the honest middle.
Why the Remarks Column Matters
The conformance level alone tells the reader very little. Partially Supports without context could mean one minor issue on one page, or it could mean a feature is unusable with a screen reader.
Procurement teams, accessibility reviewers, and legal teams all read the Remarks column to assess actual risk. A vague entry raises questions. A specific entry answers them.
How Do You Write a Clear Partially Supports Remark?
Start with the issue itself. Name the WCAG-related problem in plain language. Then add the location, the user impact, and any workaround.
Here is an example for SC 1.4.3 Contrast (Minimum):
Most text meets the 4.5:1 contrast ratio. Placeholder text inside form fields on the registration and checkout pages does not meet the minimum contrast ratio against the field background. Users with low vision may find this text hard to read. Field labels above each input convey the same information at sufficient contrast.
That single paragraph names the issue, scopes it, describes user impact, and points to a workaround. A reviewer knows what they are dealing with.
Common Mistakes to Avoid
Vague remarks weaken an ACR. Phrases like “some issues exist” or “minor accessibility concerns” do not give a reader anything to act on.
Overpromising is another issue. Avoid statements about future fixes unless the timeline is real and committed. ACRs document the current state of the product, not aspirations.
Copying the success criterion text into Remarks is also a mistake. The Remarks column exists to add information, not repeat what the reader already sees.
Partially Supports Versus Does Not Support
The line between these two conformance levels often comes down to scope and severity. If the criterion is met in most areas with localized issues, Partially Supports is correct. If the criterion is broadly not met across the product, Does Not Support is the accurate call.
An auditor with experience evaluating products against WCAG 2.1 AA or WCAG 2.2 AA will make this determination during the audit. The Remarks column should reflect their findings, not soften them.
Where the Remarks Come From
Strong Partially Supports explanations come from a real accessibility audit. An auditor evaluates the product against each success criterion, identifies issues, documents them, and maps those findings to the VPAT.
Without an underlying audit, Remarks tend to be guesses. With one, every entry traces back to documented evidence. This is why Accessible.org pairs every ACR with a manual audit of the product in scope.
Frequently Asked Questions
Should every Partially Supports entry list every issue?
List the issues that materially affect conformance with that criterion. If there are several, summarize the pattern and reference the most significant examples. The audit report holds the full detail.
Can Partially Supports be used if there is only one minor issue?
Yes. Any known issue against a criterion moves it out of Supports. Even a single instance places the criterion in Partially Supports territory.
How long should a Partially Supports remark be?
Long enough to convey the issue, scope, and user impact. Two to four sentences is typical. Avoid one-word entries and avoid paragraphs that drift from the criterion.
Do Partially Supports entries need to reference WCAG techniques?
No. The Remarks column describes the state of the product. Technique references can be helpful but are not required, and they should never replace a description of the actual issue.
A clear ACR is one that an outside reader can act on without follow-up questions. The Remarks column is where that clarity is earned. For help producing an ACR with audit-backed remarks, contact Accessible.org.
