Teste de leitores de ecrã: NVDA, JAWS, VoiceOver

Uma página pode passar em todas as verificações automatizadas, ser entregue com HTML válido e mesmo assim ser inutilizável para quem navega na web de ouvido. As ferramentas automatizadas detetam cerca de um terço dos problemas de acessibilidade; o restante vive na lacuna entre o que a árvore de acessibilidade contém tecnicamente e o que um leitor de ecrã realmente anuncia ao utilizador. Fechar essa lacuna significa colocar a sua interface perante as mesmas ferramentas em que o seu público confia — e é precisamente para isso que serve o teste de leitores de ecrã.

Este guia explica em que medida os principais leitores de ecrã diferem, porque testar apenas um nunca é suficiente, o que testar exatamente, que combinações de leitor e navegador utilizar e as armadilhas que surpreendem até equipas experientes. Foi escrito para programadores, engenheiros de QA e especialistas de acessibilidade que querem testar de forma deliberada em vez de adivinhar. Se preferir entregar o trabalho a especialistas que usam estas ferramentas todos os dias, o nosso serviço de avaliação de leitores de ecrã faz exatamente isso.

Porque um leitor de ecrã não é uma ferramenta de «leitura em voz alta»

A ideia errada mais comum é que um leitor de ecrã se limita a pronunciar o texto da página. Faz muito mais do que isso, e compreender essa diferença é a base de um bom teste. Um leitor de ecrã constrói um modelo paralelo e não visual da interface a partir da árvore de acessibilidade do navegador. Anuncia o nome de cada elemento («Enviar, botão»), o seu papel (botão, ligação, título, caixa de verificação) e o seu estado (selecionado, expandido, desativado, obrigatório). Permite ao utilizador saltar entre títulos, marcos, campos de formulário e ligações sem tocar na disposição visual. Pronuncia alterações dinâmicas — mensagens de erro, resultados de pesquisa, atualizações de estado — quando essas alterações são expostas corretamente.

Isto é fundamentalmente diferente da conversão de texto em fala, que transforma um bloco de texto em áudio sem qualquer noção de papéis, estados ou navegação. Abordamos esta distinção em detalhe em conversão de texto em fala versus leitores de ecrã, e importa aqui porque testar uma coisa não testa a outra. Um utilizador de leitor de ecrã não consome a sua página de cima a baixo; navega-a de forma estrutural e espera que cada elemento interativo declare o que é e o que está a fazer.

Em que diferem NVDA, JAWS, VoiceOver e TalkBack

Os quatro leitores com que a maioria das equipas precisa de se preocupar comportam-se de forma suficientemente diferente para que «funciona num deles» quase nada lhe diga sobre os outros.

NVDA (Windows)

O NVDA é um leitor gratuito e de código aberto, e o leitor de ecrã mais utilizado em todo o mundo. Combina-se mais naturalmente com o Firefox e o Chrome. O NVDA tende a seguir de perto a semântica ARIA e HTML, o que o torna uma excelente linha de base: se algo estiver errado na sua marcação, o NVDA expõe-no muitas vezes de forma clara. Tem dois modos fundamentais — o modo de navegação (para leitura e navegação estrutural) e o modo de foco (para escrever em formulários e operar widgets) — e uma fonte frequente de erros são os widgets que não acionam a mudança de modo correta.

JAWS (Windows)

O JAWS é o leitor comercial há muito estabelecido, ainda dominante em empresas, na administração pública e em muitos locais de trabalho. Combina-se com o Chrome e o Edge. O JAWS é conhecido por ser «prestável»: aplica heurísticas que adivinham o significado, anuncia por vezes coisas sobre as quais o NVDA se mantém silencioso e, ocasionalmente, disfarça erros de marcação que deviam ser corrigidos. Essa prestabilidade corta dos dois lados — código que «funciona no JAWS» pode falhar no NVDA ou no VoiceOver porque o JAWS encobriu o problema. Tem também o seu próprio cursor virtual e um comportamento de modo de formulário que difere subtilmente do do NVDA.

VoiceOver (macOS e iOS)

O VoiceOver vem integrado em todos os Mac, iPhone e iPad e combina-se quase exclusivamente com o Safari. No macOS, a navegação faz-se através do rotor e de combinações de teclas VO; no iOS é totalmente gestual — deslizar para mover, tocar duas vezes para ativar, rodar o rotor torcendo dois dedos. O VoiceOver é, em geral, o mais rigoroso dos quatro quanto a ARIA: muitas vezes fica em silêncio em vez de adivinhar quando faltam nomes ou papéis, pelo que um controlo que o JAWS anuncia pode não dizer nada no VoiceOver. O VoiceOver de computador e de telemóvel também diferem entre si, pelo que contam como dois alvos de teste distintos.

TalkBack (Android)

