Contexte
Portail patient, secteur Santé. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
realisations/4:Project
Portail React accessible AA connecté à une API .NET conforme RGPD & HDS.
Portail patient, secteur Santé. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
Portail React accessible AA connecté à une API .NET conforme RGPD & HDS.
AA sur « accessibilité certifiée ». Derrière ce chiffre : une base de code couverte par des tests, une documentation à jour dans le dépôt, et une équipe interne capable de reprendre la main.
Réalisé avec React, .NET, sur une chaîne d'intégration et de déploiement continue montée avec le projet. Les technologies ont été choisies pour ce contexte-là, pas parce que nous les préférons.
L'accessibilité de niveau AA ne s'ajoute pas à la fin. Une partie des critères porte sur la structure même des pages — ordre des titres, relations entre étiquettes et champs, gestion du focus — et récrire cette structure sur une application terminée coûte plus cher que de l'avoir faite juste. C'est la contrainte qui doit arriver en premier.
S'y ajoute, dans la santé, un cadre réglementaire qui pèse sur l'architecture avant de peser sur le code : où les données résident, qui peut les lire, ce qui doit être tracé et pendant combien de temps. Ces réponses déterminent l'hébergement et le modèle de données, donc elles se traitent au cadrage.
Nous exigeons que chaque parcours soit praticable au clavier seul, et cette vérification fait partie de la recette de chaque itération. Reportée à la fin, elle révèle des problèmes structurels — pièges de focus dans les fenêtres modales, ordre de tabulation incohérent — qui demandent de reprendre des composants déjà considérés comme terminés.
Ce contrôle attrape aussi des défauts qui n'ont rien à voir avec le handicap : un bouton qui ne réagit pas à la touche Entrée, une fenêtre qui ne se ferme pas avec Échap, un formulaire qui perd sa position après une erreur. Ce sont des irritants pour tout le monde, et ils remontent par ce chemin-là.
Un vérificateur automatique détecte les contrastes insuffisants, les images sans alternative textuelle, les champs sans étiquette. Il ne détecte pas une alternative textuelle qui décrit mal, un ordre de lecture qui n'a pas de sens, ou une information portée par la seule couleur dans un graphique. Ces trois-là demandent un humain.
Nous combinons donc les deux : les contrôles automatiques dans la chaîne d'intégration, qui bloquent, et une revue manuelle au lecteur d'écran sur les parcours principaux. Annoncer une conformité sur la seule foi d'un outil est une affirmation qu'on ne peut pas tenir.
Savoir qui a consulté quoi et quand n'est pas une fonctionnalité qu'on ajoute : c'est une propriété du modèle. Ajouter une piste d'audit après coup oblige à instrumenter chaque accès à la main, avec la certitude d'en oublier, et sans moyen de reconstituer le passé.
Nous plaçons donc ce mécanisme au niveau de l'accès aux données, une fois, plutôt que dans chaque écran. C'est aussi ce qui permet de répondre à une demande d'exercice de droits sans développement supplémentaire, alors que la même demande devient un chantier quand la traçabilité est dispersée.
La mention AA renvoie au niveau de conformité visé par les WCAG sur les parcours audités. Un niveau de conformité porte sur un périmètre daté, pas sur une application entière et pour toujours : un écran ajouté après l'audit n'est pas couvert par lui, et c'est la raison pour laquelle les contrôles automatiques restent dans la chaîne d'intégration. La conformité est un état qu'on maintient, pas un certificat qu'on obtient.
Et ce qu'il ne mesure pas. Un indicateur qu'on n'explique pas ne vaut rien.
Continuer:Project[3]
Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.