Healthcare website accessibility: What the law requires and how to keep up

If your hospital receives federal financial assistance from the Department of Health and Human Services (HHS), WCAG 2.1 Level AA is now the written standard for your website, patient portal, and mobile apps. The date for meeting it moved in 2026. The obligation behind it didn’t.

That distinction matters, because most healthcare organizations still treat accessibility like an annual project, something you check off between website redesigns. Annual audits. Reactive fixes after complaints. Website accessibility relegated to “that thing IT handles during redesigns.” Meanwhile, your content teams publish dozens of pages weekly of digital content that nobody checks for accessibility until a patient can’t book an appointment or a lawyer sends a demand letter.

This guide covers what federal law requires of healthcare websites, which digital properties are in scope, what WCAG 2.1 Level AA means in practice, and how to govern accessibility at the speed your teams publish.

What are the accessibility requirements for healthcare websites?

Healthcare websites answer to three federal frameworks, and which ones apply depends on how your organization is funded and who runs it. Section 504 of the Rehabilitation Act covers organizations that receive federal financial assistance from HHS. ADA Title II covers state and local government entities, including hospitals and health systems a state or local government operates. ADA Title III covers private businesses open to the public, including private hospitals and practices. A public health system that receives HHS funding answers to both Section 504 and Title II.

HHS adopted WCAG 2.1 Level A and Level AA as the technical standard for recipients’ web content and mobile apps in a final rule published May 9, 2024, which took effect July 8, 2024. In May 2026, an HHS interim final rule extended the dates for meeting that standard by one year. The extension moved the dates, not the duty: recipients still have an ongoing obligation under Section 504 to make programs they deliver through web content and mobile apps accessible.

The Title II dates also moved by one year, under a Department of Justice interim final rule published April 20, 2026. Title III has no equivalent rule: the Department of Justice hasn’t adopted a technical accessibility standard for public accommodations through regulation.

Litigation doesn’t wait for compliance dates. Healthcare providers continue to be targets of ADA website accessibility lawsuits, and plaintiff firms have industrialized the process of finding violations.

Section 504 carries the most detail for healthcare: which recipients are covered, how the employee-count tiers work, and the limited circumstances in which content may not need to meet the standard. For the full breakdown, see Section 504 requirements for healthcare.

This article is for informational purposes only and doesn’t constitute legal advice. WCAG is a technical standard, and legal obligations depend on how your organization is funded and structured. Consult qualified counsel for guidance on your situation.

Which healthcare digital properties are in scope?

More than the main website. The HHS rule applies to the web content and mobile apps a recipient provides or makes available, whether directly or through contractual, licensing, or other arrangements, and it also addresses kiosks and other self-service technology. For a typical health system, that means:

• The public website, plus every microsite and campaign landing page
• Patient portals, including logged-in pages
• Online scheduling, intake forms, and bill pay
• Telehealth entry points and patient-facing mobile apps
• Find-a-doctor directories and location pages
• Documents patients need, such as forms, instructions, and price information

The vendor clause changes procurement. A scheduling widget, portal, or payment page a vendor runs on your behalf is still content you make available to patients. Ask vendors for current conformance documentation for the specific product version you use, test the tasks your patients actually complete, and write accessibility requirements into the contract.

What WCAG 2.1 Level AA means for a healthcare website

WCAG 2.1, the Web Content Accessibility Guidelines, is a technical standard published by the W3C. It isn’t a law; the rules above reference it. WCAG 2.1 sets out testable success criteria at three conformance levels: A, AA, and AAA. A page conforms to Level AA when it meets every Level A and Level AA success criterion.

The wording matters when Legal asks whether you’re covered. A site conforms to WCAG 2.1 Level AA. An organization complies with a law. Conformance is the evidence; compliance is the legal status, and it depends on more than WCAG.

In healthcare, the failures that matter most sit on the tasks patients need to complete. These are the patterns that come up again and again:

These aren’t hypothetical accessibility personas from a training deck. They’re real people trying to access care, and every health equity commitment you publish gets quietly contradicted by inaccessible patient journeys.

Why annual audits can’t keep up with healthcare publishing

Most healthcare systems handle accessibility the same way they handle facility inspections: schedule it annually, fix what gets flagged, file the report, and move on.

