A regional hospital system spent three years and a real budget getting its public marketing website into shape. New homepage, accessible navigation, an accessibility statement, the works. Legal signed off. Leadership moved on, confident the risk had been handled.
Then the demand letter arrived, and it had nothing to do with the marketing site. It named the patient portal, the login-gated world where people actually check lab results, refill prescriptions, message their care team, and pay their bill. Nobody on the compliance team had looked at that experience in years, because it technically "belonged" to the EHR vendor, not to marketing.
That gap between what gets audited and what actually gets used is exactly where the next wave of healthcare accessibility litigation is forming.
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 the portal is the bigger target, not the smaller one
For years, accessibility risk conversations in healthcare centered on the public-facing website. That focus made sense early on, because the public site is what plaintiffs' firms could see without logging in. It is easy to scan, easy to screenshot, easy to cite in a demand letter.
But the public site was never where the real usage lived. The patient portal is where people with disabilities interact with their care the most, and the most often, because it is where the actual healthcare happens online: appointment scheduling, prescription refills, secure messaging with a provider, viewing test results, paying a bill. A blind patient trying to read a lab result through a broken screen reader experience, or a patient with limited dexterity unable to complete a multi-step scheduling form with a keyboard, is not a hypothetical edge case. It is a daily occurrence at scale, across every health system running a portal built primarily for visual, mouse-driven interaction.
That combination, high-stakes content plus daily, forced usage, is precisely what makes a digital property attractive to plaintiffs' counsel. It is not a "nice to have" page someone might visit once. It is infrastructure patients are required to use to manage their own health.
There is also a structural reason portal complaints tend to escalate faster than marketing site complaints. A marketing site issue usually means someone could not read a page. A portal issue often means someone could not complete a task tied to their actual medical care: they could not confirm an appointment, could not tell whether a prescription had been refilled, or could not read a message from their doctor about a result. That difference in stakes matters both to the patient filing the complaint and to how a court is likely to weigh the harm.
The compliance gap that created the opening
Most health systems structured their accessibility efforts around ownership, not risk. Marketing owned the public site, so marketing got the audit, the remediation budget, and the accessibility statement. The portal, on the other hand, often runs on a licensed EHR platform (MyChart-style software from a major vendor), which created a convenient but false sense that "the vendor handles that."
Vendors handle their own core platform. They do not automatically handle every custom field, every hospital-specific form, every branded module a health system layers on top, and they certainly do not take on the legal liability if a patient with a disability cannot complete a task inside that portal. The contractual reality and the legal reality point in different directions, and plaintiffs' firms have started to notice the gap between the two.
It also does not help that portals typically fall between departments. IT manages the technical integration, clinical operations manages the workflows, and compliance manages the policy language, but rarely does any single owner sit down and test the actual patient-facing experience with a keyboard alone or with a screen reader turned on. Nobody owns the outcome, which means nobody catches the failure until a complaint does it for them.
This is also why patient portals sit at the center of the broader regulatory picture we mapped out in Healthcare Website Accessibility: Where WCAG, ADA, and Section 1557 Actually Meet. Section 1557 nondiscrimination obligations, Section 504 requirements for federally funded providers, and ADA Title III all converge on the same question: can a person with a disability actually use this system to get equivalent access to care. The portal is where that question gets tested hardest, because it is where the highest-stakes tasks live.
What a portal-specific risk review actually looks for
A portal audit is not the same exercise as a marketing site audit, and treating it as one is how gaps slip through. A useful review focuses on the tasks patients are actually forced to complete, not just the pages that happen to be visible:
- Appointment scheduling flows. Can every step, including date pickers, provider selection, and confirmation screens, be completed with a keyboard alone and announced correctly by a screen reader?
- Secure messaging and results viewing. Are lab results, imaging reports, and provider messages presented in a structure a screen reader can navigate logically, rather than as an unlabeled data dump?
- Form validation and error handling. When a required field is missed on a billing or intake form, does the error get announced to assistive technology, or does it only appear as a visual color change?
- Session timeouts. Portals often log users out after a period of inactivity for security reasons. Is there adequate, accessible warning before that happens, so a patient using a screen magnifier or switch device is not silently kicked out mid-task?
- Third-party embedded widgets. Many portals stitch together scheduling tools, payment processors, and messaging systems from different vendors. Each one needs its own accessibility check, because a single inaccessible widget can block an otherwise compliant portal.
This kind of task-based review connects directly to the deadline pressure covered in HHS Quietly Extended Your Section 504 Deadline. An extension buys time, it does not remove the obligation, and portals are exactly the kind of complex, multi-vendor system that takes real time to get right.
Where this fits in the bigger regulatory picture
It is worth being clear that portals are not the only place regulators and plaintiffs are looking. As we broke down in Healthcare & Fintech: The 3 WCAG Failures Regulators Look For First, the failures that draw the fastest attention tend to be the ones tied to money, identity, and access to essential services. Patient portals check all three boxes at once: they handle billing, they authenticate identity, and they gate access to care. That is a lot of exposure sitting behind a single login screen.
For background on the legal foundation behind all of this, both HHS's Section 1557 civil rights guidance and the Americans with Disabilities Act itself are worth having your legal and compliance teams review directly, rather than relying on secondhand summaries.
Start with the portal, not the pamphlet
If your health system's accessibility budget and attention are still weighted toward the public marketing site, this is the moment to rebalance. The pages your legal team can screenshot in five seconds are not the pages carrying the most risk anymore. The portal patients are required to log into every time they need care is.
A focused, task-based review of your actual patient portal (not just the login page, but the full scheduling, messaging, results, and billing flows behind it) is the single highest-leverage step most health systems can take right now. You can start that conversation with our team at wcag.world/solutions/healthcare, built specifically around the healthcare compliance picture described above.
If you want to talk through where your own portal likely stands before a demand letter forces the conversation, reach a person on our team directly at experts@wcag.world, or visit wcag.world/solutions/healthcare to see how we approach a portal-specific accessibility review.