Who is responsible for patient portal accessibility

The short answer is that the portal is yours. Not because of a general principle about who bears regulatory risk, but because of the specific words the rule uses to describe what it covers.

The clause that puts your vendor’s product inside your obligation

The web and mobile accessibility requirements sit in 45 CFR part 84, subpart I — the HHS rule implementing section 504 of the Rehabilitation Act, which is the rule Section 1557 reaches disability discrimination through. Section 84.84(b)(1) requires a recipient to ensure that the web content and mobile apps it “provides or makes available, directly or through contractual, licensing, or other arrangements” comply with the Level A and Level AA success criteria of WCAG 2.1.

A portal licensed from an EHR vendor is made available through a licensing arrangement. That is not an interpretation — it is the phrase in the rule, and it is there precisely because most covered web content is not written by the covered entity. The obligation attaches to the practice that puts the portal in front of patients, not to the company that built it.

The exception practices reach for, and why it closes on them

There is a third-party content exception, and it is the first thing a practice finds when it goes looking. Section 84.85(c) excepts “content posted by a third party” — “unless the third party is posting due to contractual, licensing, or other arrangements with the recipient.”

Read the second half before relying on the first. The exception exists for content you did not invite and do not control — a comment left on your page, a review posted by a patient. A vendor you signed a contract with is the exact case the clause carves back out. The exception that looks like it solves the portal problem is written to make sure it does not.

What genuinely does sit outside the requirement

Here is the part that runs the other way, and practices tend not to know it. Section 84.85(d) excepts conventional electronic documents that are both (1) about a specific individual, their property, or their account, and (2) password-protected or otherwise secured.

Both conditions have to hold. Applied to a portal, that draws a line worth drawing carefully:

• An individual patient’s lab result, after-visit summary or billing statement, sitting behind that patient’s login — about a specific individual and secured. Excepted.
• The portal itself — the login screen, the navigation, secure messaging, appointment booking, the forms patients fill in. None of that is a document about one individual. Fully in scope, and it is where patients spend their time.
• A blank intake form or financial policy posted for anyone to download, even from inside the portal. Not about a specific individual. In scope.

So the exception is real, and it removes what would otherwise be an impossible volume of per-patient documents. It removes none of the interface that delivers them. A practice that hears “patient documents are excepted” and concludes the portal is handled has inverted the rule.

One neighbouring trap, from 84.85(b): documents that were already on your site before your compliance date are excepted unless they are currently used to apply for, gain access to, or participate in your programs or activities. An intake form from 2019 that patients still fill in today is not old enough to be out. Age is not what the exception turns on — use is.

The two flexibilities, and what they are not

Two provisions get quoted as escape hatches and neither is one.

Section 84.86(a) permits conforming alternate versions of web content “only where it is not possible to make web content directly accessible due to technical or legal limitations.” A separate accessible version of a page is a last resort with a stated precondition, not a design choice you can make because remediation is inconvenient.

Section 84.87 allows alternative designs, methods or techniques where they “result in substantially equivalent or greater accessibility and usability”. That is a genuine allowance and it is worth knowing about — but note it demands usability as well as accessibility, and it is a substantive equivalence test you would have to be able to demonstrate. It is not a lower bar; it is the same bar reached another way.

So who can actually do the work

This is where the honest answer splits in two, and it is the reason the question is hard to search for.

The portal’s own code can generally only be changed by the vendor who writes it. No outside firm can re-engineer a licensed EHR portal on your behalf. Anyone quoting to “remediate your patient portal” without naming the vendor and a mechanism is either pricing work they are not in a position to perform, or quietly excluding the portal and leaving you to assume otherwise.

What an outside party can genuinely deliver against a portal is:

• Testing — the portal, as your patients actually meet it, against WCAG 2.1 Levels A and AA.
• A dated, attributable record of what conformed and what did not. If you are ever asked to show compliance, this is the responsive artefact — and it is also the document that makes a vendor conversation concrete rather than aspirational.
• Remediation of what you do control — the public site, the documents you upload, the forms you author, the content in the templates.
• The vendor conversation, started early enough to matter. Your portal roadmap is not yours to set. A practice raising this three months before its deadline finds that out at the worst possible time.

What to ask your portal vendor, in writing

Four questions, and they should be answered in writing rather than on a call. Does the portal conform to WCAG 2.1 Levels A and AA today, and if not, where does it not? Against what version of the guidelines was that assessed, and on what date? What is the committed date for conformance, measured against our compliance deadline rather than your product roadmap? And which parts of the surface do you consider ours rather than yours — the templates, the uploaded documents, the configured content?

That last one is where practices get caught. The division of responsibility between a practice and its portal vendor is rarely written down anywhere until someone asks.

Dates, so you can scope this against something

HHS extended the compliance dates by interim final rule effective 7 May 2026. They are now 11 May 2027 for recipients with 15 or more employees and 10 May 2028 below that threshold. The requirement itself was not softened — HHS scored the extension as giving up more benefit than it saved in cost, which is not what a department preparing to withdraw a rule does. Where those dates live in the regulations, and who is covered is worth knowing before you take any of this to counsel.

Where CivicBinder Health fits

The binder tests the website, the patient portal and the patient-facing documents against WCAG 2.1 Levels A and AA, records what was tested and what was found, and gives remediation instructions written for the templates and documents you actually have — dated and attributable, so the work is evidenced rather than asserted. For the portal specifically, that record is what you take to your vendor.

Flat fees: $299 for a single practice site, $499 covering website, portal and documents, and $19/month for ongoing monitoring. Request a free scan to see where you stand — public surfaces only, no patient data.

If you are still choosing who does this work, what four healthcare accessibility vendors publish as prices sets out the per-page, per-month and flat units side by side — including which of them scope the portal at all.

The text of 45 CFR 84.84, 84.85, 84.86 and 84.87 was verified on 31 July 2026 against the codified regulation as of the 1 July 2026 edition, retrieved through the eCFR versioner API. The compliance dates were verified the same day against the published text of the interim final rule (91 FR, doc. 2026-09266). Nothing here is legal advice.