Salesforce VPAT: What Admins Need to Know
If you work in government, education, or healthcare, someone is eventually going to ask for the VPAT of the AppExchange component you just installed. Here is what that document is, and what to look for.
A VPAT (Voluntary Product Accessibility Template) is a standard document in which a vendor states, control by control, how their product measures up against accessibility standards. It is not a certificate and nobody issues it to you. It is a structured self-assessment, and its value comes entirely from how honestly it was filled in.
Why it shows up in Salesforce procurement
Salesforce itself publishes VPATs for its products. Public sector buyers in the United States are bound by Section 508, European buyers by EN 301 549, and both standards lean on WCAG. When your org is subject to those rules, every piece of software in the stack inherits the obligation, including the AppExchange package somebody installed to solve a scheduling problem.
In practice it surfaces at the least convenient moment: not during evaluation, but during a security or procurement review, after the component is already embedded in a business process.
The three standards a VPAT covers
| Standard | Who cares about it | What it covers |
|---|---|---|
| WCAG 2.1 A and AA | Almost everyone, as the baseline | The web content criteria the other two build on |
| Revised Section 508 | US federal, and most state and local | Section 508 obligations, expressed against WCAG |
| EN 301 549 | European public sector | The EU procurement equivalent |
Reading one without being an expert
Every criterion gets one of a few conformance levels. The wording matters:
- Supports means the criterion is met throughout.
- Partially Supports means it is met in most cases but not all. This is the interesting one.
- Does Not Support means it is not met.
- Not Applicable means the criterion does not apply to this product.
Be more suspicious of a VPAT that claims Supports on everything than one with a few honest Partially Supports entries. Real software has edge cases. A document with no partials usually means nobody actually tested it.
Four questions worth asking a vendor
- When was it last verified, and against which version? A VPAT written two years and six releases ago describes software that no longer exists.
- Was it tested on the packaged version? Unpackaged source and a managed-package install can behave differently. The one you install is the one that matters.
- Automated scan, manual review, or both? Automated tooling catches roughly a third of issues. Keyboard navigation and screen-reader flow need a human.
- Is color ever the only signal? This is the single most common failure in scheduling interfaces, where status is shown as a colored cell and nothing else.
Calendars are unusually hard to get right
A calendar is a grid of interactive cells, which makes it one of the harder patterns to make accessible. Getting it right means real ARIA grid semantics (role="grid", rows, gridcells, column headers), arrow-key navigation within the grid rather than tabbing through every cell, an accessible name on each cell carrying both the date and its state, and status conveyed by shape or text as well as color.
That last point has a direct consequence for admin-configurable products: if you let admins choose their own status colors, you cannot guarantee contrast, which is precisely the sort of thing that should show up as Partially Supports rather than being quietly claimed as Supports.