medical website design agency devrivo
Get a Quote

HIPAA & ADA Compliance Resources

HIPAA & ADA Compliance for Medical Websites: The Complete 2026 Guide for Healthcare Providers

Healthcare website compliance in 2026 means navigating two separate sets of obligations that overlap in ways most providers – and many web agencies – don’t fully understand. HIPAA protects patient health information from exposure through your website’s forms, tracking tools, and hosting environment. The ADA, together with a federal accessibility rule from HHS, requires your website to be usable by patients with disabilities. That rule’s enforcement timeline changed in May 2026, and a lot of guidance published before then hasn’t caught up.

This guide brings both sets of requirements together in one place, with the corrected timeline, practical checklists, tool recommendations, and concrete examples of what a violation looks like and how to fix it. Whether you’re auditing your current website, briefing a web agency, or responding to a compliance question from a patient or partner, you should be able to find the answer here.

The HHS Accessibility Deadline Just Moved - Here's What Actually Changed in 2026

Most healthcare providers know about HIPAA. Far fewer are aware that a second major compliance requirement – a 2024 rule from the Department of Health and Human Services mandating web accessibility – went through a significant timeline change in May 2026 that a lot of published guidance still doesn’t reflect.

Here’s the short version: the rule itself is real, it’s in effect, and it isn’t going away. But on May 7, 2026, HHS’s Office for Civil Rights issued an Interim Final Rule pushing the compliance deadlines back by one year, citing concerns that many covered organizations – particularly community health centers and smaller practices – would not be able to meet the original dates.

Quick-Reference Compliance Checklist

Use this as a fast self-audit. A full technical audit goes deeper, but this catches the most common gaps.

HIPAA

  • BAAs signed with hosting provider, CDN, scheduling tool, chat tool, and analytics platform
  • No tracking pixels (Meta, TikTok, etc.) on patient portal or appointment pages without a BAA
  • Forms submit to encrypted, access-controlled storage - not a standard database or email inbox
  • Privacy policy specifically addresses health information collected via the website
  • Patient portal hosted on, or linked from, HIPAA-compliant infrastructure
  • Signed BAAs are documented and kept on file, not just verbally agreed to

ADA / WCAG 2.1 AA

  • Text contrast meets the 4.5:1 minimum throughout, including in branded color palettes
  • Every meaningful image has descriptive alt text
  • The full site is navigable by keyboard alone, including embedded widgets
  • All form fields have programmatic labels, not just visual placeholder text
  • Video has captions; audio has transcripts
  • Heading structure is logical with no skipped levels
  • No accessibility overlay is used as a substitute for code-level fixes
  • PDF forms and documents are tagged for screen-reader accessibility

International

  • Cookie consent banner in place if the site receives EU/EEA visitors
  • CCPA disclosures in place if the practice serves California residents above applicable thresholds

What You’ll Find in Our Compliance Resources

A Note on Accessibility Overlays

Before you consider a quick fix: accessibility overlay widgets – tools like accessiBe, UserWay, or AudioEye that inject a script to add on-page accommodations – are widely regarded as insufficient for genuine WCAG 2.1 AA compliance. They can add surface-level features, like a font-size toggle or a contrast switch, but they don’t fix the underlying code-level barriers a screen reader or keyboard-only user actually runs into. The Department of Justice and major disability-rights organizations have been explicit that overlays alone don’t satisfy ADA or Section 504 obligations. Genuine compliance requires remediation at the code level – semantic HTML, proper ARIA labeling where needed, and tested keyboard navigation.

Who the Rule Covers

The rule applies under Section 504 of the Rehabilitation Act to any organization receiving federal financial assistance from HHS. In practice, that covers nearly every healthcare provider that accepts Medicare or Medicaid, along with hospitals, health systems, health plans, clinical research institutions, and digital health companies receiving HHS funding or grants. If your practice bills Medicare or Medicaid, this rule almost certainly applies to your website.

A related rule from the Department of Justice, updating ADA Title II for state and local government services, runs on a similar but separate timeline. For organizations subject to both rules, the earlier applicable deadline controls.

Why the Deadline Moving Doesn't Mean the Risk Did

Two things matter here, and both point in the same direction: don’t panic, but don’t relax either.

First, the extension only applies to the Section 504 federal-funding requirement. ADA Title III private lawsuits are unrelated to this deadline and have continued regardless. Plaintiffs’ attorneys have filed website accessibility lawsuits against healthcare organizations for years under Title III, independent of any HHS rulemaking, and that litigation risk doesn’t pause because a federal compliance date moved.