The pattern is familiar. A hospital hires a third-party firm to audit its main website. The report comes back with hundreds of issues. IT and marketing spend weeks fixing the critical ones. Then the content team publishes dozens of new pages over the next few months: landing pages for new services, physician bios, health resources, and event microsites. Nobody checks any of them for web accessibility until the next audit rolls around. Or until someone files a complaint.

This approach has three structural problems:

Violations pile up in gaps between audits

You audit once a year, maybe twice if you’re diligent. But your teams constantly publish. Every new campaign, every portal update, every redesigned form is a fresh opportunity to introduce accessibility barriers. Annual checks can’t govern weekly publishing.

No integration means creators are flying blind

Content authors and marketers have no real-time feedback on whether the page they’re building will pass accessibility standards. By the time someone flags an issue, that content has been live for months and patients have already hit barriers. One practical way to close this gap is to integrate accessibility feedback into the authoring workflow, so issues like missing alt text, heading order, or vague link text are flagged while pages are being drafted.

Brand and accessibility live in separate universes

Your brand team enforces terminology, disclaimers, and visual standards through one set of processes. Your accessibility checks happen somewhere else, often by different people using different systems. So, you end up with pages that are on-brand but inaccessible, or accessible but off-brand. Neither builds patient trust.

The cost shows up as operational drain. Your marketing team launches a service line microsite. Three months later, someone flags accessibility issues. Now you’re pulling developers off other work to fix things that should’ve been caught before launch. Legal gets involved. Your content team rewrites copy. Rework isn’t free, and emergency fixes cost more than getting it right the first time.

What a hospital website accessibility audit should cover

Audits still have a job. They set the baseline, and they test what automated monitoring can’t judge. A useful audit for a health system covers six things:

• A complete inventory. Every patient-facing property, including microsites, portals, mobile apps, documents, and vendor-hosted tools. The properties nobody listed are usually the ones nobody tested.
• An automated scan of all of it. This shows issue density and patterns, and separates template-level problems (fix once, fixed everywhere) from content-level ones.
• Manual and assistive technology testing of complete patient tasks. Finding a doctor, booking an appointment, logging in to the portal, paying a bill, reading results. Automated checks catch only some WCAG failures. Whether alt text is meaningful, whether focus order makes sense, and whether a task can be finished with a screen reader need a person.
• Third-party components. Compare what vendors’ conformance documentation claims with what testing finds.
• Risk-based prioritization. Rank findings by severity, traffic, and how critical the task is to care.
• Named ownership. Assign every finding to a template owner, a content author, or a vendor.

Treated this way, the audit becomes the baseline that continuous monitoring measures against, not the whole program.

What good looks like: Continuous accessibility governance

Mature healthcare accessibility governance looks less like an audit schedule and more like how your organization handles infection control: continuous monitoring, clear protocols, everyone knows their role, and leadership can see the data that proves it’s working.

The hospitals that get this right stop treating accessibility as a project with a start and end date. They treat it like security. You don’t finish security and move on. You build systems that continuously validate, catch problems early, and give teams what they need to maintain standards without constant oversight. Accessibility works the same way.

The outcome isn’t perfect; it’s predictable. Patients get consistently accessible experiences across touchpoints. Regulators see a system of control, not reactive patches. And your teams shift from panic mode to steady progress, because accessibility is built into how work gets done instead of being bolted on afterwards.

What to look for in an accessibility governance platform for healthcare

If you’re evaluating platforms to run this model, judge them against the way healthcare content actually gets made. Look for:

• Coverage of the whole estate. Public sites, microsites, authenticated portal pages, PDFs, and mobile apps, not just the main domain.
• Issues mapped to WCAG. Each issue tied to a WCAG 2.1 success criterion and conformance level, with a severity your teams can prioritize by.
• Ownership and routing. Issues assigned to named owners and tracked to close, instead of living in email threads.
• Checks where authors work. Pre-publish feedback inside the CMS or browser, so content-level issues get fixed before patients see them.
• Custom rules alongside WCAG. Approved terminology, required disclaimers, and brand standards checked in the same place as accessibility.
• Reporting Compliance can use. Trends by property, remediation speed, and a history that shows sustained effort over time.
• Honesty about limits. A vendor that claims automation alone delivers WCAG conformance is overpromising. Ask how the platform supports manual testing and how those results sit alongside automated findings.

Operational playbook: Move from reactive fixes to embedded accessibility

