ADA Compliant Healthcare Websites: May 2026 Deadline

On May 11, 2026, a federal compliance deadline takes effect that most healthcare providers still don’t know about. Every healthcare provider website must become an ADA compliant website by this deadline. In roughly three months, any healthcare organization that accepts Medicare, Medicaid, or CHIP funding must ensure its website, mobile apps, and patient-facing kiosks meet WCAG 2.1 Level AA accessibility standards. The penalty for non-compliance? Loss of federal funding.

That’s not a fine you can budget for. That’s an existential threat.

What makes this deadline particularly complex is that it sits at the intersection of three overlapping federal laws: the ADA, Section 504 of the Rehabilitation Act, and Section 1557 of the Affordable Care Act. Each carries its own requirements, its own enforcement mechanisms, and its own penalties. Most healthcare providers I work with are aware of one of these laws. Almost none understand how all three apply to their digital properties simultaneously.

After 15+ years building healthcare website design solutions at Nopio, I’ve watched accessibility shift from a nice-to-have to a legal mandate. The organizations that started preparing in 2024 are in strong shape. The ones discovering this deadline now have a narrow but workable window to act.

This guide covers everything you need to know: the legal framework, the technical requirements, the remediation process, and the realistic costs involved. It is written to help healthcare decision-makers, compliance officers, and IT leaders take informed action before May 11.

Disclaimer: This article provides general information about digital accessibility requirements for healthcare organizations. It does not constitute legal advice. Consult with a qualified healthcare attorney for guidance specific to your organization’s compliance obligations.

The May 2026 Deadline Healthcare Providers Are Missing

The U.S. Department of Health and Human Services (HHS), through its Office for Civil Rights (OCR), published a final rule on May 9, 2024 that establishes mandatory digital accessibility standards under Section 504 of the Rehabilitation Act. This rule requires healthcare providers who receive federal financial assistance to make their websites, mobile apps, and kiosks conform to WCAG 2.1 Level AA. Failure to comply puts federal funding at direct risk.

The rule creates two staggered deadlines based on organization size:

“Federal financial assistance” casts a wide net. If your organization accepts Medicare, Medicaid, or CHIP payments, you’re covered by this rule. That includes the vast majority of hospitals, health systems, physician practices, behavioral health providers, dental practices, and long-term care facilities in the United States. Hospital website ADA compliance is now mandatory for virtually all facilities receiving federal healthcare funding. Even some private practices that believe they operate outside federal programs often receive indirect federal funding through state-administered Medicaid programs.

The scope goes beyond websites. The HHS rule explicitly covers three categories of patient-facing digital technology:

• Websites including appointment scheduling, provider directories, patient education pages, billing information, and contact details
• Mobile applications used for telehealth, appointment management, prescription refills, or health record access
• Kiosks such as check-in terminals, wayfinding stations, and payment systems in healthcare facilities

The technical standard is WCAG 2.1 Level AA. This is not a suggestion or a best practice recommendation. The Web Content Accessibility Guidelines (WCAG) 2.1 published by the W3C include 50 success criteria across Levels A and AA that your digital properties must meet. Healthcare providers may also comply using WCAG 2.2 AA or AAA, which meet or exceed the rule’s requirements.

It is worth remembering that the enforcement mechanism here is not a fine or a slap on the wrist. OCR can investigate complaints, conduct proactive compliance reviews, and refer violations to the Department of Justice. The consequence is suspension or termination of federal financial assistance, which for most healthcare organizations means losing Medicare and Medicaid reimbursements.

Understanding the Three-Law Framework

Healthcare organizations must comply with three overlapping federal laws that govern digital accessibility: the Americans with Disabilities Act (ADA Title III), Section 504 of the Rehabilitation Act, and Section 1557 of the Affordable Care Act. Each law has different enforcement mechanisms, triggers different penalties, and applies based on specific organizational characteristics. Medical website ADA compliance requires understanding how all three laws apply to your digital properties simultaneously.

Healthcare website accessibility sits under these three separate federal laws, each with different triggers, enforcement bodies, and penalties. Understanding where your organization falls under each law is the first step toward building a compliance strategy that actually protects you. Most providers focus on one law and miss the other two entirely.

ADA Title III: Public Accommodation

