Como aprimoramos os testes de acessibilidade

No início da nossa jornada de acessibilidade, geralmente agrupávamos os testes de acessibilidade em duas categorias: automatizados e manuais. Os primeiros para identificar rapidamente os problemas mais fáceis de detectar por algoritmos e os segundos para tudo o mais, que exigia mais tempo e atenção para ser encontrado. Os testes automatizados se encaixam bem em processos rápidos, como a integração contínua (CI), enquanto os manuais exigiam uma coordenação cuidadosa com testadores qualificados para cobrir tudo o que as ferramentas automatizadas não conseguiam.

Ao longo do caminho, descobrimos que, na verdade, existe um ponto de equilíbrio entre essas duas abordagens. Em parceria com a Assistiv Labs, combinamos processos melhores com testes de serviço de ponta a ponta para criar um fluxo de trabalho de testes que redefine o que é automatizado e o que é manual. É algo intermediário, uma abordagem híbrida que aumenta drasticamente a cobertura automatizada e reduz a sobrecarga de coordenação manual.

Agora detectamos problemas claros e fáceis de corrigir em horas, em vez de semanas. Os nossos novos processos identificam automaticamente o que é urgente e enviam os problemas para as equipes certas, que normalmente os resolvem em poucos dias.

Os resultados foram tanto técnicos quanto culturais. Fornecemos feedback de acessibilidade muito mais rápido, as equipes resolvem bugs mais rapidamente e os engenheiros da Asana começaram a pensar de forma diferente sobre os problemas de acessibilidade.

Criação de processos para priorizar bugs de acessibilidade

Na escala da Asana, é essencial ter uma estrutura de priorização robusta, apoiada por processos e princípios de governança. As equipes precisam saber o que precisa ser agendado nos seus backlogs, para quando, e o que requer atenção neste momento.

Mas é fácil subestimar a dificuldade de priorizar os bugs de acessibilidade. A prioridade é baseada em uma matriz vertiginosa de fatores únicos, incluindo tecnologias assistivas, navegadores, grupos de usuários afetados, feedback dos usuários, área do produto, dificuldade de correção, soluções alternativas, conformidade com as WCAG e contexto histórico. Alguns bugs podem existir há muito tempo, mas só foram detectados recentemente. Outros aparecem com novos recursos. E alguns são regressões: funcionalidades que antes eram acessíveis, mas agora não são.

Para criar uma estrutura, definimos formalmente diferentes tipos de bugs de acessibilidade para que pudéssemos projetar fluxos de trabalho simplificados para cada um deles. Um passo essencial foi definir o que constituía uma regressão e o que não constituía.

regressão (s)

Um problema documentado (existe algum registro de que isso funcionava, como bugs anteriores, tópicos de comentários, capturas de tela ou gravações de tela?), reproduzível (um colega consegue reproduzi-lo usando as etapas descritas?) que antes funcionava e agora não funciona mais.

As regressões podem naturalmente receber alta prioridade: a última coisa que alguém quer é ter um retrocesso na acessibilidade. Isso pode simplificar muito a priorização em muitos casos.

No entanto, há um detalhe. As regressões são definidas por capturas de tela do antes e do depois. Por exemplo, um instantâneo anterior pode ser um vídeo da funcionalidade funcionando e um instantâneo posterior pode ser um vídeo de um novo resultado problemático. Os bugs naturalmente têm snapshots posteriores. Mas encontrar o instantâneo do “antes” geralmente requer uma investigação profunda.

Sem uma fonte confiável de instantâneos anteriores, muitas vezes não valia a pena investigar se um bug poderia ser priorizado como uma regressão. Foi aí que um novo tipo de automatização se mostrou imensamente útil.

Automatização de acessibilidade de ponta a ponta

Os testes totalmente automatizados não são novidade para os testes de acessibilidade ou para a Asana. No passado, o axe DevTools e o jsx-a11y para React nos forneciam uma cobertura ampla e horizontal. Mas eles são superficiais. Achamos que a estimativa simbólica de 30% para testes automatizados em todo o setor estava bastante próxima dos critérios das WCAG que estávamos alcançando. A cobertura limitada significava que os testes manuais ainda estavam encontrando bugs que as ferramentas automatizadas não haviam detectado.

Precisávamos de ferramentas que pudessem ir mais a fundo. Ferramentas mais alinhadas aos nossos princípios de pesquisa de usuários e governança. E foi isso que encontramos na Assistiv. Os testes para o serviço de ponta a ponta da Assistiv são escritos do zero pelos engenheiros da Assistiv com base nos fluxos de usuários e nos parâmetros de teste que fornecemos. Os pacotes incorporam atalhos do teclado, leitores de tela reais, navegadores e visão de máquina com a tecnologia da nuvem da Assistiv Labs. O resultado é mais do que uma simulação, com eventos transmitidos a uma máquina da mesma forma que um usuário humano faria, maximizando a cobertura das WCAG e de questões de acessibilidade mais amplas.

