Patient portals fail disabled patients — an audit of the top 8 US EHR-linked portals

Patient portals are the front door of the modern US healthcare system, and that door is locked for the people who need it most. We audited the patient-facing portals of the eight US electronic-health-record vendors that serve the largest share of clinics, hospitals, and ambulatory networks — Epic MyChart, Oracle Health (formerly Cerner), Allscripts, athenahealth, NextGen, eClinicalWorks, Practice Fusion, and Greenway — against WCAG 2.1 Level AA and the HHS Office for Civil Rights’ Section 504 final rule published on 9 May 2024 (89 FR 40066). Across approx. 240 portal pages and five core care-flow tasks, the average automated-audit pass rate was 61 percent, the median manually verified task-completion rate for screen-reader users was 54 percent, and the worst-performing portal failed three of the five core flows outright. The May 2024 rule applies to any portal operated by a recipient of HHS federal financial assistance — which, because Medicare and Medicaid touch effectively every clinic, hospital, and ambulatory practice in the country, means substantially every portal in this dossier is in scope.

01 · How we audited eight portals

The audit covered the patient-facing portals operated by the eight US EHR vendors with the largest installed base, by hospital and ambulatory clinic count combined: Epic MyChart, Oracle Health (the former Cerner patient portal, rebranded after the 2022 Oracle acquisition), Allscripts FollowMyHealth, athenahealth athenaPatient, NextGen Patient Portal, eClinicalWorks healow, Practice Fusion Patient Fusion, and Greenway Health MyHealthRecord. Together these vendors host the patient-portal experience for substantially every Medicare- and Medicaid-participating clinic in the country.

For each portal we ran two parallel exercises. The first was an automated WCAG 2.1 Level AA scan across 30 high-traffic pages per brand — landing page, sign-in, dashboard, lab-results index, individual lab-result page, prescription list, refill flow, appointment list, appointment booking, video-visit lobby, video-visit in-call, messaging inbox, message composer, document-upload page, and a sample of educational content pages. We used axe-core 4.10 in headless Chrome plus Lighthouse 12, and recorded the rule-pass rate per page and the count of unique violations per WCAG success criterion.

The second was a manual task-completion test against five core care flows. Each task was attempted three times on each of three assistive-tech stacks — NVDA 2024.4 with Firefox 124, JAWS 2025 with Edge 124, and VoiceOver on iOS 17.4 with Safari — by an auditor familiar with each stack. A task counted as “completed” only when the auditor reached the success state without sighted intervention in at least two of three attempts. The five tasks were chosen because they cover what patients actually do on portals: view a lab result; refill an active prescription; join a scheduled video visit; upload a document or photograph to a message thread; and reschedule an upcoming in-person appointment.

02 · The firm ranking, in one chart

The eight portals do not perform equally. Two — Epic MyChart and athenaPatient — clear the 70-percent automated-audit threshold and complete four of five manual task flows under most stacks. Three sit in the middle of the band. Three — Practice Fusion, Greenway, and NextGen — sit at the bottom, with automated pass rates under 55 percent and at least two failed core flows each. The pattern is consistent across the automated and the manual exercises: the portals that scan well also test well, and the portals that scan badly test even worse than the scan numbers alone would predict.

The ranking deliberately uses automated pass rate as the visible variable because it is the most reproducible number in the dossier — another auditor running axe-core 4.10 against the same 30 pages should land within a few percentage points of the figures above. The manual task-completion rates are noisier (auditor familiarity, AT version drift, intermittent server-side errors), but they correlate strongly with the automated scan: a portal that fails 40 percent of automated rules will fail a substantial share of manual tasks too, because the same underlying issues (missing labels on form controls, unannounced loading states, focus traps in modal dialogs) drive both.

No portal in the dossier hits 80 percent. The best of the eight still fails roughly one in five WCAG 2.1 AA rules — and the worst fails more than half.

03 · The five core care flows

Automated rule-pass percentages are useful at the page level, but patients do not visit portals to read pages — they visit to complete tasks. The five tasks below cover the bulk of what patient portals exist to do, and each was tested manually against each of the three assistive-tech stacks for each of the eight portals.

Lab-result viewing is the most-completed task because it is the closest to plain-document territory — the page is a table, the table cells contain text, and most portals do at least an adequate job of programmatically associating the row headers with the data cells. The failures that do occur are concentrated in date-range filters that lose focus after submission, in PDF-rendered result documents that ship as inaccessible scanned images, and in trend-graph widgets that present visual-only information with no equivalent text alternative. The Section 504 rule’s reference to WCAG SC 1.1.1 (non-text content), 1.3.1 (info and relationships) and 1.4.5 (images of text) covers all three failure modes.

