A guide for practice managers

The HHS web accessibility rule, and what your practice actually has to do

Most practices believe this rule is for hospitals. It is not. If you bill Medicare, you are almost certainly inside it, and there is a date.

Written for non-technical practice staff · Last reviewed September 2026 · Not legal advice

In 2024 the US Department of Health and Human Services finalised a rule under Section 504 of the Rehabilitation Act that, for the first time, sets a specific, measurable technical standard for the websites and mobile applications of the organisations it funds. Until then, "make your website accessible" was an obligation with no definition. Now it has one.

This page explains, in plain terms, who is covered, what the standard requires, when it takes effect, and what a small practice should do about it. It is written for the person who actually has to deal with this, usually a practice manager, not a lawyer or a developer.

Who the rule covers, and the part most practices get wrong

Section 504 applies to any programme or activity that receives federal financial assistance from HHS. Practices hear that phrase and reasonably assume it means grant-funded institutions: hospitals, community health centres, medical schools.

That is not how it is being read. Medicare Part B reimbursement alone is treated as triggering coverage, aligning Section 504 with the interpretation already applied under Section 1557 of the Affordable Care Act. Accepting Medicaid does the same.

Size does not exempt you. A two-dentist practice that accepts Medicare is inside the rule in exactly the same way a hospital system is. The only thing size changes is your deadline.

The deadlines

These dates were extended from the original schedule, which had the first deadline falling in May 2026. The extension moved the date; it did not change the obligation, and it did not narrow who is covered.

The runway sounds generous. In practice, remediating a site that was never built with accessibility in mind takes a few months of intermittent developer work, and the constraint is usually not the work itself but getting it into your web vendor's queue and budgeted for. Practices that start in the last quarter before a deadline pay more and have fewer options.

What WCAG 2.1 Level AA actually asks for

HHS adopted the Web Content Accessibility Guidelines (WCAG) version 2.1, Level A and Level AA. It is an international standard with roughly fifty testable criteria. Strip away the technical language and the great majority of real failures on practice websites fall into a handful of buckets:

Text people can actually read

Body text needs a contrast ratio of at least 4.5:1 against its background. Light grey on white, a near-universal design fashion, routinely fails. This is the single most common failure we find, and it matters disproportionately in healthcare because your patient population skews older and includes people with cataracts, glaucoma and diabetic retinopathy.

A site that works without a mouse

Every function must be reachable and operable with a keyboard alone, with a visible indicator showing where you are. Patients with tremor, limited hand mobility, or who use a screen reader navigate this way. Closed mobile menus that still trap keyboard focus are a very common failure.

Forms that announce what they want

Every field needs a programmatically associated label. A placeholder is not a label. It disappears as soon as someone types and is not reliably announced. On an appointment request form, an unlabelled field means a blind patient hears "edit text, blank" and has no way to know what to enter. They phone instead, or they go elsewhere.

Images that carry their meaning in text

Every meaningful image needs alternative text describing its purpose. Decorative images need explicitly empty alternative text so assistive technology skips them. Both matter: missing alt text hides information, and unnecessary alt text buries it in noise.

Content that survives being enlarged

Text must be resizable to 200% without loss of content or function, and the page must reflow at 320 pixels wide. Disabling pinch-zoom on mobile, still common in older site templates, is a direct failure and one of the most damaging in practice.

What counts as "your website"

Broader than most practices expect. The standard reaches:

• Your main practice website, every page of it
• Your patient portal, including the login screen
• Any mobile app you offer patients
• Documents you publish: new-patient packets, HIPAA notices, financial policies, insurance forms
• Embedded third-party tools: online scheduling, payment pages, chat widgets, mapped locations

Embedded third-party widgets deserve particular attention, because the responsibility does not transfer. If your scheduling vendor's booking tool is inaccessible, the patient who cannot book an appointment experienced that on your website. Ask each vendor for their current accessibility conformance report in writing. Some have one. The ones that do not will tell you something useful by how they answer.

How it gets enforced

There is no inspector who arrives to audit your website. Enforcement runs through the HHS Office for Civil Rights and is complaint-driven: a member of the public files a complaint, OCR investigates, and the usual outcome is a resolution agreement with remediation obligations and monitoring.

The practical implication is worth internalising. It only takes one person, a patient who could not complete your appointment form or an advocate testing sites in your area, for you to be in the process. And when OCR looks at a practice, what it weighs heavily is evidence of documented, ongoing effort. A practice that has a dated assessment, a remediation plan, and a record of fixes made is in a very different position from one that has nothing to show.

Four things practices get told that are wrong

"We installed an accessibility widget, so we're covered"

Overlay widgets (the little accessibility icon in the page corner) do not bring a site into conformance with WCAG, and they are not a defence in an OCR complaint. In January 2025 the Federal Trade Commission fined a leading overlay vendor $1 million over claims that its product made websites compliant. When we scan sites running an overlay, we typically still find dozens of failures, because the underlying code was never fixed. Disability advocacy organisations have campaigned against these products for years.

"Our web agency handles compliance"

Sometimes true, often not. Many practice web agencies build on templates that were never tested against WCAG, and a good number have not read this rule. It is a fair question to put to them directly, in writing: does our site conform to WCAG 2.1 Level AA, and can you show us the evidence? The answer is informative either way.

"We're too small for anyone to care"

Size affects your deadline and nothing else. Complaint-driven enforcement is, if anything, less predictable for small organisations, because it depends on one individual's experience rather than on regulatory attention.

"An automated scan proves we're compliant"

It does not, and any vendor who says otherwise is selling something that will not hold up. Automated testing reliably detects somewhere around a third of real WCAG issues. It is the fastest and cheapest way to find those, and it is genuinely valuable. But whether alt text is accurate, whether a form can be recovered from an error, whether a screen reader announcement makes sense: those need a human.

What to do, in order

1. Establish where you stand. Run an automated scan of your site against WCAG 2.1 A and AA. It takes minutes, costs little or nothing, and turns an abstract obligation into a specific list. Date it and keep it.
2. Fix the template-level failures first. Contrast, labels, button and link names, page language, frame titles. These live in shared templates, so one fix usually clears the same failure from every page at once. This is the highest-yield work by a wide margin.
3. Test the things automation cannot see. Unplug your mouse and try to book an appointment on your own site. Then try it at 200% zoom. Most practices can do this in an afternoon and it is consistently where the worst problems surface.
4. Deal with your documents. Convert scanned patient paperwork into real accessible documents, or replace it with accessible web forms. Start with new-patient packets.
5. Put the question to your third-party vendors in writing. Scheduling, payments, portal, chat. Keep their answers.
6. Re-scan periodically and keep the records. Sites regress every time content is added. A dated trail of continuing effort is the single most useful thing to have if a complaint is ever filed.