Accessibilité

Nous cherchons à améliorer progressivement l’accessibilité du site public et de l’application. La démarche s’inspire des principes WCAG 2.2 : contenu perceptible, interface utilisable, information compréhensible et code robuste.

• navigation clavier et focus visible ;
• contrastes suffisants et information qui ne dépend pas uniquement de la couleur ;
• labels de formulaires et messages d’erreur explicites ;
• alternatives textuelles pour les images pertinentes ;
• cibles tactiles suffisantes et zoom sans rupture de mise en page ;
• structure de titres cohérente ;
• tableaux, filtres et modales utilisables sur petits écrans.

Ces objectifs doivent être vérifiés sur les parcours réels : authentification, formulaires, modales, grilles, filtres, pagination, menus et paramètres. L’objectif est qu’un utilisateur puisse terminer une tâche complète sans blocage, pas seulement qu’un composant isolé paraisse lisible.

Le produit dispose de réglages de taille de texte, poids typographique et densité d’affichage. Ces options visent le confort et ne constituent pas, à elles seules, une preuve de conformité à un référentiel d’accessibilité.

Lorsque l’utilisateur augmente la taille ou le poids du texte, l’interface doit conserver des contrôles suffisamment hauts, éviter les chevauchements et laisser visibles les actions essentielles. La densité doit modifier l’espace disponible sans faire disparaître une information indispensable.

Les réglages doivent rester cohérents dans les formulaires, la sidebar, les fenêtres modales, le UserDropdown et les tableaux afin qu’aucune zone de l’application reste figée à une taille différente.

Un signalement utile peut contenir : page concernée, description du problème, navigateur/appareil facultatif et email de réponse. Il ne doit pas demander ni contenir de données patient inutiles.

Le signalement peut aussi préciser si le problème apparaît au clavier, avec le zoom du navigateur, sur téléphone ou avec une préférence d’affichage particulière. L’équipe doit pouvoir reproduire le comportement sans demander d’informations médicales.

WCAG 2.2 est utilisé comme référentiel de bonnes pratiques. Cette référence ne constitue pas une certification de CABIAX. Toute déclaration de niveau de conformité devra être fondée sur un audit de la version réellement déployée.

Un audit doit couvrir le clavier, le focus, les contrastes, le zoom, les formulaires, les erreurs, les modales, les grilles, les menus, les préférences d’affichage et les parcours mobiles.

Les corrections doivent être testées avec les composants réels de l’application et pas uniquement sur les pages publiques.

La revue doit couvrir les états chargement, erreur, aucun résultat, validation de formulaire et navigation responsive. Les composants partagés doivent être testés dans leurs différents contextes pour éviter qu’une correction crée une régression ailleurs.