Prescription refill is structurally simpler than it appears — it is a form with a few radio buttons, a pharmacy selector, and a submit — and yet it falls to 58 percent. The dominant failure is missing or programmatically incorrect form labels on the pharmacy selector and the “preferred pickup time” field, often combined with a custom-built combobox that does not implement ARIA combobox semantics. SC 1.3.1 (info and relationships), SC 3.3.2 (labels or instructions) and SC 4.1.2 (name, role, value) are repeatedly cited in the violation log.

Document upload — uploading a photograph of an insurance card, a doctor’s note from another practice, or a wound photo to a message thread — is where automated metrics and manual outcomes diverge the most. Most portals’ uploaders use a custom drag-and-drop widget that is keyboard-operable in principle but does not announce its state or progress. Screen-reader users who manage to invoke the file picker often cannot tell whether the upload succeeded, because the success state is rendered as a visual toast that is not announced. SC 4.1.3 (status messages) and SC 2.1.1 (keyboard) are the dominant violations.

Appointment rescheduling is mid-table at 67 percent because most portals’ calendar widgets are inaccessible to screen readers but recover via a “list view” alternative the user has to find. Where the list view is reachable, the task succeeds; where it is buried, hidden behind a toggle that is not announced, or unavailable on mobile, the task fails. The failure is one of discoverability, not core capability.

Video-visit joining is the worst-performing task in the dossier — 33 percent completion, eight successes out of twenty-four attempts. The next section is dedicated to it.

04 · Video visits: the most consistently broken surface

Of the five core flows, the video-visit join sequence is the one that most consistently defeats assistive-tech users on the most portals. Seven of the eight portals failed at least one assistive-tech stack on the join flow; three failed all three. The failure modes cluster into three recurring patterns:

• The pre-join device-permission prompt. When a browser asks the user to grant camera and microphone access, the prompt is typically a native browser dialog over which the portal has no control. But the lobby pages that precede the prompt — “click Continue to test your camera” — are frequently inaccessible: a video preview tile with no text equivalent, a microphone-volume indicator with no programmatic value, a captions-toggle button that is keyboard-focusable but not announced as a button. Four of the eight portals fail at this step under at least one stack.
• The in-call surface. The actual call window is where six of eight portals fail SC 4.1.2 (name, role, value) for the mute, camera-on, hand-raise, and end-call controls. Custom-built controls render as unlabelled buttons; in two portals the only way to mute is a keyboard shortcut documented nowhere visible to a screen reader. Live captions are not enabled by default in any of the eight portals, even though SC 1.2.4 (captions, live) is a Level AA criterion and the Section 504 rule names it explicitly.
• The post-call focus state. When a video call ends, six of the eight portals leave keyboard focus inside the now-dismissed call modal, producing a focus trap from which the user has to refresh the page to escape. SC 2.1.2 (no keyboard trap) and SC 2.4.3 (focus order) are the relevant criteria. The behaviour is consistent enough across vendors that it suggests a shared root-cause pattern in how the video-visit widget is mounted into the portal shell.

The rule’s language matters here because telehealth video visits are not a peripheral feature any more — they are a primary participation surface in covered programmes. CMS continued to reimburse Medicare telehealth at parity through CY2024 and signalled continued parity through CY2026 for behavioural health and qualifying ambulatory services. When the federal payer pays for video visits and the federal civil-rights enforcer says video visits must be accessible to and usable by disabled individuals at WCAG 2.1 AA, a portal whose video-visit surface fails six of the eight named WCAG 2.1 AA video-related success criteria is, on its face, out of compliance.

05 · The Section 504 rule, in scope and out

The legal frame for this audit is the HHS Office for Civil Rights’ Section 504 final rule, published 9 May 2024 at 89 FR 40066, codified at 45 CFR Part 84, Subpart I. It is the most consequential federal accessibility rulemaking in healthcare in three decades. Three features of the rule make it directly applicable to the eight portals in this dossier.

First, the rule applies to recipients of HHS federal financial assistance. The Centers for Medicare and Medicaid Services administers federal financial assistance through Medicare Part A, Medicaid, and the Children’s Health Insurance Program. A clinic, hospital, or ambulatory practice that bills Medicare or accepts Medicaid is a recipient. Substantially every general acute-care hospital in the country participates in Medicare; substantially every primary-care practice that serves children participates in Medicaid or CHIP. The practical effect of the scope clause is that the rule reaches the operator of every portal in this dossier.

Second, the rule installs WCAG 2.1 Level AA as the federal technical standard. It does not adopt WCAG 2.0, it does not adopt WCAG 2.2, and it does not adopt a vague “substantially equivalent access” standard. The naming of a specific, citable, externally maintained standard with a stable success-criterion vocabulary is the rule’s most operationally important feature. It collapses years of “substantial conformance” arguments in healthcare-accessibility litigation into a single number.

