I portali dei pazienti escludono le persone con disabilità — un audit degli 8 principali portali EHR statunitensi

I portali per i pazienti sono la porta d’ingresso del moderno sistema sanitario statunitense, e quella porta è sbarrata per le persone che ne hanno più bisogno. Abbiamo sottoposto ad audit i portali rivolti ai pazienti degli otto fornitori di cartelle cliniche elettroniche (EHR) statunitensi che servono la quota maggiore di cliniche, ospedali e reti ambulatoriali — Epic MyChart, Oracle Health (ex Cerner), Allscripts, athenahealth, NextGen, eClinicalWorks, Practice Fusion e Greenway — rispetto a WCAG 2.1 Livello AA e alla norma finale dell’HHS Office for Civil Rights sulla Section 504 pubblicata il 9 maggio 2024 (89 FR 40066). Su circa 240 pagine di portale e cinque attività principali di cura, il tasso medio di conformità all’audit automatizzato è stato del 61 percento, il tasso mediano di completamento delle attività verificato manualmente per gli utenti di screen reader è stato del 54 percento e il portale con le prestazioni peggiori ha fallito tre dei cinque flussi principali in modo definitivo. La norma del maggio 2024 si applica a qualsiasi portale gestito da un beneficiario di assistenza finanziaria federale dell’HHS — il che, poiché Medicare e Medicaid toccano praticamente ogni clinica, ospedale e ambulatorio del paese, significa sostanzialmente ogni portale in questo dossier è in ambito.

01 · Come abbiamo sottoposto ad audit otto portali

L’audit ha coperto i portali rivolti ai pazienti gestiti dagli otto fornitori EHR statunitensi con la base installata più ampia, per numero combinato di ospedali e cliniche ambulatoriali: Epic MyChart, Oracle Health (l’ex portale per i pazienti di Cerner, rinominato dopo l’acquisizione Oracle del 2022), Allscripts FollowMyHealth, athenahealth athenaPatient, NextGen Patient Portal, eClinicalWorks healow, Practice Fusion Patient Fusion e Greenway Health MyHealthRecord. Insieme, questi fornitori ospitano l’esperienza del portale per i pazienti sostanzialmente di ogni clinica partecipante a Medicare e Medicaid del paese.

Per ogni portale abbiamo condotto due esercizi paralleli. Il primo è stato una scansione automatizzata WCAG 2.1 Livello AA su 30 pagine ad alto traffico per brand — pagina di atterraggio, accesso, dashboard, indice dei risultati di laboratorio, pagina del singolo risultato di laboratorio, elenco delle prescrizioni, flusso di rinnovo, elenco degli appuntamenti, prenotazione degli appuntamenti, lobby della visita video, visita video in corso, casella di posta dei messaggi, redazione del messaggio, pagina di caricamento documenti e un campione di pagine di contenuti educativi. Abbiamo utilizzato axe-core 4.10 in Chrome headless più Lighthouse 12, e registrato il tasso di superamento delle regole per pagina e il conteggio delle violazioni univoche per criterio di successo WCAG.

Il secondo è stato un test manuale di completamento delle attività su cinque flussi principali di cura. Ogni attività è stata tentata tre volte su ognuno dei tre stack di tecnologia assistiva — NVDA 2024.4 con Firefox 124, JAWS 2025 con Edge 124 e VoiceOver su iOS 17.4 con Safari — da un auditor familiare con ciascuno stack. Un’attività è stata considerata «completata» solo quando l’auditor ha raggiunto lo stato di successo senza intervento di una persona vedente in almeno due dei tre tentativi. Le cinque attività sono state scelte perché coprono ciò che i pazienti effettivamente fanno sui portali: visualizzare un risultato di laboratorio; rinnovare una prescrizione attiva; partecipare a una visita video programmata; caricare un documento o una fotografia in un thread di messaggi; e riprogrammare un appuntamento in presenza imminente.

02 · La classifica dei fornitori, in un grafico

