Most healthcare organizations don't build their own patient portals, scheduling tools, or telehealth platforms. They purchase them — from EHR vendors, from digital health companies, from specialized SaaS providers. The assumption, often unstated, is that the vendor is responsible for making sure those tools work.
Under Section 504, that assumption is wrong.
The 2024 HHS Final Rule is explicit: covered entities are responsible for the accessibility of digital services they provide to patients, regardless of who built or hosts the underlying technology.
The fact that a platform is vendor-supplied does not transfer the obligation. It does not reduce the liability. And it does not change what a patient with a disability is entitled to expect.
For most healthcare organizations, this means a significant portion of their digital accessibility risk sits inside systems they don't directly control — and inside contracts that were almost certainly written before digital accessibility was a defined legal requirement.
In this guide, we will walk through what the rule says about vendor-supplied tools, which platforms are in scope, why most existing contracts don't protect you, and what you can do about it before the deadline arrives.
What the rule actually says about vendor-supplied tools
The language in 45 C.F.R. § 84.84(a) is direct. Covered entities must ensure that their web content and mobile applications are accessible — including content and applications "provided or made available through contractual, licensing, or other arrangements."
That phrase covers the full range of third-party platforms a healthcare organization might use to deliver services to patients.
If your organization provides access to a platform as part of delivering care or services, that platform is in scope under Section 504.
The contractual relationship between your organization and the vendor is irrelevant to the patient's right to accessible services — and to OCR's enforcement authority.
The practical implication is straightforward: your vendor relationship does not create a liability shield. It creates a liability that you need to actively manage.
Which vendor platforms are in scope
Any third-party platform your organization uses to deliver services to patients or program participants falls within Section 504's scope. In a typical healthcare organization, that includes:
- EHR patient portals — the interfaces through which patients access records, view test results, request prescription refills, and communicate with providers
- Online scheduling tools — whether embedded on your website or provided through a standalone vendor platform
- Telehealth platforms — the web or app-based environments through which patients access virtual visits
- Bill pay portals — systems through which patients pay balances or manage payment plans
- Digital intake and consent forms — online forms patients complete before or during a visit, even when hosted by a third-party forms provider
- Kiosk software — self-service check-in or wayfinding systems located in your facilities
- Web platform providers — the content management systems or website platforms that power your public-facing web presence
A useful test: if a patient interacts with it as part of receiving care or services from your organization, it is almost certainly in scope — regardless of who built it or where it is hosted.
Why most current contracts don't protect you
The HHS Section 504 Final Rule was published in May 2024. Most vendor contracts currently in use across the healthcare sector were signed before that date — many of them years earlier.
Contracts signed before May 2024 almost certainly do not include:
- An explicit requirement that the vendor's platform conform to WCAG 2.1 Level AA
- A commitment by the vendor to fix accessibility defects at their own expense
- A requirement that future updates maintain existing accessibility features
- Any mechanism for your organization to verify accessibility claims independently
Without these provisions, your organization has no contractual basis to compel a vendor to fix an accessibility barrier — even if that barrier is creating Section 504 exposure for your organization.
The vendor's obligation runs to the terms of the contract. If accessibility isn't in the contract, it isn't enforceable.
This is the gap that most healthcare organizations are currently operating in: legal responsibility without contractual leverage.
What a VPAT is — and what it doesn't guarantee
When you ask a vendor about accessibility, the most common response is to provide a VPAT — a Voluntary Product Accessibility Template. Once completed by the vendor, a VPAT becomes an Accessibility Conformance Report (ACR).
A VPAT is a standardized form that documents how a product aligns with accessibility standards across a defined set of criteria.
It is the industry-standard tool for communicating accessibility status in procurement — and it is a useful starting point.
But it is only a starting point. A few things a VPAT does not do:
- It is not independently verified: A VPAT is filled out by the vendor. Unless the claims have been validated by an independent audit, the document reflects what the vendor says about their product — not necessarily what users experience.
- It may not reflect the version you are buying: VPATs are version-specific. A report prepared for an earlier release may not accurately reflect the current state of the platform.
- Blank or vague entries are a red flag: A credible VPAT explains how each criterion is supported — not just whether it is. Entries that say "Supports" without explanation, or that leave the remarks column blank, suggest the product has not been properly tested.
- A VPAT does not transfer liability: Even a thorough, accurate VPAT does not shift your organization's Section 504 responsibility to the vendor. It is a disclosure document, not a liability waiver.
Treat a VPAT as the beginning of the conversation with a vendor — not the end of your due diligence.
What to ask your vendors now
If you have not already engaged your existing vendors on accessibility, the time to start is now. A practical set of questions to ask:
On documentation:
- Do you have a current Accessibility Conformance Report (ACR) for the version of the platform we are using?
- When was it last updated, and does it reflect the current release?
- Was the report based on automated testing alone, or does it include manual testing with assistive technologies?
On conformance:
- Which specific WCAG 2.1 Level AA criteria does your platform currently meet, and where are the known gaps?
- What is your roadmap for addressing known accessibility issues?
On accountability:
- If we identify an accessibility barrier in your platform, what is your process for addressing it and in what timeframe?
- Are accessibility fixes included in our current contract, or do they require additional cost?
A vendor that cannot answer these questions — or that is unwilling to engage with them — is a vendor that is likely to create ongoing Section 504 exposure for your organization.
What to require in new contracts and renewals
Every new vendor agreement and every contract renewal is an opportunity to close the contractual gap. At minimum, new agreements should include:
- An explicit WCAG 2.1 Level AA conformance requirement — specifying the standard by name, not by vague reference to "accessibility" or "ADA compliance"
- Vendor-paid remediation — a commitment that the vendor will fix accessibility defects in the code and components they control, at their own expense
- Regression protection — a requirement that future updates and releases do not break or remove existing accessibility features
- Verification rights — the right for your organization to conduct or commission independent accessibility testing of the vendor's platform
- A launch gatekeeper clause — the ability to delay go-live if a platform fails a final accessibility review
- Disclosure of known gaps — a requirement that the vendor disclose any known accessibility limitations before the contract is signed
These provisions do not guarantee a perfect platform. What they do is give your organization the contractual leverage to hold vendors accountable — and the paper trail to demonstrate active oversight if OCR comes knocking.
For a complete, ready-to-use set of contract language and vendor review steps, see the Section 504 vendor procurement checklist.
A note for digital health and telehealth vendors
If your organization is a digital health company, telehealth platform, or web technology provider whose clients are covered healthcare entities, this section applies directly to you.
Your clients — the hospitals, health systems, FQHCs, and behavioral health organizations that use your platform — are now subject to Section 504's digital accessibility requirements. When they provide your platform to their patients, they are responsible for ensuring it meets WCAG 2.1 Level AA. And increasingly, they will ask you to demonstrate that it does.
What covered healthcare organizations are now requiring from their vendors:
- A current, version-specific Accessibility Conformance Report (ACR)
- WCAG 2.1 Level AA conformance language in contracts and renewals
- A documented remediation roadmap for known gaps
- Independent validation of accessibility claims, not just vendor-prepared documentation
Organizations that cannot provide these are creating friction in procurement — and, at contract renewal, risk being replaced by vendors who can.
Accessibility conformance is becoming a standard procurement requirement in the healthcare sector, not an optional feature.
Supporting a defensible vendor strategy
Vendor accessibility risk doesn't resolve itself. Without independent verification of vendor claims, enforceable contract language, and documentation of active oversight, your organization is carrying liability it may not be able to defend.
accessiBe provides the professional services and technical tools healthcare organizations need to close that gap:
- Independent audits and VPAT documentation — our professional services team conducts manual accessibility testing of digital environments against WCAG 2.1 Level AA, using assistive technologies to verify what vendor documentation claims. We also produce Accessibility Conformance Reports (ACRs) for your own digital properties — the documentation that demonstrates due diligence to OCR and that procurement teams increasingly require from vendors.
- AI-powered remediation — for the web environments your organization directly controls, automated coverage addresses common accessibility barriers continuously, ensuring your own properties remain accessible as content evolves
- Source code accessibility — developer-level tooling gives technical teams visibility into WCAG issues at the code level, with tracked remediation history that supports your documented compliance program
If your organization wants to understand where vendor-related exposure is concentrated ahead of the May 2026 deadline, our Section 504 specialists can help you assess your current vendor landscape and identify practical next steps.