Third, the rule’s compliance deadlines are staged by recipient size. Recipients with 15 or more employees must conform by 11 May 2026 — that is, within the audit window of this dossier. Smaller recipients have until 10 May 2027. The eight portal vendors in this dossier are themselves not recipients, but their customers are, and the customer’s obligation runs through to the portal experience: a hospital that deploys a non-compliant portal is itself non-compliant.

What the rule does not do is matter too. It does not directly bind the EHR vendors as such — the vendors are not recipients of HHS federal financial assistance, and the rule binds recipients. The vendors’ exposure runs through their customers’ contractual demands. But the contractual demands are coming: any large hospital system signing a new MyChart, Oracle Health, or athenahealth contract in 2025–2026 is putting WCAG 2.1 AA language into the master agreement, because the alternative is signing a contract that puts the hospital itself in non-compliance. The vendors who have already prepared — Epic and athenahealth lead in the dossier — are in a stronger commercial position than the vendors who have not.

The rule also does not preempt private litigation. A disabled patient who cannot complete a lab-result lookup on a Section-504-bound portal still has a private cause of action under the ADA’s Title III (for the clinic’s place-of-public-accommodation surface), under Section 1557 of the Affordable Care Act (for the federally funded health programme surface), and under state disability statutes (California’s Unruh Act, New York’s Human Rights Law, and others). The Section 504 rule adds a federal regulatory floor; it does not replace the existing litigation pathways.

06 · What a compliant portal looks like

The audit is not a uniformly grim picture. Two of the eight portals — Epic MyChart and athenahealth athenaPatient — come close to a compliant baseline on most surfaces, and the gaps they have are substantially fixable in the rule’s compliance window. Three of the eight — Allscripts FollowMyHealth, Oracle Health, eClinicalWorks healow — are in striking distance of compliance with focused remediation. Three — NextGen, Greenway, Practice Fusion — have substantially more work to do, and on current trajectory will not clear the May 2026 deadline without commitment they have not yet visibly made.

The patterns that distinguish the compliant from the non-compliant portals are not particularly exotic. Form controls have visible labels that are programmatically associated with their inputs. Custom-built widgets — comboboxes, date pickers, file uploaders — implement the ARIA semantics they need. Status changes are announced via aria-live regions or status-role nodes. Focus order matches reading order. Modal dialogs trap focus while open and return it correctly when closed. Live captions are on by default in video calls, and a published word-error rate target sits behind them. None of this is novel work — it is the WCAG 2.1 AA baseline that every portal vendor has had since 2018 to absorb.

07 · 2026 outlook

Three threads define the year ahead for patient-portal accessibility in the US.

• The May 2026 deadline. Recipients with 15 or more employees must conform their web content and mobile applications to WCAG 2.1 Level AA by 11 May 2026. This is substantially every hospital and every Medicare-participating ambulatory practice of any meaningful size in the country. The OCR has signalled that post-deadline enforcement will follow, and the disability-rights bar is already preparing complaint templates.
• The vendor contractual cycle. EHR contracts run on three-to-seven-year cycles. The contracts being signed in 2025 and 2026 will determine the portal experience for the rest of the decade, and the hospitals signing them are putting WCAG 2.1 AA language into the master agreements. Vendors that absorb that language without renegotiation will gain share; vendors that resist it will lose share.
• The intersection with Section 1557. Section 1557 of the Affordable Care Act independently prohibits discrimination on the basis of disability by federally funded health programmes. HHS issued an updated Section 1557 final rule in May 2024 alongside the Section 504 rule, and the two operate in parallel. A portal that fails on Section 504 grounds is also exposed to Section 1557 complaints, with their own enforcement pathways and remedies.

The through line

Patient portals were sold to the US healthcare system as the digital equivalent of opening the clinic doors wider — meaningful-use incentives in the 2010s pushed every Medicare-participating practice to put one in front of its patients, and the EHR vendors built the infrastructure that delivered them. What the audit shows is that opening the doors wider was a partial truth: for non-disabled patients, the doors are open. For disabled patients — those who use screen readers, those who navigate by keyboard, those who depend on captions or magnification or voice control — the doors are open about half the time, on average, and substantially less than that on the bottom three portals in the dossier.

The May 2024 Section 504 rule is the largest single shift in healthcare-accessibility law in three decades, and it has set a clock. The clock runs to May 2026 for large recipients and to May 2027 for smaller ones. The eight portals in this dossier have between twelve and twenty-four months to close the gap between where they are and where federal regulation now requires them to be. Two are close. Three are within reach. Three are not. Read more from Disability World on the US accessibility-law landscape, on the 2026 reporting record, and on the federal Section 508 standard that informs the technical baseline.