Conversão de texto em fala vs leitores de ecrã

O seu conteúdo tem voz

A tecnologia de conversão de texto em fala (TTS) transforma informação escrita em áudio. Ajuda pessoas com cegueira, deficiência visual, dislexia e PHDA a consumir conteúdo de uma forma que funciona para elas. A TTS é também amplamente utilizada nas escolas, por quem aprende línguas e por profissionais que revêem ouvindo em vez de lendo com os olhos.

Como tanto a TTS como os leitores de ecrã produzem uma voz sintética, é frequente supor que são a mesma coisa — ou que acrescentar um botão de «ler em voz alta» a um site o torna acessível para utilizadores cegos. Esse pressuposto está errado, e agir com base nele pode deixá-lo com um site que parece acessível mas que muitas pessoas não conseguem de facto utilizar. Este artigo explica como funciona cada tecnologia, quem depende dela, onde se situa realmente a fronteira entre as duas e o que é preciso para conceber bem para leitores de ecrã. Se só guardar uma ideia, guarde esta: um widget de leitura em voz alta é uma funcionalidade de conveniência, não uma funcionalidade de acessibilidade.

Como funciona a TTS?

A TTS processa o texto em três grandes fases:

• Análise do texto — determinar o tom, a gramática e a estrutura, expandir números e símbolos («5 €» torna-se «cinco euros») e segmentar frases.
• Processamento linguístico — calcular a pronúncia, a acentuação e a ênfase, recorrendo muitas vezes a um dicionário de pronúncia mais regras para palavras desconhecidas.
• Síntese de áudio — gerar a fala a partir de modelos vocais matemáticos, utilizando cada vez mais redes neuronais que soam muito mais naturais do que os antigos motores de concatenação.

Os sistemas modernos oferecem personalização da voz, como a velocidade, o tom, o perfil de voz e a seleção do idioma. O ponto crucial é o que a TTS recebe como entrada: um bloco de texto que alguém já selecionou, colou ou indicou. A TTS é fundamentalmente uma tecnologia de restituição de conteúdo. Diz o que lhe é dado. Não explora uma interface e não tem qualquer noção de botões, campos de formulário ou estrutura de página.

Quais são as limitações da tecnologia de TTS?

A TTS é genuinamente útil, mas não é perfeita, e os seus limites são relevantes para a comparação que se segue:

• Falhas de pronúncia — pode pronunciar mal palavras pouco comuns, nomes próprios, termos médicos ou jurídicos e abreviaturas.
• Suporte irregular de idiomas — muitas ferramentas lidam bem com os idiomas mais comuns, mas têm dificuldades com línguas menos comuns e dialetos regionais.
• Tom e nuance — a TTS tem dificuldade com o sarcasmo, o humor e as expressões idiomáticas, pelo que o conteúdo pode ser transmitido com o tom errado.
• Sem modelo de interação — e este é o ponto fundamental: a TTS lê; não lhe permite fazer nada. Não consegue preencher um formulário de pagamento, fechar uma janela modal ou avançar entre itens de menu apenas com a TTS.

Esta última limitação é precisamente onde começa a confusão com os leitores de ecrã.

Qual é a diferença entre a conversão de texto em fala e a tecnologia dos leitores de ecrã?

É aqui que surge o equívoco comum. A conversão de texto em fala lê texto em voz alta — essa é a sua função principal. Um leitor de ecrã faz muito mais: permite aos utilizadores navegar e operar todo um computador ou dispositivo móvel pelo ouvido e pelo teclado (ou por gestos táteis).

Os leitores de ecrã anunciam as etiquetas da interface, os campos de formulário, os botões e as ligações; leem o texto alternativo das imagens para que os utilizadores compreendam o conteúdo visual; e expõem o estado dos componentes — se uma caixa está assinalada, se um menu está expandido, se um separador está selecionado ou se surgiu um erro. Transformam uma interface visual conduzida pelo rato numa interface linear, audível e operável.

