Pause: Avant d'entrer dans le vif du sujet, je vous invite à consulter mon premier article de blog consacré à l'accessibilité dans les pratiques de transformation agile. Dans cet article, nous avons abordé les pratiques culturelles en matière d'accessibilité qui permettront à vos équipes agiles de créer du contenu et des applications accessibles de manière durable.
Dans cet article, nous allons nous pencher sur l'accessibilité dans le cadre des pratiques des équipes agiles, afin de favoriser une accessibilité durable et efficace tout au long du cycle de vie du développement logiciel.
L'accessibilité passe avant tout par la conception
L'accessibilité commence dès la conception. Pour créer des conceptions accessibles, les équipes de conception peuvent notamment s'appuyer sur des personas intégrant des caractéristiques liées au handicap. Il est important d'éviter de créer des personas qui ne représentent que des personnes en situation de handicap ; il convient plutôt d'intégrer ces caractéristiques dans les personas existants. Lorsqu'ils élaborent leurs conceptions et leurs maquettes fonctionnelles, les concepteurs peuvent alors réfléchir aux étapes supplémentaires que le persona devra éventuellement effectuer si une application ou un site web s'avère inaccessible.
L'accessibilité est souvent au cœur des préoccupations en matière d'ergonomie, ce qui peut déboucher sur des conceptions plus adaptées à tous, et pas seulement aux personnes en situation de handicap. Par exemple, la ville d'Ottawa a mis au point une carte en ligne pour illustrer les nouvelles limites de la ville. Elle a mené une étude auprès des utilisateurs, à laquelle ont participé des personnes aveugles, et leur a demandé pourquoi elles souhaitaient utiliser cette carte.
Ils ont répondu qu'ils souhaitaient pouvoir rechercher une adresse et déterminer si celle-ci se trouvait à l'intérieur des nouvelles limites territoriales. La mairie a alors mis à jour la carte en y intégrant cette fonction de recherche, la rendant ainsi plus pratique d'utilisation : les personnes consultant la carte n'ont plus besoin de zoomer manuellement ni de se creuser la tête pour déterminer ce qui se trouve ou non à l'intérieur des nouvelles limites proposées.
Lorsqu'ils créent une conception accessible, les concepteurs ont longuement réfléchi à l'ergonomie et à l'accessibilité. Il est essentiel qu'ils communiquent efficacement l'intention de cette conception aux développeurs. Les équipes agiles communiquent de nombreuses façons différentes. Certaines équipes utilisent des tableaux blancs avec des annotations, tandis que d'autres réalisent des maquettes haute fidélité accompagnées d'annotations.
Peu importe la manière dont vous vous y prenez, il est très important de faire connaître votre intention à l'aide d'annotations. Voici, par exemple, des annotations de widgets pour la conception d'un lecteur multimédia :
Un élément aussi simple qu’une barre d’outils multimédia peut comporter de nombreuses interactions différentes, des interactions entre états alternatifs et des annotations indiquant la taille minimale des commandes. Ces annotations doivent préciser ce qui doit être lu par un lecteur d’écran, comment les lecteurs d’écran doivent contrôler les widgets, comment le rôle doit être codé dans ARIA, etc.
Il existe de nombreuses autres annotations relatives à l'accessibilité à prendre en compte, mais le plus important est que la communication et l'intention soient transmises du concepteur au développeur, car l'accessibilité commence avant tout dès la conception.
Démystifier les idées reçues sur l'accessibilité
Pour instaurer une culture de l'accessibilité au sein des équipes agiles, il faut tordre le cou à certains mythes concernant l'accessibilité. Premièrement, les équipes agiles pensent que les tests d'accessibilité ne peuvent pas être automatisés. Deuxièmement, elles considèrent que les tests d'accessibilité sont des tests d'ergonomie.
Chez Deque, nous savons que ces deux idées reçues sont fausses. Les tests d’accessibilité ne sont pas tous manuels ; en effet, plus haut dans cet article, nous avons évoqué les tests automatisés « axe clean » destinés aux équipes agiles. Lancer une extension de navigateur ou intégrer cet outil dans un test automatisé est un processus très simple.
En effet, il est recommandé que les équipes ne valident aucun code dans un dépôt ni ne finalisent aucune demande de fusion pour des éléments qui ne sont pas conformes aux normes Axe. Grâce à nos recherches approfondies menées dans le cadre d’audits, nous avons déterminé que l’accessibilité automatisée couvre environ 25 % des critères de succès définis par les WCAG et environ 50 % des problèmes d’accessibilité en termes de volume.
Même si certains éléments liés à l’accessibilité doivent être validés manuellement, comme le texte alternatif, vous pouvez tout de même écrire un test unitaire ou d’intégration simple pour vérifier la présence du texte alternatif, afin de servir de rappel aux développeurs. De plus, si vous disposez des informations de conception dont nous avons parlé précédemment, il est facile d’intégrer les exigences d’accessibilité dans un test. Par exemple, le code ci-dessous teste le logo « Deque » et l’attribut « alt » qui lui est associé :
<// Check the Deque Logo
ok(img.src.indexOf('logo.png' !== -1, 'image is the Deque logo image'));
equal(img.getAttribute('alt'), 'Deque Logo');>
Les tests visent en fin de compte à réduire les risques ; vous devez donc déterminer à quelle fréquence vous souhaitez refaire ces tests. En général, cela se fait lorsqu’une mise à jour majeure est publiée pour les lecteurs d’écran.
Bibliothèques de modèles accessibles
L'utilisation d'une bibliothèque de modèles peut sembler aller à l'encontre de la méthodologie agile, dans la mesure où vous concevez du code avant d'en avoir réellement besoin. Cependant, une bibliothèque de modèles peut vous aider à différents niveaux. Disposer d'une bibliothèque qui montre à quoi ressemble un composant ou un widget accessible dans divers états est très utile. Ce sont des éléments que vous pouvez réutiliser quel que soit le framework que vous utilisez. Si vous souhaitez découvrir à quoi ressemble une bibliothèque de modèles d’accessibilité, consultez Cauldron, la bibliothèque de modèles d’accessibilité d’ Deque.
TLDR : Résumé des pratiques d'accessibilité au sein des équipes agiles
L'agilité et l'accessibilité ne sont pas des concepts incompatibles. Si vos équipes agiles mettent en œuvre les pratiques décrites ci-dessus, elles pourront poursuivre leurs méthodes habituelles tout en créant des logiciels et des sites web accessibles et conformes, qui seront au final plus faciles à utiliser pour tous les utilisateurs. Pour rappel, ces pratiques d'équipe sont les suivantes :
- Démystifier les idées reçues selon lesquelles l'accessibilité ne peut pas être automatisée et qu'elle ne concerne que l'ergonomie.
- Sachant que l'accessibilité commence dès la conception, les concepteurs doivent apporter un soin particulier à leurs annotations en matière d'accessibilité.
- Réutiliser une bibliothèque de modèles accessibles, indépendante de tout framework.