The Americans with Disabilities Act, specifically Title III, prohibits discrimination against individuals with disabilities in places of public accommodation. The Department of Justice has consistently interpreted this to include websites operated by businesses that serve the public, and healthcare providers clearly qualify.

Key facts about ADA Title III for healthcare:

• Enforced through private lawsuits (not just government action)
• No specific technical standard is written into the statute, but courts routinely reference WCAG 2.1 AA
• Plaintiffs don’t need to prove intent, only that barriers exist
• Damages can include injunctive relief (mandatory fixes), attorney’s fees, and in some cases monetary settlements
• Applies regardless of whether you receive federal funding

This is the law driving the wave of accessibility lawsuits against healthcare organizations. A patient who can’t book an appointment, access test results, or navigate a provider directory using a screen reader has standing to sue under Title III.

Section 504: Federal Funding Recipients

Section 504 of the Rehabilitation Act is the law behind the May 2026 deadline. It prohibits disability discrimination by any program or activity receiving federal financial assistance. The HHS OCR final rule published in May 2024 updated Section 504’s requirements to include specific digital accessibility mandates for the first time.

What makes Section 504 different:

• Enforced by HHS OCR (government enforcement, not just private lawsuits)
• Applies specifically to recipients of HHS federal financial assistance
• Now includes explicit WCAG 2.1 AA technical requirements
• Penalty is loss of federal funding, a far more severe consequence than a lawsuit settlement
• Covers websites, mobile apps, and kiosks

Section 1557 of the Affordable Care Act

Section 1557 is the healthcare-specific civil rights provision of the ACA. It prohibits discrimination on the basis of race, color, national origin, sex, age, or disability in health programs that receive federal financial assistance.

For digital accessibility, Section 1557 adds a critical dimension: language access requirements. Covered entities must provide notices about the availability of language assistance services in English and at least the top 15 languages spoken by individuals with limited English proficiency in the state(s) where the organization operates. These notices must appear on websites and in key patient-facing documents.

How They Work Together

Keep in mind that ADA compliance is a separate requirement from HIPAA compliance. HIPAA governs the privacy and security of protected health information. ADA, Section 504, and Section 1557 govern access for people with disabilities and limited English proficiency. You need both, and meeting one doesn’t satisfy the other.

WCAG 2.1 Level AA Explained for Healthcare

WCAG 2.1 Level AA is the mandatory technical standard for healthcare digital accessibility compliance. This standard includes 50 testable success criteria organized under four core principles: content must be perceivable, operable, understandable, and robust. Healthcare providers must apply these criteria to all patient-facing websites, mobile applications, and self-service kiosks to meet the HHS Section 504 rule requirements by May 2026.

Published by the World Wide Web Consortium (W3C), WCAG 2.1 contains these 50 success criteria at Levels A and AA combined. These criteria are organized under four foundational principles that every healthcare website design, patient portal, and mobile app must satisfy.

The Four Principles (POUR)

Perceivable means patients must be able to perceive all content and interface elements through at least one of their senses. In healthcare, this applies directly to situations where information is literally life-critical. Medical images and diagrams need descriptive alt text. Patient education videos require captions and audio descriptions. Lab result notifications must not rely solely on color (red for abnormal, green for normal) to convey meaning. A blind patient using a screen reader and a deaf patient reading captions must both be able to access the same clinical information as a sighted, hearing patient.

Operable means patients must be able to navigate and interact with every feature using their preferred input method, whether that’s a mouse, keyboard, touch screen, voice command, or switch device. For healthcare websites, this includes appointment booking flows, form submissions, dropdown menus, and interactive patient portal features. A patient with a motor disability who navigates entirely by keyboard must be able to complete every task, from scheduling an appointment to downloading discharge instructions, without hitting a dead end.

Understandable means content must be readable and predictable, and input assistance must be available when patients make errors. Healthcare content presents unique challenges here because medical terminology is inherently complex. Forms must include clear labels and instructions. Error messages must explain what went wrong and how to fix it. Navigation must behave consistently across pages. For a patient managing a chronic condition, an understandable portal interface isn’t a convenience. It’s a factor in treatment adherence.

Robust means content must be compatible with current and future assistive technologies. Healthcare websites must produce clean, valid markup that screen readers, magnification software, and alternative input devices can interpret correctly. This is especially important for hospital website design that integrates third-party tools like patient portals, scheduling widgets, and telehealth platforms, since each integration point must maintain accessibility.

