Acessibilidade na prática: testes reais com leitores de tela

Mais de 90% dos sites brasileiros apresentam falhas graves de acessibilidade que impedem pessoas com deficiência de completar tarefas básicas, segundo dados do WebAIM Million. A maioria dessas barreiras não exige tecnologia complexa para ser encontrada — basta fechar os olhos, ligar um leitor de tela e tentar navegar pelo próprio projeto. O choque de realidade costuma ser imediato: menus que não abrem, formulários que não anunciam erros, carrosséis que travam a navegação, imagens informativas sem descrição alguma.

Este artigo nasceu da rotina de auditorias que realizamos na Betânia Web Designer. Não há teoria abstrata aqui: cada seção reflete um padrão de falha que encontramos repetidamente em projetos reais, desde landing pages institucionais até e-commerces complexos. O objetivo é transformar o teste com leitor de tela de “algo que a gente deixa para depois” em etapa obrigatória do fluxo de entrega, tão natural quanto validar responsividade ou performance.

Se você projeta ou desenvolve para web, já tem as ferramentas necessárias instaladas no computador. O NVDA é gratuito no Windows. O VoiceOver roda nativo no Mac e no iPhone. O TalkBack está no Android. Não há barreira de custo, apenas de hábito. Vamos ao que funciona na prática.

Por que testes automatizados não bastam

Ferramentas como axe DevTools, Lighthouse e WAVE são excelentes para triagem inicial. Elas capturam ausência de alt text, contraste insuficiente, atributos ARIA mal formados e estrutura de headings quebrada. Mas elas têm um ponto cego fundamental: não navegam. Não sabem se a ordem de foco faz sentido, se um modal prende o teclado, se o texto de um link “clique aqui” faz sentido fora de contexto, se uma atualização dinâmica de carrinho foi anunciada ao usuário.

Em uma auditoria recente de um e-commerce de moda, o Lighthouse reportou 96% de score de acessibilidade. Na navegação real com NVDA, o carrinho lateral abria mas o foco permanecia no botão “comprar” atrás do painel. O usuário ouvia “botão comprar” enquanto o conteúdo do carrinho era invisível para o leitor. O checkout era inutilizável. Nenhuma ferramenta automatizada sinalizou isso.

A regra prática: use automação para limpar o básico (o “chão de fábrica”) e reserve tempo humano para os fluxos críticos — cadastro, login, checkout, busca, filtros, navegação principal. São nesses percursos que a experiência vive ou morre.

Configurando o ambiente de teste sem dor de cabeça

No Windows, baixe o NVDA em nvaccess.org. Instale com as opções padrão. Atalhos essenciais para começar: NVDA + Espaço entra no modo foco (interage com formulários), NVDA + Shift + Espaço sai dele. Insert + F7 abre a lista de elementos (headings, links, landmarks, formulários). Insert + F5 lê a linha atual. Insert + Seta Baixo lê tudo a partir do cursor.

No macOS, ative o VoiceOver com Command + F5 (ou toque três vezes no Touch ID). A combinação Control + Opção (chamada de tecla VO) é a base de tudo. VO + U abre o rotor — menu radial para navegar por headings, links, formulários, landmarks. VO + Seta Direita/Esquerda move item a item. VO + Espaço ativa. No iPhone, o gesto de rotor é dois dedos girando na tela; swipe direito/esquerda navega; double-tap ativa.

Dica de fluxo: crie um perfil de teste no navegador (Chrome ou Firefox) sem extensões, com zoom em 100%, cache desabilitado no DevTools. Mantenha uma planilha aberta com colunas: Página, Componente, Problema, Critério WCAG, Severidade (Crítica/Alta/Média/Baixa), Sugestão de Correção. Registre tudo enquanto navega — memória falha.

O roteiro de navegação que não falha

Não teste “o site”. Teste percursos. Defina 5 a 8 fluxos críticos antes de ligar o leitor. Exemplo para site institucional: (1) Home → navegação principal → página de serviços → formulário de contato → envio com erro → correção → sucesso. (2) Home → blog → artigo → compartilhamento → retorno. (3) Home → rodapé → política de privacidade → volta. Cada percurso deve ser executado do início ao fim sem usar o mouse.

Durante a navegação, faça três perguntas a cada tela:

