Bienvenue dans ce nouvel épisode de ma série d’articles consacrée à la stratégie de conception. Aujourd’hui, je vais vous raconter une anecdote tirée de récentes visites chez des clients, qui vous aidera à comprendre POURQUOI vous devriez changer vos méthodes afin de faire évoluer et de développer rapidement votre programme d’accessibilité numérique. Une fois de plus, je vais éviter les listes rébarbatives de consignes tactiques du type « faites ceci / ne faites pas cela ».
J'utiliserai les termes « système de design » et « bibliothèque de composants » de manière interchangeable. Les directives relatives à la marque et au style constituent toutefois, comme on dit, une tout autre histoire, et ces termes seront utilisés séparément.
Passons à l'histoire…
Le problème
J'ai récemment effectué deux visites consécutives chez deux clients. Dans les deux cas, puisque nous étions sur place (et donc connectés à leur réseau), j'ai demandé si nous pouvions prendre quelques instants pour examiner leurs systèmes de conception. Pour être clair, je souhaitais examiner les informations relatives à l'accessibilité des composants, et non la conformité aux WCAG du système de conception lui-même. Tous deux ont généreusement accepté.
Dans les deux cas, le système était arrivé à maturité (après 2 à 3 ans de développement) et, d’après ce que l’on disait, à la pointe du secteur. Il s’agissait de plus de 75 composants accompagnés de code, de documentation, d’exemples, de conseils d’utilisation et des prémices d’une documentation de conception réutilisable. J’ai demandé si nous pouvions nous concentrer sur les aspects liés à l’expérience utilisateur que j’avais relevés avant d’aborder les questions d’accessibilité.
Dans l'ensemble, les données étaient compréhensibles si l'on disposait de suffisamment de temps pour s'asseoir et en analyser le contenu ; mais leur présentation ne se prêtait pas à une consultation rapide. Les concepteurs du système de conception n’ont pas respecté les règles et techniques standard de conception de l’expérience utilisateur en matière de mise en page, de hiérarchie, de libellé et de titrage, etc. Plus important encore, ils n’avaient pas impliqué leurs utilisateurs finaux dans le processus de conception. Le système avait donc été conçu pour être utilisé par l’équipe chargée du système de conception elle-même, et non par les concepteurs, les développeurs et les testeurs/ingénieurs qualité. Il était très évident qu’il avait été conçu comme un référentiel de données et de règles, et non comme un outil destiné à être réellement utilisé par les équipes numériques.
Il s'agit là d'un élément crucial du problème, car les informations d'accessibilité relatives à ce composant ont été rédigées à l'intention d'un expert en accessibilité (SME), et non aux utilisateurs visés — qui n’étaient assurément PAS des experts en accessibilité. Le composant citait les règles des WCAG, mais ne les formulait pas dans des termes compréhensibles pour les utilisateurs réels ; les bonnes pratiques relatives aux critères de succès des WCAG n’étaient même pas abordées. Par exemple, les informations relatives au nom, au rôle et à la valeur du champ de la case à cocher n’étaient même pas mentionnées, et encore moins clairement mises en évidence dans la documentation. Il y avait bien des images illustrant les états coché et non coché, mais aucune indication précisant si la norme de la marque prévoyait que l’utilisateur final devait cocher ou décocher la case. Il n’y avait aucun contenu montrant une interaction réussie entre un lecteur d’écran et le composant, qui aurait pu aider le développeur lors de la mise en œuvre ou le testeur lors des tests.
Le moment « Eurêka ! », suivi d'une réflexion, de prises de conscience et de quelques commentaires hauts en couleur
Dans les deux cas, lorsque j’ai présenté mes observations sur l’expérience utilisateur, les équipes ont eu des moments de prise de conscience, en découvrant pour la première fois leur contenu à travers le regard d’autrui. Vous voyez de quel moment je parle, n’est-ce pas ? Elles se taisent, pâlissent peut-être un peu, déglutissent bruyamment et, dans certains cas, lâchent un juron (ou deux). Disons simplement que les mots prononcés étaient très colorés !
En nous mettant dans la peau d’un concepteur, nous avons pris le temps d’examiner un composant en vue d’une éventuelle mise en œuvre. En tant que concepteur, j’avais besoin d’une case à cocher dans un formulaire d’inscription à une newsletter afin que l’utilisateur final accepte les conditions d’utilisation de son adresse e-mail par l’entreprise dans le cadre de futures transactions. J’ai encouragé tout le monde à « jouer le jeu » et à dresser la liste (par ordre d’importance) des informations que nous devrions examiner si nous avions le choix entre plusieurs composants : consignes d’utilisation, descriptions des états, visuels, choses à faire et à ne pas faire, exceptions, extraits de code de conception à intégrer dans nos maquettes fonctionnelles, garanties de conformité de ce composant aux normes WCAG 2.1AA et consignes d’accessibilité.
Comme le système de conception ne comportait qu’une seule case à cocher, il n’a pas fallu beaucoup réfléchir pour décider de l’utiliser. Cependant, en examinant leur interface, nous avons constaté que seule la moitié des données à vérifier était disponible. Et les informations qui étaient disponibles n’étaient pas présentées dans le bon ordre (voir le paragraphe ci-dessus). Cela signifiait qu’en tant qu’utilisateurs, nous devions chercher ce dont nous avions besoin, puis deviner le reste des informations.
J’ai cliqué sur un autre composant et ils ont rapidement constaté qu’il présentait des informations différentes de celles du composant « case à cocher » et que celles-ci étaient organisées dans un ordre encore différent. En tant qu’utilisateur, je devrais réapprendre la disposition des informations à chaque nouveau composant, ce qui augmenterait considérablement ma charge cognitive, sans parler de ma vitesse d’exécution. Disons simplement qu’il y a eu d’autres soupirs et que des jurons très colorés ont fusé.
Il est essentiel que vous, cher lecteur, compreniez que le travail acharné que vous avez déjà consacré à votre programme d’accessibilité et/ou à votre système de conception n’est ni erroné ni inutile. Tout ce que vous avez accompli s’inscrit dans un processus d’évolution. La volonté, les efforts et l’ambition qui ont présidé à la réalisation de ce que vous avez accompli jusqu’à présent ne sont en aucun cas minimisés ici. Le fait qu’une personne comme moi intervienne et identifie rapidement les points à améliorer relève du phénomène consistant à « ne pas voir la forêt à cause des arbres ». Vous êtes trop proche de la situation, ce qui obscurcit votre objectivité. Croyez-moi, je suis passé par là. Il faut souvent un regard neuf et une perspective différente pour voir la « forêt » dans son ensemble. Respirez profondément et concentrez-vous sur l’horizon, c’est-à-dire la destination. Soyez fier de ce que vous avez construit jusqu’à présent et rassemblez l’énergie nécessaire pour passer au niveau supérieur. Kumbaya !
Que pouvons-nous faire de ces informations ?
Chaque client a indiqué que cet exercice lui avait rapidement permis d'identifier les prochaines étapes à franchir pour faire passer son système de design à un niveau de maturité supérieur. Voici quelques réflexions supplémentaires que j'ai partagées avec eux :
Généralités
- Veillez à vous concentrer sur les véritables utilisateurs finaux, par exemple les concepteurs, les développeurs, les testeurs, etc. Recourez à des exercices de « design thinking » avec vos utilisateurs finaux afin de cerner leurs besoins et de déterminer comment vous pouvez les aider à réussir dans leur travail.
- Respectez une mise en page cohérente (pour chaque composant). Cela permettra de réduire la charge cognitive tout en améliorant l'efficacité des utilisateurs, qui sauront exactement où trouver les informations dont ils ont besoin.
REMARQUE : si une section de données ne s'applique pas à un composant spécifique, indiquez-le en ajoutant la mention « sans objet » ; ne ne ne la supprimez pas ! L’utilisateur s’attendra à trouver les informations à des emplacements et dans un ordre précis. - Tenez compte de l’utilisation par plusieurs utilisateurs. Trouvez un format de présentation homogène adapté à différents utilisateurs. Cela doit inclure le type de données, le ton et la pertinence des informations. Par exemple : le fait d’indiquer clairement les informations « Nom / Rôle / Valeur » aide le concepteur à comprendre l’expérience de l’utilisateur d’un lecteur d’écran, facilite le travail de codage du développeur et permet au testeur de connaître le scénario correct pour ce composant. Tout autre élément que cette expérience doit être consignée par le testeur comme un défaut.
Tests
- Fournissez des scripts de test pour chaque composant. Cela permettra aux testeurs de reproduire facilement le test pour ce composant. Intégrez les scripts de test finalisés par l’équipe chargée du système de conception afin de vérifier la conformité du composant avant sa mise en œuvre. Cela permettra également d’indiquer implicitement que les défauts détectés après l’intégration du composant ont nécessairement été introduits après son importation par l’équipe de développement. Si certains critères de succès des WCAG ne peuvent être testés qu’une fois le composant en place, indiquez-le dans le script de test afin de rafraîchir la mémoire du testeur.
- Test de conformité aux WCAG 2.2AA quel que soit le niveau indiqué dans votre politique. En veillant à ce que tous les composants de la bibliothèque de conception respectent le niveau WCAG le plus élevé possible, les équipes seront mieux armées pour s'adapter aux futures modifications de la politique.
- Présentez clairement les informations relatives à la « réussite » afin d'aider les testeurs. Par exemple, incluez une vidéo montrant le lecteur d'écran annonçant correctement le composant.
Normes
- Indiquez toutes les informations spécifiques et pertinentes relatives à l'accessibilité (comme s'il s'agissait d'une annotation) pour le composant. Par exemple, quels sont le nom, le rôle et la valeur de la case à cocher lorsqu'elle est cochée et lorsqu'elle ne l'est pas ? Précisez l'utilisation recommandée par la marque pour ce composant. Dans le cas de la case à cocher, celle-ci peut servir aux utilisateurs à accepter les conditions générales (ou équivalent) et à refuser toute autre option.
- Intégrez dans votre système de conception des directives ou des normes concernant les éléments universels, notamment la manière dont les numéros de téléphone ou les montants monétaires doivent être lus par un lecteur d'écran.
- Pensez à optimiser l'efficacité en intégrant les directives relatives à votre marque et à votre style dans le système de conception, plutôt que de les conserver dans des documents distincts. Si vous devez tout de même les conserver dans des documents séparés, ajoutez des liens faciles d'accès vers ces derniers dans la barre de navigation principale de votre système de conception.
- Faites passer votre documentation sur l'accessibilité au niveau supérieur : précisez (et identifiez) les bonnes pratiques par rapport aux critères de conformité normatifs des WCAG. Par exemple : X est une bonne pratique des WCAG (facultative), mais fait partie intégrante de votre image de marque (obligatoire). Cela permettra aux utilisateurs de savoir quelles bonnes pratiques ils doivent respecter. Sachez qu'il vous faudra peut-être un certain temps, dans le cadre de votre programme d'accessibilité, pour définir des bonnes pratiques définitives et les documenter. C'est tout à fait normal.
- Communiquez de manière passive les données de conformité aux WCAG au niveau des composants. Cela permettra non seulement de rappeler à vos utilisateurs l'importance de la conformité, mais aussi à votre équipe chargée du système de conception d'améliorer de manière autonome le niveau de conformité pendant les périodes de transition.
- Les systèmes de conception présentant un haut niveau de maturité comporteront des entrées distinctes pour les composants répondant aux niveaux AA et pour les composants similaires répondant au niveau AAA. Chacune d'entre elles sera accompagnée d'une documentation claire expliquant pourquoi et comment ces composants répondent aux différents niveaux, et proposera des conseils d'utilisation afin d'aider l'utilisateur à déterminer pourquoi il devrait privilégier l'un plutôt que l'autre dans sa mise en œuvre.
Collaboration
- Veillez à ce que votre système de conception (de préférence au niveau des composants) dispose d'un processus simple de signalement des défauts. Comme nous l'avons tous constaté, tous les cas de figure ne peuvent pas être testés lors de la conception et du développement des composants. Les installateurs peuvent provoquer des dysfonctionnements du composant lorsqu'ils l'utilisent dans un contexte non testé.
- Soyez une équipe avec laquelle il est facile de travailler. Permettez à vos collègues de vous contacter facilement et répondez rapidement à leurs besoins. Vous êtes un prestataire de services dont l’utilisateur rencontre des difficultés. Il est essentiel de lui permettre de reprendre ses activités le plus rapidement possible, en faisant preuve d’un sens aigu du service client. Nous constatons que les taux d’adoption des systèmes de conception sont plus élevés lorsque l’équipe chargée de ces systèmes est perçue comme facile à côtoyer.
- Mettez en place des cycles de travail de qualité pour votre équipe chargée du système de design. Organisez des rétrospectives ou des bilans périodiques pour passer en revue les problèmes de mise en œuvre, les difficultés, les réclamations et les questions, afin d’optimiser votre processus, votre documentation et le système de design lui-même. Dans la mesure du possible, impliquez les membres de l’équipe numérique qui ne font pas partie de l’équipe principale chargée du système de design.
Leadership
En tant que dirigeant, trouvez le juste équilibre entre « confiance » et « confiance aveugle ». Ce qui ressort clairement dans les deux cas : les dirigeants avec lesquels je travaillais faisaient confiance à leur équipe pour mener à bien les tâches, mais ils n’utilisaient ni n’évaluaient eux-mêmes le système de conception. Ils ont été choqués de constater le manque de cohérence qui semait la confusion chez les utilisateurs et contribuait à leurs difficultés d’adoption. En tant que dirigeant, vous devez absolument faire confiance à votre équipe pour qu’elle accomplisse correctement son travail, mais vous devez également faire partie intégrante de l’équipe et mettre à profit votre expérience pour apporter un regard extérieur. Aidez votre équipe à prendre régulièrement du recul pour voir la forêt – et non seulement les arbres. Si vous dirigez une équipe dont le domaine d’activité ne relève pas de vos compétences principales, veillez à ce que l’équipe sollicite régulièrement des utilisateurs pour qu’ils évaluent et donnent leur avis sur le contenu, l’ergonomie, la cohérence, la pertinence par rapport à l’objectif, etc. tout au long du processus de conception et de développement, et non pas seulement une fois celui-ci terminé et devant les utilisateurs.
Pourquoi j'apprécie cette approche pour résoudre les problèmes de conception à grande échelle
Voici quelques-unes des nombreuses raisons pour lesquelles j'apprécie cette approche :
- Vous pouvez rapidement étendre l'utilisation de votre système de conception et enrichir sans tarder votre bibliothèque de composants accessibles grâce à des bases solides, une mise en page robuste et une stratégie claire, en fournissant les informations sous un format qui permettra aux concepteurs, aux développeurs et aux testeurs d'atteindre rapidement leurs objectifs. (Vous pourriez même devenir extrêmement populaire par la même occasion !)
- Intégrer l'accessibilité dès la conception des composants permettra de réduire considérablement la dette technique à des étapes ultérieures de votre cycle de développement logiciel (SDLC).
- Renforcez la confiance dans le système de conception en vous assurant que les composants sont conformes aux WCAG, en fournissant des preuves de cette conformité et en veillant à ce que celle-ci soit clairement indiquée dans l'ensemble du système de conception. Cela permettra de réduire les allers-retours avec les développeurs, ce qui fera gagner un temps considérable à tout le monde.
- En vous montrant ouverts à la collaboration, vous renforcerez la fidélité des utilisateurs, leur confiance et leur utilisation régulière de votre système de conception.