Gli otto portali non hanno prestazioni uniformi. Due — Epic MyChart e athenaPatient — superano la soglia dell’audit automatizzato del 70 percento e completano quattro dei cinque flussi di attività manuali con la maggior parte degli stack. Tre si trovano nella fascia mediana. Tre — Practice Fusion, Greenway e NextGen — si trovano in fondo, con tassi di conformità automatizzati inferiori al 55 percento e almeno due flussi principali falliti ciascuno. Il pattern è coerente tra gli esercizi automatizzati e quelli manuali: i portali che ottengono buoni punteggi nelle scansioni ottengono buoni risultati anche nei test, e i portali che ottengono punteggi bassi nelle scansioni ottengono risultati ancora peggiori di quanto i soli dati di scansione lascerebbero prevedere.

La classifica utilizza deliberatamente il tasso di conformità automatizzata come variabile visibile perché è il numero più riproducibile nel dossier — un altro auditor che esegue axe-core 4.10 sulle stesse 30 pagine dovrebbe ottenere un risultato entro pochi punti percentuali dalle cifre precedenti. I tassi di completamento manuale delle attività sono più rumorosi (familiarità dell’auditor, deriva della versione della tecnologia assistiva, errori intermittenti lato server), ma correlano fortemente con la scansione automatizzata: un portale che fallisce il 40 percento delle regole automatizzate fallirà anche una quota sostanziale delle attività manuali, perché gli stessi problemi sottostanti (etichette mancanti sui controlli dei moduli, stati di caricamento non annunciati, trappole del focus nelle finestre modali) guidano entrambi.

Nessun portale nel dossier raggiunge l’80 percento. Il migliore degli otto fallisce comunque circa una regola WCAG 2.1 AA su cinque — e il peggiore ne fallisce più della metà.

03 · I cinque flussi principali di cura

Le percentuali di superamento delle regole automatizzate sono utili a livello di pagina, ma i pazienti non visitano i portali per leggere pagine — li visitano per completare attività. Le cinque attività seguenti coprono la maggior parte di ciò per cui i portali per i pazienti esistono, e ciascuna è stata testata manualmente su ciascuno dei tre stack di tecnologia assistiva per ciascuno degli otto portali.

La visualizzazione dei risultati di laboratorio è l’attività più completata perché è la più vicina al territorio dei documenti semplici — la pagina è una tabella, le celle della tabella contengono testo e la maggior parte dei portali fa almeno un lavoro adeguato di associazione programmatica delle intestazioni di riga con le celle dei dati. I fallimenti che si verificano sono concentrati nei filtri per intervallo di date che perdono il focus dopo l’invio, nei documenti dei risultati resi in PDF come immagini scansionate non accessibili e nei widget con grafici di tendenza che presentano informazioni solo visive senza un equivalente testuale. Il riferimento della norma Section 504 a WCAG SC 1.1.1 (contenuto non testuale), 1.3.1 (informazioni e relazioni) e 1.4.5 (immagini di testo) copre tutte e tre le modalità di fallimento.

Il rinnovo delle prescrizioni è strutturalmente più semplice di quanto sembri — è un modulo con alcuni pulsanti radio, un selettore di farmacia e un invio — eppure scende al 58 percento. Il fallimento dominante è costituito da etichette di modulo mancanti o programmaticamente errate sul selettore di farmacia e sul campo «orario di ritiro preferito», spesso combinate con una combobox costruita su misura che non implementa la semantica ARIA combobox. SC 1.3.1 (informazioni e relazioni), SC 3.3.2 (etichette o istruzioni) e SC 4.1.2 (nome, ruolo, valore) vengono ripetutamente citati nel registro delle violazioni.

Il caricamento di documenti — caricare una fotografia di una tessera assicurativa, una nota medica di un altro studio o una fotografia di una ferita in un thread di messaggi — è dove le metriche automatizzate e gli esiti manuali divergono di più. La maggior parte degli uploader dei portali utilizza un widget di drag-and-drop costruito su misura che è teoricamente operabile da tastiera ma non annuncia il proprio stato o avanzamento. Gli utenti di screen reader che riescono a richiamare il selettore di file spesso non riescono a capire se il caricamento è andato a buon fine, perché lo stato di successo viene reso come un toast visivo che non viene annunciato. SC 4.1.3 (messaggi di stato) e SC 2.1.1 (tastiera) sono le violazioni dominanti.