Second, the rule mandates WCAG 2.1 Level AA – a 50-criterion technical standard – across every patient-facing page, not just the homepage. That’s a substantial remediation project for most existing healthcare websites, and an extended deadline is exactly the kind of date that gets ignored until it’s twelve months away again. Starting now, while there’s no time pressure, is the difference between a manageable phased rollout and a panicked scramble in 2027.

What WCAG 2.1 Level AA Means in Practice

WCAG 2.1 (Web Content Accessibility Guidelines) Level AA is organized around four principles: content must be Perceivable, Operable, Understandable, and Robust. In practical terms for a medical website, this means:

  • Text has a color contrast ratio of at least 4.5:1 against its background
  • All functionality is operable by keyboard alone, with no mouse required
  • All images carry descriptive alt text
  • All form fields have programmatic labels, not just visual placeholder text
  • Videos include captions; audio content includes transcripts
  • Pages follow a logical heading structure (H1 → H2 → H3, with no skipped levels)
  • Error messages identify the specific field with an error and explain how to fix it
  • No content flashes more than three times per second (seizure risk)
  • Free tools to spot-check your site: WAVE (wave.webaim.org), axe DevTools (a Chrome extension), and Google Lighthouse (built into Chrome DevTools). These catch a meaningful share of common issues but not everything - manual testing with a screen reader like NVDA is the only way to fully validate compliance.
The Cost of Getting This Wrong

Two separate risks apply here, with different mechanics:

Section 504 / federal funding risk: Non-compliance can jeopardize federal funding tied to HHS programs – a serious exposure for any practice dependent on Medicare or Medicaid reimbursement.

ADA Title III litigation risk: Private lawsuits over inaccessible websites are a well-established category of litigation, with healthcare among the more frequently targeted industries in recent years. Settlements commonly run into the tens of thousands of dollars once legal fees and required remediation work are factored in – money that buys the practice nothing except the accessibility work it should have already had.

HIPAA Compliance for Healthcare Websites: The Full Breakdown

What Actually Makes a Website HIPAA Compliant?

HIPAA compliance isn’t a feature you install or a badge you purchase. It’s a framework of administrative, physical, and technical safeguards applied everywhere Protected Health Information (PHI) could be created, transmitted, or stored on your site. For a healthcare website, that mostly comes down to three things: secure hosting and data handling, compliant third-party tools, and proper documentation – specifically, signed Business Associate Agreements (BAAs).

The distinction that trips up most practices: a website is not HIPAA compliant just because it has an SSL certificate. SSL/HTTPS encrypts data in transit – a necessary safeguard, but far from a sufficient one. HIPAA also requires encryption at rest, access controls over who can view stored data, audit logging, and protections against unintended third-party data exposure. An agency that tells you “we use SSL, so you’re covered” doesn’t understand HIPAA.

The Most Common HIPAA Website Violations

Based on OCR guidance and healthcare cybersecurity audit findings, these are the violations that show up again and again on healthcare websites:
Contact forms without secure, encrypted storage.

Forms that collect a patient's name, condition, or reason for visit, and store submissions in a standard, non-HIPAA-compliant database or forward them by unencrypted email, create direct PHI exposure.

Missing a BAA with the hosting provider.

Any host with technical access to your server is, by HIPAA's definition, a business associate if your site touches PHI. Most mainstream hosting providers will not sign a BAA at all.

Live chat tools without a BAA.

Chat plugins like Intercom, Drift, and Tidio often route conversation data through third-party servers. If a patient types health information into that chat window, that's a HIPAA problem unless the vendor has signed a BAA.

Outdated or generic privacy policies.

A privacy policy that doesn't specifically address how health information collected through the website is handled fails HIPAA's Notice of Privacy Practices requirement.

Booking tools that collect health information.

Generic scheduling tools that ask "reason for visit" are collecting PHI. That tool needs to be covered under a BAA or swapped for a HIPAA-compliant alternative.

Patient portals embedded on non-compliant infrastructure.

Even when the portal vendor itself is compliant, linking it from a marketing site hosted on non-compliant infrastructure can create downstream risk.

Tracking pixels on patient-facing pages.

