Healthcare Website Accessibility: Compliant in Code, Not a Widget
A demand letter doesn't ask questions. It names your clinic, cites the ADA, and gives you a deadline. By the time most owners go looking for an accessibility fix, the clock is already running, and the first thing they get sold is an overlay widget that auto-detects nothing and shields them from no one. Courts have ruled against sites running those widgets. They are not compliance.
Real accessibility lives in the code: keyboard paths a patient can actually navigate, contrast a low-vision user can read, forms a screen reader can announce. I build it into custom code from the first line, so the site passes a real WCAG 2.2 AA audit instead of a plugin's marketing claim. Fifteen years in, with that work recognized by CSS Design Awards and Awwwards. None of this is legal advice. Key Takeaways:- Web accessibility for clinics is enforced through the ADA, Section 504, and Section 1557 - not a single "ADA compliance" checkbox.
- The technical standard is WCAG 2.2 AA, built on four POUR principles: Perceivable, Operable, Understandable, Robust.
- Canadian clinics in Ontario also fall under AODA, which requires WCAG 2.0 AA.
- Accessibility overlays and plugins are not compliance - they often fail real audits and can increase legal exposure.
- Healthcare-specific components - appointment booking, intake forms, patient portals, and care instructions - must be usable by screen readers and keyboard-only users.
- Real compliance comes from accessible custom code plus a cycle of audit, remediation, and ongoing monitoring.
- HIPAA (US patient-privacy law) and web accessibility are two separate problems - meeting one does not satisfy the other.
The Lawsuit and the Deadline: Why Clinics Are Worried Now
Two separate pressures are driving healthcare providers to take accessibility seriously, and they are easy to confuse.
The first is litigation. Plaintiffs file thousands of website accessibility lawsuits and demand letters every year, and healthcare sites are frequent targets because they handle essential services. A demand letter typically arrives without warning, cites your inaccessible booking flow or forms, and asks for a settlement plus remediation. Most are settled quietly, which is exactly why you rarely hear about them until one lands on your desk.
The second is regulatory. The US Department of Health and Human Services and the Department of Justice have set firm technical standards and deadlines that turn "you should be accessible" into "you must meet WCAG 2.1 AA by this date." Missing a deadline can put federal funding, including Medicare and Medicaid reimbursement, at risk.
Both pressures point to the same fix: a website that actually works for people using assistive technology. Not a compliance badge. Not a disclaimer. Working code.
WCAG 2.2 AA Explained (POUR)
WCAG - the Web Content Accessibility Guidelines - is the technical standard nearly every accessibility law points to. The current version is WCAG 2.2, and the legal target for most obligations is Level AA. The guidelines are organized around four principles, known by the acronym POUR.
Perceivable - users must be able to perceive the content. That means text alternatives for images, captions for videos, and sufficient color contrast so text is readable for low-vision users.
Operable - users must be able to operate the interface. Every function works with a keyboard alone, nothing flashes in a way that triggers seizures, and users have enough time to complete forms.
Understandable - content and operation must be predictable. Form fields are clearly labeled, errors are explained in plain language, and navigation behaves consistently across pages.
Robust - content works reliably across browsers, devices, and assistive technologies, now and as they evolve. This is where clean, semantic code matters most.
WCAG 2.1 AA is still the version cited in many current US regulations, and WCAG 2.2 AA is the newer superset that adds criteria around focus visibility, dragging alternatives, and target size. Building to 2.2 AA covers you for 2.1 AA as well, so that is the standard I build to.
The US Legal Stack: ADA, Section 504, and Section 1557
In the United States, web accessibility for healthcare is governed by a stack of overlapping laws. You usually fall under more than one.
ADA Title III
The Americans with Disabilities Act, Title III, covers "places of public accommodation," and courts have consistently treated the websites of doctors' offices, clinics, dentists, and hospitals as covered. The ADA itself does not name WCAG, but settlements and DOJ guidance overwhelmingly use WCAG 2.1 AA as the benchmark. This is the law behind most private demand letters.
Section 504 of the Rehabilitation Act
Section 504 applies to any program or activity that receives federal financial assistance. If your practice accepts Medicare or Medicaid, or receives federal grants, Section 504 applies to you and requires your digital services to be accessible.
Section 1557 of the ACA
Section 1557 is the nondiscrimination provision of the Affordable Care Act. It applies to health programs and activities that receive federal funds and explicitly reaches patient-facing technology - your website, patient portal, and online scheduling.
HHS OCR Enforcement and Federal Deadlines
The HHS Office for Civil Rights enforces Section 504 and Section 1557. A DOJ rule under Title II set WCAG 2.1 AA as the required standard for state and local government entities, with compliance deadlines arriving across 2026 and 2027 depending on the size of the entity, and related obligations extending further out. For recipients of federal health funding, HHS has aligned its expectations to the same WCAG 2.1 AA standard on comparable timelines. The exact deadline that applies to you depends on your entity type, your population size, and your funding sources - which is precisely why this is a question for your attorney, not a vendor's marketing page.
AODA: The Ontario Layer for Canadian Clinics
If your clinic operates in Ontario, you have a separate and very specific obligation: the Accessibility for Ontarians with Disabilities Act, or AODA.
AODA requires conforming to WCAG 2.0 Level AA for public-facing websites. It applies to the public sector and to private and non-profit organizations with 50 or more employees. The enforcement teeth are real - the province can levy administrative penalties that, for corporations, can reach up to 100,000 dollars per day for serious or ongoing non-compliance.
AODA accessibility is entirely separate from Canadian privacy law. Privacy is governed by PIPEDA at the federal level and by a provincial health information act - PHIPA in Ontario, PHIA in Manitoba and Nova Scotia and Newfoundland and Labrador, PHIPAA in New Brunswick, and HIA in Alberta. A site can be perfectly private and still fail accessibility, or vice versa. They are two different problems with two different solutions. If your build touches Canadian patient data, see PHIA and PIPEDA compliant healthcare websites for the privacy side.Why Accessibility Overlays Are Not Compliance
Here is the most important thing on this page, and the part the overlay industry does not want you to read.
Accessibility overlays - accessiBe, UserWay, AudioEye, and similar plug-in widgets - promise instant compliance for a monthly fee. You paste one line of JavaScript and a little wheelchair icon appears in the corner. They do not make your site compliant. In many cases they make your legal exposure worse.
Overlays sit on top of your existing code and try to patch problems at runtime with automation. But automated tooling can only detect and "fix" a fraction of WCAG criteria. The rest - meaningful alt text, logical reading order, accessible custom widgets, sensible error messages - require human judgment and code-level changes the overlay cannot make. Screen reader users frequently report that overlays interfere with the assistive technology they already use, making sites harder to navigate, not easier.
This is not a fringe opinion. Hundreds of accessibility advocates and screen reader users have publicly stated overlays do not solve the problem, and a growing number of accessibility lawsuits have named sites that were running an overlay at the time they were sued. The widget became evidence that the business knew about the obligation and chose a shortcut.
Real accessibility lives in the markup. It means semantic HTML, correct ARIA only where native elements fall short, keyboard-operable components, and contrast and labels handled in the design and the code. That is the work I do, and it is why I am the anti-overlay builder. If you want a deeper look at why I avoid plugin-and-pray builds entirely, the same logic drives my WordPress alternatives approach.| Accessibility Overlay | Code-Level Remediation | |
|---|---|---|
| Where the fix lives | A script on top of your site | In the HTML, CSS, and components |
| WCAG coverage | A fraction, automated only | Full criteria, manual and automated |
| Screen reader experience | Often interferes | Works with the user's own tools |
| Legal standing | Has been cited in lawsuits | Holds up in audits |
| Ongoing cost | Monthly fee, forever | Built in, maintained as needed |
The Healthcare Components That Must Be Accessible
Generic accessibility advice ignores the parts of a medical site that actually matter. These are the components patients use to get care, and they are exactly where accessibility most often breaks.
Booking and scheduling widgets. Many third-party booking embeds are inaccessible out of the box. A patient who cannot tab through your calendar cannot book. I vet and integrate scheduling tools that work with a keyboard and a screen reader - see patient booking and scheduling integration.Intake and contact forms. Every field needs a programmatic label, every error needs an accessible message tied to the field, and the whole form needs to be completable by keyboard. This is the single most common failure point on healthcare sites.
Patient portals and telehealth. Login flows, video consultation interfaces, and document uploads all need accessible controls and focus management. For telehealth specifically, captioned video and keyboard-operable controls are non-negotiable - more on the build in telehealth website design.Medical PDFs and documents. A scanned PDF of your patient intake packet is invisible to a screen reader. Documents need to be tagged and structured, or replaced with accessible HTML.
Videos. Provider introductions, procedure explainers, and patient education videos need accurate captions and, where appropriate, transcripts or audio descriptions.
The Core Criteria I Build To
Underneath the headline laws, accessibility comes down to a concrete checklist. Here is what I implement and verify on every healthcare build.
Keyboard navigation. Every interactive element - links, buttons, menus, form fields, modals - is reachable and operable without a mouse, with a visible focus indicator so users always know where they are.
Color contrast. Body text meets a 4.5:1 contrast ratio against its background, and large text and meaningful interface elements meet at least 3:1. This is checked at the design stage, not patched later.
Alt text. Every meaningful image has a descriptive text alternative, and decorative images are hidden from assistive technology so they do not add noise.
Form labels and accessible errors. Inputs have real labels, required fields are announced, and validation errors are described in plain language and connected to the field that needs fixing.
Heading structure and semantics. Pages use a logical heading hierarchy and proper landmarks so screen reader users can navigate by structure instead of reading every word.
Screen reader compatibility. The site is tested against actual screen readers so the experience is coherent, not just technically present.
This is the same standard that underpins all my healthcare website design work, and it carries across every practice type, from a dental practice site to a mental health clinic.Audit, Remediation, and Ongoing Monitoring
Accessibility is not a one-time checkbox. It is a process with three parts, and skipping any of them leaves a gap.
Audit and Manual Testing
A real audit combines automated scanning with manual testing. Automated tools catch obvious failures fast - missing alt text, low contrast, unlabeled fields. Manual testing catches everything automation cannot: keyboard traps, illogical focus order, screen reader confusion, and components that technically pass but are unusable in practice. Both are required. A clean automated scan alone proves almost nothing.
Remediation
Remediation means fixing the issues at the code level - rewriting markup, adjusting the design system, rebuilding inaccessible components properly. With a custom-coded site, this is straightforward because I control the entire stack. With a template builder or an overlay, you are often stuck working around code you cannot change.
Ongoing Monitoring
HIPAA and Accessibility Are Two Different Problems
Clinics constantly conflate these, so let me be blunt. HIPAA and accessibility solve completely different problems and there is no overlap in the fix.
HIPAA is US federal law governing the privacy and security of protected health information. It is about who can see patient data and how it is protected - encryption, access controls, signed Business Associate Agreements. There is no such thing as a "HIPAA-certified website" or a builder that is "HIPAA compliant out of the box." Compliance is a system of safeguards and contracts, not a product feature. That is covered in HIPAA website requirements.Accessibility is about whether a disabled patient can use your site at all. You can have a perfectly HIPAA-secure patient portal that a blind patient cannot log into. You can have a beautifully accessible site that leaks PHI. A real healthcare build handles both, separately and correctly. Neither one is optional, and neither one substitutes for the other.
Case Studies: Prime Home Health and Korawells
Prime Home Health is a home-care clinic in Winnipeg operating under Manitoba's Personal Health Information Act (PHIA). They came to me effectively invisible on Google.
I rebuilt the site as custom code - accessible, fast, and compliant - and paired it with an SEO retainer. Inside about 30 days, the results were measurable in Google Search Console:| Metric | Before | After |
|---|---|---|
| Organic clicks / month | ~4 | 194 |
| Search impressions / month | 433 | 11,400 |
| Indexable pages | under 50 | 303 |
| Terms ranked Page 1 (1,000+ searches/mo) | 0 | 13 |
| New patient inquiries (30 days) | 0 | 20 |
| Figure | Amount |
|---|---|
| Avg revenue / client / month (industry benchmark) | $2,070 |
| Projected monthly revenue (10 new clients) | ~$20,700 |
| Projected first-year value (before renewals) | ~$248,400 |
The same code-level discipline that makes a site rank is the discipline that makes it accessible. They are not separate efforts. They come from building it right the first time.
The Korawells wellness clinic is the other side of that coin. It was built to WCAG 2.1 AA from the ground up: proper heading hierarchy for screen readers, color contrast of at least 4.5:1 for body text, full keyboard navigation, clearly visible focus indicators, and alt text on every image. None of it came from a paste-in overlay. The result was a site that earned international design awards for UI, UX, and innovation, proving that code-level accessibility and beautiful, high-converting design are the same project, not competing ones.
Transform your website into a revenue-generating asset
Partner with an award-winning web designer and web developer from the Philippines, delivering world-class websites to global brands. 15+ years of experience creating sites that convert visitors into customers.
Frequently Asked Questions
-
In almost all cases, yes. Under the ADA, Section 504, and Section 1557 in the US, and AODA in Ontario, patient-facing websites for healthcare providers are treated as covered services. The specific law and deadline that applies depends on your funding, size, and location, so confirm your obligations with an attorney. This is informational, not legal advice.
-
No. Overlays patch only a fraction of WCAG criteria, often interfere with the assistive technology patients already use, and have themselves been named in accessibility lawsuits. Real protection comes from code-level fixes, not a script you paste on top of a broken site.
-
The standard target is WCAG Level AA. Most current US regulations cite WCAG 2.1 AA, while WCAG 2.2 AA is the newer superset. I build to 2.2 AA, which automatically satisfies 2.1 AA, so you are covered either way.
-
No. HIPAA governs the privacy and security of patient data, while accessibility governs whether disabled patients can use your site. A site can satisfy one and fail the other completely. A proper healthcare build addresses both as separate requirements.
-
Only a portion. Automated scanners reliably catch issues like missing alt text and low contrast, but the majority of WCAG criteria - keyboard operability, focus order, meaningful labels, screen reader coherence - require manual testing by a human. A clean automated scan alone is not proof of compliance.
-
In the US, they range from private settlements and remediation costs from demand letters to the loss of federal funding such as Medicare and Medicaid under Section 504 and Section 1557. In Ontario, AODA penalties for corporations can reach up to 100,000 dollars per day for serious ongoing non-compliance. This is informational, not legal advice.
-
Sometimes, but it is often limited. Template builders and plugins generate code you cannot fully control, which caps how accessible the site can become. In many cases a custom rebuild costs less in the long run than fighting a platform that was never built for accessibility. Let's talk and I will tell you honestly which path fits.
-
The opposite. Accessible, semantic code is cleaner and faster, and the contrast and structure rules produce a clearer, more usable design for everyone. My builds win design awards and hit 95-100 Lighthouse scores while meeting AA standards. Good accessibility and good design are the same craft.
-
Book a discovery call and we will review your current site, your obligations, and your patient-facing components. You can book a discovery call and I will give you a straight assessment of where you stand and what it takes to fix it.