Checking a vendor's accessibility claims: VPATs and real testing

Reference article · 5 min read

Nearly every vendor selling software to government offers a Voluntary Product Accessibility Template with its proposal, usually a PDF offered as evidence that the product meets accessibility requirements. It is useful evidence. It is not proof. The vendor prepares it, or a consultant the vendor hired does, and nothing about the format requires independent testing.

Treat it as a structured self-disclosure: it tells you what the vendor claims and, read carefully, how seriously the vendor takes the question. What follows is how to read one, how to verify it during evaluation without an accessibility specialist on staff, and what to put in the contract.

What a VPAT is, and what an ACR is

The VPAT is a blank template published by the Information Technology Industry Council. When a vendor fills it in for a specific product, the completed document is an Accessibility Conformance Report, or ACR. People say "VPAT" for both, but ask for an ACR and you are asking for findings rather than a form.

The template comes in editions aligned to different standards: a WCAG edition, a Revised Section 508 edition, a European EN 301 549 edition, and a combined international edition. For state and local web content and mobile applications, the WCAG content at Level AA is usually what matters. Editions and standard versions change, so confirm which applies to your obligation with the official source or your counsel.

Each row is one success criterion with a conformance level and a remarks column, rated Supports, Partially Supports, Does Not Support, Not Applicable, or Not Evaluated.

Reading the report critically

• Scope. Which product, which version, which platforms, browsers, and assistive technologies were tested. A report on the staff console says nothing about the resident-facing portal.
• Date. A report from two years ago against a product on a monthly release cycle describes software that no longer exists.
• Evaluator and method. Manual testing with assistive technology by a named third party is stronger evidence than an unattributed internal review, and much stronger than a scan alone.
• The remarks, not the ratings. "Supports" on every row with an empty remarks column is not a conformance report. Useful reports explain how each criterion is met and name the exceptions.
• Honest concessions. A few specific Partially Supports entries, each describing the defect and a fix plan, are more credible than a clean sweep.
• Authoring disclaimers. Many reports note that conformance depends on content agency staff create. True, and it raises a question: does the authoring interface help staff produce accessible output, or make inaccessible output the default?

Verification you can run during evaluation

Pick the three to five tasks that matter most: the ones a resident must complete, the ones a caseworker repeats all day. Test those in the demonstration environment, on the version offered.

Start with a keyboard-only pass, using only Tab, Shift and Tab, Enter, Space, the arrow keys, and Escape.

• Every control you need is reachable, and the focus indicator is visible at all times.
• Focus order follows the visual order and does not jump unexpectedly.
• Nothing traps focus, and menus, dialogs, and date pickers take focus when opened, close with Escape, and return focus where it was.
• Validation errors can be reached and understood without a mouse.

Then run a screen reader spot check. NVDA on Windows and VoiceOver on macOS and iOS cost nothing. This is not an expert audit; it is an attempt to finish the same tasks by listening. Note whether form fields announce a real label, whether buttons announce their purpose rather than just "button", whether headings give the page a usable structure, and whether errors and dynamic updates are announced at all. Record the task, the screen, and where you got stuck.

Automated scanning and its limits

Run a scanner too. Automated tools are fast and repeatable, and they find real defects: missing labels, empty links, low contrast, broken heading structure. Ask the vendor for their scan output and run your own.

They also miss most of what matters. A tool can confirm an image has alternative text but not that the text describes the image. It cannot judge whether focus order makes sense, whether an error message is understandable, or whether captions are accurate. A clean scan is a floor, not a ceiling.

What to ask vendors

• Who prepared the ACR, when, against what version, and with which methods and assistive technologies.
• Which defects are known and unfixed today, when each is scheduled, and how accessibility is tested before each release.
• Whether they will complete your core tasks live in the demonstration, keyboard only and then with a screen reader.
• How agency-authored content and uploaded documents are handled.

What to require in the contract

• A standard named precisely. The version and level, applied to the delivered product, not to accessibility in general.
• A warranty that survives acceptance. The vendor represents conformance and remediates defects found later at no added cost.
• Remediation timelines tied to severity, with a defined path for defects that block a core task and a consequence, such as withheld payment or credits, when the timelines are missed.
• A right to test, including a test environment and the option of a third-party audit.
• An updated ACR at each major release, so the document does not go stale during the term.
• Indemnification for third-party accessibility claims arising from the product, in the form your counsel approves.

Accessibility problems are cheapest to fix before award, while the agency still has leverage. An afternoon of keyboard and screen reader testing is among the highest-return work an evaluation team can do. HQT builds and evaluates public-sector applications against WCAG conformance requirements, including procurement-stage verification and remediation of existing systems.

Frequently asked questions