Lien original : https://equalentry.com/every-jira-ticket-is-your-accessibility-policy/ (Traduction automatique)
Résumé
Charlie Triplett explique comment l’accessibilité devient durable lorsqu’elle est intégrée aux outils quotidiens que les équipes utilisent déjà. Plutôt que de compter sur un changement d’état d’esprit ou d’attendre que tout le monde apprenne les WCAG, Charlie montre comment des critères d’acceptation, des accords d’équipe et des pratiques agiles aident les designers, développeurs et product owners à comprendre à quoi ressemble le succès pour de vraies personnes. En intégrant l’accessibilité dans les user stories et les tickets Jira, les équipes gagnent en autonomie, réduisent l’ambiguïté et créent des produits numériques qui fonctionnent pour tous.
Cet article est basé sur la présentation de Charlie Triplett à A11yNYC sur la monnaie sur laquelle se construit le logiciel moderne : le ticket Jira. Si c’est dans le ticket Jira, c’est fait. Si l’accessibilité n’y figure pas, il y aura une alerte de remédiation.
Intégrer l’accessibilité dans le développement produit quotidien
Le travail de Charlie Triplett vise à construire des programmes d’accessibilité qui manqueraient si on les supprimait. Il aborde l’accessibilité comme une discipline pratique centrée sur l’équipe plutôt que comme un exercice de conformité.
La première chose à comprendre est le fonctionnement du développement logiciel moderne. Les équipes opèrent dans des cadres agiles et leur travail est structuré par des outils tels que Jira, les accords d’équipe et les critères d’acceptation. Ces outils définissent déjà comment les équipes communiquent, planifient et livrent. Plutôt que de demander aux équipes d’adopter un nouvel état d’esprit, il faut se concentrer sur l’utilisation des outils sur lesquels elles s’appuient.
L’accessibilité devient durable lorsqu’elle est intégrée à ces systèmes existants. Les gens viennent au travail pour faire leur travail, pas pour entretenir un état d’esprit. Lorsque l’accessibilité fait partie de la définition de “prêt”, de la définition de “terminé” et des critères d’acceptation de chaque story, elle devient une partie naturelle du flux de travail.
C’est important de comprendre comment les équipes fonctionnent. Quand les spécialistes de l’accessibilité évitent les réunions agiles ou qualifient le scrum de « trop de réunions », ils ratent l’occasion d’influencer le processus. Les équipes ne peuvent pas intégrer l’accessibilité si les experts ne comprennent pas leur mode de fonctionnement.
Pourquoi la responsabilité est importante dans le travail d’accessibilité
Même si l’intention est bonne, « tout le monde est responsable de l’accessibilité » conduit souvent à ce que personne ne soit tenu responsable. Les équipes sont composées de personnes aux rôles spécifiques, et chaque rôle a des responsabilités définies. Chefs de produit, designers, développeurs et spécialistes assurance qualité (QA) contribuent chacun différemment.
Attendre de tous le même niveau d’expertise en accessibilité est irréaliste. Les équipes ont plutôt besoin de clarté sur qui rédige les critères d’acceptation, qui les réalise et comment le succès est mesuré. Les product owners rédigent généralement les critères d’acceptation, tandis que les designers et développeurs les mettent en œuvre. Cette structure reflète le fonctionnement déjà en place des équipes.
En alignant l’accessibilité sur les responsabilités existantes, les équipes peuvent l’intégrer sans confusion. Cette approche respecte les rôles et évite de les surcharger avec des attentes hors de leur périmètre.
Les équipes prospèrent quand les attentes sont testables et sans ambiguïté. Les critères d’acceptation fournissent cette clarté. Ils aident les équipes à comprendre à quoi ressemble le succès pour les personnes utilisant des aides techniques ou des paramètres d’appareil comme le texte agrandi.
Comment les critères d’acceptation créent clarté et collaboration
Les critères d’acceptation sont des énoncés courts et testables décrivant ce qui doit être vrai pour qu’une fonctionnalité soit considérée comme terminée. Ils aident les équipes à comprendre les besoins de l’utilisateur et à s’aligner sur le résultat attendu.
Deux formats courants existent : les user stories et les critères de type Gherkin. Les user stories décrivent ce qu’un utilisateur veut et pourquoi. Les critères Gherkin décrivent ce qui est vrai, quelle action se produit et quel résultat doit suivre. Les deux formats facilitent la communication.
« Vous réaliserez probablement que certains détails manquent et que vous devrez parler avec vos développeurs et designers avant de pouvoir finir les stories. C’est une bonne chose ! Identifier les parties manquantes et réduire la portée avant même de construire, c’est exactement ce que Gherkin met au jour », écrit Nic Werner.
Les critères d’accessibilité peuvent être intégrés aux user stories. Par exemple, un bouton de panier peut avoir des états visuels par défaut et au survol, mais le design peut ne pas inclure d’état de focus. Lorsque les critères d’acceptation exigent un indicateur de focus visible, le développeur doit demander des précisions au designer. Cela favorise la collaboration sans obliger l’intervention d’un expert en accessibilité.
Les critères peuvent aussi couvrir le comportement des lecteurs d’écran, l’interaction au clavier, les lecteurs d’écran mobiles et les paramètres d’appareil comme le texte agrandi. Ces critères poussent les équipes à penser à des personnes réelles et à des cas d’usage concrets.
Avec le temps, les équipes deviennent plus autonomes. Elles posent moins de questions basiques et commencent à poser des questions plus nuancées. Ce changement libère les experts en accessibilité pour qu’ils se concentrent sur des problèmes complexes plutôt que de répéter des conseils fondamentaux.
Étapes pratiques pour les organisations
Les organisations peuvent commencer par intégrer l’accessibilité aux outils et processus qu’elles utilisent déjà. Les accords d’équipe peuvent inclure des attentes d’accessibilité dans la définition de « prêt » et la définition de « terminé ». Cela garantit que l’accessibilité est prise en compte avant le début du travail et vérifiée avant la livraison.
Les product owners peuvent ajouter des critères d’acceptation d’accessibilité aux user stories. Les designers peuvent annoter les fichiers Figma avec des informations d’accessibilité. Les développeurs peuvent implémenter les comportements clavier, lecteurs d’écran et paramètres d’appareil dans leur flux de travail habituel.
Les équipes peuvent utiliser des ressources comme le guide de bonnes pratiques ARIA (APG) ou des outils comme le site AtomicA11y. Ces ressources fournissent des conseils pratiques au niveau des composants qui peuvent être copiés directement dans les tickets Jira. Elles aident les équipes à ne pas réinventer la roue et à assurer la cohérence entre les projets.
En se concentrant sur la clarté, la communication et des outils partagés, les organisations peuvent construire des programmes d’accessibilité qui s’étendent aux équipes et aux produits.
Une voie durable
Cette approche montre que l’accessibilité devient durable lorsqu’elle est tissée dans le travail quotidien. Les critères d’acceptation aident les équipes à communiquer clairement, à collaborer efficacement et à comprendre ce que le succès signifie pour de vraies personnes. Quand l’accessibilité fait partie du flux de travail, les équipes gagnent en confiance et en autonomie.
Cette méthode respecte les rôles, réduit l’ambiguïté et construit des programmes durables. Elle fait passer l’accessibilité d’un effort centré sur des spécialistes à une pratique partagée et pragmatique, ancrée dans les outils que les équipes utilisent déjà.
Voir la vidéo : https://www.youtube.com/watch?v=DmD6ITUMExI