Leitores de Tela Explicados: Como Pessoas Cegas Navegam na Web

Estima-se que existam 36 milhões de pessoas cegas em todo o mundo, e aproximadamente mais 217 milhões vivem com deficiência visual moderada a grave. Ainda assim, em 2025, mais de 96% dos sites ainda têm pelo menos uma falha de acessibilidade detectável. Para uma pessoa cega que depende de um leitor de tela, um único rótulo ausente, uma hierarquia de títulos quebrada ou um CAPTCHA inacessível pode ser a diferença entre concluir uma tarefa de forma independente e abandonar completamente o seu site. Entender como os leitores de tela realmente funcionam — não apenas em teoria, mas na prática — é a base para construir uma web acessível.

O que é um leitor de tela e quem usa um?

Um leitor de tela é um software de tecnologia assistiva que converte o conteúdo exibido na tela em fala sintetizada ou em saída braille por meio de linha braille. Em vez de simplesmente ler o texto em voz alta, os leitores de tela interpretam a estrutura, os papéis, os estados e as relações dos elementos da interface, oferecendo às pessoas usuárias uma compreensão abrangente de uma página da web sem depender da apresentação visual. Pense nele menos como um narrador e mais como um intérprete inteligente que traduz toda a sua interface visual em um fluxo de informações em áudio ou tátil.

Leitores de tela são usados principalmente por pessoas cegas ou com baixa visão, mas também dão suporte a pessoas com determinadas deficiências cognitivas ou de leitura. De acordo com a 10ª Pesquisa de Usuários de Leitores de Tela da WebAIM — conduzida no final de 2023 e publicada em fevereiro de 2024 — quase 77% das pessoas que usam leitores de tela são pessoas com cegueira, seguidas por pessoas com baixa visão ou outras deficiências visuais, com quase 20%. Perda auditiva, deficiências cognitivas e deficiências motoras respondem pelo restante. Este não é um público de nicho: 4,9% dos adultos nos EUA têm uma deficiência visual com cegueira ou dificuldade séria de enxergar, e o número global de pessoas com deficiência visual é contado em centenas de milhões.

Também vale destacar que pessoas que usam leitores de tela não formam um grupo homogêneo. Pesquisas mostram de forma consistente uma grande variação em habilidades, preferências, estratégias de navegação e abordagens de resolução de problemas. Uma pessoa que é cega desde o nascimento e usa JAWS há vinte anos navega de forma muito diferente de alguém que perdeu a visão recentemente e ainda está aprendendo tecnologia assistiva. Mesmo sites tecnicamente acessíveis podem apresentar desafios significativos quando os modelos mentais que exigem não correspondem às expectativas da pessoa usuária. Designers e desenvolvedores devem resistir à tentação de imaginar uma única pessoa usuária de leitor de tela arquetípica.

Como os leitores de tela realmente funcionam: a árvore de acessibilidade

Para realmente entender os leitores de tela, é preciso entender o que eles leem — e não é o seu layout visual. Leitores de tela funcionam acessando a árvore de acessibilidade, uma representação estruturada da página que o navegador constrói a partir do DOM HTML. O navegador expõe essa árvore por meio de APIs de acessibilidade específicas da plataforma: UI Automation no Windows, NSAccessibility no macOS e AccessibilityService no Android. O leitor de tela consulta essa API, recebe informações semânticas sobre cada elemento e as converte em saída de voz ou braille.

Isso tem uma implicação crucial: o que você vê na tela e o que um leitor de tela percebe pode ser radicalmente diferente. Se o seu design visual usa uma <div> estilizada para parecer um botão, um leitor de tela não vai anunciá-la como um botão — porque ela não tem papel de botão na árvore de acessibilidade. O leitor de tela anuncia o que o código diz, não o que os pixels mostram. Elementos HTML semânticos como <button>, <nav>, <h1> e <form> carregam papéis embutidos que são expostos automaticamente à árvore de acessibilidade. Quando desenvolvedores ignoram esses elementos em favor de elementos genéricos remendados com papéis ARIA, criam complexidade desnecessária e frequentemente introduzem novos erros.

Leitores de tela também fornecem contexto que não é visível na tela. Quando uma pessoa encontra uma lista, o leitor de tela anuncia quantos itens ela contém. Quando uma tabela é alcançada, ele anuncia o número de linhas e colunas. Quando o foco se move para um campo de formulário, ele lê o rótulo do campo, seu tipo e seu estado atual. Esses metadados contextuais dependem inteiramente de HTML bem estruturado e semântico. Se você os remove, remove também a capacidade da pessoa usuária de entender com o que está lidando.

