Estimativa do tempo necessário para uma correção de acessibilidade
Como estimar uma correção de acessibilidade: os problemas de acessibilidade (a11y) são recursos que você não incluiu na versão inicial. Por que avaliar a magnitude do problema como um todo, e não apenas um caso isolado.
Correções de acessibilidade não são bugs. São recursos que a equipe não incluiu na versão inicial.
Tratar um problema de acessibilidade como um bug (“corrija o modal para que ele retenha o foco”) limita a solução a esse problema específico. Isso não leva em conta os fatores dos quais a solução depende: o restante da experiência de navegação por teclado, os anúncios do leitor de tela e o contraste de cores, que provavelmente apresenta o mesmo problema no próximo modal também. A maioria das “pequenas correções de acessibilidade” são pontos de entrada para uma classe de problemas que se estende por todo o componente.
A estimativa realista diz respeito à classe, não à instância. Envie uma correção e você voltará no próximo sprint para lidar com a classe irmã, e com a irmã dessa, até que alguém admita que o trabalho é “auditar o modelo de interação modal” e faça a estimativa com base nisso.
O que é dito na sala
Front-end: “Adicionar a ‘focus trap’ leva meio dia.”
Pergunta de controle de qualidade: “O botão ‘Fechar’ é anunciado pelos leitores de tela?”
Designer: “O contraste do botão secundário está adequado?”
Introdução: “Quantos outros verbos modais têm a mesma forma?”
PM: “Vamos verificar todos ou só aquele sobre o qual os clientes reclamaram?”
Perguntas que vale a pena fazer antes de votar
- Isso é uma instância ou uma classe? Quantos componentes semelhantes existem?
- Escopo da auditoria: este componente, esta página, este produto?
- Nível de conformidade com as WCAG: A, AA, AAA?
- Testes: axe, leitor de tela manual, orientação usando apenas o teclado?
- Prevenção de regressão: regra do Lint, snapshot da história, verificação de CI?
- Qual será o orçamento contínuo para o trabalho de acessibilidade depois que isso for implementado?
Se for uma classe, e não uma instância, utilize a função split para separar o componente com o qual os clientes interagem da auditoria do restante e avalie cada um em relação ao que você realmente está se comprometendo a cumprir.
Defina o tamanho da turma, não da instância. Uma armadilha comum é o “meio dia”; o padrão por trás disso é a história.
Assim como estimar uma mudança no sistema de design, a correção na parte upstream é pequena, e a cobertura na parte downstream é o trabalho propriamente dito. Consulte os outros exemplos de estimativas já realizadas, ou inicie uma sessão gratuita de Planning Poker assim que o escopo for acordado.