Healthcare-Specific Requirements

Beyond the four principles, healthcare websites face requirements that other industries rarely encounter:

• ADA compliant patient portals must make every workflow accessible: viewing lab results, messaging providers, requesting prescription refills, paying bills, and managing appointments
• Medical forms including intake forms, consent forms, and health questionnaires must be fully operable by keyboard, properly labeled for screen readers, and must provide accessible error handling
• Emergency information such as urgent care locations, ER wait times, and crisis hotlines must be immediately accessible to all users without requiring complex navigation
• Video content including patient education videos and telehealth sessions must include synchronized captions and, where applicable, audio descriptions of visual content

Mobile Apps and Kiosks

The HHS rule doesn’t stop at websites. Mobile health applications used for appointment scheduling, telehealth visits, medication management, or health record access must meet the same WCAG 2.1 AA standards. Self-service kiosks in healthcare facilities, such as check-in terminals and payment stations, must also comply. This means touch targets need to be large enough for patients with motor impairments, screen content must support magnification, and alternative interaction methods must be available.

Patient Population Accessibility Needs

Healthcare websites serve a population with significantly higher accessibility needs than most industries. According to the CDC, more than 1 in 4 U.S. adults (28.7%, or over 70 million people) have some type of disability. Healthcare organizations serve a disproportionate share of this population because people with disabilities interact with the healthcare system more frequently than the general population. Designing for accessibility isn’t a niche consideration; it’s designing for your core audience.

Elderly Patients

Patients over 65 represent a growing majority of healthcare consumers, and age-related changes directly affect how they interact with digital interfaces. Vision decline makes small text and low-contrast designs difficult or impossible to read. Reduced motor precision makes small click targets and hover-dependent navigation frustrating. Hearing loss affects video content and audio-based notifications. Lower digital literacy means that complex navigation patterns and unfamiliar interface conventions create barriers that go beyond disability in the traditional sense.

Designing for elderly patients often means larger default font sizes, generous touch targets (at least 44×44 pixels per WCAG), simplified navigation with clear visual hierarchies, and avoiding time-limited interactions that penalize slower users.

Patients with Disabilities

The spectrum of disabilities your website must accommodate is broad:

• Visual disabilities (5.5% of U.S. adults) range from low vision to complete blindness. Screen reader compatibility, proper heading hierarchy, and descriptive alt text are foundational requirements.
• Motor disabilities (12.2% of U.S. adults) affect keyboard navigation, form completion, and any interaction requiring precise mouse movements. All functionality must work without a mouse.
• Hearing disabilities (6.2% of U.S. adults) require captions for video content, visual alternatives for audio alerts, and text-based communication options.
• Cognitive disabilities (13.9% of U.S. adults) demand clear language, consistent navigation, error prevention, and interfaces that don’t overwhelm users with information density.

Limited English Proficiency

Section 1557 requires covered healthcare entities to address language barriers. Notices about the availability of language assistance must be provided in at least the top 15 languages spoken by LEP individuals in the state(s) where you operate. These aren’t machine-translated taglines. Professional translation is necessary to meet the regulatory standard and to ensure that patients actually understand their rights and how to access services.

Healthcare organizations should use resources from lep.gov and U.S. Census data to identify the relevant languages for their service areas.

Patient Leakage Economics

There’s a business case layered on top of the legal mandate. When a patient can’t complete an appointment booking, access their test results, or navigate a provider directory, they don’t simply try harder. They leave. They find a competitor with a more accessible website. In healthcare, this is called patient leakage, and it has direct revenue implications.

An inaccessible website doesn’t just create legal risk; it actively drives patients, particularly the 70+ million adults with disabilities, to organizations that serve them better.

The Lawsuit Risk Healthcare Providers Face

Digital accessibility lawsuits have reached record levels, with over 5,100 digital accessibility cases filed in 2025 alone. Federal ADA Title III web accessibility lawsuits surged 37% in the first half of 2025 compared to the same period in 2024. While healthcare isn’t the most targeted sector yet, the convergence of the May 2026 HHS deadline and growing plaintiff awareness makes healthcare organizations increasingly vulnerable to both private litigation and federal enforcement.

The Numbers

