Chez Deque, nous sommes fiers de proposer une gamme complète d'outils et de services destinés à aider nos clients à réussir dans le domaine de l'accessibilité du Web. Cependant, la notion de « complet » dans ce contexte est en constante évolution. À mesure que nous comprenons mieux ce dont nos clients ont besoin pour réussir, nous adaptons notre offre en y intégrant leurs besoins.
Récemment, pour répondre directement à ce besoin, nous avons appris à améliorer la manière dont nous identifions les problèmes d’accessibilité et les communiquons aux équipes de développement de nos clients. Cela s’est traduit par des améliorations concrètes en termes de clarté et de précision des mesures correctives. Dans ce qui suit, je vais expliquer pourquoi cette amélioration des processus était nécessaire et présenter les avantages qu’elle apporte à nos clients.
Transmettez vos exigences à vos développeurs
Réfléchissez à ceci : qu’est-ce qui permet à une équipe de développement de rester motivée malgré un afflux récent de tâches complexes et inhabituelles ? Des exigences claires – c’est aussi simple que cela. Les développeurs sont prêts à travailler dur, mais ils attendent d’abord des chefs de produit qu’ils répondent à quelques questions qui, en apparence, semblent simples, mais qui sont en réalité difficiles. Les développeurs veulent savoir :
- Quels sont les objectifs fixés pour cette tâche ?
- Comment puis-je vérifier que j'ai atteint les objectifs fixés ?
Apportez des réponses mûrement réfléchies à ces deux questions, et admirez votre équipe transformer votre liste de tâches en un tas de sciure. Cette philosophie s'applique tout autant à la mise en conformité en matière d'accessibilité qu'à tout autre domaine.
Pourquoi La mise en conformité en matière d’accessibilité est un terme impropre
Pour certains développeurs, l’expression « mise en conformité en matière d’accessibilité » évoque une sorte de jeu de devinettes sadique. Si l’on tend l’oreille dans les locaux de développement, on peut percevoir toutes sortes de remarques empreintes de frustration : « Est-ce que ça fonctionne vraiment comme prévu ? », « Je suppose que ça fera l’affaire », etc. Pour comprendre comment nous en sommes arrivés à cette triste situation, il faut savoir comment les choses se passaient traditionnellement.
Autrefois, pour lancer un projet de mise en conformité à l’échelle de l’entreprise, il était courant que des experts en accessibilité viennent de l’extérieur, réalisent une série d’évaluations à la chaîne et remettent les résultats à l’équipe de développement interne avec le sourire. « Voici vos problèmes. Corrigez-les et le tour est joué. » Un service formidable, sans aucun doute ; mais, comme de nombreux développeurs ont une expérience limitée en matière d’accessibilité, ce transfert donnait souvent lieu à des regards perplexes, et des éléments cruciaux concernant la signification exacte du terme « corrigé » se perdaient dans la traduction.
Chez Deque, nous avons réussi à combler cette lacune en veillant non seulement à identifier les problèmes d'accessibilité pour nos clients, mais aussi à traduire ces problèmes en formules de solutions, qui comprennent des suggestions de mise en œuvre et des instructions de validation. Prenons l'exemple d'un problème d'accessibilité et voyons comment il peut être traduit du jargon de l'accessibilité vers le langage du développement.
Sam vérifie son programme de fidélité « Mileage Plan »
Sam, qui utilise un lecteur d'écran, souhaite réserver un vol auprès d'une compagnie aérienne fictive appelée Excellent Airways. Avant de réserver son vol, Sam souhaite connaître le solde de son compte de miles ; il se rend donc sur le site web de la compagnie et se connecte à son compte. La page « Compte » organise les informations en sections, chacune étant identifiée par l’un des courts titres suivants : « Portefeuille », « Programme de fidélité » et « Codes de réduction ». Or, les lecteurs d’écran ne reconnaissent absolument pas ces textes comme des titres, ce qui rend l’expérience de Sam assez déroutante. En effet, Sam ne bénéficie pas de l’organisation hiérarchique des informations que ces titres sont censés mettre en évidence.
Dans ce cas précis, tout repose sur sémantique. Sur la page « Compte », ce qu’on appelle les « rubriques » ne sont en réalité que <div> des éléments auxquels on a appliqué des styles afin qu’ils ressemblent à du texte de type « titre ». Cette approche convient aux utilisateurs voyants, capables de faire la distinction entre ces pseudo-titres et le reste du contenu textuel normal de la page, mais elle n’aide en rien les logiciels, tels que les lecteurs d’écran, à reconnaître l’importance de ces titres. Par extension, Sam ne peut pas non plus en reconnaître la signification.
Il ne suffit pas de signaler la lacune
Pour reprendre notre exemple hypothétique, les responsables produit d’Excellent Airways ont la situation bien en main : conscients de l’existence de certains problèmes, ils font appel à un groupe d’experts en accessibilité pour évaluer leurs pages de compte. Les experts identifient sans difficulté le problème lié aux titres. Parfait ! D’autant plus que ce type de problème d’accessibilité est extrêmement difficile, voire impossible, à détecter à l’aide d’outils automatisés. Excellent Airways en a vraiment eu pour son argent.
Tout semble aller bien pour l'instant. Le problème a été signalé, documenté et ajouté à la liste des tâches en attente. Quelques semaines plus tard, Amber, développeuse front-end chez Excellent Airways, repêche ce ticket, dont la description indique :
Amber, déjà désorientée, se met au travail et se heurte aussitôt à des difficultés.
Comme Amber s'y connaît un peu en balisage sémantique, elle suppose que qu'elle devrait au moins transformer chaque passage de texte en balise de titre (c'est déjà un bon début, et certains n'iront pas plus loin). Dans ce cas précis, cependant, les titres sont générés par une bibliothèque de code, elle ne peut donc pas simplement modifier le <div> balises vers un <h2> sur cette seule page sans entraîner de modifications à de nombreux autres endroits du site.
De plus, Amber se demande : « Même si je changeais le type de balise, comment saurais-je si les lecteurs d'écran reconnaissent ces titres ? » Elle a besoin de plus d'informations.
Transformer les problèmes en solutions
Prêts pour un aphorisme ? La solution au problème des problèmes sans solution consiste à ajouter des solutions à ces problèmes. Relisez cette dernière phrase ; laissez-la faire son chemin dans votre esprit.
Un ticket idéal pour la mise en conformité en matière d'accessibilité se compose de nombreux éléments. Chacun d'entre eux a un rôle précis, et ensemble, ils contribuent à la réussite de l'équipe de développement. Examinons chaque composante du ticket agile idéal pour la mise en conformité en matière d'accessibilité.
1re partie : Présentation générale
Une description très succincte du numéro dans son ensemble – rien d'extraordinaire à signaler ici. Néanmoins, chaque numéro doit se démarquer dans une liste, et chaque nouveau lecteur doit pouvoir se mettre rapidement au courant.
Partie 2 : Scénario utilisateur
Nous voyons ici le cas d'utilisation de la tâche de remédiation formulé sous la forme d'une « user story » agile. Cela permet :
- Préciser l'analyse de rentabilité à l'intention des responsables produit
- Justifier ce travail auprès des développeurs
Personnellement, je suis toujours surpris de constater à quel point les développeurs sont davantage motivés pour s'attaquer aux problèmes d'accessibilité lorsqu'ils ont sous les yeux un scénario utilisateur simple et bien formulé, qui met en avant les avantages concrets de la modification de code proposée.
3e partie : Comment reproduire le phénomène
Simple, mais extrêmement utile, cette méthode permet au développeur chargé du problème de le retrouver facilement et de savoir exactement ce qu’il doit rechercher. Associée à des captures d’écran jointes, elle évitera de nombreux e-mails exaspérés du type « Que vouliez-vous dire par “le lien à côté” ? » ou « Comment êtes-vous arrivé sur cette page ? ».
4e partie : Remédiation
Il s'agit d'un élément essentiel de la résolution du problème d'accessibilité ; c'est ici que Deque peut tirer parti des connaissances en développement de nos experts en accessibilité. Cette section comprend des instructions détaillées pour mettre en œuvre la solution au problème d'accessibilité en question, accompagnées d'exemples de code et d'autres options de correction (le cas échéant).
Il convient de noter que les recommandations formulées ici tiennent compte des spécificités du code source, de l’environnement de développement et des pratiques de codage propres au client. La relation étroite que nous entretenons avec les équipes de développement de nos clients nous permet également de prendre en compte des facteurs tels que la matrice de prise en charge des navigateurs et des technologies d’assistance de l’organisation.
En proposant des suggestions détaillées de mise en œuvre, cette section :
- Élimine les conjectures dangereuses et frustrantes
- Encourage l'adoption de solutions cohérentes pour des problèmes similaires tout au long du projet
Partie 5 : Critères d'acceptation
Nous proposons ici un guide détaillé, étape par étape, consacré à la validation, comprenant des instructions destinées aux débutants pour les cas où la validation nécessite l'utilisation de logiciels spécifiques, tels que les lecteurs d'écran, avec lesquels le développeur n'est peut-être que peu familiarisé.
Nous avons ainsi bouclé la boucle. Cette section permet au développeur d'affirmer en toute confiance qu'il a résolu le problème avec succès. En reproduisant l'expérience de l'utilisateur final, cette section permet :
- Veiller à une validation précise
- Favoriser l'empathie envers les utilisateurs
Conclusion
En identifiant non seulement les problèmes d’accessibilité, mais aussi en proposant des solutions adaptées aux équipes de développement agiles d’aujourd’hui, Deque s’efforce de redorer l’image de la mise en conformité en matière d’accessibilité, en la présentant comme une démarche positive et efficace qui contribue activement à rendre le Web accessible à tous. Le travail de mise en conformité n’a pas besoin d’être déroutant ni difficile, ni de se résumer à des tentatives au hasard et à des essais à l’aveuglette – et c’est une bonne nouvelle, car c’est exactement ce qu’attendent les équipes de développement d’aujourd’hui.