A automatização de acessibilidade de ponta a ponta é radicalmente diferente da automatização tradicional, interagindo com a Asana para realizar tarefas da mesma forma que um testador manual faria. É possível cobrir até 75 % dos critérios das WCAG, dependendo do cenário de teste. E ainda há especialistas em pensamento crítico em tempo real supervisionando tudo isso. Pessoas da Asana e da Assistiv estão envolvidas na concepção de ações representativas do usuário e na revisão dos resultados, elevando drasticamente o nível dos testes automatizados em termos de escopo, frequência e precisão.

Combinando forças

Com uma sólida estrutura de priorização em vigor e uma nova automatização que passou de encontrar uma minoria de bugs para encontrar a maioria, implementamos um poderoso fluxo de trabalho de priorização.

Primeiro, os testes automatizados são sincronizados com o pipeline de engenharia existente da Asana. Novos problemas são detectados quase em tempo real e correlacionados com as alterações de código que provavelmente os causaram.

Em seguida, um engenheiro da Assistiv faz uma revisão para filtrar os falsos positivos e registra um problema no backlog da Asana com o impacto contextualizado para o usuário e as orientações de remediação. Como os testes automatizados são executados continuamente, um instantâneo anterior está prontamente disponível e as regressões podem ser facilmente classificadas. Mantemos fluxos de trabalho automatizados na Asana que encaminham o problema para a equipe correta.

Na prática, isso significa que as regressões geralmente são sinalizadas dentro de 24 horas após uma implantação e documentadas de uma maneira que seja fácil de entender para engenheiros sem experiência em acessibilidade. Isso permite que a nossa equipe de acessibilidade defina um SLA para lidar com as regressões e deixe as equipes de produto à vontade para fazer isso. Ninguém precisa justificar qual regressão vem em primeiro, segundo ou último lugar. São apenas bugs que precisam de atenção.

Essa descentralização se traduz diretamente em um programa mais sustentável e em experiências mais inclusivas para o usuário final. Temos muito mais autonomia e impacto, muito espaço para a criatividade, porque não estamos constantemente solucionando problemas do momento. E isso, por sua vez, significa que somos mais felizes e mais eficazes.

O retorno sobre o investimento em ciclos de feedback mais rápidos

Um bug que passa despercebido por semanas ou meses é caro de corrigir. Alguém tem que fazer a triagem e encaminhá-lo à equipe apropriada, garantindo que seja priorizado. O engenheiro designado provavelmente não é o mesmo que o causou. Mesmo quando é, é difícil desenterrar o contexto esquecido, mudar de marcha ou coordenar com outras equipes para desembaraçar a dívida técnica que surgiu nas semanas e meses que se seguiram.

Colocando números no problema, um estudo altamente citado da IBM descobriu que custa 30 vezes mais descobrir bugs na produção do que aqueles encontrados durante a fase de design. Isso parece verdade.

Quando os engenheiros implementam uma atualização pela manhã, qualquer evidência de regressões normalmente começará a aparecer antes do final do dia de trabalho. O ciclo de feedback é tão curto que, em várias ocasiões, os nossos testes de ponta a ponta foram os primeiros a nos alertar sobre bugs genéricos da interface do usuário, não restritos a leitores de tela ou navegação por teclado.

À medida que os engenheiros começaram a receber feedback mais rápido dos testes de ponta a ponta, notamos uma redução na sobrecarga cognitiva da priorização. A ambiguidade desapareceu. Os engenheiros pensavam: “Eu sou responsável por isso porque lancei hoje de manhã. Funcionou ontem e está quebrado hoje, preciso corrigir agora.” Corrigir bugs de acessibilidade passa a ser como memória muscular.

Na Asana, os bugs de acessibilidade são apenas bugs. E eles são corrigidos.

Uma maneira melhor de automatizar a acessibilidade

Antes de adotar os testes de acessibilidade de ponta a ponta, a nossa equipe de acessibilidade fez progressos significativos. No âmbito das operações, as equipes de design e engenharia tinham processos de revisão documentados, definições de regressão e acordos de nível de serviço em vigor. Quando se tratava de testes, havia soluções automatizadas para relatórios rápidos, mas superficiais, e controle de qualidade manual para auditorias completas, mas demoradas.

Com a abordagem de ponta a ponta, temos uma solução técnica que complementa e se sobrepõe aos esforços existentes. As regressões estão sendo documentadas mais cedo, com mais detalhes e mais evidências. Praticamente ninguém está perdendo tempo com relatórios de bugs que não são acionáveis ou reproduzíveis.

Agora, temos uma visão clara de quais bugs são novos e quais são antigos, quais fluxos de usuários eles afetam e quem é responsável pela correção. Podemos ficar à frente da concorrência e nos concentrar na nossa visão para a acessibilidade da Asana no futuro.

Sobre os autores:  Cameron Cundiff (líder técnico) e Jiaxin Zheng (gerente técnico de programa) são membros do grupo de Ciclo de vida de desenvolvimento, dedicado a fornecer ferramentas que permitam aos desenvolvedores levar as ideias à produção de forma rápida, robusta e agradável.