O TalkBack é o leitor integrado no Android, associado ao Chrome. Tal como o VoiceOver do iOS, é gestual, mas os seus gestos, comportamento de foco e tratamento de regiões dinâmicas e controlos personalizados diferem dos do VoiceOver. Os leitores móveis, em geral, expõem problemas que nunca surgem no computador: alvos táteis que não se conseguem alcançar por deslizar, foco que salta de forma inesperada após uma transição de ecrã, e conteúdo visualmente presente mas totalmente ignorado pela ordem linear dos gestos.

Porque testar vários leitores é essencial

Como estes leitores divergem na forma como interpretam exatamente a mesma marcação, testar um único leitor produz uma falsa sensação de segurança. Alguns padrões concretos surgem vezes sem conta:

Uma caixa de combinação personalizada que o JAWS anuncia na perfeição pode ficar totalmente silenciosa no VoiceOver, porque o VoiceOver recusa-se a inferir um role ou um estado aria-expanded em falta.
Uma região dinâmica que o NVDA anuncia educadamente uma vez pode ser anunciada repetidamente, ou de todo, noutro leitor, consoante a forma como aria-live e o momento de inserção no DOM interagem.
Um controlo com um nome redundante ou contraditório (etiqueta visível mais aria-label mais title) pode ser anunciado de forma sensata por um leitor e como uma sequência confusa de duplicados por outro.
Uma ordem de leitura que coincide com a ordem visual numa combinação navegador/leitor pode divergir noutra quando o CSS reordena o conteúdo mas o DOM não.

Cada leitor está também associado a um navegador diferente, pelo que está, na verdade, a testar combinações de leitor mais navegador, e não leitores isolados. A única forma de saber que o seu produto é coerente para todos é testar as combinações reais que o seu público utiliza. Esse princípio é o mesmo que sustenta as auditorias de acessibilidade manuais em geral: as ferramentas estreitam a busca, as pessoas confirmam a experiência.

O que testar

Testar é muito mais eficaz quando é estruturado. Estas são as dimensões que importam, aproximadamente por ordem de prioridade, e cada uma corresponde a critérios de sucesso específicos das WCAG 2.2.

Anúncios: nome, papel, valor

Para cada elemento interativo, confirme que o leitor anuncia um nome rigoroso (o que é), o papel correto (botão, ligação, caixa de verificação, separador) e, quando relevante, o valor ou estado. Este é o cerne da WCAG 4.1.2 (Nome, papel, valor). Ouça em particular: controlos silenciosos, controlos anunciados apenas como «clicável» ou «grupo», botões de ícone sem nome acessível, e nomes que são lidos como caminhos de ficheiro em bruto ou nomes de classes.

Papéis e estados

Os estados têm de se atualizar à medida que o utilizador interage. Um elemento expansível que se abre deve passar de «recolhido» para «expandido»; uma caixa de verificação deve passar de «não selecionada» para «selecionada»; um botão de ordenação deve anunciar a direção atual. A marcação estática que nunca atualiza aria-expanded, aria-checked, aria-selected ou aria-pressed é um dos defeitos mais comuns, e só se revela quando opera o widget com um leitor em funcionamento.

Ordem e gestão do foco

Percorra toda a interface com a tecla Tab. O foco deve mover-se numa ordem lógica e previsível (WCAG 2.4.3), deve estar sempre visível e nunca deve ficar preso, exceto deliberadamente dentro de uma janela modal. Os casos difíceis são dinâmicos: quando uma caixa de diálogo abre, o foco deve mover-se para ela; quando fecha, o foco deve regressar ao elemento que a abriu. Ignorar isto é a razão mais comum para um fluxo modal ser inutilizável.

Ordem de leitura e de navegação

Para além do foco, os utilizadores de leitores de ecrã navegam pela estrutura. Verifique se os títulos formam uma estrutura lógica (WCAG 1.3.1), se os marcos (header, nav, main, footer) permitem aos utilizadores deslocar-se, e se as listas e tabelas estão marcadas de modo a que o leitor as consiga percorrer e contar. Verifique se a sequência de leitura corresponde à intenção visual e se nada de importante é anunciado fora de ordem.

Regiões dinâmicas e atualizações dinâmicas

As alterações assíncronas — erros de validação, «3 resultados encontrados», «a guardar…», notificações efémeras — têm de chegar ao utilizador sem o sobrecarregar. aria-live="polite" para atualizações não urgentes, aria-live="assertive" apenas para as genuinamente urgentes, e role="status" ou role="alert" para os casos comuns. Teste se a região existe no DOM antes de o conteúdo mudar, se a atualização é anunciada exatamente uma vez, e se não interrompe o utilizador a meio de uma frase. Isto sustenta a WCAG 4.1.3 (Mensagens de estado).

Widgets ARIA personalizados

