Acessibilidade morre nos handoffs entre design, dev e QA

O problema: acessibilidade se perde entre etapas

O autor parte de uma experiência recorrente: ao revisar designs antes do desenvolvimento, conclui que a funcionalidade "pode ser implementada de forma acessível". Semanas ou meses depois, ao auditar o produto final, encontra imagens sem texto alternativo, modais que não retêm foco de teclado, atualizações dinâmicas não anunciadas a leitores de tela e partes da interface inacessíveis por teclado. Nenhum desses problemas estava no design original.

O autor descarta duas explicações simplistas. Não é que os desenvolvedores não se importem - eles já haviam trabalhado em produtos acessíveis antes. E treinamento adicional, embora às vezes necessário, não explica o que aconteceu nesse caso específico.

Design acessível é condição necessária, não suficiente

Uma revisão de design responde se algo pode ser implementado de forma acessível. Ela não documenta os detalhes de implementação: como o foco de teclado será gerenciado, quais mudanças serão anunciadas a tecnologias assistivas, como um componente customizado expõe sua semântica. Essas decisões pertencem ao desenvolvimento e precisam ser tomadas, documentadas e verificadas.

O autor também refuta a ideia de que desenvolvedores, por usarem teclado o dia todo, deveriam entender naturalmente de acessibilidade por teclado. Escrever código com atalhos de editor é uma habilidade diferente de navegar uma interface sem mouse, entender ordem de tabulação ou saber quando um leitor de tela precisa de uma live region.

O desaparecimento nos handoffs

A tese central é que a acessibilidade desaparece nas transições entre etapas, não por decisão consciente de ninguém. Cada fase tinha um dono: design, desenvolvimento, QA e auditoria de acessibilidade. O que não tinha dono era transportar a acessibilidade de uma etapa para a próxima. A auditoria não era rigorosa demais - chegava tarde demais.

O autor faz uma analogia: nenhum time aceitaria descobrir problemas de performance na semana do lançamento ou fazer a primeira revisão de segurança depois de todo o código escrito. Acessibilidade merece o mesmo tratamento.

Propostas concretas

Durante o design: requisitos de acessibilidade (ordem de foco, comportamento de teclado, anúncios, semântica, mudanças de estado) devem ser documentados junto com a especificação visual e transformados em critérios de aceitação testáveis.

Durante o desenvolvimento: alguém precisa ser responsável por confirmar que a implementação corresponde à intenção original. Bibliotecas compartilhadas de componentes acessíveis evitam reinvenção. Verificações automatizadas no pipeline de build capturam problemas comuns antes da auditoria final.

Durante a validação: um checkpoint de acessibilidade antes do lançamento, mesmo que não seja uma auditoria completa, permite corrigir erros enquanto ainda são baratos. Acessibilidade deve estar presente nas revisões de código e de funcionalidade que já existem, sem criar cerimônias novas.

A conclusão é que o problema não é de pessoas, mas de fluxo de trabalho: acessibilidade precisa de um dono em cada handoff, não apenas no último.