Google Analytics, the Meta Pixel, and similar tools placed on appointment-booking pages, patient portals, or condition-specific landing pages can transmit identifying information - IP address paired with the specific health condition or service a visitor was viewing - to third parties without a BAA in place. This exact pattern was at the center of the Novant Health case, in which the health system's use of the Meta Pixel on its MyChart patient portal led to a $6.6 million class-action settlement after the pixel reportedly transmitted data tied to roughly 1.3 million patients to Meta between 2020 and 2022. Advocate Aurora Health settled a similar pixel-related case for $12.25 million. Neither was an OCR enforcement fine - both were civil settlements - but the financial and reputational exposure was comparable either way.

Business Associate Agreements: The Vendor Checklist

A BAA is a binding contract that any vendor with potential access to PHI must sign. For most medical practice websites, that list includes:
  • Web hosting provider
  • Contact form plugin provider
  • Live chat tool provider
  • EHR/EMR integration vendor
  • Telehealth platform provider
  • Online scheduling or appointment tool
  • Payment processor, if you collect copays online
  • CDN provider (Cloudflare, for example, offers a BAA)
  • Analytics platform, if patient data could be captured
  • Email marketing platform, if you email patients
Not every vendor will sign a BAA. If one refuses, that tool cannot be used on a patient-facing page – full stop. Keep signed BAAs on file as part of your compliance documentation; OCR will ask for them if your practice is ever audited.

ADA Website Accessibility for Medical Practices

The Four Principles of WCAG 2.1 AA
HIPAA-compliant website design is essential for many healthcare providers, including:
  • Perceivable - Information must be presentable in ways users can perceive, regardless of sensory ability: alt text for images, captions for video, sufficient color contrast between text and background.
  • Understandable - Text must be readable, pages must behave predictably from one to the next, and forms must help users avoid and correct mistakes rather than just rejecting input silently.
  • Robust - Content must work reliably across assistive technologies, including screen readers and voice control software, both today and as those technologies continue to evolve.

Free Tools to Test Your Site's Accessibility

  • WAVE (wave.webaim.org) - browser extension that overlays issues directly on the page
  • axe DevTools - Chrome extension that integrates with browser developer tools
  • Google Lighthouse - built into Chrome DevTools, includes a 0–100 accessibility score
  • NVDA - a free screen reader for Windows, and the only real way to experience your site the way a screen-reader user does
Automated tools typically catch a meaningful but partial share of WCAG issues – things like missing alt text or contrast failures are easy to flag programmatically. The issues automated scanners miss tend to be the ones that matter most in practice: whether the reading order makes sense, whether link text is meaningful out of context (“click here” tells a screen reader user nothing), and whether keyboard focus moves logically through the page. Those require a human, or at minimum a screen reader test pass, to catch.

The Most Common ADA Violations on Medical Websites

  • Appointment forms with no programmatic labels - a sighted user sees "Email," but a screen reader announces nothing, because the label isn't actually associated with the input field in code.
  • Color-only indicators, such as a red asterisk marking a required field with no text equivalent like "(required)" for users who can't perceive color.
  • PDF intake forms that aren't tagged for accessibility and are effectively unreadable by screen readers, even though the visual document looks fine.
  • Provider bio or procedure-explainer videos with no captions, which excludes deaf and hard-of-hearing patients from content they may specifically need before a procedure.
  • Image carousels and testimonial sliders that can't be operated by keyboard, trapping keyboard-only users or skipping content entirely.
  • Insufficient contrast between body text and background, a problem that shows up disproportionately often in light, pastel "wellness" color palettes that look calming but fail the 4.5:1 contrast minimum.
  • Pop-ups and modals that trap keyboard focus or can't be dismissed without a mouse, which can strand a keyboard user on the page entirely.
  • Missing or broken "skip to main content" links, forcing keyboard users to tab through an entire navigation menu on every single page.
  • Auto-playing video or audio with no visible pause control, which can also interfere with screen reader audio output.
  • Inaccessible third-party appointment-booking widgets - embedded scheduling tools are a frequent blind spot, since the practice didn't build them and often doesn't realize they fail basic keyboard and screen-reader tests.

What to Do If Your Website Isn't Compliant

