VPAT and ACR for Data-Heavy Products

Enterprise and public-sector buyers ask for an Accessibility Conformance Report — usually written using the Voluntary Product Accessibility Template (VPAT) from the Information Technology Industry Council. For data-heavy products, ACRs are often either suspiciously perfect (“Supports” everywhere) or uselessly vague. Buyers’ accessibility teams know that grids, charts and dashboards are hard, and a credible ACR says precisely what works, what partially works and what does not — with remarks that let customers plan around gaps.

This guide belongs to accessibility governance for data products.

Spec reference

VPAT editions — WCAG (WCAG 2.x A and AA), Section 508 (US), EU (EN 301 549), and INT (all three). Choose the edition your buyers require.
Conformance levels — Supports; Partially Supports; Does Not Support; Not Applicable; Not Evaluated (only allowed for AAA in some editions).
Remarks and explanations — the column where credibility is won or lost.
EN 301 549 includes non-web documents and software clauses, relevant for exports and native apps.

When to use — and when not to

Produce an ACR when customers or regulations ask for one — common for enterprise SaaS, government and education sales. Base it on real testing of the current version.

Do not write an ACR from a component library’s claims alone; assembled products introduce failures components did not have. Do not mark a criterion “Supports” because most of the product supports it — that is “Partially Supports” with a remark.

The misapplication: an ACR listing “Supports” for 1.1.1 Non-text Content while dashboards contain dozens of charts with no text alternatives. Buyers’ testers find it in an hour, and the whole report loses credibility.

Annotated code example

Remarks are prose, but structure helps. A remark template for data-heavy products:

Criterion: 1.1.1 Non-text Content (Level A)
Conformance Level: Partially Supports
Remarks and Explanations:
  Supported: icons, images and form controls have text alternatives; dashboard
  charts provide a summary and a data table view ("Show as table").
  Exceptions: the legacy "Network map" in Admin > Topology has no text
  alternative; the "Export as image" feature produces PNGs without alt text.
  Workaround: topology data is available in Admin > Connections as a table.
  Plan: Network map text alternative scheduled for version 7.4.

// Keeping ACR remarks honest: a small script listing charts without summaries from the component registry
const charts = registry.components.filter(c => c.type === 'chart');
const missing = charts.filter(c => !c.a11y?.summary || !c.a11y?.tableView);
console.table(missing.map(c => ({ chart: c.name, page: c.route })));   // feeds the 1.1.1 remark

Keyboard & AT behaviour

Document which assistive technologies were tested in the ACR’s evaluation methods section:

Item	Example entry
Screen readers	NVDA 2026.x with Firefox and Chrome; JAWS 2026 with Chrome; VoiceOver on macOS 26 with Safari
Keyboard	Keyboard-only testing on Windows and macOS
Magnification	Windows Magnifier and browser zoom at 200% and 400%
Contrast themes	Windows contrast themes (Aquatic, Desert)
Automated tools	axe-core 4.x in CI; Accessibility Insights FastPass

These are the criteria buyers' testers check first in data products.

Integration context

Testing for the ACR draws on manual accessibility audits and assistive technology behaviour differences. Known gaps should be tracked in the backlog described in tracking accessibility debt in component libraries. Export formats fall under EN 301 549 document clauses — see data export & print.

Gotchas

Version drift. An ACR for version 6.0 says little about version 6.4. Date it, version it, and review it each release.

Third-party components. Embedded charts or grids from vendors are part of your product; include them, using vendor ACRs as input but testing them in context.

Legal review. ACRs are often used in contracts. Keep them accurate; legal teams prefer honest partial support over claims that can be disproven.

Common mistakes

“Supports” everywhere.
Remarks that do not name features.
No evaluation methods or AT versions.
ACRs that are years old.

Framework notes

Frameworks do not appear in ACRs, but component inventories do help: generate a list of grids, charts and custom widgets from your codebase (routes, component registry) so testers sample every kind, and so remarks can list affected features precisely.

Worked example

A SaaS analytics vendor’s ACR claimed full support for all AA criteria. A government buyer’s accessibility team tested two dashboards and found charts without alternatives and drag-only widget layouts within an hour, and the procurement stalled. The vendor’s rewrite marked eight criteria “Partially Supports” with specific remarks, listed workarounds (table views, the layout menu), named the release where fixes would land, and included evaluation methods. The buyer accepted it with a remediation clause, and the remarks became the vendor’s roadmap.

Writing remarks that survive scrutiny

Buyers’ accessibility specialists read remarks first. Good remarks share four traits: they name features (“the Revenue dashboard’s Sankey chart”), they describe the gap in user terms (“values are only available on hover”), they give the workaround (“the same data is in Reports > Revenue flows as a table”), and they state the plan with a version or quarter. Avoid boilerplate such as “the product is designed with accessibility in mind” — it signals that nobody tested.

Testing checklist

Scope, version, platforms and AT are stated.
Representative grids, charts, dashboards and exports were tested.
Each criterion's level reflects the weakest relevant feature.
Remarks name features, workarounds and plans.
The ACR is dated and reviewed each release.

Design system notes

Maintain per-component conformance notes in the design system (what each component supports, known gaps). They make product ACRs faster to write and more accurate — though products must still be tested as assembled.

FAQ

Is a VPAT the same as an ACR?

The VPAT is the template; a completed VPAT is an Accessibility Conformance Report.

Can we self-assess?

Yes. Many vendors self-assess; third-party audits add credibility. Either way, state the method.

Should we publish known gaps?

Yes. Buyers expect complex products to have gaps; they care that you know them and have plans.

Which edition should we use?

The one your buyers ask for. The INT edition covers WCAG, Section 508 and EN 301 549 together.

How often should it be updated?

At least annually and after major releases that change interaction or UI.

Does "Partially Supports" lose deals?

Less often than discovered false claims. Precise remarks with workarounds and plans are usually acceptable.

Should the ACR mention third-party components?

Yes, where they affect conformance. Name the feature, not necessarily the vendor, and describe the gap and workaround like any other.

Acceptance criteria for data grids — preventing gaps
Tracking accessibility debt — managing known gaps
Manual accessibility audits — the testing behind the report

← Back to Accessibility Governance for Data Products