GSA Schedule
NASPO ValuePoint
SBA VOSB
ATA Certified Vendors
SAM Registered
Healthcare

Section 504 Digital Accessibility for Healthcare: Websites, Patient Portals, and the Vendor Tools You Don't Control

If you are the compliance officer at a hospital, community health center, or multi-site clinic group, there is a good chance the Section 504 deadline written into your remediation plan is wrong — and wrong in the direction that makes people relax, which is the dangerous direction.

Most of the guidance still circulating on Section 504 healthcare digital accessibility was written in late 2025 or early 2026, and it cites a compliance date of May 11, 2026 for larger recipients. HHS extended that date by a year in a May 2026 interim final rule. So if your plan says the deadline already passed, you are working from stale analysis. And if your plan says "we have time now," you are making the more expensive mistake: the extension moved the WCAG conformance date. It did not move Section 504's underlying duty not to discriminate, which has applied to every recipient of federal financial assistance for decades and applies today.

Quick answer: Under 45 CFR 84.84, healthcare organizations that receive federal financial assistance from HHS must make their web content and mobile applications conform to WCAG 2.1 Level A and Level AA. The compliance date is May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for recipients with fewer than 15 — both extended by one year in a May 2026 HHS interim final rule. The requirement covers digital properties provided directly or through contractual arrangements, so patient portals, scheduling tools, bill-pay, and telehealth platforms built by vendors are in scope. Only four narrow exceptions exist, at 45 CFR 84.85, and the largest of them does not cover documents currently used to apply for or participate in your programs. Section 504's general nondiscrimination and effective-communication obligations apply now, independent of the conformance date.

What the Extension Changed — and What It Didn't

The substantive rule lives at 45 CFR Part 84, Subpart I. Section 84.84 requires recipients to ensure that web content and mobile apps are readily accessible to and usable by individuals with disabilities, and it adopts WCAG 2.1 Level A and Level AA success criteria as the measure. Note the level carefully: this is Level A and AA together, not AA alone, which is how the requirement is frequently paraphrased.

The May 2026 interim final rule amended the compliance dates and nothing else of substance. HHS's stated reason was that a significant number of recipients — community health centers, hospitals large and small, primary care centers — would not be able to meet the original dates.

RecipientOriginal dateCurrent date
15 or more employeesMay 11, 2026May 11, 2027
Fewer than 15 employeesMay 10, 2027May 10, 2028

What did not change is worth listing plainly, because this is where organizations talk themselves into a year of inaction:

The extension is a scheduling change, not a permission slip. The window it bought you is the time to do the work in an orderly way instead of a panicked one — which is exactly what HHS said it was for.

The Part That Catches People: Content You Didn't Build

Section 84.84 reaches web content and mobile apps provided directly or through contractual arrangements. For a health system, that phrase is the whole ballgame. Very little of what a patient actually touches is built in-house.

Walk the path a patient takes and count the vendors: the public website, the find-a-provider directory, the online scheduling widget, the pre-visit intake forms, the patient portal, the telehealth platform, the bill-pay page, the prescription refill flow, the check-in kiosk in the lobby. Kiosks get their own provision at 45 CFR 84.83. Most of the rest is licensed software wearing your logo.

The villain here is a sentence that sounds reasonable and isn't: that's the vendor's product, so it's the vendor's compliance problem. The regulation does not distribute liability that way. You are the recipient of federal financial assistance. You are the one with the obligation. A vendor can contractually promise conformance and can be held to it — but the complaint, and the HHS Office for Civil Rights correspondence that follows, arrives at your organization.

Which makes this a procurement problem before it is a remediation problem. Ask for a current Accessibility Conformance Report, read it rather than filing it, and put conformance and remediation timelines into the contract itself. Our walkthrough of what a VPAT and ACR actually tell you covers how to read one critically, including what a vendor's "supports with exceptions" really means.

Not sure which of your patient-facing properties would pass? Our team audits hospital websites, portals, and vendor-supplied tools against WCAG 2.1 A and AA — and you can start free, right now, on your published documents.

Run the free PDF accessibility checker →

The Four Exceptions at 45 CFR 84.85 — and Why Your Content Probably Isn't in Them

The rule provides exactly four exceptions. They are narrower than most people assume, and two of them collapse on a close reading:

  1. Archived web content. Content that meets the rule's definition of archived — kept for reference or recordkeeping, not altered since archiving, and stored in a designated archival area. A page is not archived because it is old and nobody maintains it.
  2. Preexisting conventional electronic documents. Documents already posted before your compliance date — unless they are currently used to apply for, gain access to, or participate in your programs or activities. That clause is the trap. Your financial-assistance application, new-patient intake packet, notice of privacy practices, sliding-fee schedule, and consent forms are all currently used to access care. They come straight back into scope no matter how long they have been on the site.
  3. Content posted by a third party — unless the third party is posting because of a contractual, licensing, or other arrangement with you. Patient comments on your social feed are third-party content. Your scheduling vendor's embedded widget is not; you contracted for it.
  4. Individualized, password-protected documents. Conventional electronic documents that are both about a specific individual, their property, or their account and password-protected or otherwise secured. This is the one most often overstated. An individual lab result PDF sitting behind portal authentication may qualify. The portal that delivers it — the login, the navigation, the message composer, the appointment list — is not a conventional electronic document and is not excepted. Putting content behind a login does not move your portal out of scope.

