VPAT remarks examples: good and bad, criterion by criterion

The remarks column is where a VPAT becomes evidence or stays an assertion. ITI's template instructions ask for detailed remarks to justify every conformance level. For Partially Supports or Does Not Support, the remarks should identify the affected functions or features and how they fall short. For Not Applicable, they should explain why.

This post gives VPAT remarks examples for five criteria that government reviewers question often. Each has a weak version, which tends to generate a follow-up question, and a stronger one. The products and details are illustrative. Write your remarks about your product, from your testing.

What a good remark contains

Across criteria, a remark that reviewers trust usually answers three things:

1. Scope: which parts of the product were checked.
2. Method: how, briefly. Keyboard, screen reader, contrast measurement, code inspection.
3. Exceptions: what does not meet the criterion, named specifically, and when it will be fixed, if you know.

It does not need to be long. Two or three sentences usually do it.

1.1.1 Non-text Content (Level A)

The criterion requires that non-text content has a text alternative that serves the equivalent purpose, with specific handling for controls, decorative images and other cases.

Weak:

Supports. Images have alt text.

This is the most common remark in the column and it raises immediate questions. All images? Including icons used as buttons? Charts?

Stronger:

Supports. Informative images have text alternatives describing their content. Icon-only buttons (print, export, close) have accessible names. Decorative images use empty alt attributes. Dashboard charts provide a data table alternative via a "View as table" control. Verified by code inspection and with NVDA and VoiceOver.

If it is partial, say so:

Partially Supports. Uploaded user images in the document library have no mechanism for adding alt text. The map on the Facilities page has no text alternative for location information. Both are planned for release 8.3, targeted for Q1 2027. All other images meet the criterion.

1.4.3 Contrast (Minimum) (Level AA)

The criterion requires a contrast ratio of at least 4.5:1 for text and images of text, or 3:1 for large-scale text (at least 18 point, or 14 point bold). Logotypes and text in inactive components are exempt.

Weak:

Supports. Our brand colors are accessible.

Brand colors are not a measurement, and "accessible" is not a ratio.

Stronger:

Supports. Text and background color pairs in the default theme were measured with a contrast analyzer. Body text is 7.2:1; the lowest-contrast text in the product (secondary labels) is 4.6:1. Text in disabled controls is exempt under the criterion. Customer-configurable themes are outside the scope of this report; see Notes.

Partial:

Partially Supports. Placeholder text in form fields on the Registration page is 3.1:1. Error messages on the Payment page are 4.1:1. All other text meets 4.5:1. Fix scheduled for release 2026.10.

Note the useful habit: give the actual ratio of the failure. A reviewer can then judge whether this is a near-miss or a serious gap.

2.1.1 Keyboard (Level A)

All functionality must be operable through a keyboard interface, except where the underlying function depends on the path of movement, such as freehand drawing.

Weak:

Supports. The application is keyboard accessible.

Reviewers will ask how that was established and whether it includes the difficult parts: drag and drop, rich text editors, date pickers, modal dialogs.

Stronger:

Supports. All primary workflows (sign-in, search, application submission, document upload, payment) were completed using keyboard only in Chrome, Firefox and Safari. Drag-and-drop reordering in the agenda builder has keyboard-operable Move Up and Move Down buttons. No keyboard traps were found.

Partial:

Partially Supports. The calendar date picker on the Scheduling page cannot be operated by keyboard; dates can instead be typed into the text field beside it. Column resizing in the Reports grid requires a mouse. All other functionality is keyboard operable.

The partial remark names the gap and the alternative. That lets a buyer judge whether the gap blocks a task or is an inconvenience.

2.4.7 Focus Visible (Level AA)

Any keyboard-operable interface must have a mode of operation where the keyboard focus indicator is visible.

Weak:

Supports. We use browser default focus styles.

That may be true, but custom components often suppress default outlines, and reviewers know it.

Stronger:

Supports. All interactive elements show a visible focus indicator (2px solid outline in the theme's focus color). Custom components, including the dropdown menus, tab panels and data grid cells, were checked individually with keyboard navigation in Chrome, Firefox and Safari.

Partial:

Partially Supports. Focus is not visible on the row action buttons in the Case List data grid and on links in the site footer. Fix targeted for release 4.12.

4.1.2 Name, Role, Value (Level A)

For all user interface components, the name and role must be programmatically determinable, user-settable states and values must be programmatically settable, and changes must be notified to assistive technology.

Weak:

Supports. Built with standard HTML.

Standard HTML controls used as intended do meet this criterion, as WCAG itself notes. But most modern products also contain custom components, and those are where 4.1.2 failures live.

Stronger:

Supports. Native HTML form controls are used where possible. Custom components (combobox, tab panel, accordion, toggle switch, modal dialog) use ARIA roles, states and properties following the WAI-ARIA Authoring Practices patterns. Names, roles and state changes verified with NVDA and Firefox, JAWS and Chrome, and VoiceOver and Safari.

Partial:

Partially Supports. The toggle switches on the Notification Settings page do not expose their on/off state to screen readers. The custom file upload control has no accessible name. Fixes planned for release 6.2.

Patterns to avoid in any remark

A few phrasings tend to prompt follow-up wherever they appear:

• Blank beside Partially Supports, Does Not Support or Not Applicable. The template asks for an explanation in all three cases.
• "Partially Supports. Working on it." No feature, no failure, no date.
• "Supports with exceptions." In VPAT 2.5 that is Partially Supports. Use the term the template defines.
• "Not Applicable" on a criterion that plainly applies, such as 2.1.1 for any interactive product.
• Identical text on every row. It suggests the remarks were filled in without testing each criterion.
• Claims about the user's browser or assistive technology as the reason a criterion fails, without saying what the product does.

Our list of VPAT red flags covers the same issues from the buyer's side.

Where remarks fit in the larger report

Good remarks cannot rescue a report on the wrong edition or an unnamed version. Those basics are covered in how to fill out a VPAT. And remarks change how a reviewer reads conformance values. A Partially Supports with a clear remark is often received better than a Supports with none. Our note on Supports vs Partially Supports explains why.

---

Sources: ITI VPAT 2.5Rev template, Essential Requirements and Best Practices for Authors; W3C WCAG 2.1 success criteria 1.1.1, 1.4.3, 2.1.1, 2.4.7 and 4.1.2. Example remarks are illustrative and describe no real product.

GOVvpat does not write VPATs. Vendors can have their own report reviewed the way a government buyer will read it before submitting it. See how it works for vendors.