Era a última sexta-feira antes do lançamento. O produto estava pronto. Os testes de QA, feitos. E foi nesse momento, às 17h, que alguém fez a pergunta que ninguém tinha feito nos últimos 18 meses: "Isto funciona com um leitor de ecrã?"
A Product Owner abriu o computador e ligou o VoiceOver pela primeira vez. Não para testar, só para ver o que acontecia. O que ouviu não foi o produto em que tinham trabalhado durante um ano e meio. Foi uma sequência de botões sem nome, formulários sem contexto, e modais que prendiam o foco sem saída possível. Para a Maria, que usa o NVDA para navegar, isto não é hipotético. Quando chega a um formulário assim, ouve apenas "botão, botão, botão". Sem contexto. Fecha o separador e segue em frente.
"Não foi má vontade. Foi porque ninguém fez a pergunta no momento certo."
A equipa tinha três opções. Lançar assim, com a promessa de corrigir depois. Atrasar o lançamento para remediar os problemas mais críticos. Ou fazer um levantamento real e perceber a dimensão do problema.
Escolheram a segunda, um atraso de duas semanas para corrigir o essencial. Mas ao fazer o levantamento, perceberam algo que ninguém esperava: os problemas não eram pontuais. Eram estruturais. Tinham crescido com o produto, camada a camada, durante 18 meses.
E foi aí que a pergunta mudou. Deixou de ser "quanto tempo precisamos para corrigir isto?" e passou a ser "como é que chegámos aqui?"
A resposta estava na linha do tempo do próprio projeto. Não num erro específico, mas no momento em que cada decisão foi, ou não foi, tomada.
- 1º Mês - Descoberta e Design: Integrar semântica HTML correta, labels e navegação por teclado teria custado horas de conversa num wireframe. O produto ainda era apenas uma ideia e ideias são fáceis de mudar.
- 6º Mês - Desenvolvimento: Corrigir um componente durante o sprint de construção: uma a duas horas. Já implica alterar código existente, mas o produto ainda não tinha utilizadores à espera.
- 18º Mês - Véspera do lançamento: O mesmo componente estava replicado em oito ecrãs diferentes. Corrigir um era corrigir todos. E haveria utilizadores reais do outro lado, sem conseguir usar o produto.
Há uma regra não escrita no desenvolvimento de produto: quanto mais tarde se encontra um problema, mais caro fica. Com acessibilidade, essa regra aplica-se com uma brutalidade particular. Durante o design custa 1×, uma conversa, alguns comentários no Figma, ninguém sente o esforço. Durante o desenvolvimento custa 10×, alterar código funcional, retestar, rever. Após o lançamento custa 100×, desmontar código em produção, regressões, utilizadores afectados, risco legal. Após uma auditoria externa, o custo já não se mede só em tempo.
O produto desta equipa não falhou por falta de capacidade técnica. Falhou porque a acessibilidade nunca foi incluída na definição de "pronto". Não estava nos critérios de aceitação, não aparecia nas demos de sprint, não era pergunta nas retrospectivas.
Quando a acessibilidade aparece apenas no fim, como uma validação de conformidade antes do lançamento, o produto já tomou demasiadas decisões sem ela. Nessa altura, já chega tarde demais para influenciar o que mais importa: a experiência de quem o vai usar. A pergunta não é “quando vamos validar acessibilidade?”. É “quantas decisões já foram tomadas sem ela, e que impacto terão na experiência dos utilizadores?”..
Quando isso acontece desde o início, deixa de ser uma tarefa separada. Na prática, significa coisas simples: uma user story não fecha sem critério de teclado. O Figma tem um componente de estado de foco antes de ir para desenvolvimento. A demo de sprint inclui trinta segundos com o VoiceOver ligado. Não é um processo mais lento. É um processo diferente, onde os problemas se resolvem quando ainda custam pouco.
A equipa lançou o produto com as correções críticas possíveis. O produto ficou mais acessível, mas não tão acessível quanto poderia ser. Algumas decisões já estavam demasiado entranhadas no desenho, no código e nos componentes para serem resolvidas sem impacto.
Esta história não é sobre uma equipa que ignorou a acessibilidade. É sobre uma equipa que, como tantas outras, só a encontrou no fim.
E quando a acessibilidade chega no fim, chega como urgência. Quando entra no início, entra como qualidade.
A pergunta certa não é apenas “o produto cumpre?”. É “quem consegue realmente usá-lo?”.
Na Mediaweb, ajudamos equipas a fazer essa pergunta no momento certo - no design, no desenvolvimento e nas decisões de produto. Se quiser avaliar a acessibilidade do seu produto ou integrar melhores práticas na sua equipa, fale connosco.