Website Accessibility for Medical Practices: The Rule With a Date on It

Almost everything written about website accessibility for medical practices is about litigation: demand letters, serial filers, settlement figures. That coverage is not wrong, and it is a poor basis for planning, because the outcomes are genuinely unpredictable and the standard courts apply is contested.

There is a second track that gets far less attention and is much easier to act on. A federal rule names a specific technical standard, sets fixed dates, and reaches healthcare providers directly. If you want one thing to plan against, it is that rule rather than the case law.

Two tracks, and only one has a date

Title III of the Americans with Disabilities Act covers places of public accommodation, and the professional office of a health care provider is expressly within that category. What Title III does not do is state a technical standard for websites. The Department of Justice has published guidance on web accessibility and the ADA, but the statute itself predates the modern web, and courts have divided on how it applies to a website and by what measure.

That is why litigation is hard to plan against. The claim is available, the standard is argued case by case, and the economics favour settlement regardless of merit.

The economics deserve a sentence, because they explain the pattern better than the law does. Defending a website accessibility claim through to a ruling costs considerably more than settling one, and that ratio holds whether or not the site has real defects. The consequence is that outcomes correlate weakly with how accessible a site actually is, which is why practices trade stories about the topic that seem to contradict each other. Both stories are usually accurate.

What follows from that is worth stating plainly rather than as a scare: the litigation track is a poor motivator because you cannot schedule against it and cannot reliably avoid it through effort alone. The rule track is a good motivator because effort maps directly onto the outcome.

The difference in planning value is large. One track says a court may find your site inaccessible by a standard to be determined. The other names the standard, names the version, names the conformance level, and names the day.

Which rule on website accessibility for medical practices reaches you

This is where precision matters, and where a lot of vendor marketing overstates.

Section 504 applies to recipients of federal financial assistance. In the HHS context that includes hospitals, health systems, community health centres, state Medicaid agencies and providers participating in federal healthcare programmes. A practice billing Medicare or Medicaid should treat the question as live and get a real answer.

A genuinely cash-only practice taking no federal funds may fall outside it. That is a narrower category than it sounds, and it is worth confirming rather than assuming, because the analysis turns on programme participation rather than on how the practice describes itself. Notably, the same practices most likely to be outside Section 504 are often the ones squarely inside the state consumer health data statutes covered in consumer health data under state law, because both boundaries turn on the same fact and run in opposite directions.

Being outside the rule does not remove ADA Title III exposure, state accessibility law, or the plain fact that an inaccessible booking page loses patients who cannot use it. That last consideration is the one most likely to be underweighted, because it does not arrive as correspondence. A form a screen reader cannot complete is a booking that silently does not happen, and it appears in no report anywhere.

Why the standard is the same either way

The useful consequence of all this is that the two tracks converge on one technical target. WCAG 2.1 is a W3C Recommendation with testable success criteria, and Level AA is the conformance level that both the Section 504 rule and the overwhelming majority of settlement agreements reference.

So a practice does not need to resolve which regime governs before deciding what to do. The work is the same. What differs is the deadline and the consequence of missing it.

That also disposes of a common objection, which is that accessibility standards are subjective. WCAG success criteria are specific and mostly machine-checkable: contrast ratios are numbers, form fields either have programmatically associated labels or they do not, images either have text alternatives or they do not. Automated testing catches a meaningful share, and the remainder needs human judgment on a small number of criteria. Which failures actually turn up on practice sites is covered in the WCAG failures we find most.

What website accessibility for medical practices requires in practice

Four things, ordered by how much they change the outcome.

Test the pages patients convert on, not the homepage. This is the single most common measurement error and it produces falsely reassuring results. Our own engine made exactly this mistake on its first run against a real practice site: page discovery drained the blog sitemap first, seven of eight scanned pages were blog posts, and the consultation path was never opened. The site scored 93 out of 100 and grade A. After the discovery order was fixed to prioritise conversion paths, the same site scored 66 and grade C, with five real findings including an unlabelled reviews frame and a contrast failure on the consult path. A scan that skips the pages a patient converts on is not evidence of anything.

Fix the template, not the page. Practice sites are built from templates, so a contrast failure in a header or footer appears on every page. One token change frequently resolves hundreds of instances. Conversely a per-page fix on a templated defect is work that will be undone by the next theme update.

Do not install an overlay. The widget that promises to fix accessibility with one line of JavaScript does not, and it introduces its own problems. That argument is made properly in why accessibility overlays don't fix it.

Scan repeatedly rather than once. Accessibility is a property of the current rendered page, and practice sites change constantly through plugin updates, new campaign pages and content edits. A remediation done once and never rechecked describes a site that existed on the day it was checked, which is the same failure mode that affects tracking configuration.

We publish our own score for the same reason we recommend the above: consential.io scored 80 out of 100 on our own engine, driven by a site-wide contrast defect in a shared header and footer token. Naming that is more useful than claiming otherwise, and it illustrates the template point exactly. Scheduled scanning against the conversion path is what accessibility monitoring does, and the dated report is the artefact worth having when a deadline arrives.

One structural point connects this to everything else on this site. The reason a dated report matters is the same reason an append-only consent record matters: in both cases the useful artefact is evidence of what was true on a particular day, not a description of what the system is configured to do. A practice that can produce a series of dated scans showing findings identified and resolved is in a materially different position from one asserting that its site is accessible, and the difference costs nothing extra to produce if the scanning is scheduled rather than occasional. The same reasoning underlies how consent gating records decisions.

Finally, a note on sequencing for practices with a deadline. The instinct is to commission one large remediation project close to the date. The better shape is to fix the shared templates first, which resolves the bulk of instances immediately, then work the conversion path, then handle the long tail of individual pages. That ordering front-loads the instance count reduction and means an unfinished project still leaves you materially better off, which a page-by-page approach does not.