Visualização do leitor de tela

Cole HTML para ver como um leitor de tela o linearizaria e o anunciaria. Verifique seus textos alternativos, seus títulos e seus atributos ARIA.

Saída do leitor de tela

Cole HTML e clique em Analisar.
📚 Bases científicas e fontes

Para quem esta ferramenta foi projetada

Os leitores de tela são uma tecnologia assistiva essencial para pessoas cegas ou com deficiência visual significativa. Segundo o Relatório Mundial sobre a Visão da OMS (2019), pelo menos 2,2 bilhões de pessoas no mundo têm deficiência visual, das quais cerca de 43 milhões são cegas. A pesquisa WebAIM Screen Reader Survey (2024) constata sistematicamente que a grande maioria dos usuários de leitores de tela são pessoas com deficiência, sendo a cegueira a razão mais frequente. Desenvolvedores, designers e criadores de conteúdo usam esta ferramenta para pré-visualizar como seu HTML será interpretado pelas tecnologias assistivas, o que ajuda a identificar textos alternativos ausentes, estruturas de títulos incorretas, botões e campos sem nome acessível, e usos errados do ARIA, antes que os usuários finais os encontrem.

Como esta ferramenta funciona

Esta ferramenta analisa seu HTML via o DOMParser nativo do navegador (nenhum dado sai do seu dispositivo), depois percorre a árvore de acessibilidade para construir uma ordem de leitura linearizada. Ela verifica a presença de textos alternativos nas imagens, a coerência dos níveis de títulos, os links e botões sem nome acessível, as funções e rótulos ARIA, bem como os campos de formulário sem rótulo associado.

Referências científicas

  • WebAIM (2024). « Screen Reader User Survey #10 Results. » webaim.org · A maior pesquisa contínua sobre modos de uso de leitores de tela, combinações de navegadores e obstáculos de acessibilidade. Constata sistematicamente que títulos e landmarks são as principais estratégias de navegação dos usuários.
  • Organização Mundial da Saúde (2019). Relatório Mundial sobre a Visão. · Relata que pelo menos 2,2 bilhões de pessoas no mundo têm deficiência visual de perto ou de longe, das quais cerca de 43 milhões são cegas.
  • Power, C., Freire, A., Petrie, H. & Swallow, D. (2012). « Guidelines are only half of the story: Accessibility problems encountered by blind users on the web. » Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12). · Constatou que parte significativa dos problemas de acessibilidade encontrados por usuários cegos não era coberta apenas pelas WCAG, destacando a necessidade de revisão manual e testes com leitor de tela.
  • Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007). « What frustrates screen reader users on the web: A study of 100 blind users. » International Journal of Human-Computer Interaction, 22(3), 247–269. · Identificou textos alternativos ausentes, campos de formulário sem rótulo e rótulos de links enganosos entre as principais frustrações relatadas por usuários cegos.
  • W3C WAI (2023). « WAI-ARIA Authoring Practices 1.2. » · Define como as funções, estados e propriedades devem ser usados para tornar acessível um conteúdo dinâmico para tecnologias assistivas.

Aviso

Esta ferramenta oferece uma aproximação simplificada da saída de um leitor de tela com base na árvore de acessibilidade HTML. Os leitores de tela reais (NVDA, JAWS, VoiceOver, TalkBack) diferem na forma de anunciar o conteúdo, tratar atributos ARIA e interagir com widgets dinâmicos. Esta pré-visualização não substitui os testes com leitores de tela reais e com usuários reais. Destina-se a detectar problemas comuns cedo no processo de escrita.

Uma breve história dos padrões de acessibilidade web

A acessibilidade na web é governada por uma pequena pilha de padrões da Iniciativa de Acessibilidade Web do W3C (WAI), além das leis nacionais que os referenciam. WCAG 1.0 foi publicado em maio de 1999, a primeira orientação formal sobre como tornar o conteúdo web acessível. Era amplamente centrado em HTML e rapidamente ficou desatualizado. WCAG 2.0 (dezembro de 2008) foi uma reescrita importante organizada em torno de quatro princípios (Perceptível, Operável, Compreensível, Robusto) e três níveis de conformidade (A, AA, AAA). Tornou-se um padrão ISO (ISO/IEC 40500) em 2012 e é o alvo de conformidade que a maioria das leis ainda referencia. WCAG 2.1 (junho de 2018) adicionou 17 novos critérios de sucesso cobrindo móvel, visão baixa e deficiências cognitivas. WCAG 2.2 (outubro de 2023) adicionou mais 9, notavelmente 2.4.11 Foco Não Obscurecido e 3.3.8 Autenticação Acessível. WAI-ARIA 1.0 foi finalizada em março de 2014; 1.2 em junho de 2023 é a Recomendação atual. No lado legal, a Atualização Seção 508 dos EUA (janeiro de 2018) incorporou WCAG 2.0 AA na aquisição federal dos EUA. A Lei Europeia de Acessibilidade (Diretiva 2019/882) entrou em vigor em 28 de junho de 2025, exigindo que a maioria dos produtos digitais voltados ao consumidor na UE atenda aos padrões de acessibilidade. A maioria dos países referencia WCAG, então construir para WCAG 2.2 AA é o alvo prático para qualquer produto global hoje.