The scope of accessibility litigation is staggering and accelerating:

• Over 5,100 digital accessibility lawsuits were filed in 2025, with projections exceeding 6,000 in 2026
• 37% surge in H1 2025 compared to the same period in 2024
• Healthcare represents 2-3% of all ADA web lawsuits, but this share is growing
• 22.6% of lawsuits in H1 2025 targeted websites using accessibility overlay widgets, proving that shortcuts don’t work
• 40% of federal ADA Title III filings are now pro se, with plaintiffs increasingly using AI tools to draft complaints, lowering the barrier for patients to initiate litigation

The trend is clear: lawsuits are increasing, expanding geographically, and becoming easier for plaintiffs to file.

Notable Healthcare Cases

Frazier v. HCA Holdings is one of the most significant healthcare accessibility cases and serves as a cautionary example for providers seeking ADA compliant website examples. Filed in federal court, the lawsuit alleged that websites operated by over 159 hospitals and healthcare facilities owned by HCA, the largest for-profit health system in the United States, were not accessible to blind users. The complaint cited missing text alternatives, inaccessible navigation, and the inability to use screen readers across HCA’s network of hospital websites.

Tenet Healthcare faced a class action lawsuit on behalf of visually impaired Americans, alleging that websites for facilities including Hahnemann University Hospital and Hialeah Hospital violated Title III of the ADA. These cases demonstrate that both national health systems and individual facilities are targets.

Smaller practices aren’t immune either. Individual physician practices, dental offices, and behavioral health providers have all faced ADA web accessibility demands and lawsuits.

Federal Funding Risk vs. Lawsuit Risk

It is worth remembering that healthcare providers face two separate categories of risk, and most underestimate the more dangerous one:

Lawsuit risk under ADA Title III means potential settlements (typically $10,000-$100,000+), attorney’s fees, and mandatory remediation. Painful, but survivable.

Federal funding risk under Section 504 means potential loss of Medicare and Medicaid reimbursements. For most hospitals, Medicare and Medicaid account for the majority of inpatient days and a substantial share of net revenue. Losing that funding isn’t a setback. It’s an organizational death sentence.

The May 2026 deadline transforms accessibility from a lawsuit-avoidance issue into a revenue-preservation imperative.

Discover Website Offer

Learn more about our packages and pricing options for your project

See Offer

Website ADA Compliance Checklist for Healthcare

A comprehensive website ADA compliance checklist covers nine key areas that healthcare websites must address to meet WCAG 2.1 Level AA standards and the HHS Section 504 rule. This checklist provides a starting point for evaluating your current state of compliance. Each item maps to specific WCAG success criteria, and healthcare organizations should address all nine areas before the May 2026 deadline.

1. Page Structure and Navigation

• All pages use a single H1 heading that describes the page content
• Heading hierarchy is logical and sequential (H1, H2, H3, no skipped levels)
• Skip navigation link is present and functional on every page
• Page landmarks (header, nav, main, footer) are properly coded using HTML5 or ARIA roles
• Breadcrumb navigation is present and accessible
• Site search is keyboard-accessible and returns results in an accessible format
• Page titles are unique and descriptive across the entire site

2. Forms and Inputs

• Every form field has a visible, programmatically associated label
• Required fields are identified by more than just color (asterisk + text)
• Error messages are specific, descriptive, and programmatically associated with the field
• Form validation doesn’t rely solely on color to indicate errors
• Autocomplete attributes are used for common fields (name, email, phone, address)
• Healthcare-specific: Patient intake forms are fully keyboard-navigable
• Healthcare-specific: Consent forms include accessible checkboxes and signature alternatives
• Healthcare-specific: Insurance information fields use accessible dropdown menus

3. Color and Contrast

• Text contrast ratio is at least 4.5:1 against the background (normal text)
• Large text (18pt or 14pt bold) has a contrast ratio of at least 3:1
• Interactive elements (links, buttons) have a 3:1 contrast ratio against surrounding content
• Information is never conveyed by color alone
• Healthcare-specific: Lab results, health status indicators, and alerts use text/icons in addition to color

4. Images and Media

