Porque os testes automatizados de acessibilidade não detetam metade dos seus problemas

A verdade incómoda sobre os testes automatizados de acessibilidade

Os testes automatizados de acessibilidade são um dos melhores hábitos que uma equipa web pode criar. Detetam rótulos de formulário em falta, texto com baixo contraste, ARIA inválido, IDs duplicados, botões vazios e outros defeitos que nunca deveriam chegar a produção.

Também são frequentemente mal compreendidos.

Um relatório automatizado de acessibilidade aprovado não significa que uma página seja acessível. Significa que a ferramenta não encontrou o subconjunto de problemas que sabe detetar. Esse subconjunto é valioso, mas limitado. Muitas falhas de acessibilidade dependem de significado, ordem, intenção, contexto e interação humana. O software consegue inspecionar a marcação. Não consegue compreender de forma fiável se a experiência funciona para uma pessoa que usa um leitor de ecrã, teclado, ampliação, controlo por voz, legendas ou apoio cognitivo.

É por isso que a afirmação de que os testes automatizados não detetam cerca de metade dos seus problemas não é cínica. É generosa. Algumas categorias de problemas são altamente automatizáveis. Outras são quase impossíveis de automatizar.

A resposta prática não é abandonar as ferramentas automatizadas. É colocá-las no lugar certo: cedo, com frequência e como parte de um fluxo de testes mais amplo.

Em que é que os testes automatizados são bons

As ferramentas automatizadas são excelentes a encontrar falhas determinísticas. Se uma regra puder ser expressa como uma condição legível por máquina, um scanner consegue normalmente verificá-la de forma rápida e consistente.

Exemplos comuns incluem:

• Imagens sem atributos alt
• Campos de formulário sem rótulos associados
• Botões sem nomes acessíveis
• Texto que não cumpre os limiares de contraste
• Atributos ou funções ARIA inválidos
• Níveis de títulos que saltam de forma suspeita
• Marcos de referência em falta ou duplicados
• Links com nomes acessíveis vazios
• Tabelas sem estrutura básica

Vale a pena automatizar estas verificações porque os humanos não são bons em inspeções repetitivas. Ninguém deveria analisar manualmente todas as páginas à procura de rótulos em falta se uma ferramenta os consegue detetar em milissegundos.

As verificações automatizadas também tornam a acessibilidade mais fácil de discutir nos fluxos de trabalho de engenharia. Um teste falhado em CI é concreto. Um aviso num pull request chega no momento certo. Uma linha de tendência ao longo de vários modelos dá à equipa algo a melhorar.

O problema começa quando as equipas tratam estas verificações como prova de acessibilidade, em vez de prova de higiene básica.

Onde a automatização falha

A acessibilidade não é apenas uma propriedade do código. É uma propriedade da utilização.

Uma ferramenta consegue dizer se uma imagem tem texto alternativo. Normalmente, não consegue dizer se esse texto alternativo é útil. Uma imagem de um produto pode precisar de uma descrição detalhada numa página de produto, de nenhuma descrição num hero decorativo e de uma descrição completamente diferente num artigo de ajuda. A resposta correta depende do contexto. É por isso que as equipas precisam de orientação editorial, como uma abordagem pragmática ao texto alternativo de imagens, não apenas de uma regra de linter.

O mesmo problema aparece em todo o lado.

Um scanner pode confirmar que todos os botões têm um nome acessível. Nem sempre consegue dizer se o nome faz sentido. Uma página com cinco botões chamados Submeter pode passar uma regra básica e, ainda assim, ser penosa para utilizadores de leitores de ecrã. Um modal pode ter os atributos ARIA corretos, mas prender o foco incorretamente. Um dropdown personalizado pode parecer conforme na marcação estática e falhar no momento em que alguém tenta usá-lo com um teclado.

A automatização tem dificuldade com perguntas como:

• A ordem do foco corresponde à ordem visual e lógica?
• Todas as tarefas podem ser concluídas apenas com um teclado?
• As mensagens de erro são específicas, oportunas e associadas aos campos?
• A página continua a funcionar quando o texto é redimensionado ou ampliado?
• A ordem de leitura faz sentido para tecnologias de apoio?
• As instruções são compreensíveis sem depender de cor ou posição?
• As legendas, transcrições e rótulos comunicam realmente o conteúdo?
• Um componente comporta-se de forma previsível nos vários estados?

Isto não são casos marginais. São centrais para a acessibilidade.

