1188 sujets

Accessibilité du Web

Bonjour à tous,

Nous travaillons sur des systèmes d'appel malade et d'appel infirmier pour des EHPAD, hôpitaux et cliniques. Ces systèmes comprennent une gestion centralisée des alarmes, avec une signalisation à la fois lumineuse et sonore. Nous nous posons des questions sur la transposition de ces principes dans une interface web de supervision consultée par le personnel soignant.

Pour une alerte prioritaire qui arrive en temps réel, vaut-il mieux utiliser une région aria-live en mode « assertive » ou un rôle « alert », sachant que plusieurs alertes peuvent arriver presque en même temps ? Comment éviter que les annonces successives se coupent entre elles pour un utilisateur de lecteur d'écran ?

Nous voulons aussi éviter que la couleur seule indique le niveau d'urgence : quelles combinaisons (icône, libellé, motif) vous semblent les plus lisibles ? Enfin, auriez-vous des recommandations sur les animations clignotantes et les signaux sonores au regard des critères WCAG ?

Merci d'avance pour vos retours et vos expériences.
Modifié par Appel-Malade (02 Nov 2026 - 21:52)
Je ne suis pas spécialiste de l'accessibilité, mais pour les alertes qui arrivent presque en même temps, je garderais une seule région aria-live assertive, présente dans la page dès le chargement, et j'y mettrais un résumé du genre « 3 alertes prioritaires : chambres 12, 14 et 20 » plutôt qu'une annonce par alerte. Sinon chaque nouvelle annonce assertive coupe la précédente.
Modérateur
Bonjour,

Est-ce que l'interface web va être potentiellement utilisée sur n'importe quel type de machine, avec n'importe quel navigateur, et n'importe quel lecteur d'écran ?

Si c'est le cas, utiliser Aria me semble assez risqué vu l'importance du sujet, car la technologie est assez capricieuse. On n'a aucune garantie que ça va marcher comme on l'espère, ni que ça va marcher de la même manière sur tout type de matériels. C'est vraiment difficile de faire quelque chose de robuste.

Si par contre on connait à l'avance le matériel qui va être utilisé (machine, navigateur et lecteur d'écran) pour visualiser et écouter l'interface web, peut-être qu'on peut avoir une chance de s'en sortir. Mais bon, Aria est surtout faite pour les non-voyants ou ceux qui ne maitrisent pas la lecture, pas pour du personnel qui a priori n'a aucun de ces problèmes. Et en conséquence, on peut se retrouver avec tout un tas de messages de la part du lecteur d'écran qui seront non pertinents pour ce personnel, sauf à bâtir une usine à gaz pour les éviter.

Ceci dit, si j'étais en charge d'un tel projet, vu les risques et ce que je crois comprendre du besoin, je n'utiliserais pas Aria, mais j'essaierais plutôt de gérer de A à Z les messages avec de la synthèse vocale. Il y a par exemple un truc qui s'appelle SpeechSynthesis, qui est largement supporté, et pilotable bien plus facilement qu'Aria (selon moi).

Amicalement,
Merci à vous deux pour ces pistes. Dans nos systèmes d'appel malade, la règle de base est qu'une alerte ne repose jamais sur un seul canal : signalisation lumineuse et sonore ensemble, avec une hiérarchie claire entre les niveaux d'urgence. Pour l'interface web de supervision, je transposerais la même logique : une seule zone d'annonce persistante, qui résume les alertes en cours et les classe par priorité, plutôt qu'une annonce par alerte. Pour ne pas se reposer sur la couleur, l'association d'une icône distincte par niveau, d'un libellé explicite (« urgence », « appel », « assistance ») et d'une position fixe dans la liste est la plus lisible en pratique. Côté animations, mieux vaut éviter tout clignotement rapide, dont les critères WCAG sur les flashs fixent la limite, et préférer un changement d'état stable et bien contrasté. Pour le son, des tonalités différentes selon la priorité et un acquittement par le soignant évitent la fatigue d'alarme, et la synthèse vocale suggérée par parsimonhi me paraît cohérente pour un personnel dont le matériel est connu à l'avance.