Intégrer l'accessibilité au processus de votre équipe
Améliorer l'accessibilité de votre site peut s'avérer une tâche ardue. Si vous abordez l'accessibilité pour la première fois, la vaste étendue du sujet peut vous amener à vous demander par où commencer. Après tout, travailler pour s'adapter à une grande variété de capacités implique de prendre en compte une grande variété de problèmes.
N'oubliez pas que l'accessibilité est un effort d'équipe. Chaque personne a un rôle à jouer. Cet article présente les critères pour chacune des principales disciplines (gestionnaire de projet, concepteur UX et développeur) afin qu'elles puissent intégrer les bonnes pratiques d'accessibilité dans leur processus.
Chef de projet
L'objectif principal de tout chef de projet est d'essayer d'inclure le travail d'accessibilité à chaque jalon, en veillant à ce qu'il soit tout aussi prioritaire que d'autres sujets tels que les performances et l'expérience utilisateur. Vous trouverez ci-dessous quelques éléments de checklist à garder à l'esprit lorsque vous suivrez votre processus.
- Mettez à la disposition de l'équipe une formation sur l'accessibilité.
- Identifiez les critical user journeys (CUJ) sur le site ou dans l'application.
- Essayez d'intégrer une checklist d'accessibilité au processus d'équipe.
- Dans la mesure du possible, évaluez le site ou l'application à l'aide d'études utilisateur.
Formation sur l'accessibilité
Il existe de nombreuses ressources sans frais de qualité pour en savoir plus sur l'accessibilité du Web. En consacrant du temps à votre équipe pour qu'elle étudie le sujet, vous pouvez faciliter l'inclusion de l'accessibilité dès le début du processus.
Voici quelques ressources fournies par Google:
Web Accessibility by Google : cours de formation interactif sur plusieurs semaines.
Principes de base de l'accessibilité : guides et bonnes pratiques d'accessibilité écrits.
Consignes Material : Accessibilité : ensemble de bonnes pratiques d'UX pour la conception inclusive.
Identifier les critical user journeys
Chaque application comporte une action principale que l'utilisateur doit entreprendre. Par exemple, si vous créez une application d'e-commerce, chaque utilisateur doit pouvoir ajouter un article à son panier.
Certaines actions peuvent être secondaires et ne s'effectuer que de temps en temps. Par exemple, la modification de la photo de votre avatar est une fonctionnalité intéressante, mais elle n'est pas forcément essentielle pour chaque expérience.
Identifier les actions principales et secondaires de votre application vous aidera à hiérarchiser le travail d'accessibilité à venir. Vous pourrez ensuite combiner ces actions à une checklist d'accessibilité pour suivre votre progression et éviter les régressions.
Intégrer une checklist d'accessibilité
Le sujet de l'accessibilité est assez vaste. Une checklist des points importants à prendre en compte peut vous aider à vous assurer que vous avez tout couvert.
Il existe de nombreuses checklists d'accessibilité. Voici quelques exemples du secteur:
Checklist WebAIM WCAG Consignes d'accessibilité de Vox
Une fois la checklist en main, vous pouvez examiner vos actions principales et secondaires pour commencer à trier les tâches qui restent à accomplir. Vous pouvez être très tactique dans ce processus et même créer une matrice d'actions principales et secondaires, et déterminer pour chaque étape de ces processus s'il existe des éléments d'accessibilité manquants.
Évaluer avec des études utilisateur
Rien ne vaut de s'asseoir avec des utilisateurs réels et de les observer lorsqu'ils essaient d'utiliser votre application. Si vous adaptez l'accessibilité à une expérience existante, ce processus peut vous aider à identifier rapidement les domaines à améliorer. Si vous démarrez un nouveau projet, des études utilisateur précoces peuvent vous aider à éviter de passer trop de temps à développer une fonctionnalité difficile à utiliser.
Essayez d'intégrer les commentaires d'une population d'utilisateurs aussi diversifiée que possible. Tenez compte des utilisateurs qui naviguent principalement avec le clavier ou qui s'appuient sur des technologies d'assistance telles que les lecteurs d'écran ou les loupes.
concepteur UX
Les concepteurs ont tendance à concevoir en fonction de leurs propres biais. Par conséquent, si vous n'avez pas de handicap et que vous n'avez pas de collègues ayant un handicap, vous risquez de ne concevoir que pour certains de vos utilisateurs. Au fur et à mesure de votre travail, demandez-vous : "Quels sont tous les types d'utilisateurs qui pourraient s'appuyer sur cette conception ?" Voici quelques techniques que vous pouvez essayer pour rendre votre processus plus inclusif.
- Le contenu présente un contraste des couleurs suffisant.
- L'ordre des onglets est défini.
- Les commandes sont associées à des libellés accessibles.
- Il existe plusieurs façons d'interagir avec l'UI.
Le contenu présente un bon contraste des couleurs
L'objectif principal de la plupart des sites est de transmettre des informations à l'utilisateur, que ce soit par le biais de texte écrit ou d'images. Toutefois, si le contraste de ce contenu est faible, il peut être difficile à lire pour certains utilisateurs (en particulier ceux ayant une déficience visuelle). Cela peut avoir un impact négatif sur leur expérience utilisateur. Pour y remédier, veillez à ce que le contraste des couleurs soit suffisant pour tous les textes et les images.
Le contraste est mesuré en comparant la luminance d'une couleur de premier plan et d'une couleur d'arrière-plan. Pour le texte de petite taille (moins de 18 points avec une police normale ou 14 points en gras), nous vous recommandons un ratio minimal de 4,5:1. Pour le texte plus grand, ce rapport peut être ajusté à 3:1.
Dans l'image ci-dessous, le texte de gauche répond à ces contrastes minimaux, tandis que le texte de droite est à faible contraste.
Il existe plusieurs outils permettant de mesurer le contraste des couleurs, comme l'outil de sélection de couleur Material de Google, l'application de rapport de contraste de Lea Verou et aXe de Deque.
L'ordre des onglets est défini
L'ordre de tabulation est l'ordre dans lequel les éléments reçoivent le focus lorsque l'utilisateur appuie sur la touche Tabulation. Pour les utilisateurs qui naviguent principalement à l'aide d'un clavier, la touche Tabulation est leur principal moyen d'accéder à tout ce qui s'affiche à l'écran. Vous pouvez le considérer comme le curseur de la souris.
Dans l'idéal, l'ordre des onglets doit suivre l'ordre de lecture et s'étendre du haut de la page vers le bas, les éléments les plus importants apparaissant plus haut dans l'ordre. Cela permet à tous les utilisateurs de clavier d'accéder plus rapidement à ces éléments.
L'interface fictive ci-dessus est numérotée pour indiquer l'ordre des onglets. Créer un modèle comme celui-ci peut vous aider à identifier l'ordre des onglets prévu. Vous pouvez ensuite le partager avec les développeurs et les testeurs du contrôle qualité pour vous assurer qu'il est correctement implémenté et testé.
Les commandes ont des libellés accessibles
Pour les utilisateurs de technologies d'assistance comme les lecteurs d'écran, les libellés fournissent des informations qui ne seraient autrement que visuelles. Par exemple, un bouton de recherche qui n'est qu'une icône en forme de loupe peut être associé au libellé accessible "Rechercher" pour combler l'affordance visuelle manquante.
Voici quelques suggestions simples à suivre lorsque vous concevez des libellés accessibles:
- Soyez concis : écouter de longues descriptions peut être fastidieux.
- Essayez de ne pas inclure le type ou l'état de la commande. Si la commande est codée correctement, un lecteur d'écran l'annonce automatiquement.
- Concentrez-vous sur les verbes d'action. Utilisez "rechercher" plutôt que "loupe".
Vous pouvez envisager de créer un modèle avec tous vos boutons libellés. Vous pouvez le partager avec votre équipe de développement et votre équipe d'assurance qualité pour l'implémentation et les tests.
Plusieurs façons d'interagir avec l'UI et de la comprendre
Il est facile de supposer que tous les utilisateurs interagissent principalement avec la page à l'aide d'une souris. Lors de la conception, réfléchissez à la façon dont un utilisateur interagira avec un contrôle à l'aide d'un clavier.
Planifiez vos états de mise au point. Cela signifie déterminer à quoi ressemblera une commande lorsque l'utilisateur la sélectionnera avec la touche Tabulation ou appuiera sur les touches fléchées. Il est utile de planifier ces états à l'avance, plutôt que d'essayer de les intégrer à la conception plus tard.
Enfin, pour chaque point d'interaction, vous devez vous assurer que l'utilisateur dispose de plusieurs façons de comprendre le contenu. Essayez de ne pas utiliser la couleur seule pour transmettre des informations, car un utilisateur souffrant de déficience visuelle des couleurs risque de ne pas remarquer ces signaux subtils. Un exemple classique est un champ de texte non valide. Au lieu de simplement souligner en rouge un problème, pensez également à ajouter un texte d'aide. Vous couvrez ainsi plus de cas de figure et augmentez la probabilité qu'un utilisateur remarque le problème.
Développeur
C'est le rôle du développeur qui permet de combiner la gestion du focus et la sémantique pour créer une expérience utilisateur robuste. Vous trouverez ci-dessous quelques points à garder à l'esprit lorsque vous travaillez sur votre site ou votre application:
- L'ordre de tabulation est logique.
- La mise au point est correctement gérée et visible.
- Les éléments interactifs sont compatibles avec le clavier.
- Les rôles et attributs ARIA sont appliqués si nécessaire.
- Les éléments sont correctement libellés.
- Les tests sont automatisés.
Ordre logique des onglets
Les éléments natifs tels que input, button et select sont activés sans frais dans l'ordre des onglets et peuvent être sélectionnés automatiquement avec le clavier. Cependant, tous les éléments ne reçoivent pas le même comportement. Plus précisément, les éléments génériques tels que div et span ne sont pas activés dans l'ordre des onglets. Par conséquent, si vous utilisez un div pour créer un contrôle interactif, vous devrez effectuer des tâches supplémentaires pour le rendre accessible au clavier.
Voici deux options:
- Attribuez un
tabindex="0"à la commande. Vous pourrez ainsi au moins le mettre en surbrillance, mais vous devrez probablement effectuer des tâches supplémentaires pour prendre en charge les frappes au clavier. - Dans la mesure du possible, envisagez d'utiliser un
buttonau lieu d'undivou d'unspanpour tout contrôle semblable à un bouton. L'élémentbuttonnatif est très facile à styliser et est compatible avec le clavier sans frais.
Gérer la sélection
Lorsque vous modifiez le contenu de la page, il est important de diriger l'attention de l'utilisateur en déplaçant le focus. Un exemple classique d'utilisation de cette technique est l'ouverture d'une boîte de dialogue modale. Si un utilisateur qui utilise un clavier appuie sur un bouton pour ouvrir une boîte de dialogue et que le focus n'est pas déplacé vers l'élément de boîte de dialogue, sa seule option est de parcourir l'ensemble du site à l'aide de la touche Tabulation jusqu'à ce qu'il trouve la nouvelle commande. En mettant l'accent sur le nouveau contenu dès qu'il apparaît, vous pouvez améliorer l'efficacité de l'expérience de ces utilisateurs.
Compatibilité avec le clavier pour les éléments interactifs
Si vous créez un contrôle personnalisé tel qu'un carrousel ou un menu déroulant, vous devrez effectuer des tâches supplémentaires pour ajouter la compatibilité avec le clavier. Le Guide des bonnes pratiques d'écriture ARIA est une ressource utile qui identifie différents modèles d'UI et les types d'actions de clavier qu'ils doivent prendre en charge.
Pour en savoir plus sur l'ajout de la compatibilité avec le clavier à un élément, consultez la section Tabindex itinérant dans la documentation Google sur les principes fondamentaux de l'accessibilité.
Les rôles et attributs ARIA sont appliqués si nécessaire
Les commandes personnalisées ont besoin d'une prise en charge appropriée du clavier, mais aussi d'une sémantique appropriée. Après tout, sémantiquement, un div n'est qu'un conteneur de regroupement générique. Si vous utilisez un div comme base de votre menu déroulant, vous devrez vous appuyer sur ARIA pour ajouter des sémantiques supplémentaires afin que le type de contrôle puisse être transmis à la technologie d'assistance. Ici encore, le Guide des bonnes pratiques d'écriture ARIA peut vous aider à identifier les rôles, états et propriétés que vous devez utiliser.
En bonus, de nombreuses explications du guide ARIA sont accompagnées d'exemples de code.
Éléments d'étiquetage
Pour ajouter des libellés aux entrées natives, vous pouvez utiliser l'élément <label> intégré, comme décrit sur MDN. Cela vous aidera non seulement à créer une affordance visuelle à l'écran, mais aussi à donner à la saisie un nom accessible dans l'arborescence d'accessibilité. Ce nom est ensuite détecté par une technologie d'assistance (comme un lecteur d'écran) et annoncé à l'utilisateur.
Malheureusement, <label> n'est pas compatible avec l'attribution d'un nom accessible aux commandes personnalisées (comme celles créées à l'aide d'éléments personnalisés ou à partir de divs et de spans simples). Pour ces types de commandes, vous devez utiliser les attributs aria-label et aria-labelledby.
Tests automatiques
La paresse peut être une bonne chose, en particulier pour les tests. Dans la mesure du possible, essayez d'automatiser vos tests d'accessibilité afin de ne pas avoir à tout faire manuellement. De nombreux outils de test du secteur existent aujourd'hui pour vérifier facilement et rapidement les problèmes d'accessibilité courants:
aXe, créé par Deque Systems, est disponible en tant qu'extension Chrome et en tant que module Node (adapté aux environnements d'intégration continue). Ce court A11ycast explique différentes façons d'intégrer aXe à votre processus de développement.
Lighthouse est le projet Open Source de Google qui permet d'auditer les performances de vos applications Web progressives. En plus de vérifier si votre PWA est compatible avec des éléments tels que les Service Workers et un fichier manifeste d'application Web, Lighthouse exécute également une série de tests de bonnes pratiques, y compris des tests pour les problèmes d'accessibilité.
Conclusion
L'accessibilité est un effort d'équipe. Chacun a un rôle à jouer. Ce guide présente quelques éléments clés que chaque membre de l'équipe peut utiliser pour se familiariser rapidement avec le sujet et, espérons-le, améliorer l'expérience globale de son application.
Pour en savoir plus sur l'accessibilité, consultez notre cours Udacity sans frais et parcourez la documentation sur l'accessibilité disponible sur web.dev.