1. Onde estou? O título da página (<title>), o heading principal (<h1>) e os landmarks (<main>, <nav>, <aside>, <footer>) anunciam o contexto?
2. Para onde posso ir? A navegação principal, links de rodapé, botões de ação e skip links (<a href="#main">Pular para o conteúdo principal</a>) são alcançáveis e anunciados com propósito claro?
3. O que este elemento faz? Botões dizem “botão, enviar formulário” não apenas “botão”. Links dizem “link, baixar portfólio PDF” não “link, clique aqui”. Inputs dizem “campo de edição, e-mail, obrigatório” e anunciam erro ao sair do campo inválido.

Registre falhas com precisão cirúrgica: “Página Serviços → cards de serviço → heading h3 não anunciado ao navegar por setas; role=region ausente no container do card”. Isso vira tarefa dev direta.

Padrões de falha que aparecem em 9 de 10 projetos

1. Estrutura de headings quebrada

Pular de <h1> para <h3> ou usar <h2> apenas por estilo visual. Headings não são design — são índice semântico. Usuários de leitor de tela navegam por headings (tecla H no NVDA, rotor no VoiceOver). Se a hierarquia mente, a navegação mente.

2. Formulários sem label programático

<input placeholder="Seu e-mail"> sem <label for="email"> associado. Placeholder não substitui label — some ao digitar e não é anunciado consistentemente. Erro: mensagem de validação injetada em <span> sem aria-live="polite" ou role="alert"; o usuário sai do campo, erra, e não sabe por quê.

3. Componentes ARIA mal implementados

Accordion, tabs, menu dropdown, modal, tooltip — todos exigem teclas específicas (setas, Home, End, Escape) e estados ARIA corretos (aria-expanded, aria-controls, aria-selected, role="tablist", role="tabpanel"). Copiar CSS de biblioteca sem o JavaScript de teclado cria armadilhas intransponíveis.

4. Conteúdo dinâmico silencioso

Carrinho atualizado, toast de sucesso, filtros que recarregam resultados, lazy load de imagens. Sem aria-live="polite" ou aria-live="assertive" na região que muda, o leitor não avisa. O usuário acha que nada aconteceu.

5. Imagens informativas sem alt ou alt genérico

Gráfico de resultados, infográfico de processo, foto de equipe na página “Sobre”, ícone de status (verde/vermelho) sem texto alternativo. alt="" só em imagem puramente decorativa. Se a imagem carrega informação, o alt deve transmitir essa informação, não descrever a imagem.

6. Contraste e zoom quebrados

Texto cinza #777 sobre branco falha em WCAG AA (4.5:1). Ao dar zoom 200% (Ctrl++), layouts com position: fixed ou overflow: hidden cortam conteúdo. Teste com zoom 200% e largura 320px — critério de refluxo (Reflow, WCAG 1.4.10).

Ferramentas complementares que economizam horas

Ferramenta	Uso principal	Gratuita?
axe DevTools (extensão)	Auditoria automática por componente, destaca no DOM	Sim
Lighthouse (DevTools)	Score geral, relatório CI/CD	Sim
WAVE (extensão/web)	Sobreposição visual de erros/alertas/features	Sim
Colour Contrast Analyser (CCA)	Verifica contraste de pares de cores (hex/rgba)	Sim
Bookmarklets de Paul J. Adam	Headings, landmarks, ARIA, imagens, formulários	Sim
NVDA Speech Viewer	Mostra na tela tudo que o NVDA fala (debug)	Sim
VoiceOver Utility > Atividades	Cria perfis de verbosidade para testes rápidos	Sim

Os bookmarklets do Paul J. Adam (disponíveis em pauljadam.com/bookmarklets) são ouro: um clique e todos os headings da página ganham outline colorido com nível; outro clique e todos os landmarks aparecem rotulados. Use antes de ligar o leitor para mapear a estrutura visualmente.

Integrando acessibilidade no fluxo de entrega

Acessibilidade não é fase de QA no final do projeto. Ela começa no briefing (pergunte: “Este projeto precisa atender WCAG 2.1 AA?”), passa pelo design system (tokens de cor com contraste validado, componentes com teclado nativo), entra no desenvolvimento (lint com eslint-plugin-jsx-a11y, testes de componente com Testing Library + jest-axe), e termina em homologação com checklist de navegação real.

