24 bis. L'accessibilité : vérifier que la capacité est réellement utilisable
Pourquoi ce chapitre existe
Une fonctionnalité n'est pas de qualité si une partie de ses utilisateurs ne peut pas la percevoir, la comprendre ou l'opérer. L'accessibilité est parfois confiée à une revue tardive d'interface. Cette approche découvre trop tard des choix de structure, d'interaction, de contenu ou de composants impossibles à corriger sans coût. Elle oublie aussi que l'accessibilité concerne les formulaires, erreurs, parcours, documents et opérations, pas seulement le contraste visuel.
Les idées essentielles
- L'accessibilité est un comportement utilisateur à concevoir et à prouver, au même titre que la performance ou la sécurité.
- Les standards comme WCAG fournissent une base commune, mais la conformité automatisée ne remplace pas l'essai de parcours réels avec des technologies d'assistance.
- Structure sémantique, navigation au clavier, gestion du focus, messages compréhensibles et alternatives non visuelles doivent être décidés dès la conception.
- Une interface accessible bénéficie aussi aux usages mobiles, temporaires, dégradés et aux utilisateurs novices.
Concevoir un parcours, pas une page
Demander si un champ a un libellé est utile ; demander si une personne peut terminer le parcours au clavier, comprendre une erreur, revenir au bon endroit et confirmer le résultat est plus proche de l'expérience réelle. Les états transitoires comptent : chargement, modale, validation, contenu mis à jour, document généré et message d'échec.
| Situation | Risque d'exclusion | Preuve adaptée |
|---|---|---|
| Formulaire | Erreur non associée au champ ou ordre de focus perdu | Parcours clavier, lecteur d'écran, test de composant |
| Action asynchrone | Mise à jour silencieuse ou bloquante | Annonce d'état et test d'interaction |
| Donnée visualisée | Information uniquement par couleur ou graphique | Texte équivalent, structure et test utilisateur |
| Authentification | Étape inaccessible ou temps insuffisant | Parcours représentatif avec aides techniques |
Combiner automatisation et évaluation humaine
Les linters et tests automatisés repèrent des défauts structurels : attribut manquant, contraste, rôle incorrect. Ils ne savent pas toujours si un libellé est compréhensible, si l'ordre de lecture correspond au parcours ou si une interaction est soutenable avec une technologie d'assistance. Les capacités critiques méritent donc une évaluation manuelle, idéalement avec des utilisateurs concernés ou des spécialistes de l'accessibilité.
Le chemin nominal est souvent le plus accessible car il est le plus démontré. Les messages de validation, de panne et de reprise sont précisément les moments où les personnes ont le plus besoin d'orientation. Les inclure dans les scénarios de test évite une accessibilité de vitrine.
Anti-patterns
Ajouter l'accessibilité à la fin comme une liste de corrections
Les remédiations tardives améliorent parfois un défaut, mais ne remplacent pas une structure et un modèle d'interaction accessibles dès la conception. Elles sont aussi plus difficiles à arbitrer face à une date de livraison déjà fixée.
Se satisfaire d'un score automatique
Un score ne prouve ni la compréhension du contenu ni l'opérabilité complète. Il est un signal utile à intégrer à la CI, jamais le jugement final sur un parcours significatif.
Créer un composant « accessible » non adopté
Une bibliothèque interne peut réduire le coût si elle offre une expérience plus simple que la réimplémentation. Sans documentation, exemples, maintenance et adoption par les équipes, elle devient une dépendance de plus sans effet sur les utilisateurs.
Bonnes pratiques
Inclure l'accessibilité dans les critères de comportement
Une demande devrait préciser les interactions, alternatives et messages nécessaires pour accomplir l'objectif. Les tests de composant, de parcours et les revues de conception peuvent alors vérifier une attente explicite au lieu de chercher des défauts à la fin.
Capitaliser les apprentissages dans le système de composants
Lorsqu'un motif est corrigé plusieurs fois — modale, menu, erreur, tableau — le transformer en composant, test ou guide de contenu rend l'amélioration disponible à toute l'organisation.
Checklist — Le parcours est-il utilisable par tous ses utilisateurs ?
- Peut-on percevoir l'information sans se reposer sur une seule modalité ?
- Peut-on terminer l'interaction au clavier et avec des technologies d'assistance pertinentes ?
- Les états de chargement, erreur, succès et focus sont-ils compréhensibles ?
- Les messages et libellés expliquent-ils l'action et sa conséquence ?
- Quelles vérifications automatiques couvrent la structure, et quelle évaluation humaine couvre le parcours ?
- Quel composant ou standard permet de ne pas répéter la même correction ?
À retenir
L'accessibilité rend une capacité réellement disponible, pas simplement affichée. La concevoir et la tester dès le parcours protège les utilisateurs les plus exposés et améliore la qualité de l'expérience pour tous.