Os principais leitores de tela: JAWS, NVDA, VoiceOver e TalkBack

O mercado de leitores de tela é dominado por um pequeno conjunto de ferramentas, cada uma com características distintas. Entender quais ferramentas suas pessoas usuárias provavelmente utilizam informa diretamente como você deve testar seu site.

JAWS (Job Access With Speech), desenvolvido pela Freedom Scientific e lançado pela primeira vez em 1995, há muito é considerado o padrão ouro do setor, especialmente para uso corporativo. Na pesquisa WebAIM 2024, o JAWS era o leitor de tela principal de aproximadamente 41% das pessoas respondentes. É um produto comercial com custos de licenciamento que variam de US$ 90 a mais de US$ 1.400 por ano. O JAWS oferece ampla personalização, compatibilidade robusta com fluxos de trabalho complexos no Microsoft Office e em aplicativos profissionais, e um “Browse Mode” que transforma a página em um ambiente linear navegável, permitindo que as pessoas saltem por títulos, marcos e campos de formulário usando teclas de atalho intuitivas.

NVDA (NonVisual Desktop Access), desenvolvido pela NV Access e introduzido em 2006, é um leitor de tela gratuito e de código aberto para Windows. Ele foi o leitor de tela principal de aproximadamente 38% das pessoas respondentes da pesquisa WebAIM em 2024 — quase idêntico ao JAWS. O NVDA ganhou popularidade significativa devido ao seu modelo gratuito, atualizações frequentes e desempenho robusto. Em 2025, o NVDA introduziu melhorias no tratamento da gestão de foco em aplicações de página única, ajudando as pessoas a entender quando o conteúdo mudou e para onde o foco se moveu. Seu emparelhamento de navegador recomendado é o Firefox, embora o suporte ao Chrome também seja forte.

VoiceOver é o leitor de tela integrado da Apple, disponível no macOS, iOS e iPadOS — sem necessidade de instalação. No desktop, ele usa atalhos de teclado com o modificador VO (Control + Option), enquanto no iOS depende de gestos de toque como deslizar, toque duplo e o rotor. Em dispositivos móveis, o VoiceOver é o leitor de tela mais utilizado, com 70,6% das pessoas usuárias de leitores de tela móveis dependendo dele. Ele funciona melhor emparelhado com o Safari, que é o único navegador que expõe totalmente as APIs de acessibilidade do macOS/iOS ao VoiceOver.

TalkBack é o leitor de tela integrado do Android, oferecendo feedback falado e vibrações para ajudar as pessoas a navegar em seus dispositivos. É a ferramenta padrão para testes móveis em Android e funciona melhor com o Chrome. O Windows também vem com o Narrator, um leitor de tela integrado que tem melhorado de forma constante, mas ainda carece de alguns recursos do JAWS e do NVDA. Cada uma dessas ferramentas se comporta de forma um pouco diferente — um padrão que funciona corretamente no NVDA pode falhar no JAWS — e é por isso que testar em vários leitores de tela é essencial para qualquer programa sério de acessibilidade.

Como pessoas cegas realmente navegam: o modelo mental que muda tudo

Eis o insight que mais profundamente transforma a forma como desenvolvedores devem pensar sobre seu trabalho: pessoas que usam leitores de tela não leem páginas de forma linear, de cima para baixo. Elas usam um conjunto sofisticado de estratégias de navegação para percorrer e saltar pelo conteúdo de forma eficiente, de maneira muito semelhante a como uma pessoa vidente faz uma leitura dinâmica visual. Se você não der suporte a essas estratégias, até mesmo uma página tecnicamente acessível se torna uma experiência exaustiva e inutilizável.

A estratégia de navegação mais prevalente é a navegação por títulos. O uso de títulos para encontrar informações aumentou ao longo do tempo e continua sendo o método predominante — 88,8% das pessoas respondentes da pesquisa consideram os níveis de título muito ou um pouco úteis. Pessoas usuárias avançadas têm muito mais probabilidade de navegar por títulos do que iniciantes. Na prática, isso significa que a pessoa pressiona a tecla H no JAWS ou NVDA para pular para o próximo título na página, examinando rapidamente a estrutura. Pressionar 1 a 6 leva diretamente a um título daquele nível. Se a sua página não tem títulos, ou usa títulos escolhidos pelo tamanho visual em vez da estrutura do documento, pessoas cegas não têm marcos entre os quais possam saltar — são obrigadas a ouvir a página inteira desde o início.

