Depuis le début de ma carrière en 2012, mon apprentissage du design inclusif s’est heurté à de nombreux obstacles et lacunes pédagogiques. Mon ambition est d’aider les designers, les développeurs et les professionnels de la technologie qui souhaitent créer des expériences de meilleure qualité et plus inclusives à surmonter ces obstacles. Dans cet article de blog, j’espère notamment informer mes collègues designers sur les moments précis où il est nécessaire de prendre en compte les questions d’accessibilité.
Je vais me concentrer sur ce qui me semble être l'aspect le plus crucial du travail en matière d'accessibilité que les concepteurs peuvent accomplir : la création de systèmes de conception intégrant d'emblée la conformité aux normes d'accessibilité. Nous nous attacherons notamment à apprendre à identifier les problèmes d'accessibilité dans nos systèmes de conception existants et à les documenter de manière à ce qu'ils puissent faire l'objet de mesures concrètes, tant pour nous-mêmes que pour nos équipes.
Préférez-vous lire cet article sous forme audio ou vidéo ? Vous pouvez visionner une version vidéo de cet article sur YouTube!
Table des matières
- Systèmes de conception et accessibilité
- Particules subatomiques
- Atomes
- Molécules
- Organismes
- Modèles et pages
- Que se passe-t-il lorsqu'un système de conception néglige l'accessibilité ?
- La conception doit tenir compte de l'accessibilité
- Audit des systèmes de conception
- Passer en revue le contenu des fichiers existants
- Capturer tous les composants actifs
- Effectuer des recoupements et commencer à recenser les problèmes
- Intégrer l'accessibilité dans notre audit
- Problèmes courants d'accessibilité dans la conception
- La conception accessible ne se limite pas au contraste des couleurs.
- Comment consigner les résultats d'un audit
- Ajouter des informations contextuelles
- Créez votre audit
- Thèmes communs et éléments récurrents
- Faites la distinction entre l'intention et la mise en pratique
- Que faire de votre rapport d'audit ?
- Adaptez votre audit à votre public
- Concevoir avec les personnes handicapées, et non pour elles
- Résumé
- Outils pour vous lancer dans votre audit:
Systèmes de conception et accessibilité
Qu'est-ce qu'un système de design, exactement ? Un système de design constitue une source unique de référence pour un produit, un site ou une expérience. Il englobe notamment une vision commune et un ensemble de valeurs pour une équipe de design et de développement, ainsi que des éléments de marque et des composants. Les systèmes de design regroupent les éléments de mise en œuvre connexes, définissent leur objectif et précisent leur mise en œuvre.
Lorsqu'il est correctement mis en place, un système de design doit évoluer et s'adapter à la croissance de l'entreprise. Ces systèmes sont importants car ils nous permettent de travailler à grande échelle, de créer un élément une seule fois pour ensuite l'appliquer partout, et d'asseoir une image de marque plus cohérente. Mais surtout, un système de design est essentiel car il nous aide également à développer l'accessibilité.
Chaque atome, chaque molécule et chaque organisme que nous créons au sein de notre système influe sur notre capacité à évoluer à plus grande échelle et à répondre aux besoins des personnes en situation de handicap. Lorsque je parle d’atomes, de molécules et d’organismes, je fais directement référence à l’ouvrage de Brad Frost intitulé « Atomic Design » (que je vous recommande vivement si la réflexion autour des systèmes de conception vous intéresse).
La publication de l’« Atomic Design » en 2016 a marqué un tournant décisif dans la réflexion sur le design dans le domaine du numérique. Même si de nombreuses équipes avaient déjà commencé à utiliser des bibliothèques de modèles et des frameworks, tels que Bootstrap, l’« Atomic Design » a mis en lumière une réalité que nous avions tous commencé à constater : le design numérique avait besoin de systèmes plus performants.
Plus de quatre ans après sa parution, l’ouvrage de Brad Frost est encore régulièrement cité lorsque les équipes de conception défendent l’intérêt des systèmes de conception. Nous pouvons également nous appuyer sur cette méthodologie pour définir comment concevoir l’accessibilité à grande échelle et vérifier la conformité de nos systèmes en matière d’accessibilité. Dans« Atomic Design », Brad Frost décompose l’échelle des systèmes de conception à l’aide d’une approche atomique. Nos systèmes s’articulent essentiellement les uns sur les autres, en partant d’éléments, tels que des atomes, qui peuvent être combinés pour créer des molécules, puis combinés à leur tour pour former des organismes.
Ces entités définissent et créent des modèles qui peuvent ensuite être appliqués à des pages spécifiques de nos plateformes. Chaque personne et chaque équipe a une compréhension ou un jargon légèrement différent concernant cette échelle, mais les éléments fondamentaux de ces principes se retrouvent généralement de manière cohérente dans la plupart des systèmes de conception numérique.
Il n’est pas nécessaire de disposer d’un système de conception robuste ou « parfait » pour utiliser cette méthodologie ou réaliser un audit d’accessibilité. Les principes abordés dans cet article peuvent être mis en œuvre à n’importe quelle étape du développement de notre système de conception, que notre équipe en soit à ses débuts, qu’elle dispose déjà d’un système fonctionnel et bien documenté, ou qu’elle se situe quelque part entre les deux.
Particules subatomiques
Commençons par analyser comment la conception atomique évolue généralement à grande échelle. Mais avant d’aborder les « atomes », parlons de nos « particules subatomiques », ces éléments fondamentaux qui constituent la base de notre système de conception.
Ce ne sont pas nos atomes, mais ils guident la création des atomes. Ces particules subatomiques correspondent généralement à des éléments tels que les couleurs de la marque ou les polices de caractères. Même si, pris isolément, ces éléments peuvent ne pas sembler essentiels pour notre système, ils auront une incidence sur tous les éléments que nous créons, de la plus petite échelle jusqu’à nos pages complètes.
Atomes
Les « atomes » permettent de visualiser d'un seul coup d'œil l'ensemble de nos styles de base, ce qui peut constituer une référence utile à laquelle revenir régulièrement au fur et à mesure que nous développons et maintenons notre système de design. Certains systèmes présentent une granularité plus fine que d'autres ; gardez donc à l'esprit que des termes tels que « atomes », dans ce contexte, peuvent parfois revêtir des significations différentes selon les équipes.
Dans le cadre de cette approche, les « atomes » sont des éléments tels que les libellés, les champs de saisie et les boutons, ainsi que d’autres éléments qui ne peuvent être décomposés sans perdre leur fonctionnalité. L’exemple ci-dessous présente un libellé, un menu déroulant et un bouton, chacun constituant un « atome » unique. Mais à l’instar des atomes du monde naturel, les atomes d’interface n’existent pas dans le vide et ne prennent véritablement vie qu’une fois mis en œuvre.
Molécules
À l'échelle atomique, l'étape suivante est celle des molécules : les molécules sont des groupes relativement simples d'éléments, ou d'atomes, qui fonctionnent ensemble comme une seule et même entité.
Par exemple, une étiquette de formulaire, un menu déroulant et un bouton « Enregistrer » peuvent désormais former un ensemble fonctionnel de champs de formulaire. Une fois combinés, ces « atomes » abstraits prennent soudain tout leur sens. Auparavant, nous avions simplement une étiquette, un menu déroulant et un bouton, mais nous pouvons désormais créer une interface cohérente en associant ces éléments.
En cliquant sur le bouton « atom », on enregistre désormais le champ de sélection, et le libellé indique la fonction de ces champs. Résultat : un composant simple, portable et réutilisable qui peut être inséré partout où un champ de sélection ou un formulaire d'enregistrement est nécessaire.
Organismes
Passons à une échelle supérieure : les organismes sont des entités relativement complexes, composées de groupes de molécules et/ou d'atomes, voire d'autres organismes. Ces organismes forment des sections distinctes d'une interface.
Partir des molécules pour aboutir à des organismes plus complexes offre aux concepteurs et aux développeurs une compréhension essentielle du contexte. Les organismes illustrent le fonctionnement de ces composants plus petits et plus simples et constituent des modèles distincts pouvant être réutilisés à l'infini.
Vous trouverez ci-dessous notre exemple de formulaire à menu déroulant et d'enregistrement appliqué à un contexte spécifique, en l'occurrence un formulaire de renseignements d'expédition. Cet organisme est également composé d'autres atomes et molécules et remplit une fonction plus spécifique.
Modèles et pages
Si l'on s'éloigne un peu de notre analogie, nous pouvons utiliser nos atomes, molécules et organismes pour créer des modèles et des pages. Les modèles sont des objets au niveau de la page qui placent des composants dans une mise en page et définissent les structures de conception sous-jacentes à la structure du contenu.
Si nous réutilisons la structure d'une page pour de nombreuses applications différentes, nous pouvons utiliser ce modèle pour d'autres pages. Un modèle présente l'ensemble des composants nécessaires d'une page fonctionnant de concert, fournissant ainsi un contexte à nos molécules et organismes relativement abstraits.
En définissant le modèle d'une page, nous pouvons créer un système capable de prendre en charge différents contenus dynamiques, tout en fournissant les contraintes nécessaires pour les types de contenu qui viennent remplir certains modèles de conception.
Enfin, les pages sont des instances spécifiques de modèles qui montrent à quoi ressemble une expérience avec un contenu réel et représentatif. En plus de présenter l'interface finale telle que nos utilisateurs la verront, les pages jouent un rôle central dans l'évaluation de l'efficacité des éléments sous-jacents du système de conception. Nous pouvons ainsi observer comment tous ces modèles se comportent lorsque du contenu réel est appliqué au système de conception au niveau de la page.
Dans l'exemple ci-dessous, nous avons repris notre formulaire de coordonnées de livraison et l'avons intégré à une page spécifique de notre site ou de notre application.
Que se passe-t-il lorsqu'un système de conception néglige l'accessibilité ?
Nous avons donc pris nos atomes, les avons assemblés en une molécule, puis avons regroupé cette molécule avec d’autres atomes et molécules pour créer un organisme, avant de l’appliquer à une page ou à un modèle. Ce sont ces principes de conception « atomique » qui ont permis à nos systèmes de conception de prospérer, tant au niveau de la conception que du développement. Un système de conception bien modulable peut faciliter considérablement la réflexion autour des besoins des utilisateurs et rendre notre flux de travail extrêmement efficace. Plutôt simple, non ?
Mais attendez, un instant !
Le « atomic design » est une excellente approche, mais lorsque nous avons créé cette interface d’exemple, nous n’avons pas pris en compte l’accessibilité. Nous nous sommes uniquement concentrés sur le système de conception. Cette approche peut avoir des répercussions sur l’ensemble du système ; prenons donc un peu de recul pour en comprendre certaines.
Dans notre exemple d'interface, nous avons créé une page présentant des problèmes, notamment, mais sans s'y limiter :
- Utilisation d'un menu « hamburger » sans étiquette visuelle et manque de clarté concernant l'étiquette programmatique. Les menus « hamburger » ne fournissent pas de contexte clair, et les utilisateurs peuvent avoir du mal à comprendre leur fonction en l'absence d'étiquetage, tant visuel que programmatique.
- Aucun des champs du formulaire n'est marqué comme obligatoire ; les utilisateurs ne sauraient donc pas distinguer les champs obligatoires des champs facultatifs.
- Les bordures des champs du formulaire présentent un contraste insuffisant, ce qui signifie que les utilisateurs peuvent avoir du mal à repérer l'endroit où cliquer pour saisir leurs données (le rapport de contraste actuel est de 1,48 pour 1).
- Les libellés des champs du formulaire sont placés les uns à côté des autres. Les utilisateurs pourront-ils agrandir cette interface jusqu'à 200 % sans perte de contenu ni de fonctionnalité ?
- Aucune instruction relative à la saisie n'est fournie. Les utilisateurs sauront-ils comment éviter les erreurs si une saisie ne respecte pas le format requis ?
- Le contraste des couleurs du bouton « Enregistrer » n'est pas suffisamment élevé. De ce fait, les utilisateurs pourraient avoir du mal à le distinguer (le rapport de contraste actuel est de 2,38 pour 1).
Il existe peut-être encore davantage de problèmes que ceux-ci, mais on commence à comprendre à quel point l’accessibilité peut rapidement se détériorer à la suite de quelques incidents seulement. Si nous utilisons des atomes, des molécules et des organismes sans tenir compte de l’accessibilité, nous nous retrouverons avec des éléments présentant des problèmes d’accessibilité intégrés partout sur la page, voire dans l’ensemble de notre expérience utilisateur. L’audit de pages complètes peut s’avérer un peu intimidant, en particulier lorsque les problèmes sont liés à la conception inhérente d’un composant ou à la manière dont celui-ci a été construit.
Pour simplifier, revenons au tout début. Avant de créer un organisme ou une molécule, nous avions nos atomes. Nous pouvons commencer par examiner l’accessibilité de cette page en partant d’un seul atome : notre bouton. La conception de notre bouton d’exemple présente peut-être quelques lacunes, mais pour rester simple, concentrons-nous sur le fait qu’il ne respectait pas les règles de contraste des couleurs.
Cette erreur concerne non seulement notre « atome », mais aussi nos éléments « subatomiques » dans nos styles de texte et nos options de couleur. Plus haut dans cet article, nous avons évoqué ces éléments fondamentaux et la manière dont ils peuvent influencer ces conceptions. Nous pouvons désormais constater les conséquences de l’utilisation de ces fondements pour créer des « atomes » sans tenir compte de l’accessibilité.
Notre bouton présente un fond bleu ciel sur lequel figure un texte blanc. Le texte mesure 14 pixels, est en majuscules et en semi-gras. En effectuant un test à l'aide d'un outil de vérification du contraste des couleurs, nous constatons que ce bouton ne respecte pas les exigences en matière de contraste des couleurs. Cette combinaison de couleurs et de police présente un rapport de 2,39 pour 1, alors que le contraste doit être de 4,51 pour satisfaire au niveau minimum requis.
Mais comme je l'ai déjà mentionné, cette combinaison de couleurs n'aura pas seulement d'incidence sur ce composant. Nous savons qu'un composant présente un problème, et nous savons qu'il est très probable que cela affecte d'autres composants, car ce problème est structurel. C'est là que notre audit commence vraiment à jouer un rôle déterminant.
La conception doit tenir compte de l'accessibilité
C’est précisément à cause de problèmes tels que celui du contraste des couleurs que les concepteurs doivent prendre en compte l’accessibilité, en particulier dans le cadre des systèmes de conception. Il existe une idée reçue au sein des communautés de conception selon laquelle l’accessibilité relèverait principalement de la responsabilité des développeurs ; or, ces derniers ne peuvent pas résoudre les problèmes liés aux systèmes de conception lorsque ceux-ci sont axés sur le design.
En effet, une étude de cas réalisée l'année dernière par l'Deque a révélé que 67 % des problèmes d'accessibilité trouvent leur origine dans la conception.
Comme indiqué ci-dessus, la résolution des problèmes d’accessibilité peut entraîner une augmentation du temps et des coûts engagés si elle n’est pas prise en charge dès le début et de manière régulière. Les systèmes de conception étant notre moyen le plus efficace de faire évoluer nos produits à grande échelle, donner la priorité à l’accessibilité au sein de ces systèmes peut permettre de réaliser d’importantes économies de temps et d’argent. Lorsqu’elle est mise en œuvre à grande échelle via notre système de conception, la correction d’éléments tels que le contraste des couleurs peut entraîner des améliorations significatives en matière d’accessibilité pour nos produits.
Audit des systèmes de conception
Passer en revue le contenu des fichiers existants
Le moment le plus propice pour vérifier la conformité de nos conceptions en matière d’accessibilité est avant le développement. Cependant, nous sommes nombreux à travailler sur des systèmes de conception qui combinent des composants en production, des composants en cours de développement, voire des composants déjà en production mais non documentés. Les premières étapes d’un audit d’accessibilité de notre système de conception s’apparentent à celles d’un audit standard des composants. Nous souhaitons passer en revue nos composants les plus utilisés pour créer des conceptions et répertorier ce qui existe déjà.
Nous n’avons pas encore besoin de nous pencher sur la question de l’accessibilité. Notre objectif ici sera plutôt de recenser ce qui existe déjà et de regrouper les éléments ayant des finalités similaires. Avant de rendre notre travail plus accessible, nous devons comprendre dans quelle mesure notre système l’est déjà et quel chemin il nous reste à parcourir. Nous pouvons auditer un composant isolé, des composants liés entre eux ou l’ensemble d’un système de composants. Nous pouvons même auditer un simple bouton et obtenir des résultats exploitables. Tout dépend de l’approche que nous souhaitons adopter et des ressources dont nous disposons sur une période donnée.
Nous pouvons constater que les composants de conception existants comprennent des atomes, des molécules et des organismes. Il est important de les répertorier tous, tout en précisant leur fonction prévue. Il n'est pas nécessaire pour l'instant de rédiger une documentation complète ou quoi que ce soit de ce genre : une simple note suffira.
Capturer tous les composants actifs
De la même manière, nous devons recenser tous les composants dynamiques. Pour ce faire, nous pouvons nous référer à nos fichiers de conception, à nos bibliothèques de développement, à l'expérience utilisateur réelle ou à tout autre élément intermédiaire, à condition de recenser ce qui existe ou ce qui est prévu de réaliser. Nous devons également inclure des éléments tels que les différents états d'interaction, comme le survol ou la mise en surbrillance.
Pour ce faire, nous pourrions réaliser une capture d'écran de chaque bibliothèque de modèles et de chaque composant en ligne, puis les importer dans un fichier d'inventaire en indiquant la date, l'heure et l'emplacement. Ensuite, chaque élément capturé pourrait être placé sur une page nommée en fonction de son objectif. Capturer les composants de cette manière est utile pour documenter ce qui est actuellement en ligne, car ce qui existe aujourd'hui peut facilement changer dans un produit en ligne. Cela nous permet de nous souvenir où et quand ils existaient.
N'oubliez pas que l'objectif de l'inventaire de ces composants est avant tout d'auditer le système lui-même et de recenser ce qui existe. Cette étape de votre processus vise simplement à identifier les éléments avec lesquels nos utilisateurs interagissent et à nous assurer que nous sommes en mesure de comprendre l'impact global de chaque composant sur notre système.
Par exemple, nos boutons auront un impact plus important sur nos utilisateurs, car ils constituent un élément central présent dans l'ensemble de notre expérience utilisateur. D'autres éléments peuvent néanmoins avoir un impact significatif s'ils sont liés à des interactions essentielles, telles que la possibilité pour un utilisateur de se connecter.
Effectuer des recoupements et commencer à recenser les problèmes
Dans la dernière partie de notre audit du système, nous souhaitons nous assurer que ce que nous avons recensé est cohérent dans toutes les parties de notre expérience utilisateur et repérer tout cas isolé ou particulier. Nous devons vérifier que ces boutons, tels qu’ils apparaissent dans les maquettes, correspondent bien à ce qui figure dans la bibliothèque de développement et qu’ils sont également cohérents avec ce qui est en ligne.
Lorsque nous analysons ce qui est en ligne, nous pouvons croiser ces données avec celles de notre équipe de conception et commencer à identifier les lacunes. Vous vous dites peut-être : « Un simple audit de notre système de conception ne va pas suffire à améliorer l’accessibilité ! » Mais n’oubliez pas que l’accessibilité doit être intégrée dès le départ à notre stratégie de système de conception. Notre système de conception doit être audité et adapté pour nous permettre de développer l’accessibilité à grande échelle. Ces pratiques doivent aller de pair.
Maintenant que nous avons procédé à un audit de notre système, nous pouvons aborder les points à examiner pour garantir la conformité en matière d'accessibilité, ainsi que la manière de procéder.
Intégrer l'accessibilité dans notre audit
Problèmes courants d'accessibilité dans la conception
Que devons-nous vérifier au niveau de la conception ? Comme nous l’avons évoqué précédemment, 67 % des problèmes d’accessibilité trouvent leur origine dans la conception ; leur ampleur est donc peut-être plus importante que nous ne le pensons ! Les directives d’accessibilité du contenu web énumèrent de nombreux points, dont beaucoup concernent autant la conception que le développement. Même si notre exemple précédent portait sur un cas typique d’accessibilité dans la conception numérique, il y a bien d’autres aspects à prendre en compte que le simple contraste des couleurs.
Parmi les autres exigences standard en matière d'accessibilité qui doivent être prises en compte lors de la conception, on peut citer :
- Utilisation des couleurs
- Stratégie de contenu
- Structure des titres
- Comportements des liens
- États « survol » et « focus »
- Formulaire (erreurs, libellés, etc.)
- Mise en page (cohérence, réactivité)
- Éléments multimédias (légendes, texte alternatif, etc.)
- Ordre de navigation au clavier et blocs de contournement
- Calendrier
- Typographie
- Et bien plus encore !
Le « Guide de référence rapide » des WCAG constitue une excellente source d'information sur les éléments à prendre en compte : il répertorie tous ces points et bien d'autres encore, et propose des solutions pour se conformer à ces directives. Ce guide de référence rapide s'avère également très pratique lors de la réalisation de vos audits et de la vérification de vos composants.
Lorsque nous disposons d'un ensemble de composants classés par fonction, il nous est plus facile de dépasser le cadre de l'interface utilisateur pour prendre en compte ces autres besoins en matière d'accessibilité. Nous pouvons désormais examiner nos « atomes », nos « molécules » et nos « organismes » en fonction de leur style et de leur fonction, ce qui nous aidera à aller au-delà des problèmes superficiels.
La conception accessible ne se limite pas au contraste des couleurs.
Vous vous dites peut-être : « Les WCAG ne s’appliquent-elles pas uniquement au contraste des couleurs ou à l’interface utilisateur ? » Or, les audits d’accessibilité au sein de nos systèmes de conception ne se limitent pas au contraste des couleurs ou à l’interface utilisateur. L'audit d'accessibilité de notre système de conception concerne autant l'expérience utilisateur (UX) que l'interface utilisateur (UI). Comme nous l'avons vu, une grande partie de l'accessibilité réside dans d'autres aspects de notre système, notamment le contenu, la hiérarchie, les images et bien d'autres éléments encore. Bien que l'accessibilité de l'interface utilisateur soit importante, les concepteurs ont tendance à penser que notre responsabilité en matière d'accessibilité se concentre principalement sur les couleurs et les polices, car nous ne réalisons pas à quel point l'expérience utilisateur est étroitement liée à l'accessibilité.
Examinons donc ensemble un composant, en allant au-delà de l'interface utilisateur.
Cet exemple d'alerte est conçu pour comporter différents types de messages : information, réussite, avertissement et erreur. Cette alerte nous permet d'étudier plusieurs aspects liés à l'expérience utilisateur. Par exemple, pouvons-nous nous demander si ces icônes devraient comporter un texte alternatif ? Supposons que ces icônes ne comportent pas actuellement de texte alternatif, mais que nous estimions qu'elles devraient en avoir un, car nous souhaitons que cette icône transmette un message d'alerte aux utilisateurs qui ne la verraient pas.
Ainsi, dans notre audit d'accessibilité, nous pouvons noter qu'aucun texte alternatif n'est utilisé pour ces icônes et faire le lien avec la directive WCAG 1.1.1 « Contenu non textuel ». Si nous utilisons ces icônes ailleurs à des fins similaires, cette remarque figurant dans notre audit nous aidera à appliquer cet élément d'expérience utilisateur à de nombreux cas de figure différents.
Ou bien, imaginons que notre alerte d’erreur affiche plusieurs erreurs dans un même conteneur d’alerte. Nous devrons alors nous demander si cette alerte identifie les erreurs à corriger, leur emplacement et la manière de les corriger. Si notre alerte ne remplit pas ces critères, nous pouvons noter ce problème et le relier à l’exigence WCAG 3.3.1 « Identification des erreurs ».
Ce ne sont là que quelques-unes des questions que nous, en tant que concepteurs, pouvons et devons nous poser lorsque nous examinons nos composants existants et que nous en créons de nouveaux. Si nous disposons d’une vue d’ensemble de ces composants et d’une référence concernant leur contexte, il nous sera plus facile d’identifier les lacunes potentielles en matière d’accessibilité et de les intégrer à notre audit.
Une dernière chose avant d’aborder la manière de documenter un audit : notre audit du système de conception doit porter à la fois sur les éléments graphiques et sur le code en matière d’accessibilité. Que nos composants se trouvent dans une bibliothèque de composants ou qu’ils soient déjà en production, nous devrons également examiner leur code. En effet, même si nous pouvons résoudre 67 % des problèmes au niveau de la conception, comme pour toutes les questions d’accessibilité, notre travail ne se limite pas à une seule équipe.
Je sais que certains concepteurs peuvent être réticents à l'idée de vérifier le code pour détecter d'éventuels problèmes d'accessibilité, mais il n'est pas nécessaire d'être développeur pour effectuer un audit du code. Pour cela, nous pouvons collaborer directement avec les développeurs, voire effectuer une première analyse à l'aide d'outils qui nous permettent d'auditer le code, que ce soit au niveau des pages ou de composants spécifiques. De nombreux outils nous permettent d'auditer le code, que ce soit au niveau des pages ou de composants spécifiques.
Je recommande tout particulièrement le plugin Axe DevTools pour Chrome, qui constitue une excellente option pour les concepteurs souhaitant évaluer leurs systèmes de conception. Axe DevTools vous indique la nature du problème lorsque vous sélectionnez « Plus d’informations », les critères WCAG concernés ainsi que l’impact sur l’utilisateur. Grâce à cet outil, nous pouvons effectuer à la fois des tests automatisés et des tests manuels guidés afin de procéder à une révision approfondie de nos conceptions et de notre code.
Pour utiliser Axe DevTools :
- Dans Chrome, je vais faire un clic droit, choisir « Inspecter », puis sélectionner l'onglet « DevTools » d'Axe.
- Pour effectuer un audit d'un élément, vous pouvez sélectionner « Analyser une partie de ma page ». Sélectionnez ensuite la partie de la page que vous souhaitez analyser, puis cliquez sur « Analyser ».
- Utilisez l'outil « Mise en évidence » pour mettre en avant les éléments graphiques que vous souhaitez mettre en valeur.
- Enregistrez vos résultats ou exportez les problèmes sous forme de fichier CSV ou JSON
Comment consigner les résultats d'un audit
Jusqu’à présent, j’ai beaucoup parlé de ce qu’est un système de design et des éléments à prendre en compte lors d’un audit d’accessibilité d’un tel système, mais voyons maintenant comment documenter un audit. Je sais que j’ai évoqué à plusieurs reprises l’ajout d’éléments à notre audit, mais à quoi cela ressemble-t-il concrètement ?
Ajouter des informations contextuelles
Tout audit d'accessibilité, qu'il porte sur notre système de conception, notre code, nos pages, etc., nécessite de commencer par établir un contexte. Il convient de préciser qui effectue l'audit, de présenter un résumé de ce qui est examiné et d'indiquer le niveau d'accessibilité que nous souhaitons atteindre. Il faudra également définir le périmètre de l'audit, le calendrier et décrire le processus d'audit.
Ce contexte est essentiel, car notre audit fera toujours l'objet de références une fois achevé, et nous devons nous assurer que toute personne chargée de l'examiner dispose des éléments nécessaires pour le faire en toute connaissance de cause. Si notre audit date d'un certain temps, la personne qui l'examine saura qu'il n'est peut-être plus aussi pertinent. L'inclusion de ces détails nous aidera, ainsi que nos pairs, à tirer le meilleur parti possible de cet audit. Cela constituera également un excellent point de référence pour les audits futurs.
Créez votre audit
Puisque nous avons déjà abordé le sujet de l'audit en lui-même, je ne m'attarderai que brièvement sur la mise en place de notre audit. Disposer d'une liste des éléments que nous avons recensés nous aidera à identifier les problèmes existants, à évaluer leur gravité et à déterminer les solutions possibles.
Si nous utilisons Axe DevTools Pro, nous pouvons exporter les résultats et affiner les détails en fonction des besoins de notre organisation. Axe fournit toujours par défaut une grande quantité d’informations détaillées ; j’ai donc trouvé qu’il était facile de le personnaliser en fonction de mon public et des exigences de l’audit. Nous pouvons également ajouter manuellement des éléments au fichier CSV ou JSON d’Axe que nous utilisons, à mesure que nous rencontrons de nouveaux problèmes ou lorsque nous effectuons un audit dans notre outil de conception plutôt que dans le code.
En général, je recommande d'inclure au moins les éléments suivants :
- Élément/composant – Quel composant est concerné par ce problème ? Il est utile d'inclure des liens vers des captures d'écran, car celles-ci permettent de mieux comprendre ce dont nous parlons.
- Directive WCAG – Quelle directive WCAG concerne ce sujet ? Un lien vers la directive WCAG correspondante, via le guide de référence rapide des WCAG, peut grandement aider à replacer le sujet dans son contexte.
- Impact – quel sera l'impact sur les utilisateurs ou l'entreprise ? À quelle fréquence cet élément est-il utilisé (plus il est utilisé, plus l'impact est important) ? Cet élément est-il utilisé pour des actions indispensables (comme la connexion) ? Axe DevTools Pro fournira une estimation de l'impact, ce qui constitue un bon point de départ.
- Description – Décrivez plus en détail le problème que vous avez rencontré
- Recommandation – Expliquez à votre équipe comment elle peut résoudre le problème. Dans de nombreux cas, il existe plusieurs façons de résoudre un problème. Nous pouvons décrire les solutions possibles afin d’aider notre équipe à comprendre les différentes options.
Je vous encourage à adapter votre approche afin de trouver celle qui convient le mieux à vous et à votre équipe. L'essentiel est que vous vous efforciez de consigner les problèmes de manière à ce qu'ils puissent donner lieu à des actions concrètes et que votre organisation ou votre équipe puisse agir en conséquence.
Thèmes communs et éléments récurrents
De plus, lorsque vous menez et documentez votre audit, je vous recommande de regrouper les éléments qui reviennent fréquemment. Là encore, cela nous ramène à notre approche « atomique » : si un problème de rapport de contraste se manifestait sur de nombreux éléments différents, vous pourriez les regrouper en un ensemble de problèmes. Le regroupement et la classification par thèmes, en particulier pour l’audit de votre système de design, sont très importants car ils vous permettent d’obtenir un impact bien plus important sans avoir à effectuer de nombreux ajustements ponctuels à différents endroits. La force d’un système de design réside dans le fait qu’un seul changement peut avoir un impact considérable avec un minimum d’effort.
Faites la distinction entre l'intention et la mise en pratique
Autre point important à garder à l'esprit : vous vous rendrez probablement compte que vous ne repérez pas tout ce qui doit être rendu plus accessible lorsque vous effectuez seul l'audit de votre système de design. En effet, les designers ont tendance à travailler au sein de systèmes complexes, et les systèmes de design reposent avant tout sur une intention. Il y aura donc toujours des cas où ce que vous avez identifié lors de votre audit et corrigé ne correspondra pas à l'application de votre système de design.
Vos éléments de base sont peut-être excellents et accessibles, mais vos organismes nécessitent davantage d’attention, car ils sont plus spécifiques à certaines circonstances. Ou peut-être que la mise en œuvre des composants de votre système de conception n’est pas accessible en raison, par exemple, du texte que vous avez finalement choisi d’utiliser.
C'est en partie pour cela que j'ai passé en revue notre échelle atomique : pour nous aider à comprendre qu'il existe une différence entre l'intention et la mise en œuvre. Commencer par les systèmes de conception sera très utile, mais cela ne résoudra pas forcément tous les problèmes sur votre site en ligne, car la mise en œuvre est différente.
Que faire de votre rapport d'audit ?
Une fois notre audit terminé, quelle devrait être la prochaine étape ? Tout d’abord, vous devrez mettre votre équipe en mesure d’agir grâce aux conclusions figurant dans la feuille de calcul que vous avez créée. Recevoir une feuille de calcul contenant des centaines d’éléments aide à résoudre les problèmes, mais cela risque d’être intimidant si vous vous contentez de remettre cette feuille de calcul à une partie prenante en lui disant simplement : « Tenez, voilà ! »
Voici plutôt ce que vous devriez faire avec votre audit pour le rendre plus utile :
- Répertoriez les domaines d'impact et déterminez le nombre d'éléments classés comme critiques, graves, modérés, mineurs et correspondant aux meilleures pratiques.
- Identifier les thèmes clés, c'est-à-dire les éléments qui sont apparus le plus fréquemment dans l'ensemble du système.
- Élaborez un cadre d'analyse d'impact afin d'identifier les enjeux qui ont l'impact le plus important et qui nécessitent le moins d'efforts.
- Partagez les résultats avec votre équipe et votre organisation de manière claire et positive.
- Collaborer avec les parties prenantes afin de définir les priorités en matière d'améliorations.
Adaptez votre audit à votre public.
Le plus important dans votre audit d'accessibilité, c'est de veiller à ce qu'il débouche sur des actions concrètes et de partager les résultats avec votre équipe de manière à ce qu'elle puisse facilement en tirer des enseignements et agir en conséquence.
Vous trouverez ci-dessous un exemple de compte rendu d'audit destiné à un client, dans lequel je présente les problèmes les plus courants, les thèmes récurrents et les points ayant un impact majeur. Une fois notre audit terminé, nous devons veiller à présenter l'ensemble de nos constatations, mais de manière synthétique. En d'autres termes, nous devons mettre en évidence les points les plus urgents à corriger ainsi que les thèmes clés, et proposer un cadre d'impact permettant d'identifier les problèmes pouvant être résolus le plus rapidement possible tout en ayant le plus grand impact.
En combinant ces éléments avec notre audit complet, nous sommes en mesure de présenter les résultats sous une forme claire et accessible, et de collaborer avec les parties prenantes pour hiérarchiser les améliorations à apporter, tout en disposant d'informations détaillées permettant d'agir concrètement sur chaque point.
Concevoir avec les personnes handicapées, et non pour elles
Enfin, n’oubliez pas que l’accessibilité n’est qu’une forme de conception qui, comme toute conception, nécessite des discussions et des tests. La différence réside dans le fait que l’accessibilité vise à garantir que nos conceptions répondent aux besoins des personnes en situation de handicap.
L'un des aspects les plus essentiels de la conception accessible consiste à concevoir « avec » les personnes en situation de handicap plutôt que « pour » elles. Les WCAG ont été rédigées avec et par des personnes en situation de handicap ; elles constituent donc un excellent outil à utiliser lors d'un audit. Mais est-ce suffisant ? Non, comme pour toute conception, l'accessibilité exige que nous dialoguions avec les personnes et que nous nous informions sur leur situation particulière, notamment lorsqu'elles utilisent nos sites et nos produits.
L'audit ne peut pas se substituer aux tests et à la conception menés avec des utilisateurs en situation de handicap. Même si je ne vais pas proposer de stratégie de recherche inclusive parfaite dans cet article (peut-être dans un autre), je tiens à le souligner car je ne veux pas que l'on pense qu'un audit résume à lui seul la conception accessible. C'est un élément clé, mais nous devons continuellement être à l'écoute et respecter les besoins des utilisateurs et des personnes en situation de handicap. Je vous encourage à tirer parti des enseignements de vos audits, à trouver des moyens de demander leur avis aux utilisateurs, à tester vos idées avec eux et à accorder une attention particulière à vos utilisateurs marginalisés.
En résumé
Se lancer dans l'évaluation de l'accessibilité des systèmes de conception peut représenter un défi de taille, quel que soit votre niveau de maîtrise en la matière. Je tiens toutefois à vous encourager à rester curieux. De nombreux designers n'ont pas reçu de formation en matière d'accessibilité, et la responsabilité en incombe aux établissements d'enseignement, pas à vous. Le simple fait que vous souhaitiez vous former constitue déjà un grand pas en avant.
Si vous débutez dans l'évaluation de l'accessibilité des conceptions ou du code, essayez axe DevTools Pro, ouvrez le guide de référence rapide des WCAG, testez-les et notez vos observations. Posez-vous des questions. Posez des questions à votre équipe. Le simple fait de tester ces outils, de parcourir ces directives et de faire preuve de curiosité vous mènera déjà très loin. Honnêtement, une grande partie de mes connaissances en matière d'accessibilité provient de ces pratiques.
