Estimation du temps nécessaire à la mise en place d'une correction en matière d'accessibilité
Comment évaluer l'ampleur d'une correction d'accessibilité : les problèmes d'accessibilité (a11y) correspondent à des fonctionnalités que vous n'avez pas intégrées dès le départ. Pourquoi il faut évaluer l'ampleur du problème dans son ensemble, et non pas un cas isolé.
Les corrections liées à l’accessibilité ne sont pas des bogues. Ce sont des fonctionnalités que l’équipe n’avait pas intégrées lors de la première version.
Considérer un problème d’accessibilité comme un bug (« corrigez la fenêtre modale pour qu’elle retienne le focus ») revient à ne s’attaquer qu’à la partie visible du problème. Cela ne prend pas en compte les éléments dont dépend ce problème : le reste de la navigation au clavier, les annonces du lecteur d’écran, le contraste des couleurs qui présente probablement le même problème dans la fenêtre modale suivante. La plupart des « petites corrections d’accessibilité » constituent des points d’entrée vers une catégorie de problèmes qui touche l’ensemble du composant.
L’estimation réaliste porte sur la classe, et non sur l’instance. Si vous livrez un correctif, vous reviendrez lors du prochain sprint pour le « frère », puis pour le « frère » de ce « frère », et ainsi de suite, jusqu’à ce que quelqu’un admette que le travail consiste à « analyser le modèle d’interaction modal » et qu’il en évalue l’ampleur en conséquence.
Ce qui se dit dans la salle
Front-end : « L’ajout du “focus trap” prend une demi-journée. »
Question : « Le bouton “Fermer” est-il annoncé par les lecteurs d’écran ? »
Concepteur : « Le contraste du bouton secondaire est-il satisfaisant ? »
Introduction : « Combien d’autres verbes modaux ont la même forme ? »
PM : « Est-ce qu’on s’occupe de toutes, ou seulement de celle qui a fait l’objet d’une réclamation de la part des clients ? »
Questions qu’il convient de se poser avant de voter
- S’agit-il d’une instance ou d’une classe ? Combien y a-t-il de composants similaires ?
- Portée de l’audit : ce composant, cette page, ce produit ?
- Niveau de conformité WCAG : A, AA, AAA ?
- Tests : Axe, lecteur d’écran manuel, guide pas à pas utilisant uniquement le clavier ?
- Prévention des régressions : règle Lint, instantané de story, vérification CI ?
- Quel sera le budget alloué aux travaux d’accessibilité une fois que ce projet aura été mis en place ?
S’il s’agit d’une classe plutôt que d’une instance, utilisez la fonction split pour séparer le composant auquel les clients ont accès du reste de l’audit, puis évaluez chacun d’entre eux par rapport à ce à quoi vous vous engagez réellement.
Définissez la portée de la classe, et non celle de l’instance. Un « piège de focalisation » correspond à une demi-journée ; le modèle qui se cache derrière, c’est l’histoire.
Tout comme l’estimation d’une modification du système de conception, la correction en amont est mineure et c’est la couverture en aval qui constitue le véritable travail. Consultez les autres exemples d’estimations concrètes, ou organisez une session gratuite de Planning Poker une fois que le périmètre aura été défini.