If you’ve gone through the checklist below and found gaps – and most existing healthcare websites will – the fix isn’t usually a full rebuild. It’s a structured remediation process:
Document what you find.
A written audit, even an informal one, becomes useful evidence of good-faith effort if you’re ever questioned by OCR or face an ADA claim.
1
Triage by risk, not by ease.
Tracking pixels on patient-facing pages and missing BAAs are the highest-risk HIPAA gaps – fix those first, even before less urgent accessibility work, because the exposure (PHI already being transmitted) is active and ongoing.
2
Fix code-level accessibility issues directly
rather than reaching for an overlay widget. This usually means updates to templates and components rather than every individual page, since most violations repeat across the site (the same broken form pattern, the same un-labeled icon button) rather than being one-off mistakes.
3
Get BAAs signed before re-enabling any third-party tool
that touches PHI. If a vendor won’t sign, that’s your answer – replace the tool.
4
Re-test after remediation,

using both automated tools and at least one manual pass, since fixes can introduce new issues (a corrected tab order that skips a different element, for instance).

5
Set a recurring review cadence.
Compliance isn’t a one-time project – a new page, a new booking widget, or a redesigned form can reintroduce the exact issues you just fixed.
6

Frequently Asked Questions

Yes, if your website collects any patient information - including appointment requests, contact forms that ask about health conditions, live chat, or patient portal links. Even when no PHI appears directly on the page, tracking tools like Google Analytics can inadvertently capture and transmit PHI (an IP address paired with a health-related URL or form field), which constitutes a violation. Any website connected to a HIPAA-covered entity needs safeguards in place.
No. SSL/HTTPS encrypts data in transit, which is necessary but far from sufficient. HIPAA also requires encryption at rest, access controls on stored data, audit logging, signed BAAs with every vendor that touches PHI, and administrative policies governing all of it. SSL alone covers one safeguard among many required ones.
As of May 7, 2026, the deadline was extended. Organizations with 15 or more employees receiving HHS federal financial assistance now have until May 11, 2027 to meet WCAG 2.1 Level AA; organizations with fewer than 15 employees have until May 10, 2028. The underlying requirement hasn't changed - only the compliance timeline has. This extension applies specifically to the Section 504 federal-funding rule; it doesn't affect ADA Title III private lawsuit risk, which has continued on its own timeline for years.
Yes. The rule applies to existing websites, not just new ones - there's no grandfather clause. Organizations need to actively bring existing sites into WCAG 2.1 AA compliance by their applicable deadline. Starting that work now, while there's no immediate time pressure, is far less costly than starting in early 2027.
Generally, no. Overlay tools like accessiBe, UserWay, and AudioEye add surface-level accommodations but don't fix underlying code-level barriers. The Department of Justice and major disability-rights organizations have stated that overlays alone are not considered sufficient to meet WCAG 2.1 AA or ADA obligations. Genuine compliance requires code-level remediation.
Novant Health used the Meta Pixel on its MyChart patient portal between 2020 and 2022. The pixel reportedly transmitted data linked to roughly 1.3 million patients to Meta. The resulting class-action lawsuit was settled for $6.6 million - a civil settlement, not an OCR enforcement fine, though the underlying conduct (an unauthorized PHI disclosure via a tracking pixel) is exactly the kind of HIPAA violation OCR has separately warned healthcare organizations about.
GDPR applies when your website collects data from individuals physically located in the EU or EEA, regardless of where your practice is based. If you see telehealth patients or medical tourists from Europe, you need a cookie consent mechanism, data processing agreements with your analytics vendors, and a process for handling data erasure requests.
HIPAA is enforced by HHS's Office for Civil Rights, which can pursue corrective action plans and civil monetary penalties against covered entities. ADA Title III accessibility claims are typically brought as private lawsuits, independent of any federal agency action. Section 504 compliance - the WCAG deadline discussed above - is tied to HHS federal funding and is enforced separately from both.
Cost depends heavily on the site's current state. Adding BAAs to existing compliant tools and fixing a handful of accessibility issues might take a few hours of focused work. A site with deeply embedded tracking pixels, a non-compliant hosting setup, and systemic accessibility gaps across dozens of pages is a larger remediation project. A compliance audit is the right first step before estimating cost, since it tells you whether you're looking at targeted fixes or a more substantial rebuild.

Is Your Medical Website Compliant? How to Find Out

The checklist above will surface obvious gaps, but it won’t catch everything – particularly on the HIPAA side, where the real risk often lives in how third-party scripts behave on the back end, not in what’s visible on the page. Devrivo specializes in HIPAA-compliant medical website design for healthcare practices across the US, UK, and Canada. Every site we build meets WCAG 2.1 AA accessibility standards and implements HIPAA safeguards by default, including secure hosting, encrypted forms, and proper BAA documentation with every vendor in the stack.
Get a Free Compliance Review