• All informative images have descriptive alt text
• Decorative images have empty alt attributes (alt=””)
• Healthcare-specific: Medical diagrams and anatomical images include detailed descriptions
• Healthcare-specific: Provider photos include name and credentials in alt text
• Healthcare-specific: Patient education videos include synchronized captions
• Healthcare-specific: Videos with important visual content include audio descriptions
• Complex images (charts, infographics) have extended text descriptions nearby

5. Patient Portal Accessibility

• Login process is keyboard-accessible and screen reader compatible
• Two-factor authentication provides accessible alternatives (not just SMS)
• Lab results are presented in an accessible table format
• Secure messaging interface works with screen readers
• Appointment scheduling is fully keyboard-operable
• Bill payment workflow includes accessible form controls
• Prescription refill process doesn’t rely on drag-and-drop or other mouse-only interactions
• Session timeout provides adequate warning and extension options

6. Mobile Responsiveness and Touch Targets

• Touch targets are at least 44×44 CSS pixels
• Content reflows without horizontal scrolling at 320px width
• Text can be resized to 200% without loss of content or functionality
• Spacing between interactive elements prevents accidental activation
• Mobile navigation menu is operable by screen reader and keyboard

7. Emergency Information Accessibility

• Emergency contact numbers are accessible and clickable (tel: links)
• ER wait times and urgent care availability are presented accessibly
• Crisis hotline information can be found within one click of the homepage
• Emergency pages load quickly and don’t depend on JavaScript for critical content

8. Multi-Language Support (Section 1557)

• Language assistance notices appear in at least the top 15 languages for your state(s)
• Language switcher is keyboard-accessible and labeled with the lang attribute
• Translated pages use the correct lang attribute in the HTML
• Professional (not machine) translation is used for patient-facing content
• Section 1557 nondiscrimination notices are displayed prominently

9. Keyboard Accessibility

• All interactive elements are reachable via Tab key
• Focus order follows a logical reading sequence
• Focus indicators are clearly visible (not just default browser outlines)
• No keyboard traps exist (users can Tab in and out of every element)
• Modal dialogs trap focus appropriately and return focus on close
• Custom widgets (accordions, tabs, date pickers) follow WAI-ARIA authoring practices

For organizations building websites for specialized patient populations, the checklist extends further. Providers operating mental health practice websites, for example, should pay particular attention to cognitive accessibility: clear language, calming visual design, and crisis resource prominence.

Testing Your Healthcare Website for Accessibility

Meeting WCAG 2.1 Level AA requires a layered testing approach that combines automated scanning, manual testing, and workflow-specific evaluation. Using an ADA compliant website checker is just the first step in a comprehensive testing strategy. No single method catches everything, and relying on automated tools alone is one of the most common mistakes healthcare organizations make. Automated tools detect approximately 30-40% of accessibility issues. The remaining 60-70% require human evaluation.

Automated Testing Tools

Automated tools provide a useful first pass for identifying common, programmatic accessibility issues. The most widely used tools include:

• WAVE (WebAIM) provides visual, in-context feedback by overlaying icons and indicators on your rendered page. Particularly useful for non-technical stakeholders who need to see problems visually.
• axe DevTools (Deque Systems) runs automated checks against WCAG 2.1 Level A and AA success criteria. Strong for developer-focused testing integrated into the browser.
• Lighthouse (Google) includes accessibility auditing as part of its broader page quality analysis. Built into Chrome DevTools.
• Pa11y is an open-source command-line tool useful for integrating accessibility testing into CI/CD pipelines for automated, ongoing monitoring.

The critical limitation: these tools can identify missing alt text, insufficient color contrast, missing form labels, and structural markup issues. They cannot evaluate whether alt text is meaningful, whether reading order makes sense, whether custom widgets are usable with a screen reader, or whether a form workflow actually functions for someone navigating by keyboard. Those evaluations require human testers.

Manual Testing

Manual testing fills the 60-70% gap that automated tools miss:

• Keyboard testing means navigating your entire website using only the Tab, Enter, Space, and Arrow keys. Can you complete every task? Can you always see where focus is? Can you escape from every modal or menu?
• Screen reader testing using NVDA (free, Windows), JAWS (commercial, Windows), or VoiceOver (built-in, Mac/iOS) reveals how assistive technology users actually experience your content. Test with at least two screen readers, as they interpret markup differently.
• Zoom testing at 200% and 400% magnification confirms that content reflows properly and no information is lost or overlapped.

Patient Portal Workflow Testing