A segunda grande estratégia é a navegação por marcos. Elementos de marco do HTML5 — <main>, <nav>, <header>, <footer>, <aside> e <section> com um rótulo — criam regiões nomeadas entre as quais pessoas que usam leitores de tela podem saltar usando o rotor ou teclas de atalho de marcos. Em 2025, a adoção de marcos ARIA aumentou ligeiramente, impulsionada pelo uso crescente do elemento nativo <main>, agora presente em 47% das páginas. Embora 31,7% das pessoas respondentes indiquem que sempre ou frequentemente usam marcos quando presentes, apenas 3,7% usam marcos como seu método principal de navegação — o que sugere que marcos são uma ferramenta secundária, mas importante para orientação.

As pessoas também navegam por links, campos de formulário e botões usando atalhos de tecla única, e frequentemente abrem listas de elementos — uma caixa de diálogo que mostra todos os títulos, todos os links ou todos os campos de formulário da página de uma vez — para examinar e saltar diretamente para o que precisam. Esse comportamento tem enormes implicações para o texto de links. Uma lista de links que diz “Leia mais, Leia mais, Leia mais” não oferece nenhum valor de navegação. Cada link e botão deve ter um nome acessível descritivo e único que faça sentido fora de contexto.

Em dispositivos móveis, o paradigma muda para gestos de toque. Pessoas que usam VoiceOver e TalkBack deslizam para a direita para ir ao próximo elemento, tocam duas vezes para ativá-lo e usam gestos de rotor para alternar entre modos de navegação. A preferência pelo uso de aplicativos móveis aumentou para 58% em 2024, em comparação com 51,8% em 2021. Isso significa que o seu design responsivo e a sua acessibilidade móvel não são complementos opcionais — são casos de uso principais para uma grande parcela das pessoas que usam leitores de tela.

As barreiras mais problemáticas na web hoje

A pesquisa da WebAIM pediu às pessoas respondentes que identificassem os itens mais problemáticos que encontram. Os resultados são notavelmente consistentes ao longo de mais de uma década de pesquisas — e constituem uma lista direta do que o seu site precisa acertar.

• CAPTCHA é, de longe, a principal reclamação. Pessoas que usam leitores de tela concordam que o CAPTCHA tem sido o item mais problemático por mais de quatorze anos consecutivos. O uso de um CAPTCHA tradicional é obviamente problemático para pessoas cegas, já que os leitores de tela dos quais dependem não conseguem processar a imagem, impedindo-as de descobrir a informação exigida pelo formulário. Mesmo CAPTCHAs em áudio falham para muitas pessoas — a distorção intencional os torna ininteligíveis. A recomendação prática: use verificação invisível baseada em comportamento, como o reCAPTCHA v3, ou técnicas de honeypot sempre que possível.
• Elementos interativos com comportamento inesperado — menus, abas, janelas de diálogo e widgets personalizados que não seguem padrões estabelecidos de interação por teclado — vêm logo atrás do CAPTCHA. Esses elementos são frequentemente construídos com atributos ARIA em excesso e apresentam comportamento de interação irregular e problemas de compatibilidade entre navegadores e leitores de tela.
• Links e botões ambíguos frustram constantemente as pessoas usuárias. Frases como “clique aqui”, “saiba mais” ou “leia mais” não oferecem nenhuma pista sobre o destino ou a ação quando ouvidas isoladamente em uma lista de links.
• Mudanças inesperadas na tela — atualizações de conteúdo dinâmico que ocorrem sem aviso — desorientam pessoas cegas que não têm pista visual de que algo mudou. Isso é particularmente agudo em aplicações de página única construídas com React, Vue ou Angular, em que o conteúdo pode mudar sem recarregar a página.
• Hierarquias de títulos quebradas prejudicam a principal estratégia de navegação da maioria das pessoas usuárias avançadas. Cerca de 39% dos sites têm hierarquias de títulos quebradas, o que dificulta que pessoas que usam leitores de tela naveguem adequadamente pelo conteúdo.
• Texto alternativo ausente ou inadequado em imagens. Quando o texto alternativo está ausente, um leitor de tela pode apenas indicar a presença de uma imagem sem descrever seu conteúdo ou — pior — ler um nome de arquivo sem sentido como “IMG_4823.jpg”.

