Who owns accessibility when a vendor hosts your public-facing service? The short answer is that your organization still owns the user experience, the legal exposure, and the reputational risk, even when a third party designs, builds, or operates the platform. That reality surprises many procurement teams, product owners, and compliance leaders who assume a software contract transfers responsibility along with hosting, maintenance, and support. In practice, accessibility ownership is shared operationally but retained by the organization that offers the service to the public.
Accessibility, in this context, means that people with disabilities can perceive, operate, understand, and robustly use a website, portal, application, kiosk, or digital document. For public-facing services, the benchmark usually centers on the Web Content Accessibility Guidelines, commonly WCAG 2.1 or WCAG 2.2 Level AA, though some sectors also map to Section 508, EN 301 549, or national disability laws. Vendor-hosted services include software as a service platforms, case management portals, payment systems, online forms, event platforms, telehealth tools, and student, patient, or citizen portals.
I have worked on enough vendor remediation projects to know the pattern: a business team buys a capable platform, implementation moves quickly, accessibility language is vague, and only after complaints, audits, or a launch review does anyone ask who is supposed to fix keyboard traps, unlabeled buttons, inaccessible PDFs, or broken screen reader flows. By then, the contract is signed, release deadlines are fixed, and leverage is reduced. This is why procurement and vendor management sit at the center of accessibility compliance and implementation. If you do this work well upstream, you prevent expensive firefighting later.
This hub article explains how to assign responsibility, evaluate vendors, write enforceable requirements, govern implementation, and manage ongoing risk. It also frames the subtopics every strong procurement and vendor management program should connect: due diligence, contract language, VPAT review, testing, service-level expectations, exception handling, remediation governance, and renewal decisions. If your organization relies on outside platforms for public services, this is the operational playbook that keeps accessibility from falling into the gap between legal, procurement, IT, and the vendor.
Why your organization remains accountable
Your organization remains accountable because the public experiences the service as your service, not the vendor’s infrastructure. A resident paying a bill, a patient booking an appointment, or a student registering for classes does not distinguish between your brand and the technology stack beneath it. Regulators, plaintiffs’ firms, and oversight bodies generally take the same view. If the service is offered under your name, for your program, to your users, responsibility stays with you even if the defect originates in vendor code.
That does not mean vendors carry no responsibility. They may be contractually responsible for conforming to WCAG, supplying accessibility documentation, fixing defects, and supporting assistive technology compatibility. But those are delivery obligations, not a transfer of accountability. Think of accessibility like security in a cloud service model: a vendor may operate the environment, yet the customer must still assess controls, configure features correctly, monitor issues, and respond to incidents. Accessibility governance works the same way. The hosting model changes who executes tasks, not who bears the final business risk.
A useful internal rule is simple: the organization owns the obligation; the vendor owns defined deliverables; both parties share execution. That framing resolves many recurring arguments. It clarifies why procurement cannot approve a purchase without accessibility review, why implementation teams must test configurations and content, and why legal and compliance teams should track remediation commitments throughout the contract term rather than treating accessibility as a one-time sourcing checkbox.
What procurement and vendor management must cover
Procurement and vendor management for accessibility start before the request for proposal and continue through renewal or exit. Mature teams define baseline standards, build them into sourcing documents, score vendor responses, validate evidence, negotiate remediation terms, and monitor performance after launch. They also distinguish between platform accessibility and implementation accessibility. A vendor may provide an accessible core product while the customer introduces barriers through branding, templates, uploaded documents, workflow configuration, or custom integrations.
In practice, I separate vendor review into four layers: product conformance, implementation responsibility, content responsibility, and support responsibility. Product conformance asks whether the underlying service meets WCAG requirements across major user journeys. Implementation responsibility defines who handles templates, custom code, single sign-on, embedded widgets, payment pages, and mobile wrappers. Content responsibility covers PDFs, help articles, videos, alt text, and transactional emails. Support responsibility addresses defect intake, severity definitions, remediation timelines, and escalation paths when users report barriers.
These layers matter because many accessibility disputes come from ambiguity. A vendor may say the platform is accessible, but the inaccessible part turns out to be a customized application form built by a reseller, a third-party CAPTCHA, or agency-authored documents uploaded without tagging. Good vendor management eliminates this ambiguity by assigning named owners, documented evidence requirements, and acceptance criteria for each layer before a contract is signed and again before go-live.
| Procurement stage | Accessibility action | What good evidence looks like |
|---|---|---|
| Market research | Identify critical user journeys and minimum WCAG target | Documented requirements tied to forms, payments, authentication, documents, and mobile use |
| RFP or RFQ | Request VPAT, test results, roadmap, and remediation process | Recent Accessibility Conformance Report, issue log, named standards, release notes |
| Evaluation | Score claims against independent review | Demo with keyboard only, screen reader walkthrough, sample defects, plain-language answers |
| Contracting | Insert enforceable clauses and service levels | WCAG version, timelines, audit rights, indemnities, cure obligations, exit provisions |
| Implementation | Test configured service and content | UAT findings, assistive technology checks, defect ownership matrix |
| Operations | Monitor complaints and vendor fixes | Ticket metrics, regression testing results, updated conformance reports |
| Renewal | Review performance and unresolved risks | Trend data, backlog age, fulfilled commitments, user feedback |
How to evaluate vendors before you buy
The most common mistake in vendor evaluation is treating a VPAT as proof of accessibility. A VPAT, properly called an Accessibility Conformance Report when completed, is useful but not sufficient. It is a vendor-authored statement, often high level, sometimes outdated, and occasionally written against an older standard or a product edition that does not match the one you plan to deploy. Read it as a starting point for questions, not as a certification.
Ask direct, operational questions. Which version of WCAG does the vendor support today? Was the product tested against Level AA success criteria? When was the last audit, and who performed it? Which assistive technologies and browser combinations are part of regression testing? How does the vendor handle accessible authentication, error identification, focus management, captions, reflow, and PDF export? If mobile access matters, ask specifically about iOS VoiceOver and Android TalkBack support rather than assuming responsive design equals mobile accessibility.
Live demonstrations reveal more than documents. Request a keyboard-only walkthrough of the most critical tasks, such as account creation, form submission, search, payment, document download, and error correction. If the product relies on complex components, ask to see modals, date pickers, drag-and-drop alternatives, status messages, and timeout warnings. Named tools can help frame the conversation: axe DevTools, WAVE, Accessibility Insights, JAWS, NVDA, VoiceOver, and browser zoom testing all expose whether the vendor has a disciplined practice or only a sales narrative.
Also evaluate the vendor’s accessibility maturity, not just the current defect count. Vendors with a documented design system, automated testing in continuous integration, release gates, trained product teams, and a published accessibility statement are generally lower risk than vendors who promise future remediation without process evidence. I have seen imperfect products improve quickly under strong governance, while products that looked acceptable in a demo became long-term liabilities because the vendor lacked engineering ownership and could not sustain fixes across releases.
Contract terms that make accessibility enforceable
If accessibility is important enough to request during sourcing, it is important enough to define in the contract. The contract should state the required standard, usually WCAG 2.1 AA or WCAG 2.2 AA unless a legal or sector framework requires otherwise. Avoid soft wording such as “endeavor to comply” or “substantially conforms.” Use explicit obligations tied to the specific service, environments, and user journeys your organization will expose to the public.
Strong contracts require delivery of an up-to-date Accessibility Conformance Report, notice of material changes affecting accessibility, cooperation in testing, and remediation of nonconformities within defined timelines. They should identify severity levels and cure periods. For example, a blocker that prevents keyboard-only completion of payment may require a workaround within days and a permanent fix within a scheduled release window, while a lower-severity issue may follow a longer timetable. The point is not to demand impossible perfection but to create enforceable operational expectations.
Other useful clauses include audit rights, customer testing rights, obligations for subcontractors, and commitments that updates will not regress accessibility. Where risk is high, organizations sometimes negotiate holdbacks, acceptance criteria linked to accessibility defects, or termination rights if critical barriers remain unresolved. Indemnity language can help, but it should not be your primary protection. The best protection is practical leverage: documented standards, measurable obligations, evidence rights, and the ability to delay acceptance or renewal when the service does not meet agreed requirements.
Implementation, content, and shared responsibility
Even with a strong vendor, many accessibility failures happen during implementation. Public-facing services rarely run as untouched commercial products. They are branded, configured, integrated, populated with documents, and connected to identity systems, payment gateways, maps, chat tools, and analytics tags. Every one of those decisions can create barriers. That is why the hub topic of procurement and vendor management must connect tightly to implementation governance.
A practical responsibility matrix prevents confusion. The vendor may own the codebase, component library, hosting, and standard releases. Your internal team may own page content, document uploads, video transcripts, alt text, error messages, and policy notices. A systems integrator may own custom workflows and API integrations. Without a RACI-style model, defects bounce among teams and users wait longer for relief. During launches, I insist that each critical journey has a named business owner, technical owner, and vendor contact so there is no ambiguity when testing finds issues.
Content deserves special emphasis because it is one of the most common blind spots. A platform can be technically conformant while the public still encounters inaccessible PDFs, unlabeled links, images of text, or videos without captions. Contracts should address platform accessibility, but internal governance must address authoring practices and quality control. If your staff uploads forms or notices, train them on heading structure, tagged PDF basics, plain language, color contrast, and accessible tables. Vendor hosting does not excuse inaccessible content created by the customer.
Ongoing monitoring, complaints, and renewal decisions
Accessibility ownership does not end at launch. Public-facing services change constantly through patches, new features, content updates, browser changes, and assistive technology updates. The right operating model combines periodic audits, regression testing on critical paths, and a clear complaint-handling process. If a user reports that a form cannot be submitted with a screen reader, that issue should enter the same disciplined workflow as a production defect: triage, severity assignment, workaround, root-cause analysis, fix, and communication back to the user when appropriate.
Vendor management should review accessibility performance during regular service meetings. Track open defects, average age by severity, regressions introduced in new releases, adherence to remediation timelines, and repeat problem areas. Trend data matters. A vendor with a few known issues and reliable closure may be lower risk than one with polished documents but chronic slippage. Renewal decisions should weigh these patterns explicitly. If the vendor has not met contractual commitments, renewal is the moment to impose stronger terms, require a roadmap, or consider replacement.
The central takeaway is straightforward: when a vendor hosts your public-facing service, your organization still owns accessibility outcomes. Procurement and vendor management are the control points that turn that ownership into action. Set standards early, validate vendor claims, write enforceable contracts, define shared responsibilities, test the configured experience, and monitor performance throughout the relationship. If this page is your starting point for the broader compliance and implementation hub, use it to build a repeatable process now, then apply it to every hosted public service before the next renewal or launch.
Frequently Asked Questions
Who is ultimately responsible for accessibility when a vendor hosts our public-facing website, portal, or application?
Your organization is still ultimately responsible. If the service is public-facing and people associate it with your brand, your organization owns the user experience, the legal exposure, and the reputational consequences if accessibility barriers prevent users from completing tasks. A vendor may design, develop, host, maintain, or support the platform, but those operational roles do not remove your responsibility to ensure the service is accessible to customers, patients, students, applicants, or members of the public. From a practical standpoint, users do not distinguish between your internal team and your vendor. If a form cannot be completed with a screen reader, if captions are missing, or if keyboard navigation fails, they see it as your service failing them.
That said, ownership is not the same as doing all the work yourself. Accessibility in vendor-hosted environments is usually a shared operational responsibility. The vendor may be responsible for code quality, remediation, platform updates, content rendering, and conformance documentation, while your organization may be responsible for procurement standards, governance, content entry, testing oversight, acceptance criteria, and ongoing monitoring. The key point is that accountability stays with your organization, even when execution is distributed across teams and suppliers.
Can a contract transfer accessibility responsibility to the vendor?
A contract can assign duties, performance expectations, remediation timelines, indemnification terms, and reporting requirements, but it does not fully transfer your real-world accountability. Contracts are essential because they create enforceable obligations for the vendor, yet they do not erase the fact that the public interacts with a service under your name. If accessibility issues arise, your organization may still face complaints, lost users, regulatory scrutiny, and damage to trust long before any contractual remedy is useful.
The smarter approach is to use the contract to make accessibility concrete and measurable. That means requiring conformance with recognized standards such as WCAG, defining the applicable level, requiring accessibility testing before launch and after major updates, specifying documentation such as an accessibility conformance report, setting remediation service-level expectations, and reserving the right to audit or independently test the service. Strong contracts are not about shifting all responsibility away; they are about reducing risk by clearly defining who must do what, when, and to what standard. In other words, the contract should support shared accountability, not create a false sense that accessibility has been outsourced.
What should procurement and compliance teams require before selecting a vendor?
Procurement and compliance teams should treat accessibility as a core business requirement, not a nice-to-have add-on. Before selecting a vendor, they should ask for detailed evidence of accessibility maturity, not just broad marketing claims. Useful materials include an up-to-date accessibility conformance report, details about how the vendor tests against WCAG, examples of known limitations, remediation processes, product roadmap commitments, and information about whether accessibility is built into design, development, quality assurance, and release management. It is also important to understand what parts of the experience are controlled by the vendor platform versus your internal teams, because responsibility often breaks down across templates, integrations, content modules, PDFs, media, and third-party plug-ins.
Teams should also evaluate the vendor’s operational readiness. Ask whether accessibility defects are tracked like other defects, whether urgent barriers have escalation paths, whether updates can introduce regressions, and whether user feedback is reviewed and acted on. If the service is business-critical, request demos that show keyboard access, screen reader compatibility, focus management, captions, form labeling, error handling, and responsive behavior. Ideally, procurement should include accessibility requirements in the RFP, selection scoring, contract language, and final acceptance criteria. Doing so makes accessibility part of vendor selection from the beginning rather than a costly issue discovered after implementation.
How should accessibility ownership be divided between our organization and the vendor after launch?
After launch, the most effective model is a clearly documented shared-responsibility framework. Your organization should own governance, policy, risk management, vendor oversight, user complaint handling, and internal content practices. The vendor should own accessibility within the parts of the platform they control, including code, components, templates, interface behavior, defect remediation, and release quality. If your team uploads documents, publishes articles, configures workflows, or creates forms inside the vendor system, your organization also owns the accessibility of those contributions. Many accessibility failures happen at these handoff points, where each party assumes the other is responsible.
To avoid gaps, define who is responsible for testing, approving releases, fixing defects, maintaining conformance documentation, and responding to accessibility incidents. Establish regular review cycles, especially after product updates, design changes, or content migrations. Accessibility should also be integrated into change management so that new features, integrations, and redesigns are not treated as exceptions. When ownership is documented at the task level rather than the slogan level, teams can act quickly, reduce finger-pointing, and keep the service accessible over time instead of only at procurement or launch.
What are the biggest risks of assuming the vendor “has accessibility covered”?
The biggest risk is discovering too late that accessibility was never fully addressed, was only partially addressed, or was addressed in ways that do not match how your users actually interact with the service. Vendors may have accessible core components but inaccessible customizations. They may provide a generally conformant platform while leaving documents, embedded tools, payment flows, chat widgets, maps, or account-management features outside the scope of their claims. They may also rely on outdated testing results, limited sampling, or statements that sound reassuring but do not amount to verified conformance. If your organization assumes the vendor has everything covered, these gaps can remain hidden until a customer complains, a deal is delayed, or a legal demand arrives.
There is also a strategic risk. When accessibility is treated as the vendor’s issue alone, internal teams often fail to build the skills and governance needed to manage public-facing digital services responsibly. That leads to weak procurement questions, vague contracts, poor acceptance testing, and slow responses when barriers are reported. The better mindset is to view the vendor as a critical delivery partner, not as a substitute for organizational ownership. Your organization should verify, monitor, and govern accessibility continuously. That approach protects users, strengthens compliance efforts, and reduces the business and reputational impact of preventable accessibility failures.