O panorama de leitores de tela hoje

A WebAIM Screen Reader User Survey #10 (2024) é a fonte canônica sobre quais leitores de tela as pessoas realmente usam. Cinco produtos dominam desktop, móvel e ChromeOS.

  • JAWS (Freedom Scientific, primeiro lançamento 1989) é o líder comercial de longa data no Windows. Custa ~$1000+. WebAIM 2024 o encontra como o leitor de tela principal para cerca de 40% dos respondentes da pesquisa, ligeiramente abaixo do NVDA.
  • NVDA (NV Access, primeiro lançamento 2006, escrito em Python) é a alternativa de código aberto para Windows. Gratuito. WebAIM 2024 o relata como o leitor de tela principal mais usado, cerca de 47% dos respondentes. O crescimento do NVDA de uma ferramenta de nicho para líder do mercado em 15 anos é uma das grandes histórias de sucesso de código aberto em tecnologia assistiva.
  • VoiceOver (Apple, 2005 no macOS, 2009 no iOS) vem integrado em cada Mac, iPhone, iPad, Apple Watch, Apple TV. É o leitor de tela móvel mais usado. Fortemente integrado com Safari e o rotor iOS para navegação.
  • TalkBack (Google, 2009 no Android) é o equivalente Android. Código aberto desde Android 4. Usa gestos e o menu de navegação.
  • ChromeVox (Google, 2012) e Narrator (Microsoft, 2000, modernizado no Windows 10) completam o cenário. Cada um tem uma base de usuários pequena mas leal.

Uma única página pode ser anunciada diferentemente por cada produto. Páginas robustas testam limpamente em pelo menos dois: geralmente NVDA + Firefox ou Chrome, e VoiceOver + Safari.

Quando recorrer a esta ferramenta

  • Auditorias pré-lançamento. Cole uma página chave (homepage, formulário de cadastro, checkout) e leia a saída linearizada em voz alta. Se não fizer sentido para você, não fará sentido para um usuário de leitor de tela.
  • Revisões de código. Antes de mesclar um PR com mudanças significativas de marcação, cole o HTML renderizado e confirme que cabeçalhos, marcos e texto alternativo sobreviveram intactos.
  • Verificação de entrega de design. Designers podem colar seu HTML final para confirmar que a hierarquia visual corresponde à hierarquia semântica. Uma página que parece um cabeçalho também deveria ser um no DOM.
  • Ensinar acessibilidade. Mostre a uma turma ou equipe o que um leitor de tela realmente recebe. A lacuna entre o layout visual e a saída linearizada é frequentemente a primeira vez que desenvolvedores não deficientes entendem por que HTML semântico importa.
  • Verificações de conformidade com WCAG. Verificações rápidas para os quatro critérios mais violados: 1.1.1 Conteúdo não textual (texto alternativo), 1.3.1 Informação e relacionamentos (estrutura semântica), 2.4.4 Propósito do link, 4.1.2 Nome, função, valor.
  • Verificações de site CMS / no-code. Editores visuais frequentemente produzem divs em vez de cabeçalhos ou links sem texto. Cole o HTML publicado, veja o que passou.
  • Acessibilidade de templates de email. Emails HTML são notoriamente difíceis de tornar acessíveis. Use a visualização para verificar texto alternativo em cada imagem, ordem adequada de cabeçalhos e fluxo de leitura legível.

Erros comuns que os leitores de tela expõem

  • Texto alternativo ausente ou inútil. alt="image", alt="photo", alt="logo" são quase melhor que nada. Lazar et al. (2007) identificaram texto alternativo ausente como a principal frustração dos usuários web cegos. Escreva texto alternativo que transmita o propósito da imagem no contexto circundante, ou use alt="" para imagens puramente decorativas para que o leitor de tela as pule.
  • Níveis de cabeçalho que pulam ou reiniciam. Ir de h1 para h3 pulando h2 confunde a navegação. Usar múltiplos elementos h1 na mesma página (um padrão bastante comum em design orientado a componentes) quebra o esquema do documento pelo qual os usuários de leitores de tela navegam. WebAIM 2024 encontra que cabeçalhos são a estratégia de navegação mais comum para usuários de leitores de tela.
  • Divite. Envolver texto clicável em <div> com um manipulador de clique em vez de usar <button> ou <a> significa sem suporte de teclado, sem anel de foco, sem anúncio de função. Sempre comece com HTML semântico e adicione ARIA apenas quando nenhum elemento nativo se encaixar.
  • ARIA usado onde HTML serviria. Primeira regra do ARIA (segundo as Práticas de Autoria WAI-ARIA do W3C): «se você puder usar um elemento HTML nativo... faça-o». <button role="button"> é redundante; <div role="button"> é um sinal de que você deveria usar um botão real.
  • ARIA usado incorretamente. aria-hidden="true" em um elemento focalizável o torna invisível aos leitores de tela mas ainda focalizável por teclado, uma receita para uma ordem de tabulação desorientadora. role="button" sem tabindex="0" e manipuladores de teclado não faz nada útil.
  • Campos de formulário sem rótulos. Um <input> sem um <label>, aria-label ou aria-labelledby associado é anunciado como «edit, blank» sem contexto. Texto de placeholder não é um substituto, desaparece ao focar e frequentemente falha em contraste.
  • Links «click here» e «read more». Usuários de leitores de tela frequentemente navegam puxando a lista de todos os links na página. «Click here» sozinho não lhes diz nada. Faça o texto do link descrever o destino: «Leia a pesquisa WebAIM 2024» vence «Leia mais aqui».
  • Remover estilos de foco. outline: none sem um indicador de foco substituto é um dos critérios WCAG mais violados (2.4.7 Foco Visível). Usuários de teclado, incluindo muitos usuários de leitores de tela, precisam ver onde o foco está.