Uma forma rápida de sentir a diferença: a TTS responde à pergunta «O que diz este parágrafo?» Um leitor de ecrã responde a «Onde estou, o que posso fazer aqui e o que acabou de acontecer?» A primeira tem a ver com o consumo de conteúdo. A segunda tem a ver com o controlo de software.

Como um utilizador de leitor de ecrã se desloca realmente por uma página

Os utilizadores com visão percorrem uma página em segundos. Um utilizador de leitor de ecrã constrói um modelo mental de forma sequencial e baseia-se na estrutura para se deslocar de forma eficiente. Na prática, ele:

• Salta entre os títulos para compreender a estrutura da página (razão pela qual uma hierarquia de títulos correta é tão importante).
• Abre uma lista de todas as ligações ou de todos os campos de formulário para navegar por marco em vez de ler de cima para baixo.
• Utiliza as regiões de marco (cabeçalho, navegação, conteúdo principal, rodapé) para ir diretamente ao conteúdo que pretende.
• Percorre os elementos interativos com a tecla Tab e espera que o foco pouse num local visível e lógico.
• Escuta os anúncios em direto quando algo muda sem um recarregamento completo da página.

Nada disto funciona a menos que a marcação subjacente descreva a página de forma honesta. Uma funcionalidade de «ler em voz alta» não fornece nenhum destes recursos de navegação — limita-se a narrar o texto que estiver no ecrã, pela ordem visual, sem qualquer forma de operar os controlos.

Quem usa cada uma e por que razão é importante

A TTS é usada por um público alargado, muitas vezes de forma situacional: pessoas com dislexia, PHDA ou baixa visão; multitarefas; quem aprende línguas; e qualquer pessoa que simplesmente prefira ouvir. A maioria destes utilizadores ainda consegue ver o ecrã e usar um rato.

Os utilizadores de leitores de ecrã incluem pessoas cegas ou com deficiências visuais graves, bem como algumas pessoas com deficiências cognitivas ou motoras, que dependem da tecnologia para sequer poderem usar um dispositivo. Para elas não é uma camada de preferência sobre uma interface utilizável — é a interface. As ferramentas mais comuns são o NVDA e o JAWS no Windows, o VoiceOver nos dispositivos Apple e o TalkBack no Android. Cada uma interpreta a mesma página web de forma ligeiramente diferente, o que é uma das razões pelas quais testar em todas elas é importante.

Por que razão os widgets de leitura em voz alta não substituem a acessibilidade

Um número crescente de sites adiciona um botão de «ouvir esta página» ou um widget de terceiros que realça e lê o texto. Estas ferramentas podem ajudar alguns leitores, e não há nada de errado em oferecer uma por conveniência. O problema é tratá-la como um substituto de um verdadeiro suporte de leitor de ecrã. Não é, por várias razões concretas.

• Apenas leem; não operam. Um widget de leitura em voz alta irá narrar a sua tabela de preços, mas não consegue permitir que um utilizador cego selecione um plano, abra o carrinho, introduza os dados de pagamento e conclua a compra. As tarefas reais exigem controlos operáveis, não narração.
• Não conseguem expor estados nem funções. Se um botão está premido, se um campo é obrigatório, se uma secção está recolhida ou se uma mensagem de erro acabou de surgir — nada disso é transmitido pela leitura do texto visível. Os leitores de ecrã baseiam-se nas funções, nomes e estados da marcação para o anunciar.
• Os utilizadores de leitores de ecrã já têm uma ferramenta. Os utilizadores cegos trazem o seu próprio leitor de ecrã, afinado às suas preferências e à sua memória muscular. Um widget ao nível da página concorre com ele, por vezes interfere com ele e nada faz para corrigir a marcação defeituosa em que o seu leitor de ecrã está a falhar.
• Mascaram os problemas em vez de os corrigir. Se um campo de formulário não tiver etiqueta, o widget ignorá-lo-á tal como o faria um leitor de ecrã — mas agora a etiqueta em falta está escondida por trás de uma funcionalidade que parece útil. A falha subjacente mantém-se.

