Les hôpitaux et les cliniques sont confrontés à des délais fédéraux stricts pour rendre leurs sites web conformes à la norme WCAG 2.1 AA en vertu de la règle finale de la Section 504 du HHS, la plupart des organisations devant se mettre en conformité d’ici mai 2026. La page web de santé moyenne contient 272 problèmes d’accessibilité — un nombre stupéfiant étant donné que plus de 1 adulte sur 4 aux États-Unis vit avec un handicap. Ce guide décompose le paysage juridique, les exigences spécifiques des WCAG, les points de défaillance courants et une feuille de route pratique pour la conformité.
Considérez ceci : la page web de santé moyenne contient 272 problèmes d’accessibilité — des champs de formulaire défectueux aux descriptions d’images manquantes. Dans le même temps, plus de 28 pour cent des adultes aux États-Unis vivent avec un certain type de handicap, selon le CDC. Lorsque ces deux réalités se rencontrent dans le système de prise de rendez-vous d’un hôpital ou dans un portail patient, les conséquences ne se limitent pas à une mauvaise expérience utilisateur. Elles constituent un obstacle aux soins. Et à partir de 2024, elles constituent également une violation fédérale des droits civils.
Pourquoi l’accessibilité numérique en santé est une question de droits civils
Les organisations de santé comprennent depuis longtemps leur obligation de fournir des installations physiquement accessibles — rampes, tables d’examen accessibles, etc. Mais pendant des années, le volet numérique de la santé a largement fonctionné sous un patchwork de jurisprudence et d’interprétations larges de textes existants. Cela a changé de manière décisive en 2024.
En mai 2024, le U.S. Department of Health and Human Services (HHS) a finalisé une mise à jour historique de la Section 504 du Rehabilitation Act — la première mise à jour spécifiquement numérique de la Section 504 en près de 50 ans. Pour la première fois, la règle fixe une norme technique explicite pour l’accessibilité numérique et un délai concret pour s’y conformer. La règle précise clairement que les sites web, les applications mobiles et même les bornes doivent respecter les normes d’accessibilité WCAG 2.1 Niveau AA. Les outils tiers — tels que les planificateurs de rendez-vous, les portails de paiement de factures et les plateformes de télésanté — doivent également s’y conformer.
À peu près au même moment, le Department of Justice a finalisé une règle parallèle en vertu du Title II de l’Americans with Disabilities Act, exigeant que les entités gouvernementales d’État et locales — y compris les hôpitaux publics et les départements de santé publique — respectent WCAG 2.1 Niveau AA pour le contenu web et les applications mobiles. L’effet pratique est que presque tous les types d’organisations de santé opérant aux États-Unis ont désormais une obligation explicite et exécutoire en matière d’accessibilité numérique.
Les enjeux sont élevés des deux côtés. Pour les patients, un site web inaccessible peut signifier manquer un rendez-vous de suivi sensible au temps, être incapable de lire des résultats de laboratoire ou ne pas réussir à rejoindre une session de télésanté. Pour les organisations, la non-conformité peut déclencher des plaintes, des enquêtes fédérales, la perte de financements Medicare et Medicaid, et des litiges au titre de l’ADA. L’Office for Civil Rights du HHS peut enquêter sur les plaintes — et peut mener un contrôle de conformité même en l’absence de plainte — et renvoyer les violations au Department of Justice si nécessaire. Il ne s’agit pas d’un risque théorique : la santé fait partie des cinq secteurs les plus ciblés par les poursuites liées à l’accessibilité web au titre de l’ADA.
Qui est concerné et quand
La règle de la Section 504 du HHS s’applique largement à toute organisation qui reçoit une aide financière fédérale administrée par le HHS. Il s’agit d’un filet très large. L’aide financière fédérale comprend Medicare Parts A, C et D ; Medicaid ; le Children's Health Insurance Program (CHIP) ; TANF ; HeadStart ; et le financement de la recherche clinique, parmi plus de 100 autres programmes du HHS. En pratique, cela couvre les hôpitaux, les cliniques de santé, les prestataires dentaires et de vision, les établissements de soins de longue durée, les prestataires de santé comportementale, les agences de soins à domicile, les plateformes de télésanté et les résidences-services.
Les délais de conformité sont liés à la taille de l’organisation. Les organisations comptant 15 employés ou plus doivent s’assurer que leurs plateformes web et mobiles sont conformes aux normes WCAG 2.1 AA d’ici le 11 mai 2026. Les entités plus petites — celles comptant moins de 15 employés — ont jusqu’au 10 mai 2027. Les organisations de santé gérées par l’État ou le comté qui remplissent les conditions d’entités publiques au titre du ADA Title II font face à un délai légèrement plus précoce, avec une conformité requise d’ici avril 2026 pour les juridictions plus importantes.
Pour les organisations qui se demandent si la conformité est réellement requise pour chaque point de contact numérique, la réponse est oui. Les exigences d’accessibilité de la règle s’appliquent au site web et aux applications mobiles d’une organisation de santé, y compris celles exploitées par des tiers pour le compte de l’organisation — comme les fournisseurs de dossiers médicaux électroniques et les plateformes de planification externes. Une organisation ne peut pas externaliser son obligation d’accessibilité en se retranchant derrière un contrat de fournisseur.
« Ce n’est pas seulement une question de site web principal. Les portails patients, les applications mobiles, les outils de planification en ligne, les plateformes de télésanté et les formulaires d’admission doivent tous être accessibles. Vous devez le vérifier, pas simplement faire confiance aux affirmations des fournisseurs. »
Il existe une poignée d’exceptions limitées. Le contenu web archivé, certains documents électroniques conventionnels préexistants et les publications préexistantes sur les réseaux sociaux ne sont pas tenus de respecter WCAG 2.1 AA. Cependant, ces exceptions sont étroites et spécifiques — elles ne fournissent pas une exemption générale pour les anciens PDF ou le contenu hérité qui reste activement utilisé et n’est pas clairement archivé.
Ce que WCAG 2.1 AA exige réellement
WCAG signifie Web Content Accessibility Guidelines, publiées et maintenues par le World Wide Web Consortium (W3C). WCAG 2.1 Niveau AA est organisé autour de quatre principes fondamentaux, souvent désignés par l’acronyme POUR :
- Perceivable : L’information doit être présentée de manière à pouvoir être perçue par les utilisateurs — par exemple, avec des alternatives textuelles pour les images et des sous-titres pour les vidéos. Le contenu ne peut pas reposer sur un seul canal sensoriel.
- Operable : La navigation et les composants de l’interface utilisateur doivent être utilisables par des personnes ayant différents modes d’entrée — navigation au clavier, commande vocale, dispositifs à contacteurs, etc. Aucune fonctionnalité ne doit exiger l’utilisation d’une souris.
- Understandable : Le contenu et les interactions doivent être clairs et prévisibles afin d’éviter la confusion et la surcharge cognitive. Les messages d’erreur doivent expliquer ce qui s’est mal passé et comment y remédier.
- Robust : Le contenu numérique doit être compatible avec les technologies actuelles et émergentes, y compris les lecteurs d’écran et autres outils d’assistance. Il s’agit fondamentalement de code propre et sémantique.
Pour les sites web de santé, traduire ces principes en pratique signifie répondre à un ensemble spécifique d’exigences techniques. Voici ce que WCAG 2.1 AA exige dans les domaines les plus critiques pour le contexte de la santé :
Contraste des couleurs : Le texte de taille normale doit avoir un ratio de contraste d’au moins 4,5:1 par rapport à son arrière-plan. Le texte de grande taille (18pt ou 14pt en gras) nécessite un ratio de 3:1. Cela compte énormément dans le design en santé, où les marques privilégient souvent des palettes de couleurs douces et atténuées — gris clair sur blanc, ou texte bleu pâle — qui peuvent être totalement illisibles pour les patients malvoyants.
Accessibilité au clavier : Chaque fonction qu’un utilisateur peut effectuer avec une souris doit également être opérable uniquement au clavier. Prendre un rendez-vous, naviguer dans un menu déroulant, fermer une fenêtre modale et soumettre un formulaire doivent tous être réalisables via Tab, Entrée, les flèches et Échap. C’est essentiel pour les utilisateurs ayant des déficiences motrices et pour toute personne utilisant une technologie d’assistance.
Images et texte alternatif : Les images contenant des informations importantes doivent inclure un texte alternatif descriptif afin que les lecteurs d’écran puissent transmettre le contenu aux utilisateurs malvoyants. Cela va au-delà des images décoratives — cela inclut les photos des prestataires, les cartes des emplacements des cliniques, les schémas expliquant les procédures et les infographies sur les options de traitement.
Formulaires et gestion des erreurs : Les formulaires doivent inclure des champs correctement étiquetés, des instructions claires et des messages d’erreur accessibles pour garantir que les utilisateurs puissent accomplir avec succès les tâches liées aux soins de santé. Cela inclut les formulaires de demande de rendez-vous, les formulaires de contact, les champs de vérification d’assurance et — de manière critique — tout champ à l’intérieur du portail patient.
Vidéo et multimédia : Les vidéos de santé, les enregistrements de télésanté et les supports d’éducation des patients doivent inclure des sous-titres et des transcriptions pour les personnes malentendantes. Les sous-titres générés automatiquement ne suffisent pas à eux seuls ; ils doivent être précis et synchronisés.
Structure de page et navigation : Les sites web doivent utiliser du HTML sémantique, des titres appropriés et des structures de navigation logiques afin que les technologies d’assistance puissent interpréter correctement le contenu. Cela inclut la fourniture de liens de saut de navigation, une navigation cohérente d’une page à l’autre et des titres de page significatifs.
WCAG 2.1 a introduit plusieurs critères au-delà de la norme WCAG 2.0 antérieure qui sont particulièrement pertinents pour la santé. Ceux-ci incluent des exigences pour l’accessibilité mobile (orientation, finalité de la saisie), l’espacement du texte et le reflow — la capacité de consulter le contenu à des niveaux de zoom élevés sans défilement horizontal. Pour un secteur où de nombreux patients sont âgés et accèdent aux sites de santé sur des appareils mobiles avec un fort zoom, ces ajouts ont un poids clinique réel.
Les zones à plus haut risque sur les sites de santé
Toutes les défaillances d’accessibilité n’ont pas le même poids. En santé, certaines défaillances ne sont que gênantes ; d’autres entravent directement l’accès aux soins. Comprendre où se concentrent les risques aide les organisations à hiérarchiser intelligemment leurs efforts de remédiation.
Selon le AudioEye's 2025 Digital Accessibility Index, les sites de santé présentaient l’un des taux les plus élevés de formulaires et d’éléments de saisie inaccessibles — une moyenne de 21,5 par page — créant des obstacles pour les patients qui tentent de prendre des rendez-vous, d’accéder à des résultats d’examens ou de remplir des formulaires médicaux de manière autonome. La page de santé moyenne comptait également 5,4 liens inaccessibles, ce qui peut rendre plus difficile pour les personnes handicapées de trouver des ressources essentielles comme la prise de rendez-vous, les portails patients ou les coordonnées d’urgence.
Les portails patients sont la zone à plus haut risque. De nombreux portails patients échouent à des tests d’accessibilité de base — les patients ne peuvent pas accéder à leurs propres dossiers médicaux, résultats de laboratoire ou informations sur les prescriptions parce que l’interface ne fonctionne pas avec les technologies d’assistance. Une défaillance d’accessibilité qui empêche un patient d’accéder à ses propres dossiers de santé pourrait déclencher à la fois une plainte au titre de l’ADA et une enquête de l’OCR. Chaque parcours utilisateur critique au sein du portail — connexion, prise de rendez-vous, consultation des résultats, messagerie et gestion des prescriptions — doit être testé avec une navigation au clavier uniquement et des lecteurs d’écran.
Les documents PDF sont un problème chronique en santé. Les organisations partagent régulièrement des documents importants — formulaires de consentement, supports d’éducation des patients, informations sur l’assurance — sous forme de PDF inaccessibles. Les lecteurs d’écran ne peuvent pas analyser les PDF non balisés, ce qui les rend inutiles pour les patients aveugles. Les formulaires d’admission, les formulaires de consentement et les supports d’éducation des patients doivent soit être fournis sous forme de PDF correctement balisés, soit être proposés sous forme d’alternatives HTML accessibles.
Les parcours de prise de rendez-vous comptent parmi les expériences interactives les plus critiques sur tout site de santé. Si une étape d’un formulaire est inaccessible, un patient peut être incapable de prendre un rendez-vous ou de remplir un document requis — avec des conséquences directes sur sa capacité à recevoir des soins. C’est particulièrement vrai pour les patients plus âgés, malvoyants ou atteints de maladies chroniques, pour qui le site web est souvent la porte d’entrée de leur expérience de soins.
Les annuaires de prestataires et les localisateurs d’établissements reposent souvent sur des cartes intégrées et des interfaces de filtrage fortement basées sur JavaScript qui rompent fréquemment l’accessibilité au clavier et aux lecteurs d’écran. Un patient utilisant un lecteur d’écran qui ne peut pas trouver un prestataire de proximité dans son réseau fait face à un obstacle tangible aux soins, à la fois évitable et juridiquement contestable.
Les défaillances d’accessibilité courantes sur les sites de santé incluent également des sections de héros riches en images sans texte alternatif, des interfaces de portails patients qui rompent la compatibilité avec les lecteurs d’écran et des formulaires de prise de rendez-vous qui exigent une interaction à la souris. Il ne s’agit pas de cas marginaux — ce sont des schémas identifiés de manière constante dans des organisations de santé de toutes tailles.
Les conséquences juridiques et financières de la non-conformité
L’environnement de risque juridique pour l’accessibilité en santé s’est considérablement durci. En plus de l’application réglementaire par l’Office for Civil Rights du HHS, l’ADA crée des opportunités pour des plaignants privés d’intenter des actions individuelles. Les cabinets de plaignants ont industrialisé le processus de détection des violations — en utilisant des outils d’analyse automatisés pour identifier les défaillances WCAG à grande échelle, puis en intentant des poursuites devant les tribunaux fédéraux et d’État. Les organisations de santé ayant une empreinte numérique importante sont des cibles privilégiées.
L’application par le HHS peut aller au-delà des amendes. Les violations peuvent conduire le HHS à suspendre ou à mettre fin au financement fédéral de l’établissement — y compris les remboursements Medicare et Medicaid, ainsi que les subventions de recherche et de sensibilisation communautaire. Pour la plupart des systèmes de santé, la perspective d’une interruption des remboursements Medicare et Medicaid constitue un risque existentiel, non un coût gérable dans un poste budgétaire.
Il existe également une dynamique cumulative du côté des fournisseurs. Les organisations engagées dans des contrats gouvernementaux peuvent constater que la non-conformité entrave leur capacité à obtenir de nouveaux contrats ou perturbe ceux existants. Les juristes spécialisés en accessibilité et les avocats de plaignants peuvent facilement utiliser des technologies d’analyse de sites web qui identifient l’absence de conformité aux normes WCAG, créant un risque de litige important et continu.
Le cas économique en faveur d’une conformité proactive est clair. Les organisations qui intègrent l’accessibilité dans leurs opérations numériques dès maintenant ne se contenteront pas de répondre aux exigences réglementaires, elles amélioreront également la satisfaction des patients, réduiront le risque juridique et renforceront leur position en tant que prestataires de soins équitables.
Élaborer une feuille de route pratique de conformité
Passer de la situation actuelle de votre organisation à une conformité substantielle à WCAG 2.1 AA n’est pas un projet en un seul sprint. Des consultants expérimentés en accessibilité rapportent qu’il peut falloir de six à huit mois pour amener un site web standard à un état solide de conformité — et cela avant même de prendre en compte le portail patient, l’application mobile, les PDF et les outils tiers. Les organisations qui respecteront l’échéance de mai 2026 sont celles qui ont commencé leur travail en 2024 ou au début de 2025. Pour celles qui en sont encore à la phase de planification, l’urgence est de mise.
Une feuille de route pratique ressemble à ceci :
- Auditez l’ensemble de votre écosystème numérique. Ne limitez pas l’audit à votre site web public. Incluez les applications mobiles, les systèmes de planification, les portails patients, les PDF et les outils de télésanté. Utilisez une combinaison d’outils d’analyse automatisés (qui détectent environ 30–40 % des problèmes) et de tests manuels avec de véritables technologies d’assistance — lecteurs d’écran, navigation au clavier uniquement et saisie vocale. Les analyses automatisées seules ne vous donneront pas une image fidèle de la conformité.
- Hiérarchisez en fonction de l’impact sur les patients. Concentrez-vous d’abord sur les domaines où l’inaccessibilité entrave directement les soins : parcours de prise de rendez-vous, connexion au portail patient et fonctions principales, annuaires de prestataires, formulaires de contact et d’admission, et supports d’éducation des patients critiques. Un attribut alt cassé sur une image décorative est une priorité moindre qu’un bouton de soumission de formulaire qui n’est pas accessible au clavier.
- Corrigez le contenu hérité inaccessible. Traitez les anciens PDF et la documentation longue destinée aux patients. Si la correction complète des PDF hérités est gourmande en ressources, fournissez des alternatives HTML accessibles ou assurez-vous que le personnel peut fournir des versions accessibles sur demande.
- Auditez vos fournisseurs et engagez-les contractuellement. Assurez-vous que les portails patients, les plateformes de télésanté, les outils de planification et autres services tiers fournissent une documentation d’accessibilité — en particulier des Voluntary Product Accessibility Templates (VPATs) — et incluez des exigences d’accessibilité dans vos contrats fournisseurs. Votre organisation reste légalement responsable même lorsqu’une plateforme externe introduit la barrière.
- Intégrez l’accessibilité dans vos flux de travail. Créez des politiques d’accessibilité, formez les équipes de contenu et intégrez des contrôles d’accessibilité dans votre système de gestion de contenu et vos flux de développement. Les nouvelles pages, les articles de blog et les supports destinés aux patients doivent être examinés sous l’angle de l’accessibilité avant leur mise en ligne — et non signalés lors d’un audit annuel a posteriori.
- Mettez en place un widget d’accessibilité comme complément, pas comme substitut. Un widget de superposition d’accessibilité, tel qu’Accsible, peut améliorer de manière significative l’utilisabilité pour les patients malvoyants et d’autres besoins d’accessibilité en fournissant des contrôles à la demande pour la taille de la police, le contraste et d’autres préférences d’affichage. Ces outils apportent une réelle valeur à de vrais patients. Cependant, ils fonctionnent mieux en complément — et non à la place — de la correction du code sous-jacent. Un widget d’accessibilité bien implémenté combiné à une accessibilité solide du code source offre une expérience plus inclusive que l’une ou l’autre approche seule.
- Publiez une déclaration d’accessibilité. Élaborer et publier une politique d’accessibilité décrivant les pratiques d’accessibilité de votre organisation, votre objectif de conformité, les limitations connues et un moyen de contact pour les utilisateurs qui rencontrent des obstacles. Cela démontre votre bonne foi et constitue en soi une bonne pratique au regard de WCAG.
- Surveillez en continu. L’accessibilité n’est pas un projet ponctuel. Les nouveaux contenus, les mises à jour de fonctionnalités et les mises à jour du CMS peuvent introduire des régressions. Des audits et des tests réguliers sont essentiels pour maintenir la conformité — et pour démontrer que votre organisation exerce une diligence continue, ce qui compte si une plainte est un jour déposée.
WCAG 2.2 et la suite
Bien que WCAG 2.1 AA soit le plancher juridique actuel en vertu de la règle de la Section 504 du HHS, il vaut la peine de comprendre ce qui se profile. Les organisations peuvent également se conformer aux exigences de la règle en respectant les normes WCAG 2.2 AA ou AAA, qui sont devenues une norme officielle du W3C en octobre 2023. WCAG 2.2 s’appuie sur 2.1 avec de nouveaux critères, dont plusieurs ont une forte pertinence pour la santé.
Les nouveaux critères de succès de WCAG 2.2 incluent des exigences concernant l’apparence du focus (faciliter la visualisation de l’élément ayant le focus clavier), les mouvements de glissement (garantir que les opérations nécessitant un mouvement de glissement disposent d’une alternative à un seul pointeur), la taille des cibles (les éléments interactifs doivent être suffisamment grands pour être touchés de manière fiable — important pour les patients âgés utilisant des écrans tactiles) et l’aide cohérente (les mécanismes d’aide récurrents doivent apparaître au même endroit). Pour les organisations de santé qui conçoivent pour des populations vieillissantes et des patients ayant des déficiences motrices ou cognitives, WCAG 2.2 n’est pas seulement le futur plancher de conformité — c’est tout simplement un bon design.
Les organisations tournées vers l’avenir devraient concevoir de nouvelles fonctionnalités et repenser les existantes selon WCAG 2.2 AA dès aujourd’hui, tout en travaillant à mettre le contenu hérité en conformité avec WCAG 2.1 AA. L’investissement dans 2.2 maintenant évite un futur cycle de remédiation et positionne l’organisation bien en avance sur toute mise à jour réglementaire qui élèverait la norme requise.
Points clés à retenir
- La date limite de conformité est réelle et exécutoire. La plupart des organisations de santé recevant des financements fédéraux doivent respecter WCAG 2.1 AA sur leurs sites web, applications mobiles, portails patients et outils tiers d’ici le 11 mai 2026. Le HHS peut enquêter, imposer des mesures correctives et renvoyer les organisations non conformes au Department of Justice — et peut suspendre les remboursements Medicare et Medicaid.
- La page de santé moyenne présente 272 problèmes d’accessibilité. Ce n’est pas un problème qui ne touche que les petites organisations ou celles disposant de ressources limitées. Les grands systèmes de santé avec des empreintes numériques tentaculaires ont fréquemment le plus de problèmes et sont les plus ciblés par les cabinets de contentieux représentant les plaignants.
- Vos relations avec les fournisseurs font partie de votre obligation de conformité. Si votre portail patient ou votre plateforme de télésanté est inaccessible, votre organisation reste responsable. Demandez des VPATs à chaque fournisseur numérique et incluez des normes d’accessibilité dans les contrats nouveaux et renouvelés.
- Commencez par le parcours patient, pas par la page d’accueil. Donnez la priorité à la remédiation autour des parcours à plus fort impact : prise de rendez-vous, connexion et navigation dans le portail patient, annuaires de prestataires et formulaires d’admission. C’est là que l’inaccessibilité cause de réels préjudices et génère une véritable exposition juridique.
- L’accessibilité est une opération continue, pas un projet. La conformité n’est pas acquise une fois pour toutes. Les mises à jour de contenu, les changements de plateforme et les nouvelles intégrations tierces peuvent réintroduire des obstacles. Intégrez l’accessibilité dans les flux de travail quotidiens, utilisez des outils de surveillance continue et considérez la conformité à WCAG comme une norme opérationnelle permanente, pas comme une case à cocher annuelle.
