Estimativa do tempo necessário para uma correção de acessibilidade
Como estimar uma correção de acessibilidade: os problemas de acessibilidade 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, 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. Se você entregar uma correção, vai ter que 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: “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 implementação desta funcionalidade?
Se for uma classe, e não uma instância, use 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 fazer.
Defina o tamanho da classe, não da instância. Uma armadilha comum é “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. Confira os outros exemplos de estimativas já feitas, ou inicie uma sessão gratuita de Planning Poker assim que o escopo for acordado.