3 stratégies pour développer des logiciels plus accessibles

Il n’y a pas un seul expert en accessibilité. C’est une responsabilité partagée, et tous les développeurs doivent tirer parti des connaissances des autres pour développer leur compréhension et leur manifestation de l’accessibilité. De la même manière, les principaux frameworks accessibles que les développeurs utilisent ne peuvent pas être considérés comme englobants. De la même manière que les développeurs ne créeraient pas une nouvelle fonctionnalité à l’aide d’un seul outil, ils devraient disposer de plusieurs entrées pour les guider dans l’accessibilité. Plus les vérificateurs d’accessibilité des développeurs sont robustes, mieux ils serviront les personnes ayant des besoins divers. L’auteur présente trois façons pour les développeurs d’éviter de se rabattre sur des outils et des directives d’accessibilité inadéquats et de suivre le seuil changeant de l’accessibilité.

La General Services Administration des États-Unis a récemment publié son plan d’action pour l’équité, qui met l’accent sur l’accessibilité au-delà du strict minimum pour tous les services gouvernementaux numériques. Ce passage d’une agence fédérale signale aux entreprises qu’elles devront emboîter le pas et s’efforcer d’atteindre une accessibilité qui dépasse les changements inclusifs de base.

Mais aller au-delà du strict minimum exige un état d’esprit différent de la part des développeurs. De nombreuses personnes chargées de repenser la barre pour l’accessibilité s’appuient trop sur un petit ensemble d’outils qui leur donnent une vision étroite lors de la construction. React, Vue et Svelte ont tous une accessibilité intégrée, mais les développeurs qui n’utilisent que ce qui sort du commerce risquent de devenir trop ciblés. De nombreux outils donnent la priorité aux éléments visuels de l’accessibilité parce qu’ils sont les plus visibles, mais qu’en est-il des utilisateurs ayant des problèmes auditifs ou de mobilité ?

De la même manière que les développeurs ne créeraient pas une nouvelle fonctionnalité à l’aide d’un seul outil, ils devraient avoir plusieurs entrées pour les guider à travers l’accessibilité. Plus les vérificateurs d’accessibilité des développeurs sont robustes, mieux ils serviront les personnes ayant des besoins divers.

J’ai travaillé dans le développement pendant près d’une décennie et j’ai passé les deux dernières années à créer des outils qui aident les concepteurs et les développeurs de logiciels à intégrer l’accessibilité dans leur métier. Voici comment les développeurs peuvent éviter de se rabattre sur des outils et des directives d’accessibilité inadéquats et suivre le seuil changeant de l’accessibilité.

Mélangez et assortissez vos outils d’accessibilité.

Chaque plate-forme de développement a son propre ensemble de directives et d’exigences en matière d’accessibilité. Par exemple, les normes d’accessibilité (a11y) pour le Web sont détaillées dans les Web Content Accessibility Guidelines (WCAG), Apple utilise les Human Interface Guidelines (HIG) et Android a son propre ensemble de directives. Les bibliothèques Web comme React et Vue ont des sections sur les meilleures pratiques d’accessibilité, tout comme les bibliothèques spécifiques aux composants comme React Select et Vue Select.

Mais si les développeurs se contentent de suivre les paramètres d’accessibilité de la plate-forme qu’ils construisent, ils laisseront inévitablement certaines lacunes d’accessibilité non comblées. Utiliser un seul ensemble de directives, c’est comme s’attendre à ce qu’une table des matières vous raconte toute l’histoire.

La meilleure façon d’éviter ce problème est de mélanger et assortir les outils et les directives. Si votre cadre se penche davantage vers la navigation visuelle, associez-le à l’arborescence d’accessibilité de Google ou à l’inspecteur d’accessibilité de Firefox, qui aident les développeurs à comprendre comment le contenu est exposé à la technologie d’assistance. Si vos besoins concernent principalement les personnes ayant une déficience auditive, essayez le lecteur d’écran Orcas pour les ordinateurs de bureau tels que MATE, GNOME et Unity. Le projet Sonar GNU/Linux est idéal pour accueillir les utilisateurs ayant des difficultés visuelles

Il existe également une multitude d’outils que les développeurs peuvent utiliser pour tester l’accessibilité sur toutes les plates-formes. Les linters sont parfaits pour vérifier le code, tandis que tous les modules complémentaires peuvent prendre en charge l’écriture de composants accessibles dans Storybook.