ARIA em um relance: o que cada tipo de função faz

  • Funções de marco (banner, navigation, main, complementary, contentinfo, search) dividem a página em regiões entre as quais um usuário de leitor de tela pode saltar. A maioria tem equivalentes HTML nativos (<header>, <nav>, <main>, <aside>, <footer>). Use o elemento nativo primeiro.
  • Funções de widget (button, checkbox, combobox, menu, tabpanel, etc.) descrevem controles interativos. As funções de widget implicam padrões de interação de teclado que o Guia de Práticas de Autoria ARIA do W3C (APG) documenta em detalhes. Se você não puder corresponder à especificação APG exatamente, prefira HTML nativo.
  • Funções de estrutura de documento (article, list, listitem, row, cell, etc.) descrevem conteúdo não interativo. A maioria também tem equivalentes HTML nativos. Use-os apenas quando o elemento nativo estiver indisponível (e.g., construir uma grade de dados personalizada onde <table> não se encaixe).
  • Regiões ao vivo (aria-live="polite", aria-live="assertive", role="status", role="alert") dizem aos leitores de tela para anunciar atualizações dinâmicas sem mover o foco. Usado para mensagens de chat, erros de formulário, estados de carregamento. O uso excessivo causa fadiga de notificação; reserve assertive para emergências genuínas como estados de erro.

Mais perguntas frequentes

Esta visualização corresponde ao que NVDA / JAWS / VoiceOver realmente dirão?

Ela aproxima. Esta ferramenta lê a árvore de acessibilidade do navegador (a mesma estrutura que os leitores de tela usam) e produz uma versão linearizada do que seria anunciado. Leitores de tela reais adicionam comportamentos específicos do produto: anúncios de mudanças de foco, navegação em tabelas, cabeçalhos de tabela, contagens de itens de lista, tratamento de cortesia ARIA-live, configurações de verbosidade personalizadas. Trate a visualização como uma primeira verificação de sanidade; para lançamentos de produção, teste com pelo menos um leitor de tela real nos sistemas operacionais que sua audiência usa.

Qual é a diferença entre WCAG e ARIA?

WCAG (Web Content Accessibility Guidelines) é uma lista de requisitos: «todo conteúdo não textual deve ter uma alternativa textual». Diz o quê alcançar mas nem sempre como. ARIA (Accessible Rich Internet Applications) é uma das ferramentas para atender ao WCAG: um conjunto de atributos HTML (funções, estados, propriedades) que expõem a semântica à tecnologia assistiva quando o HTML nativo é insuficiente. Você pode atender ao WCAG sem ARIA algum se seu HTML for suficientemente semântico. ARIA é para os casos em que não é.

Como escrevo bom texto alternativo?

Três regras da Árvore de Decisão alt do W3C: (1) Se a imagem é puramente decorativa, use alt="" para que o leitor de tela a pule completamente. (2) Se a imagem transmite informações não já no texto circundante, descreva essas informações concisamente (tipicamente abaixo de 125 caracteres). (3) Se a imagem é funcional (e.g., um logo que linka para a home ou um botão de ícone), descreva a ação em vez da aparência. «Pesquisar» vence «ícone de lupa». Evite «imagem de...», «foto de...», leitores de tela já anunciam que o elemento é uma imagem.

Meu site usa divs em todo lugar. Por onde começo?

Comece adicionando os cinco elementos de marco: <header>, <nav>, <main>, <aside>, <footer>. Então substitua divs clicáveis por <button> (para ações) ou <a> (para navegação). Então audite os cabeçalhos: cada página deveria ter um <h1> e o resto em ordem aninhada. Esses três passos consertam talvez 70% dos problemas de acessibilidade em um site típico carregado de divs. ARIA e gestão de foco JavaScript vêm depois, uma vez que a base semântica esteja no lugar.

O HTML que colo aqui é enviado para algum lugar?

Não. A análise usa o DOMParser integrado do navegador e a análise executa inteiramente do lado do cliente. Abra a aba Rede no DevTools e clique Analisar, você verá zero requisições de saída durante a linearização. Seguro para templates internos, páginas não lançadas ou HTML contendo dados de clientes.

Ferramentas relacionadas

Verificador de cabeçalho WCAG Recursos de acessibilidade Gerador de paleta de cores acessível Verificador de contraste de cores