Esta mesma lógica aplica-se, de forma ainda mais vincada, às chamadas sobreposições de acessibilidade — scripts que prometem conformidade instantânea sobrepondo correções automatizadas e uma barra de ferramentas a um site existente. Não reparam o código subjacente, entram frequentemente em conflito com a própria tecnologia de apoio dos utilizadores e não conseguem proporcionar uma conformidade genuína. O caminho fiável é corrigir a origem. Para uma explicação mais completa sobre por que razão as correções superficiais ficam aquém, veja o nosso guia sobre a verdadeira acessibilidade digital.

Um exemplo concreto: o pagamento que «fala»

Imagine uma loja online que adicionou um widget de leitura em voz alta e está convencida de que o site está agora acessível. Um cliente cego chega com o seu próprio leitor de ecrã em funcionamento. A descrição do produto lê-se sem problemas — essa parte é apenas texto. Mas o controlo «Adicionar ao carrinho» é um div estilizado com um gestor de cliques em vez de um botão verdadeiro, pelo que o leitor de ecrã nunca o anuncia como botão e o teclado não lhe consegue chegar. O seletor de quantidade atualiza um total sem região live, pelo que a alteração é silenciosa. O campo do código promocional tem texto de marcador de posição mas nenhuma etiqueta associada, pelo que é anunciado apenas como «editar texto». O formulário de envio mostra visualmente um erro a vermelho, mas o erro não está associado ao campo e não é anunciado de todo. O widget de leitura em voz alta narra alegremente o texto visível e nada altera disto. O cliente consegue ouvir o texto de marketing mas não consegue concluir uma compra. Essa lacuna — entre ouvir o conteúdo e operar um produto — é toda a diferença entre uma funcionalidade de conveniência e a acessibilidade.

O que a conceção para leitores de ecrã realmente exige

Suportar leitores de ecrã não consiste em adicionar uma funcionalidade — consiste em construir as suas páginas de modo a que o significado, a estrutura e o comportamento estejam disponíveis para o software, e não apenas para o olho humano. Os ingredientes essenciais:

HTML semântico e estruturado

Use títulos verdadeiros (h1–h6) por uma ordem lógica, botões e ligações nativos para os fins certos, listas para listas e elementos de marco para as regiões da página. O HTML semântico transporta gratuitamente informação de acessibilidade; um amontoado de contentores genéricos não transporta nenhuma.

Alternativas textuais para conteúdo não textual

Cada imagem com significado precisa de um texto alternativo rigoroso, e as imagens decorativas devem ser marcadas para serem ignoradas. Os ícones que funcionam como botões precisam de nomes acessíveis. Os gráficos e infografias precisam de um equivalente textual que transmita a mesma informação.

Nomes, funções e estados acessíveis

Os campos de formulário precisam de etiquetas associadas programaticamente. Os componentes personalizados — separadores, acordeões, caixas de combinação, janelas modais — precisam das funções e estados corretos para que o leitor de ecrã anuncie o que são e como se comportam. Onde o HTML nativo não chega, o ARIA preenche a lacuna, mas tem de ser usado com precisão; um ARIA incorreto é pior do que nenhum.

Operabilidade pelo teclado e gestão do foco

Tudo o que funciona com o rato tem de funcionar com o teclado, a ordem do foco tem de ser lógica, o indicador de foco tem de ser visível, e as alterações dinâmicas (abrir uma caixa de diálogo, revelar um erro) têm de mover ou anunciar o foco de forma adequada. O suporte do teclado e o suporte dos leitores de ecrã estão profundamente interligados.

Anunciar as alterações dinâmicas