Tudo o que tenha construído de raiz — menus, separadores, caixas de combinação, seletores de data, carrosséis, grelhas de dados, vistas em árvore — exige o maior escrutínio. Teste face às ARIA Authoring Practices quanto à interação por teclado e aos anúncios esperados, e depois confirme se os leitores reais se comportam efetivamente assim. As APG descrevem o ideal; os leitores implementam-no de forma imperfeita, e é por isso que um padrão que funciona tem ainda de ser verificado em cada leitor.

Um exemplo concreto: um interruptor inacessível vs acessível

Considere um interruptor de definições. Uma versão visualmente estilizada mas semanticamente vazia:

<div class="toggle" onclick="setNotifications()">
  <span class="dot"></span> Notifications
</div>

Para um leitor de ecrã, isto é, na melhor das hipóteses, um pedaço de texto estático. Não há papel, pelo que não é anunciado como um controlo; não há estado, pelo que o utilizador não consegue saber se as notificações estão ligadas ou desligadas; e não está na ordem de tabulação, pelo que um utilizador de teclado ou de leitor de ecrã não consegue de todo alcançá-lo nem operá-lo. No teste, o NVDA lê «Notifications» e segue em frente; o VoiceOver pode ignorá-lo por completo.

O equivalente acessível usa o elemento nativo e expõe o estado:

<button type="button" aria-pressed="false" id="notif">
  Notifications
</button>

const btn = document.getElementById('notif');
btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!on));
});

Agora, cada leitor anuncia «Notifications, botão de alternância, não premido», o elemento é alcançável com Tab, operável com Enter ou Espaço, e o estado alterna de forma audível ao ser ativado. A lição é generalizável: prefira a semântica nativa e, quando tiver de usar ARIA, teste se cada leitor respeita efetivamente o papel e o estado. Padrões como este defeito de estado em falta estão entre os problemas de acessibilidade comuns a evitar.

Combinações de leitor e navegador recomendadas

Teste as combinações que os utilizadores reais usam, não pares arbitrários. Uma matriz prática que cobre a grande maioria dos utilizadores de leitores de ecrã:

NVDA + Firefox (Windows) — a linha de base mais limpa para detetar problemas de marcação
NVDA + Chrome (Windows) — a combinação de leitor gratuito mais comum na prática
JAWS + Chrome (Windows) — dominante em ambientes empresariais e governamentais
VoiceOver + Safari (macOS) — a única combinação de VoiceOver de computador totalmente suportada
VoiceOver + Safari (iOS) — móvel gestual, um alvo distinto do computador
TalkBack + Chrome (Android) — a combinação Android padrão

As combinações importam porque os leitores estão afinados para navegadores específicos; o VoiceOver com o Chrome ou o JAWS com o Firefox produz um comportamento que não reflete a forma como o seu público experiencia realmente a página. Quando as suas análises mostram um público específico — por exemplo, um produto do setor público com forte utilização de JAWS, ou uma aplicação de consumo orientada para o móvel — pondere a matriz em conformidade. O nosso serviço de avaliação de leitores de ecrã ajusta esta matriz às análises de cada cliente em vez de testar uma lista fixa.

Armadilhas comuns

Mesmo as equipas cuidadosas tropeçam nas mesmas coisas. Esteja atento a estas:

Testar de olhos abertos. Se conseguir ver o ecrã, vai compensar inconscientemente o que o leitor não lhe diz. Desligue o monitor, ou pelo menos desvie o olhar, e navegue apenas pelo áudio.
Testar apenas um leitor. Abordado acima — é, de longe, a maior fonte de falsa confiança.
Saltar o modo de formulário/foco. No NVDA e no JAWS, os widgets personalizados precisam muitas vezes de que o utilizador esteja no modo certo. Se só testar no modo de navegação, irá falhar interações que se quebram no modo de foco.
Abusar do aria-label. Adicionar etiquetas ARIA por todo o lado pode sobrepor-se ao texto visível, dessincronizar o nome acessível do que é mostrado e confundir os utilizadores de comando por voz. Prefira a rotulagem nativa; recorra a ARIA apenas quando o HTML não consegue exprimir a relação.
Presumir que as APG garantem o sucesso. As ARIA Authoring Practices descrevem o comportamento pretendido, não o que cada leitor faz. Verifique sempre face a leitores reais.
Confiar nos widgets de sobreposição. Os widgets de sobreposição e de «acessibilidade com IA» que afirmam corrigir o acesso de leitores de ecrã em tempo de execução não proporcionam uma experiência fiável e muitas vezes pioram a navegação para as próprias pessoas que dizem ajudar. Não há substituto para uma marcação acessível confirmada por testes reais. Audite o DOM e os anúncios reais, não o marketing da sobreposição.
Tratar o móvel como uma reflexão tardia. O VoiceOver no iOS e o TalkBack no Android expõem os seus próprios problemas de gestos, foco e regiões dinâmicas que o teste em computador nunca revela.