La riprogrammazione degli appuntamenti è a metà classifica con il 67 percento perché la maggior parte dei widget del calendario dei portali non è accessibile agli screen reader ma si recupera tramite una «vista elenco» alternativa che l’utente deve trovare. Dove la vista elenco è raggiungibile, l’attività riesce; dove è sepolta, nascosta dietro un toggle non annunciato o non disponibile su mobile, l’attività fallisce. Il fallimento riguarda la scopribilità, non la capacità principale.

La partecipazione a una visita video è l’attività con le prestazioni peggiori nel dossier — 33 percento di completamento, otto successi su ventiquattro tentativi. La sezione successiva è dedicata a essa.

04 · Visite video: la superficie più costantemente difettosa

Dei cinque flussi principali, la sequenza di accesso alla visita video è quella che sconfigge più costantemente gli utenti di tecnologia assistiva sul maggior numero di portali. Sette degli otto portali hanno fallito almeno uno stack di tecnologia assistiva sul flusso di accesso; tre hanno fallito tutti e tre. Le modalità di fallimento si concentrano in tre pattern ricorrenti:

• Il prompt di autorizzazione del dispositivo di pre-accesso. Quando un browser chiede all’utente di concedere l’accesso alla fotocamera e al microfono, il prompt è tipicamente una finestra di dialogo nativa del browser sul quale il portale non ha alcun controllo. Ma le pagine della lobby che precedono il prompt — «fai clic su Continua per testare la fotocamera» — sono spesso non accessibili: un tile di anteprima video senza equivalente testuale, un indicatore del volume del microfono senza valore programmatico, un pulsante di toggle dei sottotitoli che è raggiungibile da tastiera ma non annunciato come pulsante. Quattro degli otto portali falliscono in questo passaggio con almeno uno stack.
• La superficie in chiamata. La finestra della chiamata effettiva è dove sei degli otto portali falliscono SC 4.1.2 (nome, ruolo, valore) per i controlli di silenziamento, attivazione della fotocamera, alzata di mano e fine chiamata. I controlli costruiti su misura vengono resi come pulsanti senza etichetta; in due portali l’unico modo per silenziare è una scorciatoia da tastiera non documentata in nessun posto visibile a uno screen reader. I sottotitoli in diretta non sono abilitati per impostazione predefinita in nessuno degli otto portali, anche se SC 1.2.4 (sottotitoli, in diretta) è un criterio di Livello AA e la norma Section 504 lo nomina esplicitamente.
• Lo stato del focus post-chiamata. Quando una videochiamata termina, sei degli otto portali lasciano il focus da tastiera all’interno della modale della chiamata ora chiusa, producendo una trappola del focus da cui l’utente deve ricaricare la pagina per uscire. SC 2.1.2 (nessuna trappola da tastiera) e SC 2.4.3 (ordine di focus) sono i criteri pertinenti. Il comportamento è sufficientemente coerente tra i fornitori da suggerire un pattern di causa radice condivisa nel modo in cui il widget della visita video viene montato nel contenitore del portale.

Il linguaggio della norma è rilevante qui perché le visite video in telehealth non sono più una funzionalità periferica — sono una superficie di partecipazione primaria nei programmi coperti. Il CMS ha continuato a rimborsare il telehealth Medicare alla parità per tutto l’anno civile 2024 e ha segnalato una parità continuata per l’anno civile 2026 per la salute comportamentale e i servizi ambulatoriali qualificati. Quando il pagatore federale paga per le visite video e il responsabile federale dei diritti civili afferma che le visite video devono essere accessibili e utilizzabili da persone con disabilità a WCAG 2.1 AA, un portale la cui superficie di visita video fallisce sei degli otto criteri di successo WCAG 2.1 AA relativi al video è, in linea di principio, fuori dalla conformità.

05 · La norma Section 504, in ambito e fuori ambito

