O prazo do European Accessibility Act passou em junho de 2025, tornando a conformidade com WCAG 2.1 AA um requisito legal para empresas privadas que vendem na UE. A maioria dos bugs de acessibilidade é invisível durante o desenvolvimento normal. Eles aparecem quando um usuário de teclado não consegue acessar um modal. Ou quando um leitor de tela anuncia um botão com ícone apenas como "button". Ou quando um campo de formulário não dá contexto sobre o que preencher. Capturá-los exige combinar testes de teclado e uso básico de leitor de tela com varreduras automatizadas de axe-core no CI do Playwright.
Por que testes de acessibilidade importam em 2026
Cerca de 15% da população mundial vive com alguma forma de deficiência. Não é um caso extremo; é um segmento de usuários maior do que a maior demografia da maioria das empresas. Mas até recentemente, a acessibilidade era tratada como um capricho de design ou um requisito legal reservado para sites governamentais. Isso está mudando rápido.
O prazo do European Accessibility Act (EAA) passou em junho de 2025. Empresas privadas que vendem produtos ou serviços na UE precisam agora atender aos requisitos de acessibilidade ou enfrentar ação regulatória e multas. Reino Unido, Canadá e Austrália têm seus próprios frameworks sobrepostos. Nos EUA, o ADA tem sido aplicado a produtos digitais por meio de litígios há anos. O WCAG 2.1 AA é o padrão internacional que a maioria desses frameworks referencia.
O risco legal é real, mas não é o único motivo de preocupação. Aplicações inacessíveis têm taxas de rejeição mais altas, geram mais chamados de suporte e expõem empresas a danos reputacionais. Um fluxo de checkout que não pode ser concluído com teclado exclui usuários que não conseguem usar mouse. Um formulário com inputs sem label é inútil para um usuário de leitor de tela. Esses não são casos hipotéticos. São padrões que aparecem em aplicações em produção todo dia, muitas vezes por anos antes que alguém perceba.
QA engineers que conseguem identificar esses problemas antes de chegarem em produção são genuinamente valiosos. As ferramentas existem. As técnicas são aprendíveis. O que falta é consciência.
WCAG 2.1 básico para testers: o que POUR significa na prática
O WCAG 2.1 (Web Content Accessibility Guidelines) é organizado em torno de quatro princípios, abreviados como POUR: Perceivable (Perceptível), Operable (Operável), Understandable (Compreensível) e Robust (Robusto).
Perceivable significa que os usuários conseguem perceber todo o conteúdo por pelo menos um sentido. Imagens precisam de alternativas em texto. Vídeos precisam de legendas. O conteúdo não pode depender apenas de cor para transmitir significado ("campos obrigatórios são mostrados em vermelho" é uma falha se vermelho é o único indicador). Operable significa que toda funcionalidade está disponível sem mouse. A navegação por teclado deve alcançar todo elemento interativo. Os usuários devem ter tempo suficiente para concluir tarefas (sem sessões que expiram automaticamente sem aviso). Nada pisca mais de três vezes por segundo (risco de convulsão). Understandable significa que a interface se comporta de forma previsível e as mensagens de erro explicam o que deu errado. Um formulário que diz "Entrada inválida" é uma falha. "O e-mail deve conter o símbolo @" não é. Robust significa que o conteúdo pode ser interpretado por uma ampla variedade de tecnologias assistivas, incluindo agentes de usuário atuais e futuros. É aqui que o HTML semântico importa: um estilizado para parecer um botão geralmente não é.
A conformidade AA, o padrão exigido pelo EAA e pela maioria dos frameworks legais, significa que todos os critérios de sucesso de nível A e AA são atendidos. A e AA juntos cobrem coisas como: imagens têm alt text (A), cor não é o único indicador visual (A), razão de contraste de pelo menos 4.5:1 para texto normal (AA). Toda funcionalidade é acessível por teclado (A), indicadores de foco são visíveis (AA), e inputs de formulário têm labels associadas programaticamente (A).
Como tester, você não precisa memorizar a especificação completa. Você precisa saber quais critérios são violados com mais frequência e como testá-los.
Testes manuais de a11y: navegação por teclado e leitores de tela
Nenhuma ferramenta automatizada vai capturar todas as falhas de acessibilidade. Testes manuais, especialmente com teclado e leitor de tela, são insubstituíveis.
A navegação por teclado é a primeira coisa a testar. Desconecte o mouse (ou desative eventos de ponteiro no DevTools) e navegue pela aplicação usando apenas Tab, Shift+Tab, Enter, Espaço e as setas. Todo elemento interativo (links, botões, campos de formulário, dropdowns, modais, date pickers) deve ser alcançável e operável. A ordem de tab deve seguir uma sequência de leitura lógica, geralmente da esquerda para a direita, de cima para baixo. O foco nunca deve ficar preso: você pressiona Tab e nada se move. A exceção é dentro de um modal, onde o foco deve ser restrito até que o modal seja fechado.
O padrão de falha de teclado mais comum: um desenvolvedor cria um dialog modal, mas quando você pressiona Tab dentro dele, o foco escapa para a página de fundo. O modal está visualmente presente, mas o usuário de teclado agora interage com o conteúdo atrás dele sem saber.
Indicadores de foco fazem parte desse teste. Todo elemento focado deve ter um indicador visível: o outline padrão do navegador, um estilo customizado, qualquer coisa. Designs que removem estilos :focus com outline: none no CSS criam foco invisível, o que torna a navegação por teclado completamente inutilizável. Procure isso em toda revisão de sprint.
Os testes com leitor de tela são mais difíceis e exigem prática, mas mesmo familiaridade básica é imensamente valiosa. Os dois leitores de tela gratuitos mais comuns são o NVDA (Windows, gratuito) e o VoiceOver (macOS e iOS, integrado). O JAWS é comum em ambientes corporativos, mas custa dinheiro.
Instale o NVDA e abra sua aplicação. Desligue o monitor se quiser a experiência completa. Navegue com Tab para alcançar elementos interativos, e use o modo de navegação do NVDA (teclas de seta) para ler o conteúdo estático. Ouça o que o leitor de tela anuncia. Um botão que diz "Clique aqui" não diz nada ao usuário. Um botão que diz "Confirmar pagamento" diz exatamente o que vai acontecer. Um botão com ícone sem aria-label anuncia sua role como "button", mas nada sobre sua função. Um campo de formulário sem label é anunciado como "editar" sem contexto sobre o que preencher.
Você não precisa virar expert em leitor de tela para encontrar bugs significativos. Passe 30 minutos navegando pelos principais fluxos de usuário com o NVDA. Os problemas que tornam a experiência confusa ou bloqueada vão aparecer rapidamente.
A combinação de testes de teclado e uso básico de leitor de tela vai encontrar a maioria dos bugs graves de a11y que existem em uma aplicação web típica.
Testes automatizados de a11y com axe-core e Playwright
Ferramentas automatizadas não substituem os testes manuais. Capturam, porém, um subconjunto confiável de problemas de forma consistente e em escala: alt text faltando, contraste de cor insuficiente, labels de formulário ausentes, uso incorreto de ARIA. Rodá-las no CI significa capturar regressões antes que cheguem aos testers.
O motor mais usado é o axe-core, mantido pela Deque Systems. Ele alimenta extensões de navegador (axe DevTools), o Lighthouse e diversas integrações de frameworks. Para times que já usam Playwright, o pacote @axe-core/playwright adiciona varredura de a11y com setup mínimo.
Aqui está um teste básico do Playwright que escaneia uma página em busca de violações de acessibilidade:
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('homepage não deve ter violações de acessibilidade detectáveis automaticamente', async ({ page }) => {
await page.goto('/');
const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
expect(accessibilityScanResults.violations).toEqual([]);
});
Isso falha o teste se o axe encontrar violações. Na prática, especialmente em uma base de código existente, você vai querer começar por registrar em vez de bloquear. Logue as violações, corrija incrementalmente e adicione as assertions conforme o backlog diminui.
Para varreduras mais específicas, você pode escanear componentes específicos e filtrar para um nível WCAG particular:
test('formulário de checkout atende WCAG 2.1 AA', async ({ page }) => {
await page.goto('/checkout');
const results = await new AxeBuilder({ page })
.include('#checkout-form')
.withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
.analyze();
if (results.violations.length > 0) {
const violationDetails = results.violations.map(v => ({
id: v.id,
impact: v.impact,
description: v.description,
nodes: v.nodes.map(n => n.html),
}));
console.log('Violações:', JSON.stringify(violationDetails, null, 2));
}
expect(results.violations).toEqual([]);
});
O filtro .withTags() limita a varredura a critérios WCAG específicos. wcag2a, wcag2aa e wcag21aa juntos cobrem o nível de conformidade AA. Adicione esses testes ao seu pipeline de CI junto com seus testes funcionais existentes.
O axe-core detecta cerca de 30-40% dos problemas WCAG automaticamente. Isso não é motivo para pular a ferramenta; capturar um terço dos problemas automaticamente em escala é genuinamente valioso. Mas significa que uma varredura axe sem erros não é uma certificação de acessibilidade. É um piso, não um teto.
O que ferramentas automatizadas não conseguem detectar
É aqui que vivem os problemas de a11y mais críticos, e é por isso que testes manuais são inegociáveis.
Alt text com significado é o exemplo mais claro. Uma ferramenta automatizada consegue detectar que um elemento ![]()
alt. Isso é uma verificação de aprovado/reprovado. Ela não consegue determinar se o alt text é preciso ou significativo. Uma imagem de um gráfico de linhas mostrando queda de receita descrita como alt="gráfico" passa na verificação automatizada. Um usuário de leitor de tela ouve "gráfico" e não tem nenhuma informação. A falha é semântica, não estrutural.
Ordem de leitura lógica é outra. A ordem do DOM determina como os leitores de tela percorrem a página. O estilo visual pode fazer os elementos aparecerem em uma ordem completamente diferente da que existem no DOM. Um usuário com visão lê o botão "Adicionar ao carrinho" depois da descrição do produto porque está posicionado abaixo. Se a ordem do DOM coloca o botão antes do título do produto, um usuário de leitor de tela ouve o botão antes de entender com qual produto está interagindo. Ferramentas automatizadas podem sinalizar algum reordenamento, mas layouts complexos exigem um humano para avaliar a experiência real de escuta.
Contraste de cor em contexto é parcialmente automatizável mas pode produzir resultados falsos. O axe escaneia estilos computados, mas elementos sobrepostos, imagens de fundo e fundos com gradiente podem enganar o scanner. Teste o contraste manualmente com o verificador de contraste do navegador ou ferramentas como o WebAIM Contrast Checker ao ver designs visuais complexos.
Nomes acessíveis para botões com ícone são uma falha consistente que ferramentas capturam parcialmente. Um Bugs de a11y comuns que QA engineers encontram
Esses padrões aparecem repetidamente em produtos de todo tamanho. Conhecê-los significa que você vai reconhecê-los à primeira vista.
Labels de formulário faltando é o mais comum. Um placeholder visível em um input não é uma label acessível. Quando o usuário começa a digitar, o placeholder desaparece, e um usuário de leitor de tela que navega de volta ao campo ouve apenas "editar" sem contexto. A correção é um elemento for/id, ou um atributo aria-label ou aria-labelledby. Encontre esses bugs navegando por teclado em cada input de formulário e ouvindo no NVDA.
Elementos interativos não semânticos aparecem sempre que um desenvolvedor cria um ou role, tabindex e handlers de eventos de teclado explícitos para ser acessível. Essas são correções caras; encontrá-las cedo poupa refatoração significativa.
Gerenciamento de foco ruim em modais e drawers aparece em quase todo componente de dialog construído customizado. O modal abre, mas o foco permanece no botão que o disparou (agora atrás do overlay). A ordem de tab vaza para a página de fundo. Quando o modal fecha, o foco vai para o topo do documento em vez de retornar ao elemento disparador. Teste todo modal abrindo-o com Tab+Enter e navegando inteiramente pelo teclado.
Atualizações de conteúdo dinâmico sem anúncio afeta muito apps de página única. Um usuário envia um formulário, a página mostra uma mensagem de sucesso, mas a mensagem aparece em uma parte diferente do DOM sem mudança de foco e sem live region. Um usuário de leitor de tela não tem como saber que o envio funcionou. ARIA live regions (role="status" ou aria-live="polite") resolvem isso, mas só se alguém pensou em adicioná-las.
Armadilhas de teclado em widgets customizados, especialmente dropdowns customizados, date pickers e editores de rich text, frequentemente prendem o foco do teclado ou não implementam as interações de teclado padrão (teclas de seta para navegação no dropdown, Escape para fechar). Teste todo componente interativo customizado apenas com teclado.
Como escrever bug reports de a11y
Bug reports de acessibilidade precisam de mais contexto do que bugs comuns de UI porque o impacto depende de qual tecnologia assistiva é afetada e qual critério de sucesso WCAG é violado. Um report vago ("o leitor de tela não funciona aqui") não dá nada acionável para os desenvolvedores.
Um bom bug report de a11y inclui:
O critério WCAG violado. Toda falha mapeia para um critério. Uma label faltando viola WCAG 1.3.1 (Info and Relationships) e 4.1.2 (Name, Role, Value). Um indicador de foco faltando viola WCAG 2.4.7 (Focus Visible). Inclua o ID e o nome do critério. Isso diz ao desenvolvedor exatamente qual é o requisito, e documenta a lacuna de conformidade para qualquer auditoria.
A tecnologia assistiva e o navegador usados. "NVDA 2024.1 + Chrome 124 no Windows 11" é acionável. "Leitor de tela" não é. Combinações diferentes de AT/navegador se comportam de forma diferente, e os desenvolvedores precisam do stack específico para reproduzir o problema.
O anúncio esperado vs. o real. Para bugs de leitor de tela, escreva o que o AT anunciou e o que deveria ter anunciado. "Anunciado: 'button'. Esperado: 'Confirmar pagamento, button'." Essa é a descrição real da falha.
Passos de reprodução que usam AT, não o mouse. "Tab até o campo de e-mail, ouça o anúncio do NVDA", não "clique no campo de e-mail." Os passos devem ser reproduzíveis usando apenas o método de interação afetado.
Classificação de impacto. Use os níveis de impacto do WCAG: crítico (bloqueador para usuários de AT), sério (dificuldade maior), moderado (alguma dificuldade), menor. Uma label de modal faltando é crítica. Uma estrutura de heading subótima é menor a moderada. O impacto guia a prioridade de correção.
Não marque bugs de a11y como "nice to have" a menos que sejam genuinamente menores. Um formulário que não pode ser enviado via teclado é um bloqueador para usuários que só usam teclado. Tem a mesma severidade que um botão de checkout que não funciona para usuários com mouse. Aplique os mesmos critérios de severidade que você aplicaria a qualquer falha funcional.
Como aplicar isso já na segunda-feira
Você não precisa auditar todo o produto em um sprint. Comece pequeno e construa o hábito.
Esta semana: Instale o NVDA (gratuito, Windows) ou ative o VoiceOver (macOS: Cmd+F5). Abra uma página da sua aplicação, de preferência um formulário ou um fluxo com modal. Navegue por ela com Tab. Ouça o que o NVDA anuncia para cada elemento. Registre tudo que for confuso ou silencioso.
Neste sprint: Adicione o pacote @axe-core/playwright ao seu projeto. Escreva um teste que escaneia sua página mais crítica: login, checkout ou onboarding. Rode-o no CI. Não bloqueie a build ainda; comece registrando as violações para que o time veja a linha de base.
No próximo mês: Adicione verificações de navegação por teclado à sua definição de pronto para novas funcionalidades. Inclua "testado apenas com teclado" no seu checklist de PR. Para cada funcionalidade com formulários ou modais, passe dez minutos testando a ordem de tab e o gerenciamento de foco.
Para seus bug reports de a11y: Crie um template no seu bug tracker com campos para critério WCAG, AT afetada e anúncio esperado. Usar o template leva trinta segundos. Ter essa informação no report poupa uma hora de comunicação com o desenvolvedor.
O prazo do EAA passou. Empresas que não trataram a acessibilidade agora operam com exposição legal. QA engineers que conseguem identificar, documentar e rastrear falhas de acessibilidade estão diretamente reduzindo esse risco. Mais importante ainda, as correções que você captura antes da produção chegam a usuários que precisam delas. Um usuário de leitor de tela concluindo um checkout sem assistência, um usuário de teclado navegando por um formulário sem ficar preso: esse é o resultado. A ferramenta é o meio.
Comece com um teste de teclado. Construa a partir daí.
→ Veja também: Testes de Acessibilidade com Playwright: Verificações a11y Automatizadas | Eventos de Teclado e Mouse no Playwright | Fundamentos de Testes de Usabilidade: O que Engenheiros QA Precisam Saber
