Accessibility Evidence Should Match the Thing You’re Shipping

Accessibility evidence is not all the same.

A statement is not the same as a test.

A test is not the same as a user path.

A user path in a default product is not the same as the configured workflow your team plans to launch.

That does not mean one kind of evidence is always good and another is always bad. It means the evidence should match the decision the team is trying to make.

If the decision is, "Should we keep evaluating this vendor?" a high-level accessibility statement may be enough to continue the conversation.

If the decision is, "Are we ready to launch this workflow?" the evidence needs to be closer to the thing users will actually do.

That is where teams can get tripped up.

They collect something that sounds accessibility-related, but it does not answer the launch question.

Examples:

• A VPAT covers the platform, but not the configured workflow.
• A testing summary covers the newest version, but the implementation uses an older one.
• A vendor statement covers web screens, but the project depends on generated PDFs.
• A design review covers the happy path, but not errors, empty states, or required fields.
• A tool scan reports no issues, but keyboard flow was never checked.
• A demo looks fine with a mouse, but the team has not verified focus order.

Each item may contain useful information.

None of them automatically proves the real path is ready.

Better evidence connects to the actual thing being shipped.

That means asking:

• What workflow is this evidence about?
• What version, environment, or configuration does it cover?
• What content, documents, and integrations are included?
• Which user paths were checked?
• Which assistive technology or input methods were considered?
• What known issues remain?
• What changed after this evidence was created?

This does not need to become a giant evidence packet for every small change.

The point is fit.

Simple work may need simple evidence. Higher-risk work may need more specific evidence. Vendor-heavy work may need clearer boundaries between product claims, local configuration, and remaining gaps.

The mistake is treating any accessibility artifact as if it answers every accessibility question.

Evidence should reduce uncertainty.

If it creates more ambiguity, the team may need to ask a better question.

For example, "we have a VPAT" is less useful than "the VPAT covers version X, marks these criteria as partially supported, does not include generated documents, and the vendor confirmed these two workflow issues are on their roadmap."

That second answer may sound less polished.

It is more useful.

It tells the team what is known, what is not known, and where risk still lives.

Accessibility evidence should help the team make a responsible decision.

To do that, it has to point at the same thing the team is about to ship.

Previous note

A VPAT Is Not a Magic Shield sets up why vendor accessibility documents are useful evidence, but not automatic proof that the shipped experience is accessible.