Patient portals require specific workflow-based testing because they involve multi-step processes where a single inaccessible step can block the entire experience. Test these eight critical workflows end-to-end with keyboard and screen reader:

1. Account creation and login (including password reset)
2. Appointment scheduling and cancellation
3. Viewing and interpreting lab results
4. Sending and receiving secure messages
5. Requesting prescription refills
6. Viewing and paying bills
7. Updating personal and insurance information
8. Accessing and downloading health records

Each workflow must be completable without a mouse, and every step must be announced intelligibly by a screen reader.

Professional Accessibility Audits

When to hire a professional auditor:

• You’ve never conducted a formal accessibility assessment
• You’re preparing for the May 2026 HHS deadline and need documentation of compliance
• Your website includes complex interactive components (patient portals, scheduling tools, telehealth)
• You’ve been named in an accessibility complaint or lawsuit

Costs for professional audits range from $2,000 for a basic evaluation of a small marketing website to $25,000+ for comprehensive audits of large hospital website design implementations with integrated patient portals, mobile apps, and multi-language content. The investment is modest compared to the cost of litigation or losing federal funding.

Remediation: Fixing Accessibility Issues

Remediation is the process of identifying, prioritizing, and fixing accessibility barriers across your healthcare website and digital properties. Learning how to make a website ADA compliant requires a structured approach with clear priorities rather than a random list of fixes. The most effective approach treats remediation as a phased project with documented milestones. With the May 2026 deadline approaching, starting now is not optional; it’s the only path to compliance.

Prioritization Framework

Not all accessibility issues carry equal weight. Use this four-tier framework to sequence your remediation work:

Priority 1 (Critical, fix immediately): Issues that completely block access to essential healthcare functions. Examples: forms that can’t be submitted by keyboard, patient portal login that’s inaccessible to screen readers, missing alt text on navigation images, keyboard traps in appointment scheduling.

Priority 2 (High, fix within 30 days): Issues that significantly degrade the experience for assistive technology users. Examples: missing form labels, insufficient color contrast on body text, videos without captions, heading hierarchy violations.

Priority 3 (Medium, fix within 90 days): Issues that create friction but don’t completely prevent task completion. Examples: decorative images missing empty alt attributes, link text that says “click here” instead of describing the destination, missing skip navigation links.

Priority 4 (Low, fix in next development cycle): Issues that affect edge cases or represent best-practice refinements beyond strict WCAG compliance. Examples: optimizing reading order for complex layouts, refining ARIA labels for custom widgets, adding audio descriptions to non-essential video content.

Common Fixes and Implementation

Many accessibility fixes are straightforward code changes. Here are examples of the most common issues and their solutions:

Adding alt text to images:

<!-- Before: Missing alt text -->
<img src="dr-smith.jpg">

<!-- After: Descriptive alt text -->
<img src="dr-smith.jpg" alt="Dr. Sarah Smith, MD, Board-Certified Cardiologist">

Associating labels with form inputs:

<!-- Before: No label association -->
<label>Date of Birth</label>
<input type="date" name="dob">

<!-- After: Properly associated label -->
<label for="patient-dob">Date of Birth</label>
<input type="date" id="patient-dob" name="dob" autocomplete="bday">

Accessible error messages:

<!-- Accessible inline error with aria-describedby -->
<label for="patient-email">Email Address</label>
<input type="email" id="patient-email" name="email"
       aria-describedby="email-error" aria-invalid="true">
<span id="email-error" role="alert">
  Please enter a valid email address (example: name@domain.com)
</span>

Patient Portal Remediation

Patient portals present a unique challenge because many healthcare organizations use third-party systems like Epic MyChart or Oracle Health (formerly Cerner). The remediation path depends on your portal architecture:

If you use a vendor-hosted portal, your control over code-level fixes is limited. You must work with your vendor to ensure compliance. Key questions to ask:

• Does the current version meet WCAG 2.1 Level AA?
• When will accessibility fixes be released?
• Can you provide a VPAT (Voluntary Product Accessibility Template)?
• Will you indemnify us for accessibility claims related to your product?

If you use a custom-built or heavily customized portal, you have direct control but also full responsibility. Prioritize the eight critical workflows identified in the testing section and fix them sequentially.