Shifting from “we’ll fix it when someone complains” to “we prevent problems before they ship” isn’t a moment of inspiration. It’s a deliberate change in how work gets done.

The teams that pull this off follow a pretty consistent pattern. Not because there’s one perfect way to do it, but because skipping steps or doing them out of order tends to create new problems while solving old ones.

Audit your current digital footprint and map the risk

Inventory everything patient-facing: main sites, microsites, campaign landing pages, and logged-in portal experiences. Baseline where you stand against WCAG 2.1 Level AA using the audit approach above, and get an honest look at issue density across properties. Then map where accessibility problems intersect with high-traffic, high-stakes patient journeys. (Spoiler: appointment booking and portal login almost always top the list.)

Define policies and clarify who owns what

Establish WCAG 2.1 Level AA as your minimum standard and add any organization-specific rules on top. Then get specific about ownership: who sets policy (usually Compliance and Legal), who enforces it (Digital and IT), who remediates (content authors, dev teams). Decide which issues are hard blockers that prevent publishing versus soft warnings teams can override with documented exceptions. Without this clarity, every issue becomes a negotiation.

Build checks into CMS workflows and train authors to use them

Turn on pre-publish checks so content authors and editors get real-time guidance. Configure issue routing and priority queues: critical problems on high-traffic patient pathways escalate first; lower-severity concerns can wait. Train authors to fix issues themselves instead of filing tickets and waiting. Many content-level issues, like missing alt text or a skipped heading level, are quick fixes when they’re caught during drafting.

Align accessibility with brand and UX standards in one governance layer

Manage accessibility rules and brand rules, such as approved language, required disclaimers, and design patterns, in one place so you can enforce accessibility and brand rules together. Make sure your design system components and templates are accessible by default so teams aren’t fighting to be both on-brand and accessible. When brand and accessibility live in the same system, you stop creating tension between them.

Track metrics, report progress, and expand to new properties

Monitor what matters: number of issues over time, remediation speed, accessibility scores, and coverage of high-risk pages. Share progress with Legal, Compliance, and executives to demonstrate active control and measurable improvement. Then extend governance to new properties as they come online: campaign sites, acquisition integrations, and new portal features. Once the system works, scaling it is straightforward.

Healthcare website accessibility FAQ

Can healthcare websites get sued for accessibility violations?

Yes. Private hospitals and practices face lawsuits under ADA Title III, which has no regulatory technical standard, so plaintiffs and settlement agreements frequently use WCAG 2.1 Level AA as the benchmark. Organizations covered by Section 504 can also face complaints to the HHS Office for Civil Rights.

Did the HHS extension pause Section 504 obligations?

No. The interim final rule moved only the dates for meeting the WCAG 2.1 technical standard. Recipients’ ongoing obligation to make programs delivered through web content and mobile apps accessible continues in the meantime.

Does Section 504 apply to every healthcare organization?

No. The HHS rule applies to recipients of federal financial assistance from HHS. Whether your organization is a recipient, and whether ADA Title II or Title III also applies, is a question for counsel.

Do the rules cover patient portals and tools a vendor runs for us?

Under the HHS rule, yes. It covers web content and mobile apps a recipient provides directly or through contractual, licensing, or other arrangements, so a vendor-hosted portal or scheduling tool counts.

Start with your weakest link

The extended dates give healthcare organizations time to build a program, not time to wait. The only sustainable way to meet Section 504 and reduce ADA risk is to embed accessibility into daily digital operations through continuous monitoring, manual testing of critical patient tasks, policy-driven enforcement, and authoring guidance that catches problems before they go live.

Your starting checklist:

• Inventory your digital properties and get a baseline risk profile
• Adopt WCAG 2.1 Level AA as your minimum standard
• Implement continuous scanning, paired with manual testing of critical patient tasks
• Integrate accessibility checks into CMS workflows so teams self-correct before publishing
• Write accessibility requirements into vendor contracts
• Align accessibility with brand standards under one governance model
• Track issue trends and remediation speed, and share results internally

Pick one area where you’re the weakest (such as inconsistent standards, late-caught issues, or unclear risk exposure) and fix it systematically. Measure what changed. Move to the next problem. That beats comprehensive roadmaps that sit in slide decks for six months.

Siteimprove.ai Accessibility provides continuous accessibility monitoring across websites, documents, PDFs, and apps. Request a demo to see how healthcare teams use it to govern accessibility between audits.