| |
|
Em 2025, a WebAIM, centro de acessibilidade da Universidade Estadual de Utah, passou um verificador automático no primeiro milhão de páginas iniciais da web. Em 29,6% delas havia pelo menos um botão vazio, sem texto nem rótulo que dissesse para que ele serve.
No mesmo levantamento, a WebAIM achou campo de formulário sem rótulo em 48,2% das páginas. É a caixa de e-mail, de CEP ou de busca que só um olho humano entende, porque adivinha a função pelo desenho ao redor.
Durante anos, quem pagou esse preço foi a pessoa cega que navega com leitor de tela (programa que lê a página em voz sintética). O leitor chega ao botão do carrinho e anuncia só "botão". A pessoa desiste e compra em outra loja.
Agora existe um segundo visitante com a mesma limitação. O ChatGPT Atlas, navegador que a OpenAI lançou em outubro de 2025 para Mac, traz um modo agente: o usuário pede "compre este tênis no tamanho 42" e o assistente clica, preenche e avança pelas telas sozinho.
Para decidir onde clicar, o agente não depende só da imagem da página. A documentação da OpenAI para desenvolvedores diz que o Atlas usa os rótulos ARIA (Accessible Rich Internet Applications, marcações que descrevem cada elemento para leitores de tela) para interpretar a estrutura e os elementos interativos. A recomendação oficial é seguir as boas práticas do padrão WAI-ARIA, do consórcio W3C, com papéis, rótulos e estados descritivos em botões, menus e formulários.
Traduzindo para o balcão: o botão que a pessoa cega não conseguia usar também confunde o agente. Loja com ícone de sacola sem texto, campo de CEP sem etiqueta ou menu que só abre com o mouse corre o risco de ver o agente parar na metade da compra, ou pior, clicar no item errado.
A seguir: o que a OpenAI pede e por que o rótulo pesa, o caso de uma loja de cerâmica paulista que mediu quantas compras o agente concluía antes e depois de etiquetar os botões, e oito conferências para fazer no código da própria loja.
Continue lendo ↓
|
|
|
|
I Sinal da Semana
O que o Atlas lê quando olha para um botão
|
|
Para o agente do Atlas, um botão sem rótulo é uma porta sem placa: ele pode até abrir, mas não sabe aonde vai dar.
Todo navegador monta, com base no código da página, uma árvore de acessibilidade (a lista de elementos com nome, papel e estado que os leitores de tela consultam). Um botão feito com a tag própria do HTML entra nessa árvore como "botão", com o texto que estiver dentro dele como nome.
O problema nasce quando o botão é só um desenho. Muitas lojas usam um ícone de sacola em SVG (formato de desenho vetorial) dentro de uma div (caixa genérica do HTML, sem função definida). Para quem enxerga, a sacola diz tudo. Na árvore, aquele elemento aparece sem papel e sem nome.
Papel, rótulo e estado
O padrão WAI-ARIA resolve essa lacuna com três tipos de atributo. O papel (role) diz o que o elemento é: botão, caixa de seleção, menu. O rótulo (aria-label) diz o que ele faz, em palavras: "Adicionar ao carrinho". O estado diz como ele está agora, por exemplo se um menu está aberto (aria-expanded) ou se uma opção está marcada (aria-checked).
A página de orientação da OpenAI para desenvolvedores cita exatamente esses três pontos ao recomendar papéis, rótulos e estados descritivos. O agente combina o que vê na tela com o que lê na árvore. Quando os dois concordam, o clique sai certo. Quando a árvore está vazia, sobra a imagem, e a imagem de um ícone sem legenda é ambígua.
|
"O poder da Web está na sua universalidade. O acesso de todos, independentemente de deficiência, é um aspecto essencial."
Tim Berners-Lee, anúncio da Web Accessibility Initiative do W3C, 1997
|
A primeira regra do ARIA
O próprio W3C avisa, no guia Using ARIA, que a primeira regra é preferir o elemento nativo do HTML. Um button de verdade já nasce com papel de botão, aceita o teclado e entra na árvore com nome. ARIA serve para remendar o que o HTML nativo não cobre, e remendo mal feito piora a leitura.
Exemplo comum: um aria-label "botão" num botão de comprar. O rótulo passa a valer mais que o texto visível, e o agente lê só "botão". Outro erro frequente é marcar um elemento como botão (role="button") sem permitir que ele receba foco pelo teclado. O agente encontra o papel, tenta acionar e nada acontece.
Vale o limite: o modo agente do Atlas saiu em versão de teste para assinantes pagos, e a OpenAI não publicou quanto o rótulo pesa na decisão de clique em comparação com a imagem. O que existe é a recomendação por escrito. Como o mesmo ajuste atende o leitor de tela, o trabalho serve à loja mesmo que o agente mude de comportamento.
|
|
|
|
|
II Case Brasileiro
Cunha: dez compras e um ícone de sacola mudo
|
|
Tiago Albuquerque Moraes pediu dez compras ao agente do Atlas na própria loja e viu só três chegarem ao pagamento. Depois de etiquetar os botões, foram nove.
|
Tiago Albuquerque Moraes vende louça de cerâmica de alta temperatura feita em Cunha, na serra paulista, pela Casa Barro Alto, uma loja virtual montada numa plataforma brasileira de e-commerce com tema personalizado. São 86 produtos, entre canecas, pratos e travessas, cada um em duas ou três cores de esmalte.
Quando o Atlas liberou o modo agente, Tiago assinou o plano pago e fez um teste de balcão. Escreveu dez pedidos que um cliente faria, como "compre a caneca azul de 300 ml e mande para o CEP 12530-000", e anotou onde o agente parava.
Três compras chegaram à tela de pagamento. Nas outras sete, o agente travou em três pontos. O botão de adicionar ao carrinho era um ícone de sacola desenhado dentro de uma caixa genérica, sem texto. A escolha de cor usava bolinhas coloridas, sem nome de cor no código. E o campo de CEP no carrinho não tinha etiqueta, só um texto cinza de exemplo que some ao digitar.
Em quatro pedidos, o agente escolheu a cor errada ou ficou alternando entre as bolinhas. Em dois, não achou o botão e pediu ajuda ao usuário. Em um, digitou o CEP no campo de cupom de desconto, que ficava logo acima e também não tinha etiqueta.
A correção coube em duas tardes, com um desenvolvedor freelancer. O ícone virou um botão nativo com o texto "Adicionar ao carrinho", escondido visualmente mas presente no código. Cada bolinha de cor ganhou papel de opção de escolha (role="radio") e rótulo que diz a cor do esmalte. Os campos de CEP e de cupom receberam etiqueta própria, ligada ao campo.
O custo foi de R$ 900, pago pelas horas do freelancer. Nenhuma mudança apareceu para o cliente que compra com mouse: a página ficou visualmente igual.
Pedidos testados: 10
Compras concluídas antes: 3
Compras concluídas depois: 9
Custo da correção: R$ 900
A compra que ainda falhou esbarrou num aviso de cookies que cobria o botão de finalizar. Tiago trocou o aviso por uma faixa no rodapé e repetiu o teste na semana seguinte: dez em dez.
O ganho colateral veio de outro lado. Uma cliente que usa leitor de tela escreveu para a loja dizendo que, pela primeira vez, conseguiu escolher a cor da caneca sem pedir ajuda ao filho.
|
| |
