A Vendor Claim Is Not the Same as a Tested Workflow

A vendor claim can be useful.

It can tell the team where to start. It can show that the vendor has thought about accessibility. It can provide documentation, standards language, test summaries, or a path for follow-up.

But a vendor claim is not the same as a tested workflow.

That distinction matters because users do not experience claims.

They experience tasks.

They try to sign in, complete a form, upload a document, search for a record, read an error, submit a request, download a notice, or track a status.

If that path breaks, the sentence in a proposal or accessibility statement will not help them complete the task.

A common pattern looks like this:

• The vendor says the product supports accessibility.
• The team accepts the answer.
• The product is configured for a specific program, service, or workflow.
• Content, documents, settings, roles, and integrations are added.
• The team discovers later that the actual path has barriers.

The original claim may not have been dishonest.

It may have been incomplete for the decision the team needed to make.

That is why teams should translate vendor claims into workflow questions.

If a vendor says the product is keyboard accessible, ask which workflows were checked without a mouse.

If a vendor says the product supports screen readers, ask what was tested, with which patterns, and where known issues remain.

If a vendor says forms are accessible, ask about the specific forms, error handling, required fields, instructions, and review screens your users will encounter.

If a vendor says documents are supported, ask whether generated PDFs, attachments, exports, notices, and templates are included.

If a vendor says they follow WCAG, ask how that shows up in the configured experience.

None of this requires a hostile procurement process.

It requires a practical one.

The goal is to avoid treating accessibility as a checkbox answer when the actual risk lives in the workflow.

A tested workflow gives the team more confidence because it is tied to real user behavior.

It does not have to be perfect evidence. Even a focused check can reveal important things:

• Can someone reach every interactive control with the keyboard?
• Does focus move in a predictable order?
• Are labels and instructions clear?
• Are errors announced and explained?
• Does the user know what changed after an action?
• Can the task be completed without relying on color or visual position alone?
• Do documents and downloads preserve the information needed to continue?

Those questions move the conversation from a vendor's general posture to the user's actual path.

That is where accessibility becomes easier to manage.

A claim can start the conversation.

A tested workflow tells the team whether the claim is helping the people who need to use the thing.

Previous note

Ask Vendors How Accessibility Works in Your Configuration sets up why a general vendor answer needs to be checked against the configured workflow people will actually use.