Il quadro giuridico per questo audit è la norma finale dell’HHS Office for Civil Rights sulla Section 504, pubblicata il 9 maggio 2024 all’89 FR 40066, codificata al 45 CFR Parte 84, Sottoparte I. È il provvedimento normativo federale sull’accessibilità in sanità più rilevante degli ultimi tre decenni. Tre caratteristiche della norma la rendono direttamente applicabile agli otto portali di questo dossier.

Primo, la norma si applica ai beneficiari di assistenza finanziaria federale dell’HHS. I Centers for Medicare and Medicaid Services erogano assistenza finanziaria federale tramite Medicare Parte A, Medicaid e il Children’s Health Insurance Program. Una clinica, un ospedale o un ambulatorio che fattura a Medicare o accetta Medicaid è un beneficiario. Sostanzialmente ogni ospedale per acuti di cure generali del paese partecipa a Medicare; sostanzialmente ogni studio di cure primarie che serve bambini partecipa a Medicaid o CHIP. L’effetto pratico della clausola di ambito è che la norma raggiunge l’operatore di ogni portale in questo dossier.

Secondo, la norma istituisce WCAG 2.1 Livello AA come standard tecnico federale. Non adotta WCAG 2.0, non adotta WCAG 2.2 e non adotta un vago standard di «accesso sostanzialmente equivalente». La denominazione di uno standard specifico, citabile, mantenuto esternamente con un vocabolario stabile dei criteri di successo è la caratteristica operativamente più importante della norma. Riduce anni di argomentazioni sulla «conformità sostanziale» nel contenzioso sull’accessibilità in sanità a un singolo numero.

Terzo, le scadenze di conformità della norma sono graduate per dimensione del beneficiario. I beneficiari con 15 o più dipendenti devono conformarsi entro l’11 maggio 2026 — cioè, all’interno della finestra di audit di questo dossier. I beneficiari più piccoli hanno tempo fino al 10 maggio 2027. Gli otto fornitori di portali in questo dossier non sono essi stessi beneficiari, ma i loro clienti lo sono, e l’obbligo del cliente si estende all’esperienza del portale: un ospedale che implementa un portale non conforme è esso stesso non conforme.

Anche ciò che la norma non fa è rilevante. Non vincola direttamente i fornitori EHR in quanto tali — i fornitori non sono beneficiari di assistenza finanziaria federale dell’HHS e la norma vincola i beneficiari. L’esposizione dei fornitori passa attraverso le richieste contrattuali dei loro clienti. Ma le richieste contrattuali stanno arrivando: qualsiasi grande sistema ospedaliero che firma un nuovo contratto MyChart, Oracle Health o athenahealth nel 2025-2026 sta inserendo il linguaggio WCAG 2.1 AA nell’accordo principale, perché l’alternativa è firmare un contratto che mette lo stesso ospedale in non conformità. I fornitori che si sono già preparati — Epic e athenahealth guidano nel dossier — si trovano in una posizione commerciale più forte rispetto a quelli che non lo hanno fatto.

La norma non preempt neppure il contenzioso privato. Una persona con disabilità che non riesce a completare una consultazione dei risultati di laboratorio su un portale vincolato dalla Section 504 ha ancora un’azione privata ai sensi dell’ADA Title III (per la superficie del luogo di pubblica sistemazione della clinica), ai sensi della Sezione 1557 dell’Affordable Care Act (per la superficie del programma sanitario finanziato federalmente) e ai sensi degli statuti statali sulla disabilità (Unruh Act della California, Legge sui diritti umani di New York e altri). La norma Section 504 aggiunge un requisito minimo normativo federale; non sostituisce i percorsi di contenzioso esistenti.

06 · Come appare un portale conforme

L’audit non è un quadro uniformemente cupo. Due degli otto portali — Epic MyChart e athenahealth athenaPatient — si avvicinano a una linea di base conforme sulla maggior parte delle superfici, e le lacune che hanno sono sostanzialmente correggibili nella finestra di conformità della norma. Tre degli otto — Allscripts FollowMyHealth, Oracle Health, eClinicalWorks healow — sono a portata di conformità con una correzione mirata. Tre — NextGen, Greenway, Practice Fusion — hanno sostanzialmente più lavoro da fare e, con la traiettoria attuale, non supereranno la scadenza del maggio 2026 senza un impegno che non hanno ancora visibilmente assunto.

