Vendor Accessibility Still Needs Ownership
Buying or configuring a vendor product does not remove accessibility ownership; it changes where teams need to ask, test, document, and follow up.
Vendor products can make accessibility feel like someone else's job.
That is understandable.
The team did not design the whole platform. They may not control the source code. They may not be able to fix every issue directly. A vendor may provide documentation, support language, and accessibility statements that sound reassuring.
But vendor accessibility still needs ownership.
Not ownership of every line of code.
Ownership of the decision to use the product, the way it is configured, the evidence the team accepts, the risks the team documents, and the follow-up when users run into barriers.
That distinction matters.
A project team may say:
The vendor owns accessibility.
Sometimes that is partly true.
The vendor may own the core product. They may own updates, component fixes, platform-level bugs, and roadmap commitments.
But the local team may still own:
- which product features are enabled
- how the workflow is configured
- what content is added
- what documents are uploaded or generated
- what integrations are connected
- what alternatives are offered when gaps remain
- what evidence is collected before launch
- how issues are tracked after launch
That is not a small list.
A product can be reasonably accessible in one configuration and much weaker in another. A vendor can provide an accessible component that becomes confusing when local labels, instructions, or business rules are added. A platform can support accessible documents while a team uploads inaccessible PDFs. A workflow can depend on a third-party widget that was not part of the vendor's accessibility statement.
None of that means the team chose badly.
It means ownership has to follow the actual user path.
If a resident, employee, customer, or applicant cannot complete the task, they will not experience the org chart of responsibility. They will experience one broken path.
So the practical question is not:
Who can we blame if the vendor product has issues?
The better question is:
Who is responsible for making sure accessibility risk is understood, documented, and handled before this goes live?
That answer may involve procurement, product, business owners, developers, vendors, accessibility reviewers, legal, and support teams.
But it cannot involve nobody.
Good ownership looks like simple habits:
- Ask for current accessibility documentation early.
- Compare vendor claims to the actual workflow being used.
- Identify which parts are vendor-controlled and which parts are locally controlled.
- Document known limitations before review.
- Decide who contacts the vendor when issues are found.
- Track remediation instead of letting known gaps live in email threads.
- Make sure support teams know what to do if a user hits a barrier.
This is not about making every project team responsible for fixing a vendor platform alone.
It is about making sure vendor risk does not become invisible.
Accessibility does not become someone else's problem just because the product came from somewhere else.
The work changes shape.
The ownership still needs to be named.
Previous note
A Vendor Claim Is Not the Same as a Tested Workflow sets up the gap between vendor claims and the team’s responsibility for the workflow it chooses to ship.