If your portal integrates vendor components into a custom framework, you’re responsible for the overall experience. Even if a vendor component is accessible in isolation, the integration points (login handoffs, iframe embeds, API-driven content displays) must also be accessible.

Timeline and Budget

Remediation costs vary significantly based on website complexity:

The timeline reality: with the May 2026 deadline roughly three months away, large health systems that haven’t started remediation face an extremely compressed timeline. Starting now and prioritizing critical issues (Priority 1 and 2) can achieve meaningful compliance progress even within a tight window. Complete remediation may extend past the deadline, but demonstrating active, documented progress toward compliance significantly reduces enforcement risk.

Discover Website Offer

Learn more about our packages and pricing options for your project

See Offer

Vendor Responsibility: EHR and Patient Portal Accessibility

Healthcare organizations share accessibility responsibility with their technology vendors, but the legal obligation ultimately rests with the provider. The HHS Section 504 rule doesn’t care whether an accessibility barrier originates in your custom code or in a vendor’s patient portal. If a patient can’t access your services because of a digital barrier, your organization is accountable. This shared responsibility model applies to all aspects of healthcare website design, including third-party integrations.

Shared Responsibility Model

Think of it as two layers. Your organization is responsible for the overall patient experience, including the website you control, the content you publish, and the accessibility of the complete user journey. Your vendors (EHR companies, patient portal providers, scheduling platforms, telehealth tools) are responsible for making their products accessible. But when a vendor’s product fails to meet WCAG standards and you’ve embedded it into your patient-facing experience, you’re the one facing the OCR complaint.

This means vendor selection, contracting, and ongoing accountability are compliance activities, not just procurement decisions.

Questions to Ask Your Vendors

Before renewing or signing any vendor agreement, ask these six questions. Document the responses in writing:

1. Does your product currently conform to WCAG 2.1 Level AA? If the answer is vague, that’s a red flag.
2. Can you provide a current VPAT (Voluntary Product Accessibility Template)? A VPAT documents the product’s conformance level against accessibility standards. No VPAT means no documented commitment.
3. What is your remediation roadmap for known accessibility issues? Vendors should have specific timelines, not vague future plans.
4. Will you contractually guarantee WCAG 2.1 AA compliance by May 2026? If they won’t put it in the contract, assume they won’t deliver.
5. Do you conduct regular third-party accessibility audits? Internal testing alone is insufficient.
6. Will you indemnify our organization for accessibility claims arising from your product? This is the question that separates serious vendors from those hoping you won’t ask.

Red flags: vendors who point to an accessibility overlay or widget as their compliance solution, vendors who claim “Section 508 compliance” without addressing WCAG 2.1, and vendors who haven’t updated their VPAT in more than 12 months.

When Vendor Systems Fall Short

If your vendor can’t or won’t meet WCAG 2.1 AA, you have three options: negotiate a binding remediation timeline with contractual penalties, implement a custom accessible interface layer that wraps the vendor’s product, or switch vendors. None of these options is easy, but the alternative is carrying compliance risk that someone else created.

In my experience, the vendor conversation is the single most delayed action item in healthcare accessibility projects. Start it now.

HIPAA and ADA: How They Intersect

HIPAA and ADA serve fundamentally different purposes but apply to the same healthcare digital properties simultaneously. HIPAA protects the privacy and security of patient health information. ADA (along with Section 504 and Section 1557) protects access for people with disabilities. Compliance with one does not satisfy the other, and healthcare organizations must address both frameworks independently.

Different Laws, Overlapping Application

A common misconception I encounter is the belief that HIPAA compliance somehow addresses accessibility. It does not. A website can be fully HIPAA-compliant with encrypted data transmission, proper access controls, and comprehensive audit logging, while being completely inaccessible to a blind patient using a screen reader. The reverse is also true: a fully accessible website can violate HIPAA by transmitting PHI over unsecured channels.

Accessible Forms That Protect PHI

The good news is that accessibility and HIPAA compliance are fully compatible. You don’t have to choose between them, and implementing one doesn’t compromise the other. In fact, accessible design often strengthens privacy protections:

• Properly labeled form fields help screen reader users understand what information is being collected, reducing the chance of inputting sensitive data into the wrong field
• Clear error messages help patients correct mistakes before submitting, reducing the need to transmit and re-transmit PHI
• Accessible session timeout warnings give patients adequate notice before a session expires, preventing incomplete form submissions that could create data integrity issues

