Il s'agit de la deuxième partie d'une série de deux articles complémentaires, inspirés de la conférence donnée par Caitlin lors du salon CSUN 2017. La conférence et ces articles s'adressent principalement aux designers et mettent l'accent sur la conception de l'expérience utilisateur. 
Dans la première partie de la série « Design Before Code », j’ai présenté les trois premiers des cinq domaines clés à privilégier lorsque l’on aborde l’accessibilité, afin que vous puissiez établir de solides bases pour intégrer l’accessibilité à votre pratique du design. Ces domaines clés sont les suivants : comprendre les principes d’ergonomie, comprendre vos utilisateurs et travailler avec votre équipe. Cet article vous proposera des conseils techniques sur certains aspects pratiques de l’intégration de l’accessibilité dans votre processus de conception, et j’examinerai plus en détail les éléments qui nécessitent une réflexion approfondie lors de la phase de conception, notamment en vous donnant quelques conseils sur l’utilisation des bibliothèques de modèles pour faciliter l’accessibilité.
Conseil n° 4 : Comprendre les points délicats
Si vous travaillez directement (ou même indirectement) avec les développeurs chargés de mettre en œuvre ce que vous concevez, il est utile de comprendre que certains éléments sont plus difficiles à mettre en œuvre de manière accessible que d’autres. Certains éléments nécessitent une réflexion plus approfondie dès le départ, ainsi qu’une collaboration accrue pour déterminer la meilleure façon de les concevoir et de les mettre en œuvre. J’ai mis en avant quatre grands types d’éléments à surveiller, qui ont été mis en évidence au cours de mon expérience professionnelle dans le domaine de l’accessibilité.
Formulaires
Si vous avez déjà passé un peu de temps à concevoir des sites web ou des applications mobiles, vous savez sans doute que les formulaires peuvent être à la fois les éléments les plus simples et les plus délicats à concevoir sur une page. D’une certaine manière, les formulaires sont assez simples : vous savez quelles informations vous devez recueillir auprès de vos utilisateurs, et il n’existe traditionnellement qu’un nombre limité de types de champs que vous pouvez leur proposer pour collecter ces informations. Il n’est pas difficile de placer quelques champs sur une page, de les relier à une base de données et d’en rester là.
La difficulté réside dans la conception d’un formulaire facile à utiliser. Pour faire simple, la plupart des formulaires Web sont une source de frustration pour les utilisateurs. Il existe une multitude d’études (et une multitude d’opinions divergentes) sur ce qui rend un formulaire utilisable et pourquoi. Les WCAG (Web Content Accessibility Guidelines, ou Directives pour l'accessibilité des contenus Web) contiennent également un certain nombre de recommandations axées sur l'accessibilité des saisies utilisateur, avec un accent particulier sur les formulaires Web. (Rafraîchissez-vous la mémoire sur les WCAG sur le site du W3C.) En résumé : il est bien plus facile de créer un formulaire mal conçu et inutilisable qu'un formulaire de qualité.
Pour rendre un formulaire convivial, il faut tenir compte de plusieurs éléments : le type de champ est-il adapté au type de données que l'utilisateur va saisir ? L'étiquette et le texte d'aide associés au champ aident-ils l'utilisateur à comprendre quels types de données il peut y saisir ? En matière d'accessibilité, il existe quelques directives supplémentaires spécifiques. Selon les WCAG 2.0, les formulaires Web doivent respecter les exigences suivantes :
- Des libellés visibles pour chaque champ (qui restent toujours visibles !)
- Étiquettes programmatiques pour chaque champ
- Des textes d'aide et des messages d'erreur qui sont réellement utiles
- Accès au clavier pour chaque champ
- Des indicateurs de focus visibles sur tous les éléments accessibles via le clavier
- La possibilité de vérifier les informations que vous avez saisies dans un formulaire avant de le valider, en particulier si cette validation implique de confier vos données financières ou juridiques à des tiers
Si vous accordez de l'importance à l'ergonomie des formulaires que vous concevez, vous avez sans doute déjà pris certaines de ces mesures. Dans la plupart des cas, les exigences des WCAG concernant les champs de formulaire et les saisies des utilisateurs contribuent en réalité à rendre les formulaires encore plus ergonomiques, en vous obligeant à vérifier que vos formulaires remplissent bien leur fonction pour vos utilisateurs.
Tableaux
Je fais ici spécifiquement référence aux tableaux de données. L'utilisation de tableaux de données peut s'avérer très efficace pour transmettre des informations : un tableau de données interactif peut être un bon moyen de permettre aux utilisateurs de trier, d'organiser ou de trouver une donnée au sein d'un ensemble de données beaucoup plus vaste.
Cela dit, les tableaux de données peuvent être difficiles à rendre accessibles, en particulier s’ils sont complexes. Les lecteurs d’écran disposent d’un mode spécifique pour interagir avec les tableaux, et les utilisateurs de ces outils s’attendent généralement à ce que les tableaux soient lus d’une certaine manière. En particulier, les cellules des tableaux de données qui s’inscrivent dans un contexte spécifique doivent également être communiquées aux utilisateurs de lecteurs d’écran.
Si vous travaillez sur la conception d'un tableau de données complexe, je vous conseille d'y réfléchir un peu plus. Voici quelques questions à vous poser :
- Quelles sont les principales informations que les lecteurs devraient retenir de ce tableau ?
- Y a-t-il des informations non essentielles qui pourraient être supprimées ?
- Existe-t-il une autre façon de présenter les informations contenues dans ce tableau qui permettrait aux utilisateurs de mieux les comprendre et d'interagir plus facilement avec celles-ci ? (Un tableau de données est-il le moyen le plus approprié pour afficher ces informations ?)
- Le fait de répartir les données dans plusieurs tableaux permettrait-il aux utilisateurs de mieux comprendre ces informations ?
Il est judicieux de réaliser des tests d'ergonomie ou des tests A/B sur tous les tableaux de données complexes que vous concevez, ne serait-ce que pour déterminer si les utilisateurs sont capables d'interpréter suffisamment bien les informations qu'ils contiennent pour que ces données leur soient utiles. Dans la plupart des cas, repenser un tableau de données pour le simplifier, voire le transformer en un autre format, peut avoir un impact considérable sur l'ensemble des utilisateurs et faciliter considérablement l'accès aux données elles-mêmes.
Contrôles personnalisés
Ce que j'entends par « contrôles personnalisés » dans ce contexte, c'est un champ de formulaire ou tout autre type d'élément interactif qui n'est pas un élément HTML natif. Il est possible – et parfois nécessaire – d'utiliser des attributs HTML non standard et du JavaScript pour créer un contrôle interactif. C'est à ce type de contrôles que je fais référence.
One troublesome aspect of custom controls is that they’re much more difficult to make fully accessible. Screen readers and other assistive technology are built to work with native HTML elements, like <label> and <input>. If, instead, the developer decides to use a <div> with a content-editable attribute and styles it to look like a form field, that form field will not be accessible by default. It will actually take a lot more work to make the field fully accessible because all of the accessibility features will have added to the field from scratch.
Here you can see the form field “First Name” coded in two different ways: one using native HTML elements, and the other using the “contenteditable” attribute on a <div>. Both elements look the same through the magic of CSS, but only one of them is accessible.
Exemple de code accessible
<lable>First Name</label> <input type="text" name="fname" class="av-text" id="fname">
Exemple de code inaccessible
First Name <div id="input" contenteditable></div>
Les deux exemples se présenteront comme suit :
Dans certains cas, notamment pour les contrôles plus complexes, il n’est tout simplement pas possible d’utiliser un élément HTML natif. Cela s’explique très probablement par l’absence d’éléments natifs offrant les fonctionnalités requises par votre conception. Par exemple, la plupart des widgets de calendrier sont des contrôles personnalisés. HTML5 propose certes un type d’entrée appelé « date » en tant que contrôle natif, mais sa mise en œuvre et son apparence varient d’un navigateur à l’autre et ce type d’entrée n’est parfois même pas pris en charge. Dans le cas d’un calendrier ou d’un champ de saisie de date, il est généralement préférable, pour une expérience utilisateur optimale et plus cohérente, soit d’utiliser un plugin jQuery existant et de le personnaliser pour l’adapter à votre site, soit d’en créer un vous-même à partir de zéro.
Dans les deux cas, en tant que concepteur, vous devrez faire quelques efforts pour vous assurer que le widget a l’apparence, la convivialité et le comportement attendus. Cela implique notamment de chercher à comprendre comment les lecteurs d’écran utiliseraient un tel contrôle. Faites quelques recherches pour découvrir ce qui existe déjà (une recherche Google avec des termes tels que « widgets de calendrier accessibles » peut être un bon point de départ) et comment ces solutions fonctionnent. Choisissez un ou deux exemples et demandez à quelques utilisateurs de lecteurs d’écran de les tester afin de comprendre comment ils s’attendent à ce qu’un widget de calendrier fonctionne. Concevez un prototype et collaborez avec un développeur pour le mettre en œuvre, de manière à pouvoir tester votre propre version auprès d’utilisateurs de lecteurs d’écran. Lorsque vous aurez une version qui vous satisfait, trouvez un endroit approprié pour la stocker – par exemple, dans une bibliothèque de modèles – afin que d’autres équipes de votre entreprise puissent bénéficier du travail que vous avez effectué.
Contenu dynamique
Enfin, le contenu dynamique désigne le contenu qui est mis à jour en temps réel sur une page, sans que celle-ci ne soit actualisée. Voici quelques exemples : un téléscripteur boursier qui s'actualise toutes les 5 secondes, ou un champ « Créer un mot de passe » qui vous donne des conseils sur le niveau de sécurité de votre nouveau mot de passe au fur et à mesure que vous le saisissez. En général, ce type de contenu est fourni en temps réel car il présente une utilité pour l’utilisateur à ce moment précis. Mais en tant que concepteur, vous devez trouver le juste équilibre : si les informations sont insuffisantes, l’utilisateur ne sera pas informé autant qu’il le devrait ; si elles sont trop nombreuses, vous risquez de le submerger.
Le même principe s'applique aux utilisateurs en situation de handicap. Par exemple, si un utilisateur présentant un handicap cognitif interagit avec un élément de contrôle et que cette interaction provoque l'apparition soudaine de texte se déplaçant dans tous les sens, cet utilisateur risque d'être très désorienté, ou de considérer que ce que vous lui demandez de faire est trop difficile et d'abandonner. Autre exemple : si vous fournissez des mises à jour fréquentes aux utilisateurs lorsqu’ils créent un mot de passe, mais que ces mises à jour ne sont pas transmises automatiquement aux lecteurs d’écran, l’expérience des utilisateurs de lecteurs d’écran s’en trouvera moins fluide. En revanche, si vous transmettez chaque mise à jour aux lecteurs d’écran en temps réel, ceux-ci risquent d’être submergés au point d’oublier ce qu’ils étaient en train de saisir au départ.
Les deux meilleures choses à faire lors de la conception de contenu dynamique sont les suivantes :
- Demandez-vous quelles informations vos utilisateurs doivent pouvoir consulter immédiatement. S'ils n'en ont pas besoin tout de suite, pourquoi les affichez-vous ?
- Testez les prototypes auprès des utilisateurs. De quelles informations ont-ils besoin pour accomplir les tâches que vous leur demandez ? Est-il nécessaire de leur fournir ces informations de manière dynamique, ou non ? Si oui, quelle est la quantité minimale d'informations dont ils ont besoin pour que leur expérience soit satisfaisante ?
En règle générale, moins vous avez d'informations à communiquer de manière dynamique à l'utilisateur, moins vous aurez à vous soucier de la manière dont ces informations seront transmises aux utilisateurs en situation de handicap. Si vous devez tout de même communiquer des informations de manière dynamique, veillez à ce qu'elles soient faciles à comprendre, faciles à trouver et accessibles aux personnes utilisant des technologies d'assistance.
Point n° 5 : Guides de style et bibliothèques de modèles
Une grande partie de ce dont j'ai parlé peut être mise en œuvre de manière durable par une équipe ou une entreprise grâce à la création et à la mise en place d'une bibliothèque de modèles. Par « bibliothèque de modèles », j'entends un ensemble de composants réutilisables accompagnés d'instructions précisant quand, où, comment et pourquoi les utiliser. Une bibliothèque de modèles peut également inclure des éléments plus traditionnels propres à un guide de style, tels que des exemples de typographie et de couleurs, ou des instructions sur l'utilisation du logo.
Une bibliothèque de modèles peut se composer uniquement de maquettes ou contenir des exemples entièrement codés, prêts à être intégrés dans des applications. Elle peut être enrichie de manière semi-régulière par un designer ou un développeur, ou bien être gérée par une petite équipe dédiée. Peu importe qui l’a créée et qui en assure la maintenance, il faut comprendre qu’une bibliothèque de modèles est utile à toutes les personnes impliquées dans le processus de développement. Disposer d’une telle bibliothèque aide les designers à faire preuve de plus de cohérence dans la manière dont ils présentent l’image de marque de l’organisation et conçoivent les interactions. Une bibliothèque de modèles permet également de gagner du temps, car les concepteurs n’ont plus à concevoir les mêmes éléments à l’infini. Il en va de même pour les développeurs : si des extraits de code et des directives sont fournis pour la mise en œuvre, ceux-ci n’ont pas à passer leur temps à réinventer la roue. L’équipe d’assurance qualité peut également en tirer profit lors des tests, car elle pourra se référer à la bibliothèque de modèles pour vérifier si un composant se comporte comme prévu.
En matière d’accessibilité, la définition de fonctionnalités d’accessibilité pour les modèles d’une bibliothèque peut réduire considérablement la charge de travail nécessaire pour rendre une page ou un site accessible. Des combinaisons de couleurs accessibles peuvent être définies afin d’empêcher les concepteurs d’utiliser du texte présentant un faible contraste. Pour les éléments interactifs tels que les champs de formulaire, une bibliothèque de modèles pourrait inclure le placement des libellés, le ton et le style des messages d’erreur, ainsi que des instructions sur la manière d’associer par programmation les textes d’aide et les messages d’erreur. Les composants personnalisés, tels que les widgets de calendrier ou les listes déroulantes, ont tout à gagner à être intégrés dans une bibliothèque de modèles, en particulier si la plupart, voire la totalité, des problèmes d’accessibilité sont résolus en amont. Une grande partie du travail nécessaire pour rendre un composant personnalisé accessible peut être allégée, voire supprimée, grâce à la création d’un modèle réutilisable.
Voici une brève liste de bibliothèques de modèles proposant des modèles et des recommandations en matière d'accessibilité :
- Normes américaines en matière de conception de sites Web
- Système de conception Lightning de Salesforce
- BBC Global Experience - Langues
- Deque Bibliothèque de modèles
Et maintenant, quelle direction prendre ?
Il y a beaucoup à apprendre et à savoir sur l'accessibilité du Web. Et comme pour les autres principes de conception et de programmation, les normes d'accessibilité et les bonnes pratiques évoluent à mesure que la technologie change et se perfectionne. Même lorsque l'on dispose d'une compréhension de base des exigences et des techniques en matière d'accessibilité numérique, il faut parfois déployer beaucoup d'efforts pour se tenir au courant des nouvelles tendances et des dernières avancées.
C’est pourquoi il est d’autant plus important de commencer par les bases et de toujours y revenir. Comprendre les principes fondamentaux de l’ergonomie et s’appuyer sur cette compréhension comme cadre de référence lorsque vous échangez avec des utilisateurs de tous horizons peut vous apporter un éclairage précieux sur ce qui rend un contenu accessible ou non. Demander de l’aide à vos collègues pour combler vos lacunes vous aidera grandement à identifier les aspects de l’accessibilité du Web qui relèvent de votre domaine de compétence, et ceux qui n’en relèvent pas.
En tant que concepteur, l’accessibilité des produits commence souvent par vous, mais vous n’êtes pas le seul maillon de la chaîne de l’accessibilité. Il est extrêmement utile pour vous de connaître certains des enjeux liés à l’accessibilité concernant des éléments plus complexes, tels que les champs de formulaire ou le contenu dynamique, même si vous ne serez probablement pas chargé de leur mise en œuvre. De même, si vous lisez ces lignes en tant que développeur, sachez que la création et la mise en œuvre d’éléments ou de modèles accessibles ne reposent pas entièrement sur vos épaules.
La meilleure chose que vous puissiez faire pour rester concentré sur l’accessibilité est de continuer à vous former et à améliorer les choses petit à petit. Passer de 0 à 100 en matière d’accessibilité peut prendre des années, mais ne vous laissez pas décourager. L’expérience utilisateur accessible sera toujours un travail en cours. Si vous et votre équipe continuez à faire preuve d’empathie et à vous former, vos utilisateurs le remarqueront et l’apprécieront.