Plus vous utilisez d’outils en parallèle avec les exigences d’accessibilité de vos plates-formes principales, plus votre image de l’accessibilité est complète. Les outils ne doivent pas nécessairement être des outils de développement, ni les discussions sur la communauté Reddits Web Accessibility, Stack Overflow et le canal d’accessibilité Slacks peuvent vous indiquer les endroits que vos directives d’origine ne couvrent pas.

Apprenez de la législation sur l’accessibilité localisée.

Les développeurs doivent adopter une mentalité globale lors de la création de produits et, à leur tour, ils doivent reconnaître que l’adhésion à l’accessibilité change en fonction de l’emplacement. L’accessibilité est bien plus que traduire du texte et copier-coller à partir d’un cadre qui a fonctionné ailleurs.

Ce qui peut être juridiquement conforme ou inclusif dans un pays est probablement différent dans un autre. Par exemple, la Loi sur l’accessibilité pour les personnes handicapées de l’Ontario (LAPHO) n’a pas les mêmes spécifications que la norme européenne d’accessibilité numérique (EN301 549). Et ces types de législation ont tendance à aller au-delà de la portée des cadres techniques populaires comme React, de sorte que les développeurs ne peuvent pas créer de produits conformes en se référant exclusivement à ces cadres. Par exemple, la norme EN301 549 stipule que la biométrie ne peut pas être utilisée comme seul moyen d’identification de l’utilisateur. Cependant, les WCAG, un ensemble de directives de base dans le domaine de la technologie, ne mentionnent pas la biométrie.

Certains emplacements auront inévitablement des règles plus strictes en matière d’accessibilité, et les développeurs doivent appliquer ces normes dans leurs produits à tous les niveaux, même dans les pays qui ne les demandent pas. Les exigences d’accessibilité maximales que vous rencontrez doivent être le minimum que vous intégrez dans tout votre travail. Ce n’est pas seulement un devoir moral, mais une décision commerciale intelligente. À un moment donné, les réglementations vont évoluer et ce qui est perçu comme strict maintenant deviendra la norme plus tard. L’utilisation d’un certain nombre d’outils pour inclure une plus large diffusion de l’accessibilité dès le premier jour aidera à empêcher les entreprises de consacrer du temps et de l’argent à résoudre les problèmes rétroactivement.

Découvrez les zones grises des frameworks autonomes via des tests utilisateurs.

Il n’y a pas de certification d’achèvement pour l’accessibilité. Plus vous introduisez de produits ou de fonctionnalités, plus vous devrez tester et plus vous devrez aller au-delà des outils que vous utilisez pour surveiller votre accessibilité. Même si vous ne publiez pas activement, il y a toujours place à l’amélioration, en particulier pour les éléments plus complexes comme l’utilisation du clavier, la mise au point et les points de repère.

L’examen de l’accessibilité nécessite bien plus que le téléchargement de bibliothèques entières que vous jugez accessibles et la construction à partir de celles-ci. Les blocs de construction peuvent être accessibles, mais cela ne garantit pas que le produit final le sera. Les développeurs ont la responsabilité de tester le produit au fur et à mesure de sa construction à la fois à une échelle granulaire et dans son intégralité. Il faut le replacer dans son contexte, dans des expériences vécues pour confirmer qu’il est vraiment accessible.

Les développeurs doivent tester à plusieurs reprises les produits et fonctionnalités en personne ou à distance avec un groupe diversifié d’utilisateurs aux capacités, âges et antécédents variés. Chez Stark, nous testons en personne dans la mesure du possible, mais nous utilisons sinon Zoom pour mener des sessions de rétroaction, en veillant à ce que les sous-titres, l’interprétation en langue des signes et les autres besoins des utilisateurs soient satisfaits. Fable est une plate-forme brillante pour engager les personnes handicapées dans la recherche d’utilisateurs et pour mettre en évidence les méthodes de test qui révèlent les zones grises des frameworks autonomes. Pour nous, les tests utilisateurs ont montré que les frameworks n’empêchent pas les développeurs d’avoir un ordre de focus mal configuré pour les utilisateurs de clavier. Nous n’avons appris qu’en parlant avec des personnes qui utilisent la navigation au clavier pour les sites Web.

Il n’y a pas un seul expert en accessibilité. C’est une responsabilité partagée, et tous les développeurs doivent tirer parti des connaissances des autres pour développer leur compréhension et leur manifestation de l’accessibilité. De la même manière, les principaux frameworks accessibles que les développeurs utilisent ne peuvent pas être considérés comme englobants. Ils doivent être utilisés avec d’autres outils et tests pour suivre et continuer à pousser pour une barre d’accessibilité plus élevée.