Healthcare organizations need HIPAA-compliant hosting infrastructure alongside an accessible front-end experience. These are parallel requirements, not competing ones.

Documentation Requirements

Both HIPAA and accessibility require documentation of compliance efforts:

• HIPAA requires risk assessments, policies and procedures, training records, and business associate agreements
• Accessibility requires audit reports, remediation plans, testing documentation, and conformance statements (VPATs)

Maintaining both sets of documentation demonstrates due diligence under both frameworks and provides critical evidence if you face either a privacy breach investigation or an accessibility complaint.

Ongoing Compliance and Maintenance

Accessibility compliance is not a one-time project. It’s an ongoing operational commitment. Websites change constantly: new content is published, design updates are pushed, third-party components are updated, and staff members who understand accessibility requirements leave and are replaced by people who don’t. Without a structured maintenance program, a fully compliant website will degrade into non-compliance within months.

Why Compliance Degrades Over Time

Every content update introduces potential accessibility issues. A staff member uploads a blog post image without alt text. A developer adds a new form widget that isn’t keyboard-accessible. A marketing team launches a campaign landing page that wasn’t reviewed for color contrast. A vendor pushes a patient portal update that breaks screen reader compatibility.

These aren’t hypothetical scenarios. They’re the normal course of website operations. The question isn’t whether your compliance will degrade. It’s how quickly you’ll catch and fix the regressions.

Ongoing Testing Schedule

A practical maintenance schedule for healthcare organizations:

• Weekly: Automated scans of new and updated pages using WAVE, axe, or Pa11y (automated, low effort)
• Monthly: Spot-check manual keyboard and screen reader testing of high-traffic pages and patient portal workflows
• Quarterly: Comprehensive manual audit of the full site, including all patient-facing workflows, mobile app testing, and multi-language content review
• Annually: Full professional third-party audit with formal reporting and updated conformance documentation

Staff Training and Processes

Accessibility must be embedded into your organization’s workflows, not treated as a specialist function:

• Content authors need training on writing alt text, using proper heading structures, creating accessible documents, and selecting sufficient color contrast
• Developers need training on ARIA patterns, keyboard interaction models, focus management, and accessible coding practices
• Designers need training on contrast requirements, touch target sizing, cognitive accessibility principles, and accessible color palettes
• QA testers need accessibility testing added to their standard test plans
• Compliance officers need understanding of the regulatory landscape and documentation requirements

Budget for Ongoing Accessibility

Plan for annual accessibility maintenance costs:

This covers automated tool subscriptions, quarterly manual testing, annual professional audits, staff training, and remediation of issues found during maintenance cycles. It is worth remembering that this ongoing investment is a fraction of the cost of a single ADA lawsuit settlement or the catastrophic impact of losing Medicare funding.

Key Takeaways:

• The HHS Section 504 final rule requires WCAG 2.1 Level AA compliance for healthcare websites, mobile apps, and kiosks by May 11, 2026 (15+ employees) or May 10, 2027 (under 15 employees)
• Three overlapping laws (ADA, Section 504, Section 1557) create multiple enforcement pathways and penalties, including loss of Medicare/Medicaid funding
• Accessibility overlay widgets are not a compliance solution and have been the subject of increasing litigation
• Automated testing tools catch only 30-40% of issues; manual testing with keyboards and screen readers is essential
• Patient portals require end-to-end workflow testing across eight critical patient tasks
• Compliance degrades over time and requires ongoing testing, training, and maintenance budgets

Your Next Steps:

1. Run a free automated scan of your website using WAVE to identify immediate issues
2. Contact your patient portal vendor to request a current VPAT and accessibility roadmap
3. Conduct a manual keyboard navigation test of your five highest-traffic pages
4. Engage a professional accessibility auditor for a comprehensive assessment
5. Develop a prioritized remediation plan targeting Priority 1 and 2 issues first
6. Establish ongoing testing and training processes to maintain compliance after remediation

Disclaimer: This article provides general educational information about digital accessibility requirements for healthcare organizations. It is not legal advice. Accessibility requirements may vary based on your organization’s specific circumstances, services, and funding sources. Consult with a qualified healthcare attorney and accessibility specialist for guidance tailored to your situation.