O falso conforto de uma pontuação elevada

As pontuações de acessibilidade são sedutoras porque comprimem um tema complexo num número. Um painel diz 98. Um relatório mostra vistos verdes. O lançamento parece mais seguro.

Mas a pontuação mede apenas aquilo que a ferramenta mede.

Isto é semelhante aos testes de desempenho. Um relatório Lighthouse pode revelar problemas importantes, mas não é o mesmo que observar um utilizador real a debater-se com um checkout lento num telemóvel de gama média. Se a sua equipa já usa auditorias de desempenho, aplica-se a mesma mentalidade: leia o relatório com atenção e depois priorize as conclusões que afetam utilizadores reais. Escrevemos sobre essa distinção em como ler um relatório Lighthouse sem entrar em pânico.

Os relatórios de acessibilidade exigem a mesma contenção. Uma análise automatizada limpa é um ponto de partida. Não é um certificado.

O risco é especialmente elevado quando as equipas executam análises apenas em páginas estáticas. As interfaces modernas têm estado: menus abrem, painéis deslizam, toasts aparecem, mensagens de validação são atualizadas, separadores mudam de painel, filtros reescrevem conteúdo e a autenticação muda tudo. Muitos defeitos graves de acessibilidade vivem nessas interações.

Se o seu scanner vê apenas o DOM inicial, está a perder o produto.

As categorias mais frequentemente ignoradas

1. Comportamento do teclado e do foco

O acesso por teclado é um dos exemplos mais claros de porque a automatização é insuficiente.

Uma ferramenta consegue detetar se um elemento é focável. Pode apanhar valores positivos de tabindex ou armadilhas de foco óbvias. Mas não consegue avaliar de forma fiável se a sequência de tabulação parece coerente, se o foco se move para o sítio certo depois de uma ação ou se um componente dispensado devolve o foco ao acionador.

É preciso uma pessoa para percorrer o fluxo real com Tab, Shift+Tab, Enter, Espaço, Escape e as setas.

Isto é particularmente importante para controlos personalizados. Os elementos HTML nativos trazem anos de comportamento de acessibilidade gratuitamente. Reconstruir botões, selects, checkboxes, menus e diálogos com divs significa que a sua equipa passa a ser responsável por esse comportamento. Se estiver a rever componentes interativos, comece com uma lista curta de verificação para botões web acessíveis e aplique a mesma disciplina a todos os controlos personalizados.

2. Nomes e descrições significativos

As ferramentas automatizadas conseguem detetar ausência. São muito piores a detetar qualidade.

Um link chamado Ler mais pode tecnicamente ter um nome acessível. Um botão rotulado OK pode ser válido. Uma dica de formulário pode estar presente. Mas são significativos no contexto? Muitas vezes, não.

Os nomes acessíveis devem dizer aos utilizadores o que vai acontecer ou o que o elemento representa. Isso exige julgamento. Também exige testar com a interface, não apenas com o código.

3. Tratamento de erros

Os formulários estão cheios de falhas de acessibilidade que os scanners apenas detetam parcialmente.

Uma ferramenta pode assinalar um campo sem rótulo. Pode não detetar que a mensagem de validação aparece demasiado tarde, desaparece demasiado depressa, não é anunciada aos leitores de ecrã ou diz Entrada inválida quando deveria dizer A palavra-passe deve ter pelo menos 12 caracteres.

Um bom tratamento de erros é design de interação. Precisa de testes manuais e, idealmente, de testes com utilizadores.

4. Adaptação visual

As WCAG incluem requisitos em torno de redimensionamento de texto, reflow, contraste, espaçamento e não dependência de uma única pista sensorial. Parte disto pode ser verificada automaticamente, mas a verdadeira questão é se a interface continua utilizável em condições alteradas.

Experimente 200% de zoom. Experimente o redimensionamento de texto do navegador. Experimente modo de alto contraste ou cores forçadas. Experimente larguras estreitas de viewport. Experimente movimento reduzido. Muitos sites que parecem polidos nas definições predefinidas quebram rapidamente quando os utilizadores impõem as suas preferências.

5. Clareza do conteúdo

Nenhuma ferramenta automatizada de acessibilidade consegue avaliar plenamente se o conteúdo é compreensível.

Pode assinalar títulos em falta ou texto de link vago. Não consegue saber se a página explica claramente um processo, se os rótulos correspondem às expectativas dos utilizadores ou se texto denso cria carga cognitiva evitável.