Quando o conteúdo se atualiza sem recarregar a página — uma mensagem de validação de formulário, um contador de carrinho, um estado de carregamento — use regiões live para que o leitor de ecrã informe o utilizador de que algo aconteceu. As atualizações silenciosas são invisíveis para quem não consegue ver o ecrã.

Todas estas expectativas estão codificadas nos critérios de sucesso das WCAG 2.2, que formam a espinha dorsal técnica do European Accessibility Act e da ADA aplicada à web. Se quiser o detalhe prático, o nosso guia de testes com leitores de ecrã explica passo a passo como verificar cada um destes comportamentos com ferramentas reais.

Por que razão «para mim lê-se bem» é enganador

Um programador com visão pode ativar uma funcionalidade de leitura em voz alta, ouvir frases nítidas e concluir que a página está acessível. A armadilha é que a leitura em voz alta reproduz a ordem de leitura visível e o texto visível, que já fazem sentido para quem está a olhar para o ecrã. Nada lhe diz sobre se uma lista pendente personalizada anuncia as suas opções, se o foco fica preso dentro de uma caixa de diálogo aberta, se um botão só de ícone tem um nome ou se a ordem de tabulação corresponde à disposição visual. São precisamente as coisas que falham para os utilizadores de leitores de ecrã e precisamente as coisas que uma demonstração de leitura em voz alta não consegue revelar. A única forma de saber é testar tal como o fazem os utilizadores reais.

Como testar para ambas — e por que razão a automatização sozinha não chega

Não consegue confirmar que uma página funciona para os utilizadores de leitores de ecrã ouvindo um botão de leitura em voz alta. Confirma-o verificando a estrutura, os nomes, as funções, os estados, a operação pelo teclado e a experiência real do leitor de ecrã em várias ferramentas e plataformas.

Um processo sólido combina três camadas:

• Análise automatizada para detetar os problemas de grande volume detetáveis por máquina — texto alternativo em falta, etiquetas vazias, referências ARIA quebradas, falhas de contraste. O nosso software de análise de acessibilidade e uma análise de acessibilidade gratuita são uma forma rápida de estabelecer o ponto de partida.
• Testes manuais por especialistas para avaliar tudo o que a automatização não consegue julgar: se um nome é significativo, se a ordem do foco faz sentido, se um widget personalizado é genuinamente operável. O raciocínio por trás desta camada é abordado no nosso guia de auditorias de acessibilidade manuais.
• Testes com tecnologia de apoio real e utilizadores reais. Nada substitui conduzir a página com o NVDA, o JAWS, o VoiceOver e o TalkBack — e, idealmente, observar pessoas que usam estas ferramentas todos os dias. As nossas auditorias por pessoas com deficiência trazem exatamente essa experiência vivida.

As ferramentas automatizadas detetam normalmente apenas uma parte dos critérios de sucesso das WCAG 2.2; o resto exige juízo humano. Tratar uma análise automatizada bem-sucedida como prova de acessibilidade é o mesmo tipo de erro que tratar um widget de leitura em voz alta como suporte de leitor de ecrã.

Onde a QualiBooth se encaixa

A QualiBooth testa o seu site tanto para os casos de uso de TTS como de leitor de ecrã, para que o seu conteúdo seja acessível aos utilizadores que dependem de qualquer uma das tecnologias — e para que as pessoas que dependem de um leitor de ecrã consigam não só ouvir o seu conteúdo mas também operar de facto o seu produto. O nosso kit de ferramentas de acessibilidade e a plataforma Agora combinam a análise com uma revisão manual estruturada, e a nossa equipa de consultoria de acessibilidade ajuda-o a corrigir o que os testes revelam e a alinhar-se com os requisitos das WCAG 2.2, do EAA e da ADA.

A conclusão é simples. Dar voz ao seu conteúdo é um toque agradável. Tornar o seu conteúdo navegável, operável e corretamente anunciado a um leitor de ecrã é acessibilidade — e só uma destas opções cumpre a lei e as pessoas que ela protege.