If you have read our breakdown of the five ADA Title II exceptions at 28 CFR 35.201, these will look familiar. The two frameworks are deliberately parallel, but they are not identical, and a hospital that is both a public entity and a federal-assistance recipient is measured against both. Do not assume an analysis done for one carries over to the other.

Subpart I also provides for conforming alternate versions (84.86), equivalent facilitation (84.87), and a provision addressing noncompliance that has a minimal impact on access (84.89). And 84.84 preserves the familiar defenses where compliance would result in a fundamental alteration or in undue financial and administrative burdens — a determination that has to be made and documented at a senior level, not assumed by a web team with a small budget.

Where Accessibility and Language Access Collide

This is the gap we see most often in health systems, and it is a direct consequence of two obligations landing on the same organization from two different directions.

Section 504 and the Part 84 rule govern disability access. Section 1557 and Title VI govern language access. Both attach to a provider that takes federal money, and the same document can fail both at once. A Spanish-language financial-assistance form that was translated well and exported flat — no tags, no reading order, no language attribute — satisfies neither. It is inaccessible to a Spanish-speaking patient using a screen reader, and it is arguably worse than the English original, because the remediation work done on the English version did not carry over.

That last point is the one to take to your web team: accessibility does not survive translation. Tagging, reading order, alt text, and table headers have to be applied per language, in the translated file, and a screen reader needs a correct language attribute to pronounce the content at all. Any vendor who hands back a translated PDF and calls the accessibility work done has given you a compliance liability in two regulatory regimes simultaneously. Our PDF remediation guide covers the document side, and what Section 1557 requires of a qualified interpreter covers the interpretation side.

A Three-Step Plan That Fits the Time You Have

  1. Inventory by access path, not by page count. Do not start with a crawler dumping 40,000 URLs. Start by writing down every digital step a patient must complete to get care and pay for it, and note who built each one. That list is short, it is the highest-risk content you own, and it is what a complaint will be about.
  2. Remediate the path first, worst-first — then the library. Fix scheduling, intake, the portal, and bill-pay before the newsroom. Include the documents in that path, in every language you publish them in, and re-test with an actual screen reader and keyboard rather than an automated scan alone. Automated tools catch a useful minority of WCAG failures; they do not catch reading order, focus traps, or whether a flow can actually be completed.
  3. Put conformance in the contract and keep it there. For every vendor in that path, require a current ACR, a remediation timeline with dates, and re-testing on each release. Then keep evidence — audit reports, tickets closed, dates — because documented good-faith progress is what distinguishes an organization working the problem from one that ignored it.

Get this wrong and the failure is not abstract. It is a blind patient who cannot refill a prescription without calling and waiting on hold, a deaf patient locked out of portal messaging, an OCR complaint that arrives with a records request, and a remediation bill that is far larger under deadline pressure than it would have been today. Get it right and the same properties simply work — for patients using screen readers, for patients on phones in waiting rooms, for patients reading in Spanish or Vietnamese or Somali — and you can show exactly when and how you did it.

Why Work With Taika

Language Access Hub, powered by Taika Translations, is a veteran-owned (VOSB), SAM-registered, GSA- and NASPO ValuePoint-contracted provider built for organizations that carry both obligations at once. We deliver ADA and Section 508 accessibility remediation — websites, documents, portals, and vendor-tool audits against WCAG 2.1 A and AA — alongside certified translation by ATA-certified linguists, interpretation, and captioning. For healthcare organizations that means one vendor who can make a patient-facing document both accurate in the patient's language and conformant in that language, on contract vehicles your procurement team already recognizes.

Find out where your patient-facing properties actually stand

We audit hospital websites, patient portals, and vendor-supplied tools against WCAG 2.1 Level A and AA, then deliver a prioritized remediation plan with evidence you can show OCR. GSA & NASPO contracts accepted.

Get a 504 Accessibility Assessment →

More from the blog

Healthcare
Section 1557: What Actually Counts as a Qualified Interpreter
Jason R. Ehlinger · August 11, 2026
Digital Accessibility
The Five ADA Title II Exceptions — and Why Your Old PDFs Probably Don't Qualify
Jason R. Ehlinger · September 7, 2026