Como uma pessoa cega chama Uber? Como sabe que está pedindo pizza e não hamburguer pelo iFood?

A resposta é uma tecnologia chamada leitor de tela. Ela vem instalada em praticamente todo dispositivo: VoiceOver no iPhone e no Mac, TalkBack no Android, Narrador no Windows. Também existe o NVDA, gratuito e muito usado no Windows.

Só que existe um detalhe que quase nenhum dev conhece: o leitor de tela não lê a tela.

O que o leitor de tela realmente lê

Ele não enxerga pixels, cores ou layout. O navegador (ou o sistema operacional, em apps nativos) monta uma árvore de acessibilidade a partir do seu código, e é essa árvore que o leitor de tela anuncia.

E a pessoa também não ouve a página de cima a baixo. Ela navega: pula de título em título, pede a lista de todos os botões, vai direto para o formulário, desliza o dedo de elemento em elemento no celular.

Para cada elemento interativo, o leitor de tela precisa responder três perguntas:

• O que é? O papel: botão, link, campo de texto, checkbox.
• Como se chama? O nome: "Finalizar pedido", "Fechar", "Buscar".
• Em que estado está? Marcado, expandido, desabilitado, inválido.

Se o seu código não responde essas três perguntas, a pessoa simplesmente não consegue usar o que você construiu.

O problema: a div que finge ser botão

É aqui que a gente costuma errar. Não por maldade, mas porque visualmente funciona:

<div className="btn" onClick={finalizarPedido}>
  Finalizar pedido
</div>

Para quem usa mouse, é idêntico a um botão. Para quem usa leitor de tela:

• Não é anunciada como botão. Vira texto solto.
• Não aparece quando a pessoa pede a lista de botões da página.
• Não recebe foco com Tab, então quem navega pelo teclado nem chega nela.
• Enter e Espaço não fazem nada.

A correção é usar o elemento que já existe para isso:

<button type="button" onClick={finalizarPedido}>
  Finalizar pedido
</button>

Papel, foco, suporte a teclado e anúncio correto vêm de graça. Estilizar um <button> dá o mesmo trabalho que estilizar uma div.

Não à toa, a primeira regra de uso do ARIA definida pela W3C é: se existe um elemento HTML nativo que faz o que você precisa, use o elemento nativo.

Voltando ao iFood: pizza ou hambúrguer?

Imagine uma lista de produtos em que cada card tem um botão "Adicionar".

Quem enxerga associa o botão à foto e ao nome do produto ao lado. Quem usa leitor de tela e pede a lista de botões da página ouve:

"Adicionar, botão. Adicionar, botão. Adicionar, botão."

Adicionar o quê?

<button type="button" aria-label={`Adicionar ${produto.nome}`}>
  Adicionar
</button>

Agora o anúncio é "Adicionar Pizza Margherita, botão". Uma linha resolveu.

Em apps nativos, a lógica é a mesma com outros nomes: accessibilityLabel e accessibilityRole no React Native, contentDescription no Android, accessibilityLabel no iOS. As APIs mudam, mas as três perguntas continuam.

Faça o teste agora: ligue o leitor de tela (Cmd + F5 no Mac, ou instale o NVDA no Windows), abra o seu projeto e tente completar o fluxo principal sem olhar para a tela. Na primeira vez, quase sempre algo quebra.

"Mas a IA não resolve isso?"

Ajuda muito. Mas tem dois problemas.

Primeiro: ela reproduz o código que viu. E a internet está cheia de div com onClick. Se você não sabe que isso é um problema, aceita a sugestão sem perceber.

Segundo: ela responde ao que você pede. Compare estes dois prompts:

Deixa esse card acessível.

Esse card de produto tem um botão "Adicionar" que se repete em toda a lista. Garanta que cada botão tenha um nome acessível único com o nome do produto, que a quantidade adicionada seja anunciada ao leitor de tela, e use elementos HTML nativos em vez de ARIA sempre que possível.

O primeiro gera uma resposta genérica, às vezes cheia de ARIA desnecessário. O segundo resolve o problema real.

E o segundo só pode ser escrito por quem entende a finalidade de cada elemento. Pelo mesmo motivo, só essa pessoa consegue revisar o que a IA devolveu.

A IA acelera quem entende o problema. Para quem não entende, ela só gera o mesmo erro mais rápido.

Conclusão

Acessibilidade não começa com ARIA, com ferramenta de auditoria ou com IA. Começa com uma pergunta antes de escrever cada elemento: o que isso é, como se chama e em que estado está?

Se a resposta for "é um botão", use um <button>.

E você? Já testou o seu projeto com leitor de tela? O que quebrou primeiro? Conta nos comentários.

No próximo post, vou mostrar como testar um projeto com leitor de tela em 10 minutos, mesmo que você nunca tenha usado um.