A acessibilidade não diz respeito apenas à compatibilidade com tecnologias de apoio. Também consiste em reduzir atrito para pessoas sob stress, a usar uma língua pouco familiar, a lidar com limitações de atenção ou a navegar tarefas complexas.

Um melhor fluxo de testes

Um fluxo equilibrado de acessibilidade tem camadas.

Execute verificações automatizadas continuamente

Use testes automatizados no desenvolvimento, em pull requests, em pré-visualizações de componentes e em CI. Devem ser aborrecidos, rápidos e não negociáveis. Novos rótulos em falta e ARIA inválido não devem exigir uma auditoria trimestral para serem descobertos.

Trate estas falhas como falhas de linting. O objetivo não é heroísmo; é prevenir regressões.

Acrescente testes manuais com teclado

Para cada fluxo significativo do utilizador, teste sem rato. Isto inclui navegação, pesquisa, criação de conta, checkout, filtragem, modais, menus e submissão de formulários.

No mínimo, verifique:

• Todos os elementos interativos são alcançáveis
• O foco está sempre visível
• A ordem do foco é lógica
• As teclas esperadas funcionam
• Escape dispensa sobreposições dispensáveis
• O foco é gerido depois de abrir e fechar componentes
• Não existe nenhuma armadilha de teclado

Este único hábito deteta uma grande classe de problemas que as análises automatizadas não apanham.

Teste com pelo menos um leitor de ecrã

Não precisa de se tornar especialista em leitores de ecrã para aprender coisas úteis. Precisa, sim, de humildade. Os testes com leitores de ecrã têm uma curva de aprendizagem, e principiantes podem diagnosticar problemas incorretamente.

Ainda assim, testes básicos com VoiceOver, NVDA ou JAWS podem revelar nomes quebrados, ordem de leitura confusa, atualizações não anunciadas e problemas de marcos de referência que um scanner pode não detetar.

Combine isto com HTML semântico. Quanto mais elementos nativos usar, menos frágil se torna a sua acessibilidade.

Reveja conteúdo e estados

Verifique estados vazios, estados de carregamento, estados de erro, estados desativados, mensagens de sucesso e falhas de permissões. Os bugs de acessibilidade escondem-se frequentemente fora do caminho feliz.

Reveja também as palavras reais. Rótulos, títulos, instruções e mensagens de erro fazem parte da interface.

Inclua utilizadores com deficiência quando os riscos forem elevados

Para fluxos críticos, uma revisão manual por especialistas não basta. Testes com utilizadores com deficiência encontram problemas que as equipas não antecipam. Isto é especialmente importante para serviços públicos, saúde, finanças, educação e qualquer fluxo em que a exclusão tenha consequências graves.

Os testes automatizados escalam. Os testes humanos compreendem.

Como interpretar resultados automatizados de forma responsável

Não pergunte: Passámos?

Faça perguntas melhores:

• Que categorias de problemas esta ferramenta consegue detetar?
• Que modelos e estados foram analisados?
• Correu depois das interações ou apenas no carregamento inicial?
• As violações estão agrupadas por causa raiz ou contadas repetidamente?
• Que falhas impedem utilizadores de concluir tarefas?
• O que ainda exige revisão manual?

Este enquadramento muda a conversa. As ferramentas automatizadas tornam-se prova, não autoridade.

Também ajuda as equipas a evitar trabalho improdutivo. Corrigir um único componente pode remover centenas de violações repetidas. Inversamente, uma página com apenas um problema reportado pode ainda conter uma armadilha de teclado grave. Contagens não são impacto.

O padrão prático: automatizar o óbvio, testar manualmente a experiência

As melhores equipas de acessibilidade não são contra ferramentas. São contra fantasias.

Automatizam aquilo que as máquinas conseguem detetar de forma fiável. Testam manualmente o que depende de comportamento e significado. Usam normas como as WCAG como uma base comum, não como substituto de usar o produto.

Se o seu processo atual é apenas uma análise automatizada antes do lançamento, melhore-o por esta ordem:

1. Acrescente verificações automatizadas mais cedo no desenvolvimento.
2. Teste manualmente com teclado os fluxos principais.
3. Reveja nomes, rótulos, erros e instruções.
4. Teste componentes comuns com um leitor de ecrã.
5. Recorra a testes com especialistas e utilizadores para percursos de alto risco.

Não é um processo perfeito. É um processo realista. E encontrará muito mais do que qualquer pontuação verde de acessibilidade alguma vez encontrará.