I pattern che distinguono i portali conformi da quelli non conformi non sono particolarmente esotici. I controlli dei moduli hanno etichette visibili programmaticamente associate ai loro input. I widget costruiti su misura — combobox, selezionatori di date, uploader di file — implementano la semantica ARIA di cui hanno bisogno. I cambiamenti di stato vengono annunciati tramite regioni aria-live o nodi con ruolo di stato. L’ordine di focus corrisponde all’ordine di lettura. Le finestre modali intrappolano il focus mentre sono aperte e lo restituiscono correttamente alla chiusura. I sottotitoli in diretta sono attivi per impostazione predefinita nelle videochiamate e un obiettivo di tasso di errore delle parole pubblicato li sostiene. Nessuno di questo è lavoro nuovo — è la linea di base WCAG 2.1 AA che ogni fornitore di portali ha avuto dal 2018 per assorbire.

07 · Prospettive 2026

Tre fili definiscono l’anno a venire per l’accessibilità dei portali per i pazienti negli Stati Uniti.

• La scadenza del maggio 2026. I beneficiari con 15 o più dipendenti devono conformare i propri contenuti web e le applicazioni mobile a WCAG 2.1 Livello AA entro l’11 maggio 2026. Questo riguarda sostanzialmente ogni ospedale e ogni ambulatorio partecipante a Medicare di qualsiasi dimensione significativa del paese. L’OCR ha segnalato che l’applicazione post-scadenza seguirà, e il foro dei diritti delle persone con disabilità sta già preparando modelli di denuncia.
• Il ciclo contrattuale dei fornitori. I contratti EHR durano dai tre ai sette anni. I contratti stipulati nel 2025 e nel 2026 determineranno l’esperienza del portale per il resto del decennio, e gli ospedali che li firmano stanno inserendo il linguaggio WCAG 2.1 AA negli accordi principali. I fornitori che assorbono quel linguaggio senza rinegoziazione guadagneranno quote di mercato; i fornitori che resistono la perderanno.
• L’intersezione con la Sezione 1557. La Sezione 1557 dell’Affordable Care Act vieta in modo indipendente la discriminazione sulla base della disabilità da parte dei programmi sanitari finanziati federalmente. L’HHS ha emesso una norma finale aggiornata sulla Sezione 1557 nel maggio 2024 insieme alla norma Section 504 e le due operano in parallelo. Un portale che fallisce per motivi della Section 504 è anche esposto a denunce ai sensi della Sezione 1557, con i propri percorsi di applicazione e rimedi.

Il filo conduttore

I portali per i pazienti sono stati venduti al sistema sanitario statunitense come l’equivalente digitale dell’apertura più ampia delle porte della clinica — gli incentivi per l’uso significativo negli anni 2010 hanno spinto ogni studio partecipante a Medicare a metterne uno davanti ai propri pazienti, e i fornitori EHR hanno costruito l’infrastruttura che li ha consegnati. Ciò che l’audit mostra è che aprire le porte più ampiamente era una verità parziale: per i pazienti senza disabilità, le porte sono aperte. Per le persone con disabilità — coloro che usano screen reader, coloro che navigano da tastiera, coloro che dipendono da sottotitoli, ingrandimento o controllo vocale — le porte sono aperte circa la metà delle volte, in media, e sostanzialmente meno di quello nei tre portali in fondo al dossier.

La norma Section 504 del maggio 2024 è il singolo cambiamento più grande nella legge sull’accessibilità sanitaria degli ultimi tre decenni e ha impostato un orologio. L’orologio arriva al maggio 2026 per i grandi beneficiari e al maggio 2027 per quelli più piccoli. Gli otto portali in questo dossier hanno tra i dodici e i ventiquattro mesi per colmare il divario tra dove si trovano e dove la normativa federale ora richiede che siano. Due sono vicini. Tre sono a portata. Tre non lo sono. Per saperne di più da Disability World sul panorama della normativa sull’accessibilità statunitense, sui resoconti del 2026 e sullo standard federale Section 508 che informa la linea di base tecnica.