Na Betânia, usamos um Definition of Done que inclui: “Navegação por teclado validada nos 5 fluxos críticos + auditoria axe sem erros críticos + teste com NVDA/VoiceOver nos fluxos críticos”. Isso evita retrabalho caro em produção. Um bug de acessibilidade em produção custa 10x a 30x mais que no desenvolvimento (dado de mercado consolidado).

Para equipes que estão começando: adote a regra do componente acessível. Antes de mergulhar no projeto todo, construa um botão, um input, um card, um modal acessíveis — testados com leitor de tela. Documente o padrão. Reutilize. A consistência resolve 70% dos problemas.

Referências rápidas para o dia a dia

• WCAG 2.1 Quick Reference (w3.org/WAI/WCAG21/quickref) — filtre por nível AA, tecnologia HTML, componente.
• ARIA Authoring Practices Guide (APG) (w3.org/WAI/ARIA/apg) — padrões de teclado e ARIA para cada widget (accordion, tabs, menu, dialog, etc.).
• WebAIM Checklist (webaim.org/standards/wcag/checklist) — linguagem direta, exemplos de passa/falha.
• Inclusive Components (inclusive-components.design) — Heydon Pickering desmonta componentes acessíveis passo a passo.
• A11y Project Checklist (a11yproject.com/checklist) — lista prática por fase do projeto.

Salve esses links na barra de favoritos. Consulte quando surgir dúvida sobre “qual tecla faz o quê” ou “qual role/aria usar aqui”.

Testar com leitor de tela deixa de ser assustador na terceira vez. Na quinta, vira rotina. Na décima, você começa a pensar em acessibilidade enquanto desenha o wireframe — e é aí que o custo cai perto de zero. O site que funciona para quem navega de ouvido costuma funcionar melhor para todo mundo: estrutura mais limpa, nomes mais claros, fluxos mais previsíveis. Acessibilidade não é recurso extra. É qualidade de base.

Se você está estruturando um novo projeto ou revisando um site existente, comece pelo básico: como a arquitetura da informação guia o usuário naturalmente para organizar o conteúdo, valide a consistência visual com por que o manual de marca evita inconsistências visuais futuras e aplique elementos de persuasão que transformam visitantes em leads com acessibilidade nativa. O resultado é um site que converte — para todos.

Checklist prático

Perguntas frequentes

Quais leitores de tela devo testar para cobrir a maioria dos usuários?

Priorize NVDA no Windows (gratuito e mais usado), VoiceOver no macOS/iOS (nativo) e JAWS em ambientes corporativos. Testar nessas três combinações cobre cerca de 90% dos usuários de leitores de tela no Brasil.

Ferramentas automatizadas como axe ou Lighthouse substituem testes manuais?

Não. Ferramentas automatizadas detectam apenas 30% a 40% dos problemas de acessibilidade. Elas não validam ordem de leitura lógica, contexto de links, qualidade de alternativas textuais nem experiência real de navegação por teclado.

Como testar acessibilidade se não tenho deficiência visual?

Use o leitor de tela com o monitor desligado ou coberto, navegando apenas pelo teclado. Ative o modo de fala do NVDA (Insert + Espaço, depois S) para ouvir sem ver o cursor visual. Isso simula a experiência real de quem não enxerga a tela.

Qual a diferença entre aria-label, aria-labelledby e alt text?

O alt text descreve imagens para tecnologias assistivas. O aria-label fornece nome acessível a elementos sem texto visível (ícones, botões). O aria-labelledby referencia outro elemento que já contém o rótulo visível, evitando duplicação.

Como priorizar correções quando o orçamento é limitado?

Comece por bloqueadores críticos: navegação por teclado, rótulos de formulários, contraste de texto e estrutura de headings. Use a matriz impacto x esforço: corrija primeiro o que afeta muitos usuários e exige pouco desenvolvimento.

Testar em mobile é diferente de desktop?

Sim. No mobile, o VoiceOver (iOS) e TalkBack (Android) usam gestos de toque (swipe, double-tap) em vez de teclado. A ordem de leitura segue a ordem visual/DOM, mas zoom e rotação de tela podem quebrar layouts. Teste em ambos os sistemas operacionais.