A maioria — 67% — das pessoas que usam leitores de tela nunca ou raramente entra em contato com proprietários de sites sobre barreiras. Elas simplesmente vão embora. Você não receberá uma reclamação. Você apenas perderá uma pessoa usuária.

Escrevendo código que leitores de tela realmente conseguem interpretar

Entender os padrões de navegação das pessoas usuárias torna os requisitos técnicos muito mais concretos. Cada decisão que você toma em marcação e JavaScript tem uma consequência direta e audível para pessoas cegas. Estes são os princípios que mais importam.

HTML semântico é a sua primeira e mais poderosa ferramenta. A primeira regra do ARIA afirma: “Se você pode usar um elemento ou atributo HTML nativo com a semântica e o comportamento de que precisa já embutidos, em vez de reaproveitar um elemento e adicionar um papel, estado ou propriedade ARIA para torná-lo acessível, então faça isso.” Elementos como <button>, <nav>, <header> e <form> já vêm com acessibilidade incorporada. Usar controles nativos garante compatibilidade com navegadores e tecnologia assistiva desde o início, sem código adicional.

ARIA é um complemento, não um substituto. ARIA (Accessible Rich Internet Applications) é um conjunto de atributos HTML projetado para preencher lacunas de acessibilidade quando o HTML sozinho não consegue expressar a semântica necessária — por exemplo, tornar um controle deslizante personalizado acessível, anunciar mudanças dinâmicas de conteúdo ou indicar que um menu recolhível está atualmente expandido. O perigo está no uso indevido. Páginas iniciais com ARIA presente têm, em média, mais que o dobro de erros de acessibilidade em comparação com páginas sem ARIA. Mais ARIA não significa mais acessível — muitas vezes significa mais erros. Páginas que usaram ARIA incorretamente apresentaram 70% mais erros detectáveis do que aquelas que não usaram. Use ARIA de forma cirúrgica, onde nenhum elemento nativo consegue cumprir a função.

O exemplo de código a seguir ilustra a diferença entre um botão personalizado inacessível e um adequadamente acessível:

<!-- Inacessível: uma div com manipulador de clique, sem papel, sem suporte a teclado -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Acessível: botão nativo com papel embutido, suporte a teclado e foco -->
<button type='submit'>Submit</button>

<!-- Se você precisar usar um elemento que não seja botão, adicione papel, tabindex e evento de teclado -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

Regiões dinâmicas ARIA (ARIA live regions) são o mecanismo correto para anunciar mudanças dinâmicas de conteúdo. Quando sua página atualiza conteúdo sem recarregar totalmente — uma mensagem de validação de formulário, um total de carrinho, uma notificação — essa mudança é silenciosa para uma pessoa que usa leitor de tela, a menos que você use uma região dinâmica. O atributo aria-live='polite' instrui o leitor de tela a anunciar a mudança depois que a atividade atual da pessoa usuária for concluída, enquanto aria-live='assertive' interrompe imediatamente — use este último com moderação, apenas para alertas urgentes. Em 2025, cerca de 33% dos sites usam o atributo aria-live, um aumento de 4% em relação a 2024, mas a adoção ainda é muito baixa considerando quantas interfaces dinâmicas são implantadas.

Gestão de foco em componentes interativos — diálogos modais, menus suspensos, acordeões — deve ser tratada explicitamente. Quando um modal é aberto, o foco deve se mover para dentro dele. Quando é fechado, o foco deve retornar ao elemento que o acionou. Uma pessoa que usa leitor de tela e abre um modal e encontra o foco ainda no botão atrás dele está, na prática, impedida de acessar o conteúdo da caixa de diálogo.

Testando seu site com um leitor de tela

Verificadores automáticos de acessibilidade são valiosos, mas limitados. Ferramentas automatizadas detectam 30–40% das violações da WCAG, mas testes com tecnologia assistiva real revelam como as pessoas realmente experimentam o seu site — contexto ausente, navegação confusa e interações que simplesmente não funcionam. Nenhum verificador vai dizer que o título do seu modal não faz sentido sem o contexto visual ao redor, ou que o seu menu suspenso personalizado anuncia seu estado de forma incorreta em uma combinação específica de navegador e leitor de tela, mas não em outra.

