---
title: accessiBe - Building a defensible procurement strategy under Section 504
---

| ![accessiBe](https://lp.accessibe.com/hubfs/accessiBe%20Logo/brand=accessiBe%2c%20type=white%2c%20mono=true%2c%20by%20accessiBe=false%2c%20dark%20mood=true.svg) # Building a defensible procurement strategy under Section 504 |
| --- |

![](https://lp.accessibe.com/hs-fs/hubfs/image%20(1)-Feb-16-2026-09-49-20-3178-AM.png?width=420&height=385&name=image%20(1)-Feb-16-2026-09-49-20-3178-AM.png)

 HHS has set a clear standard for healthcare organizations: all web content and mobile applications must conform to WCAG 2.1 Level AA. While the rule is straightforward, following it can be tricky. Most healthcare organizations rely on outside vendors for essential tools like patient portals, scheduling platforms, and telehealth systems.  Under Section 504, your organization is still responsible for the accessibility of these services, even if a third party provides them.  Moving from a reactive approach to a proactive, defensible strategy requires a shift in how your organization handles vendor partnerships. By integrating accessibility requirements into the very beginning of your procurement process, you can mitigate legal risk and ensure that digital inclusion is built in from the start — not addressed after a problem arises.

## 01. Build leverage early

 If you wait until a platform is live to think about accessibility, you have already lost your primary source of leverage. Accessibility must be a defined requirement before any contract is signed — not an afterthought at go-live.

Specify the standard by nameEvery RFP and contract should explicitly require conformance to WCAG 2.1 Level AA — not vague references to “accessibility best efforts” or general non-discrimination language

Weight accessibility in vendor selectionWhen evaluating vendor bids, treat accessibility the same as security or cost. A platform that patients cannot use is not a functional platform

Require disclosure of known gapsMake it clear to potential partners that accessibility defects are “showstoppers” that can pause project milestones or payments

Make accessibility a go-live conditionEstablish that accessibility defects identified before launch can pause deployment or delay payment until resolved

![](https://lp.accessibe.com/hubfs/lightbulb.svg)

Why this matters Procurement is the decisive moment under Section 504. The rule makes clear that your organization remains legally responsible for the accessibility of vendor-supplied platforms — regardless of who built them or what the contract says. If WCAG 2.1 Level AA conformance isn’t a contractual requirement from the start, you have no enforceable basis to compel fixes later — and your organization carries the full legal exposure.

## 02. Assign responsibility clearly

 A successful vendor relationship requires a clear division of labor. When a barrier is found under Section 504, there must be a defined path to a fix — not a cycle of finger-pointing between your team and the vendor.

Define the vendor’s scopeThe vendor is responsible for the accessibility of the code, navigation, and framework they control — the platform’s underlying engine

Define your organization’s scopeYour organization is responsible for the content placed inside that platform — documents uploaded, forms configured, and communications generated through the system

Designate an internal accessibility point of contactAssign a named individual responsible for managing vendor accessibility relationships, tracking open issues, and maintaining documentation

Require a vendor accessibility contactRequire the vendor to provide a named point of contact for accessibility-related issues — not just a general support queue

![](https://lp.accessibe.com/hubfs/lightbulb.svg)

Why this matters Shared responsibility does not mean shared liability. Under Section 504, your organization remains accountable for the patient experience — even when the platform is vendor-owned. A clear division of labor prevents accessibility barriers from falling into gray areas where no one takes ownership and patients are left without recourse.

## 03. Write accountability into the contract

 Don’t rely on a vendor’s verbal promise. Your contracts should include enforceable language that protects your agency and provides a safety net if a product falls short of the required standards. To create this legal protection, your agreements should include:

A commitment by the vendor to fix any accessibility bugs in their software at their own expense, not yours.

A rule that future software updates must not break or remove any existing accessibility features.

A “gatekeeper” clause that allows you to delay a launch if the product fails a final accessibility test.

![](https://lp.accessibe.com/hubfs/lightbulb.svg)

Why this matters Contractual accountability is the only way to shift the cost of remediation back to the vendor. Without these clauses, accessibility barriers become a permanent “remediation debt” that your agency must pay for through manual workarounds or expensive third-party retrofitting. Treating accessibility as a standard product defect — with defined fix timelines and “go-live” authority — ensures that accessibility issues have a clear owner and a resolution deadline, transforming them from legal liabilities into manageable technical tasks.

## 04. Verify vendor claims

 Most vendors will provide a VPAT — a Voluntary Product Accessibility Template — to demonstrate their product is accessible. Once completed, a VPAT becomes an Accessibility Conformance Report (ACR). Under Section 504, you must treat this document as a starting point, not a guarantee.

Check the versionConfirm the ACR matches the exact version of the software you are purchasing. A report from an older release may not reflect the current platform

Review the remarks columnA credible ACR explains how each criterion is supported — not just whether it is. Entries that say “Supports” without explanation, or that leave the remarks column blank, indicate the product has not been properly tested

Challenge “perfect” scoresNo complex platform is 100% accessible. If a vendor claims total conformance with zero known issues, ask for their testing methodology and a roadmap for future fixes.

Conduct or commission independent testingIndependent manual testing — using assistive technologies including screen readers and keyboard-only navigation — is the only reliable way to verify what patients actually experience

![](https://lp.accessibe.com/hubfs/lightbulb.svg)

Why this matters A VPAT is only as credible as the audit behind it. Under Section 504, accepting vendor documentation at face value — without independent verification — is not a defensible compliance posture. If a patient files a complaint and OCR investigates, your organization needs more than a vendor’s word.

 To help you maintain a defensible posture, accessiBe provides professional support for your documentation and auditing needs.  Our experts conduct manual testing to identify barriers that automated tools might miss and help you fill out a VPAT accurately. Once completed, these ACRs live on your website as a public record of your accessibility efforts and a key piece of your compliance strategy, ensuring your documentation remains current as your digital services evolve.

## Conclusion: What a strong strategy looks like for 2026

 As the May 2026 deadline approaches, a defensible vendor strategy isn't about finding a perfect platform. It's about proving that your organization has an active, documented process for holding vendors accountable as digital services evolve.  By following these five steps, you move from a reactive state of "firefighting" to a proactive model where vendors are held accountable and digital services are built to be inclusive from the start. This structured approach not only lowers your legal risk but also ensures that your community can access essential services without barriers.