Les corrections d’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 à limiter la portée de la correction. 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 déployez une correction, vous devrez revenir lors du prochain sprint pour la classe sœur, puis pour la classe sœur de celle-ci, et ainsi de suite, jusqu’à ce que quelqu’un admette que le travail consiste à « analyser le modèle d’interaction des fenêtres modales » 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 de fermeture 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 ces demandes, ou seulement de celle qui a fait l’objet d’une réclamation de la part d’un client ? »

Questions qu’il convient de se poser avant de voter

  • S’agit-il d’une instance ou d’une classe ? Combien de composants similaires existe-t-il ?
  • Portée de l’audit : ce composant, cette page, ce produit ?
  • Niveau de conformité aux WCAG : A, AA ou AAA ?
  • Tests : Axe, lecteur d’écran manuel, guide d’utilisation uniquement au clavier ?
  • Prévention des régressions : règle Lint, instantané de story, vérification en intégration continue ?
  • Quel sera le budget alloué aux travaux d’accessibilité une fois que ce projet aura été mis en œuvre ?

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 courant est de se limiter à 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 lancez une session gratuite de Planning Poker une fois que le périmètre a été défini.