Porque os testes por pessoas com deficiência acrescentam valor

Executar um leitor por si próprio deteta imenso — mas há uma diferença significativa entre passar tecnicamente e ser genuinamente utilizável, e é aí que a experiência vivida mais conta. Um utilizador diário de leitor de ecrã navega por reflexo: move-se por título, percorre rapidamente com o rotor, reconhece quando um anúncio é prolixo ou redundante, e sente de imediato quando um fluxo o obriga a um caminho ineficiente, mesmo que cada elemento individual seja «conforme».

Um programador com visão a testar pela primeira vez tende a verificar a presença — «o botão é anunciado» — enquanto um utilizador especialista avalia a experiência — «o botão é anunciado, mas a etiqueta é ambígua, a confirmação não é pronunciada, e chegar aqui exigiu doze deslizes adicionais». Estas conclusões de usabilidade raramente aparecem numa lista de verificação de conformidade e, no entanto, são exatamente o que determina se alguém consegue realmente concluir uma tarefa. É por isso que a QualiBooth combina um software de análise de acessibilidade automatizado e o nosso conjunto de ferramentas de acessibilidade com auditorias por pessoas com deficiência: as ferramentas encontram o óbvio, os especialistas encontram o que realmente quebra a experiência. Para produtos que mudam com frequência, as auditorias de acessibilidade recorrentes impedem que essa cobertura se desvie entre versões.

Onde o teste de leitores de ecrã se insere no seu programa

O teste de leitores de ecrã é uma disciplina dentro de uma prática mais ampla. Combina-se naturalmente com o teste apenas por teclado e com as ferramentas web adaptativas em que os seus utilizadores se apoiam, e produz o tipo de prova que sustenta as obrigações legais ao abrigo da EAA, da ADA e da Section 508. As conclusões alimentam também diretamente a documentação: a nossa equipa traduz os resultados leitor a leitor em relatórios VPAT e nos planos de remediação priorizados que entregamos através da consultoria de acessibilidade. Se está a construir um programa de longo prazo em vez de uma verificação pontual, é essa integração que impede a acessibilidade de regredir.

Conclusão

Os leitores de ecrã não são intermutáveis, e um relatório automatizado impecável não é um produto utilizável. O NVDA, o JAWS, o VoiceOver e o TalkBack interpretam a sua marcação de forma diferente, combinam-se com navegadores diferentes e revelam defeitos diferentes — por isso, testar as combinações reais que o seu público usa é a única forma de ter confiança. Estruture os seus testes em torno dos anúncios, dos papéis e estados, do foco, da ordem de leitura, das regiões dinâmicas e dos widgets personalizados; prefira a semântica nativa aos remendos ARIA; ignore as sobreposições; e, sempre que possível, deixe que as pessoas que usam estas ferramentas todos os dias lhe digam o que realmente funciona.

Quando quiser essa confiança verificada por especialistas, a avaliação de leitores de ecrã da QualiBooth testa todos os principais leitores e devolve-lhe as conclusões com as correções exatas de marcação. Pode também começar com uma análise gratuita ou solicitar uma demonstração para ver onde está a sua interface hoje.

Perguntas frequentes

Quantos leitores de ecrã preciso realmente de testar?

No mínimo, teste o NVDA, o JAWS e o VoiceOver no computador, mais o VoiceOver no iOS e o TalkBack no Android se disponibilizar uma experiência móvel. Testar menos deixa pontos cegos, porque os leitores divergem na forma como tratam o ARIA e o conteúdo dinâmico.

As ferramentas automatizadas podem substituir o teste de leitores de ecrã?

Não. As ferramentas automatizadas detetam de forma fiável apenas uma parte dos problemas — texto alternativo em falta, alguns problemas de contraste, certos erros estruturais — mas não conseguem avaliar se um anúncio é claro, se o foco se move de forma sensata, ou se uma tarefa é efetivamente concluível apenas pelo áudio. Isso exige um leitor real e, idealmente, um utilizador real.

Os widgets de sobreposição ou de «acessibilidade com IA» eliminam a necessidade de testar?

Não. As sobreposições não produzem uma experiência fiável de leitor de ecrã e introduzem frequentemente novos problemas. A correção duradoura é uma marcação acessível confirmada por testes reais com leitores, e é isso que o nosso serviço de avaliação de leitores de ecrã oferece.

Que critérios WCAG é que o teste de leitores de ecrã cobre?

Sustenta diretamente o 1.3.1 (Informação e relações), o 2.4.3 (Ordem de foco), o 4.1.2 (Nome, papel, valor) e o 4.1.3 (Mensagens de estado), entre outros. Cada conclusão de uma avaliação estruturada pode ser associada ao critério de sucesso WCAG 2.2 relevante.