O ponto de partida prático para a maioria das equipes é o NVDA com Firefox — gratuito, amplamente utilizado e eficaz para detectar a grande maioria dos problemas comuns. Adicione o VoiceOver com Safari para cobrir pessoas usuárias de macOS e iOS. Para contextos corporativos ou clientes com altos requisitos de conformidade, inclua o JAWS com Chrome ou Edge. Cada leitor de tela funciona melhor com um emparelhamento específico de navegador; usar a combinação errada pode produzir resultados de teste enganosos.

Ao testar, adote os padrões de navegação que as pessoas usuárias reais empregam. Não use mouse. Navegue por títulos usando a tecla H. Abra a lista de links e confirme se cada link faz sentido fora de contexto. Percorra os campos de formulário com a tecla Tab e verifique se cada rótulo é anunciado corretamente. Abra diálogos modais e verifique se o foco se move para dentro deles. Preencha formulários e envie-os, ouvindo cada mensagem de validação. Desligue o monitor e tente concluir uma tarefa representativa de pessoa usuária do início ao fim — essa experiência, por mais desconfortável que seja para uma pessoa testadora vidente, é a realidade cotidiana das suas pessoas usuárias cegas.

Também é importante testar com tecnologia assistiva real, e não com emuladores ou simuladores de navegador. Os painéis de acessibilidade das ferramentas de desenvolvedor do navegador mostram a árvore de acessibilidade, o que é útil para depuração, mas não reproduzem a experiência auditiva nem revelam peculiaridades de interação que só surgem com software de leitor de tela real.

O caso comercial e legal que você não pode ignorar

Se o argumento moral para acessibilidade precisa ser reforçado com a realidade comercial, os números são contundentes. Existem aproximadamente 7 milhões de pessoas com deficiência visual apenas nos Estados Unidos, representando uma base de consumidores significativa. Globalmente, 26% dos adultos dos EUA têm deficiências, representando uma oportunidade de mercado estimada em US$ 13 trilhões. Quando um design inacessível impede pessoas cegas de usar o seu site, você não está apenas falhando em uma obrigação moral — está recusando clientes e expondo sua organização a riscos legais.

A WCAG 2.2 é agora o padrão legal de referência em milhares de processos judiciais relacionados à ADA, e o Ato Europeu de Acessibilidade, que entrou em pleno vigor para empresas do setor privado em junho de 2025, estende os requisitos de conformidade em toda a UE. A maioria das pessoas que usam leitores de tela nunca entra em contato com proprietários de sites sobre barreiras — elas simplesmente vão embora e levam seus negócios para outro lugar. Os 67% de pessoas que nunca relatam problemas não estão satisfeitas; estão derrotadas. Incorporar a compatibilidade com leitores de tela ao seu processo de desenvolvimento desde o início evita retrabalho caro, reduz a exposição legal e abre seus produtos para um público que está ativamente procurando experiências digitais que realmente consiga usar.

Pontos principais

• Leitores de tela navegam pela estrutura, não pelos visuais. Eles consultam a árvore de acessibilidade do navegador por meio de APIs de acessibilidade da plataforma. HTML semântico — títulos adequados, marcos, controles nativos — é o investimento de maior impacto que você pode fazer na compatibilidade com leitores de tela.
• Pessoas cegas navegam por títulos, marcos e listas de elementos — não de forma linear. Mais de 88% das pessoas que usam leitores de tela consideram os níveis de título muito ou um pouco úteis para navegação. Uma hierarquia de títulos quebrada ou ausente é uma das falhas de acessibilidade mais comuns e prejudiciais na web.
• ARIA amplifica tanto marcação boa quanto ruim. Páginas com ARIA presente têm, em média, mais que o dobro de erros de acessibilidade em comparação com páginas sem ARIA. Use ARIA apenas quando o HTML nativo não conseguir expressar a semântica necessária e sempre teste com tecnologia assistiva real após implementá-lo.
• CAPTCHA, links ambíguos e mudanças de conteúdo dinâmico não anunciadas são as principais barreiras do mundo real. Substituir CAPTCHA visual por verificação baseada em comportamento, escrever textos descritivos para links e botões e implementar regiões dinâmicas ARIA para atualizações dinâmicas terá um impacto imediato e mensurável na usabilidade para pessoas cegas.
• Teste com leitores de tela reais em vários emparelhamentos de navegador. Verificadores automatizados detectam apenas 30–40% das violações da WCAG. NVDA com Firefox e VoiceOver com Safari cobrem a maioria da sua base de pessoas usuárias a custo zero, e a experiência de navegar no seu site sem mouse revela problemas que nenhuma ferramenta automatizada consegue identificar.