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 correção. Isso não aborda o que está por trás do problema: o restante da experiência de navegação por teclado, as mensagens 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 se refere à classe, não à instância. Envie uma correção e você voltará no próximo sprint para a classe irmã, e para 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 se fala 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 previsto para o trabalho de acessibilidade após a conclusão deste projeto?
Se for uma classe, e não uma instância, separe 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 fazer.
Defina o tamanho da turma, não da instância. Uma armadilha comum é meio dia; o padrão por trás disso é a história.
Assim como na estimativa de uma alteração no sistema de design, a correção na parte inicial do processo é pequena, e a cobertura na parte final é que representa o trabalho de fato. Consulte os outros exemplos de estimativas já elaborados ou inicie uma sessão gratuita de Planning Poker assim que o escopo for acordado.