A compliance officer at a regional hospital system gets a call from outside counsel. A demand letter has arrived alleging that a blind patient could not independently schedule a follow-up appointment through the hospital's online portal. The compliance officer's first question is reasonable and, legally, almost beside the point: "That's not even our software — we license it from a vendor."
It doesn't matter. Not to the plaintiff's firm, and not to the regulators who oversee healthcare accessibility.
The Fastest-Growing Case Type in Healthcare
Website accessibility litigation has targeted retail and hospitality for years. What's changed is where the growth is now concentrated. Per 2026 legal trackers, patient-portal-related litigation — covering patient portals, appointment scheduling systems, and telehealth platforms — has been growing faster than any other healthcare accessibility case type.
That distinction matters. It's not that healthcare accessibility litigation overall is up; it's that a specific slice of it — the digital front door patients use to book, check in, and connect with a provider — is the part expanding fastest. Plaintiff's attorneys have noticed that these systems are both high-traffic and, in many organizations, the least-audited piece of the digital estate.
The Stat: Patient-portal-related litigation has been growing faster than any other healthcare accessibility case type, according to 2026 legal trackers. (Source: 2026 legal trackers)
Why Scheduling and Portal Tools Are the Target
There's a practical logic behind this shift. A hospital's marketing website usually gets some attention from a web team that has at least heard of accessibility. The scheduling widget embedded three clicks deep, licensed from a third-party vendor and rarely touched after initial setup, often hasn't. It's exactly the kind of gap a plaintiff's firm looks for: a task a real patient needs to complete (book an appointment, request a refill, join a telehealth visit) that fails for someone using a screen reader or keyboard-only navigation.
Telehealth platforms carry the same exposure. A video visit interface that can't be operated without a mouse, or that doesn't expose captions or a screen-reader-accessible waiting room, blocks access to care itself — not just information about care. That raises the stakes well above a typical retail accessibility complaint.
"Our Vendor Handles It" Is Not a Defense
This is the part that catches healthcare compliance teams off guard. A significant number of patient portals and scheduling tools are not built in-house — they're embedded from electronic health record vendors, scheduling SaaS providers, or telehealth platform companies. It's natural to assume that if the vendor's software is inaccessible, the vendor is the one on the hook.
That assumption is wrong, and it's wrong by design from a regulatory standpoint. A key enforcement position from DOJ and HHS is explicit on this point: when a scheduling form or portal is embedded from a third-party vendor, the covered healthcare entity remains legally responsible for its accessibility. "Our vendor handles it" has not been accepted as a defense.
The reasoning tracks how these laws are structured. Title III of the ADA and the Section 504 obligations that apply to recipients of federal health funding attach to the covered entity — the hospital, clinic, or health system — not to the software vendor supplying the interface. Patients don't interact with the vendor; they interact with the hospital's brand, on the hospital's domain, to access the hospital's services. Liability follows that relationship.
What This Means in Practice
For a compliance or IT leader, this reframes vendor selection and vendor management as a compliance function, not just a procurement one:
- Accessibility conformance claims from vendors need verification, not trust. A vendor's marketing page claiming "WCAG compliant" is not the same as an independent audit of the specific workflow your patients actually use.
- Embedding a tool doesn't transfer risk. The contract may include indemnification language, but the regulatory liability — and the reputational exposure of a demand letter naming your hospital — sits with the covered entity regardless of what the contract says about who pays for a fix.
- Every embedded widget is in scope. Scheduling calendars, insurance verification forms, symptom checkers, telehealth video frames, and patient messaging tools are all part of the same audit surface, even when each one comes from a different vendor.
How HHS Enforcement Actually Works
Under the HHS Section 504 rule, enforcement isn't limited to private lawsuits. HHS has its own compliance mechanisms, and they carry consequences that extend well beyond a settlement check.
Enforcement mechanisms under the HHS Section 504 rule include voluntary compliance agreements — with defined deadlines and milestones the covered entity must meet — and, in severe cases, termination of HHS funding, including Medicare and Medicaid payments. For most hospitals and health systems, Medicare and Medicaid reimbursement isn't a peripheral revenue stream; it's foundational. That makes accessibility compliance a funding-continuity issue, not merely a legal-exposure one.
| Enforcement Path | Trigger | Typical Consequence |
|---|---|---|
| Private demand letter / lawsuit | Patient unable to complete a task (scheduling, portal login, telehealth) | Legal costs, remediation timeline, possible settlement |
| HHS voluntary compliance agreement | Section 504 complaint or investigation finds non-conformance | Deadlines and milestones for remediation, monitored by HHS |
| Termination of HHS funding | Failure to reach or sustain compliance under an agreement | Loss of Medicare/Medicaid payments |
The middle and right columns of that table are the ones healthcare leaders tend to underweight. A private lawsuit is expensive and disruptive. A funding-linked enforcement action is existential for the parts of the organization that depend on federal reimbursement.
Where the Blind Spots Usually Are
Most healthcare accessibility audits still focus on the marketing site — the pages describing services, providers, and locations. That's necessary, but it's no longer where the fastest-growing litigation risk sits. The higher-risk surfaces are transactional:
Appointment Scheduling
Can a screen reader user select a provider, pick a time slot, and confirm an appointment end to end? Date pickers and calendar widgets are notoriously difficult to make accessible and are frequently the single point of failure in an otherwise reasonable portal.
Patient Portal Login and Navigation
Multi-factor authentication flows, password reset forms, and secure messaging interfaces are all places where custom JavaScript components can silently break keyboard access or screen reader labeling, even when the surrounding page looks fine.
Telehealth Visit Interfaces
Video call controls, waiting room status indicators, and captioning toggles need to work without a mouse and need to be announced correctly to assistive technology — not just visually present.
For general context on how widespread these problems are before anyone looks specifically: the WebAIM Million evaluation has found that roughly 95.9% of homepages have detectable WCAG 2 failures. Transactional healthcare tools, built with more custom interactivity than a static marketing page, are not likely to fare better without a dedicated audit — and the population affected is not small. The CDC estimates that roughly one in four U.S. adults has a disability, a share that skews meaningfully higher among the patient populations that hospitals and health systems serve.
What a Defensible Position Looks Like
None of this requires abandoning third-party vendors or telehealth platforms. It requires treating them as part of the same compliance perimeter as anything built in-house.
A workable starting checklist:
- Inventory every embedded patient-facing tool — scheduling, portal, telehealth, messaging, and any third-party widgets loaded on those pages.
- Audit each workflow with real assistive technology, not just an automated scanner, focused on task completion rather than page-level scores.
- Document vendor accessibility claims against actual test results, and flag any gap in writing.
- Prioritize remediation on the highest-traffic, highest-stakes workflows — scheduling and telehealth first, since they gate access to care itself.
- Track findings and fixes with dates, building the same kind of paper trail HHS would expect to see under a voluntary compliance agreement, before you're required to produce one.
The organizations best positioned when a demand letter or HHS inquiry arrives are the ones that already have this documentation, not the ones scrambling to produce it after the fact.
Get Ahead of It
Patient portals, scheduling tools, and telehealth platforms are where healthcare accessibility litigation is growing fastest, and regulators have made clear that outsourcing the software doesn't outsource the liability. The organizations most exposed right now are the ones that have audited their marketing site but never looked closely at the vendor-supplied tools patients actually use to get care.
If you don't have a current, independent audit of your scheduling, portal, and telehealth workflows, that's the gap most likely to surface first — whether through a plaintiff's demand letter or an HHS compliance review. Get a full accessibility audit from WCAG.World and find out exactly where your patient-facing tools stand before someone else tells you.