Accessibility Solutions for Healthcare

If your organization receives federal financial assistance from HHS, the rule applies. That covers most hospitals, health systems, community health centers, FQHCs, health plans, clinical research institutions, and many digital health, pharma, and biotech organizations. The rule applies regardless of size; smaller recipients simply have the later 2028 deadline.

Federal procurement contracts and insurance or guaranty contracts are not considered federal financial assistance under the rule. If you are unsure whether your funding arrangement is covered, it is worth confirming the determination with counsel before the deadline.

Web content and mobile apps that recipients provide or make available, directly or through contractual, licensing, or other arrangements, must conform to the success criteria of WCAG 2.1 Level AA. That includes patient-facing websites, patient portals, telehealth interfaces, online forms, scheduling tools, billing pages, and the documents posted within them.

The rule includes narrow exceptions (for example, archived content not currently used to apply for or participate in a program, and certain password-protected individualized records), but the working assumption for most patient-facing experiences is full WCAG 2.1 AA conformance.

See HHS Section 504 Digital Accessibility FAQ for Healthcare Providers.

On May 7, 2026, HHS issued an Interim Final Rule extending the original deadlines by one year. Recipients of HHS federal financial assistance must conform with WCAG 2.1 Level AA by:

• May 11, 2027 if the recipient has 15 or more employees
• May 10, 2028 if the recipient has fewer than 15 employees

The extension only moves the WCAG conformance deadline. All other Section 504 obligations, including reasonable modification and effective communication, remain in effect.

Our HHS Section 504 blog outlines how healthcare teams can use this timeline to plan audits, remediation, and governance.

ADA Title II and Section 504 both treat inaccessible digital experiences as a barrier to equal access, which puts digital accessibility in healthcare squarely in scope. For state and local providers (such as public hospitals and health departments), ADA Title II now expects public-facing websites, mobile apps, and digital documents to conform to WCAG 2.1 Level AA. If your organization receives federal funding, Section 504 likewise requires equal access to digital services for people with disabilities. In practice, that means aligning your healthcare websites, patient portals, and mobile apps with WCAG 2.1 AA, fixing barriers in high-impact journeys like scheduling, portals, telehealth, and billing, and documenting your accessibility program over time.

Learn more about Title II support 

Private providers fall under Title III of the ADA. While Title III doesn’t name a single technical standard, WCAG 2.1/2.2 Level AA is the accepted method to demonstrate accessible digital experiences in practice. Many providers follow WCAG to reduce risk and improve patient experience.

Quick way to benchmark your site: Run an Accessibility Test

 No. The IFR only extends the compliance dates. WCAG 2.1 Level AA remains the technical standard for web and mobile app accessibility under Section 504. 

Aim for WCAG 2.2 Level AA as your best practice.  The DOJ’s ADA Title II rule and HHS’s updated Section 504 regulations both point to WCAG 2.1 AA as the common baseline for healthcare websites, patient portals, and telehealth tools.

[On-Demand Webinar] Demystifying Accessible Design: How to Apply WCAG 2.2

Telehealth is a major focus for digital accessibility in healthcare because it directly affects a patient’s ability to receive care. If your organization offers telehealth visits or remote monitoring, the platforms and workflows you use must support screen readers, keyboard navigation, captioning, and other assistive technologies. That includes the steps patients take to log in, join a visit, complete intake forms, view follow-up instructions, and pay bills.

Making telehealth accessible helps ensure that patients with disabilities can schedule and attend visits independently, without relying on workarounds. It also supports your obligations under ADA and HHS Section 504, which both expect equal access to the digital services patients use to apply for, pay for, and receive care.

For more, insights read our blog, "Navigating Accessibility Challenges on Mobile Healthcare Websites."

Common issues include unlabeled fields/icons, unclear or missing errors, inaccessible date pickers, focus traps, low color contrast, and non-operable two-factor steps.

Fix with proper labels and instructions, programmatic error associations, visible focus states, accessible components, and non-visual alternatives to CAPTCHA. Validate with keyboard and screen reader testing.

Download The Ultimate Guide to Accessibility Testing. Learn to Ensure Your Websites and Apps Are Fully Accessible to People with Disabilities 

You still own the patient experience. Vet tools for WCAG support, request current VPAT/ACR documentation, require remediation timelines and evidence, and test integrated flows (e.g., appointment scheduling) end-to-end.

An accessibility statement is a public page that tells patients what standard you meet (WCAG 2.1 AA; planning for 2.2), what’s in scope (website, patient portal, mobile app, telehealth), how to get urgent help, and how to request accessible formats for medical documents. Include a last-updated date and any known limitations with timelines.

Web Accessibility Statement: How to Write One [With Examples]

An accessibility policy is an internal, operational document that sets scope, standard (WCAG 2.1 AA minimum), roles, QA gates, vendor rules (VPAT/ACR, SLAs), testing (automation + keyboard/screen reader + patient user testing), documentation, and review cadence.

The statement is public and patient-facing; it explains your commitment, what’s covered, and how to get help or alternate formats.

Read the blog, Accessibility Policy: Why It Matters and What to Include