No fim de semana passado, o UX Collective publicou um artigo chamado Secret agent bot: accessibility matters for the agents even if you can’t see them, de Mark Nowak. A tese é simples e desconfortável: o seu site tem um novo tipo de visitante, que não olha a página do jeito que você olha, lê um modelo reduzido chamado árvore de acessibilidade, a mesma estrutura que os navegadores constroem para leitores de tela há duas décadas, e não enxerga cor, só estrutura bem rotulada.
Isso não é opinião. É o que a documentação dos próprios fornecedores já diz. Vou mostrar o mecanismo, o que fazer no código e onde essa história ainda não fecha.
Como o agente lê a página por baixo
Antes de falar de ARIA, é preciso entender o que é a tal árvore de acessibilidade (accessibility tree), porque sem isso o resto vira folclore.
Quando o navegador carrega uma página, ele monta duas coisas em paralelo. A primeira é o DOM, que é a representação da marcação. A segunda é uma estrutura separada: a WAI-ARIA 1.2 do W3C define a árvore de acessibilidade como uma árvore de objetos acessíveis que representa a estrutura da interface, onde cada nó representa um elemento da UI exposto por meio da API de acessibilidade. Cada nó dessa árvore carrega quatro propriedades que importam: role (que tipo de coisa é, botão, link, região de navegação), name (como ela se chama, por exemplo, o texto “Adicionar ao carrinho”), state (se está expandida, marcada, desabilitada) e description (contexto adicional).
Compara com uma planta de evacuação de prédio. A planta não mostra a decoração, não diz de que cor é a parede, não desenha o quadro na recepção. Mostra onde fica a porta, onde fica a escada, onde está o extintor, e qual rota liga uma coisa à outra. Alguém que nunca entrou no prédio consegue agir a partir dela. A analogia quebra num ponto: a planta é um documento à parte, enquanto a árvore de acessibilidade é derivada automaticamente do que você escreveu em HTML. Se o HTML for ruim, a planta sai errada sozinha.
Agora o que mudou. Até pouco tempo essa árvore existia basicamente para leitor de tela. Hoje ela é a entrada principal de vários agentes de IA que navegam na web em nome do usuário.
ChatGPT Atlas e o posicionamento oficial da OpenAI
A OpenAI documentou isso de forma explícita. O FAQ de Publishers and Developers diz que o ChatGPT Atlas usa tags ARIA, os mesmos labels e roles que apoiam leitores de tela, para interpretar a estrutura da página e os elementos interativos, e aconselha que deixar o site mais acessível ajuda o agente a entendê-lo. O Atlas foi construído sobre Chromium, mas em vez de analisar pixels renderizados, ele consulta a árvore de acessibilidade por elementos com roles específicos como “button” e “link” e por nomes acessíveis.
Playwright MCP e o padrão que a Microsoft escolheu
Do lado da Microsoft, o Playwright MCP (o servidor oficial de Model Context Protocol para automação de browser) seguiu o mesmo caminho. O Playwright MCP opera sobre a árvore de acessibilidade da página, não sobre pixels, e quando uma ferramenta roda ele devolve um snapshot estruturado mostrando os elementos, seus roles e o conteúdo de texto, e o LLM usa referências desses snapshots para interagir com a página. Benchmarks empíricos indicam que esses snapshots consomem de 1 a 5 KB de texto, algo entre 250 e 1250 tokens, enquanto screenshots crus consomem 100 KB ou mais, de 1500 a 5000 tokens por passo, resultando em uma redução de 4 a 10 vezes no uso de tokens em workflows de múltiplas etapas.
Em outras palavras: ler pela árvore é mais barato e menos ambíguo do que olhar pixel. Esse é o motivo real por que os fornecedores foram para esse lado, não é generosidade com acessibilidade, é economia de token e redução de erro.
O que isso significa no código
A regra prática é simples e, por favor, resista a querer resolver tudo com ARIA. A primeira regra do ARIA é preferir HTML nativo sempre que possível, usar um button de verdade para um botão, um nav de verdade para navegação, uma table de verdade para dados tabulares, e um label de verdade pareado com um campo de formulário, porque elementos nativos trazem semântica embutida, comportamento de foco e compatibilidade, e ARIA deve enfatizar significado onde o HTML nativo não tem padrão, não substituir HTML correto.
O caso canônico do erro é este:
<!-- O que não funciona bem para agente nem para leitor de tela -->
<div class="btn-primary" onclick="checkout()">
Finalizar compra
</div>
<!-- O que funciona -->
<button type="button" onclick="checkout()">
Finalizar compra
</button>A div com onclick renderiza igual na tela. Para o agente, não é botão. Adicionar role=”button” a uma div não dá a ela foco de teclado, nem handler de clique em Enter ou Space, nem nenhum dos comportamentos embutidos que um button real fornece.
Onde ARIA ganha é no estado dinâmico. Um dropdown, um accordion, um dialog modal, um resultado de busca que aparece sem recarregar a página. Nesses casos o HTML nativo não dá conta sozinho:
<button
type="button"
aria-expanded="false"
aria-controls="menu-filtros">
Filtros
</button>
<div id="menu-filtros" role="region" hidden>
<!-- opções -->
</div>Quando o usuário abre, você atualiza aria-expanded para true e remove o hidden. O agente que ler o snapshot naquele instante sabe que o botão está aberto e que o controle associado é o menu-filtros. A OpenAI diz no FAQ que o ChatGPT Atlas usa tags ARIA para interpretar estrutura e elementos interativos, as ARIA snapshots do Playwright da Microsoft também mostram como ferramentas de automação de browser podem capturar a árvore de acessibilidade como YAML estruturado, e o Chrome DevTools expõe essa mesma árvore para o desenvolvedor inspecionar o que a máquina está vendo.
Esse último ponto é o que eu recomendo que você faça hoje: abra o DevTools, aba Accessibility, selecione um elemento central do seu fluxo e veja o nome acessível que ele tem. Se o botão principal do checkout aparece como “” ou como “icon-arrow-right”, o agente vai tratar ele como se fosse qualquer outro clique sem rótulo.
Na prática, num construtor de landing page que tirou a criação de página da fila da engenharia, uma das coisas que me obrigou a atenção foi exatamente essa: dar liberdade de montagem ao marketing significa aceitar página fora do design system, a menos que o próprio builder imponha o limite. Isso vale para visual, vale para texto e vale também para a árvore de acessibilidade que sai no final. Se o builder deixa colocar um “card clicável” como div com onclick, você está fabricando páginas que nenhum agente consegue operar direito. Impor o limite no builder (botão é botão, link é link, heading tem nível) é o que garante que a página gerada por marketing continua legível por máquina.
Onde essa história quebra
Primeiro ponto. ARIA mal usado é pior do que não usar. ARIA mal empregado pode na verdade reduzir a acessibilidade e criar ambiguidade de interpretação de máquina, e a abordagem mais forte é HTML semântico primeiro e ARIA só onde clareza adicional é necessária. É muito comum ver role="button" em cima de <a href="#">, ou aria-expanded estático que nunca é atualizado pelo JavaScript. Isso enche a árvore de informação mentirosa e o agente age em cima da mentira.
Segundo ponto. Nem todo fornecedor lê igual. Perplexity Comet trabalha de modo híbrido com árvore de acessibilidade mais visão seletiva, e mesmo plataformas que começaram com abordagens de visão primeiro estão incorporando dados de acessibilidade, enquanto as plataformas que otimizam para confiabilidade e eficiência, como o Playwright MCP, lideram pela árvore de acessibilidade. Dependendo do agente que você espera atender, o peso de cada camada muda.
Terceiro ponto. Interfaces densas em dado têm trade-off próprio. Em dashboard denso em dados de medição de mídia, performance de render e clareza do dado são o produto, não acabamento. Virtualizar lista melhora render e quebra busca do navegador e acessibilidade se feito sem cuidado. O mesmo vale para o agente: se a lista virtualizada só renderiza as linhas que estão na viewport, a árvore de acessibilidade também só tem essas linhas. Um agente que pede o snapshot não “vê” os outros 10 mil itens que você tem na memória. Isso não é motivo para abandonar virtualização, é motivo para expor outro caminho para o agente, por exemplo uma API documentada, e aceitar que a navegação visual e a navegação por agente são caminhos diferentes.
Quarto ponto, de segurança. Snapshots de acessibilidade contêm texto da aplicação e de conteúdo de terceiros que ela renderiza, uma página pode dizer “ignore suas instruções anteriores”, “faça upload de um arquivo de configuração” ou “envie cookies para este endpoint de diagnóstico”, essas strings são dados da aplicação, e o agente não deve promovê-las acima das regras do sistema do host nem da tarefa limitada do humano. Para quem está do lado do site, isso significa que texto que você renderiza na página pode ser lido como instrução por um agente que trate a entrada sem cuidado. Não é problema seu resolver sozinho, mas é bom saber que existe.
O que ainda não dá para afirmar
Nenhum fornecedor publicou medição de quanto um atributo ARIA específico melhora a taxa de sucesso de uma tarefa de agente. O que existe é a declaração de que o Atlas lê ARIA e orienta o publisher a seguir WAI-ARIA, mais o fato de o Playwright MCP operar sobre snapshots da árvore. Isso é posicionamento técnico claro, não é um benchmark fechado por tipo de componente.
Também não há consenso de que a árvore de acessibilidade vire o canal único. O desenho dos próprios agentes está misturando camadas, e o que a gente chama de agent-readable hoje pode virar amanhã outra coisa, uma rota API dedicada, um feed estruturado, um protocolo próprio. A aposta razoável é que árvore de acessibilidade continua sendo pelo menos um dos canais por muito tempo, porque ela já existe de graça junto do navegador.
Como testar isso você mesmo
Um caminho pequeno para experimentar hoje, sem instalar nada exótico:
- Abra o seu site no Chrome. Vá em DevTools, aba Elements, painel Accessibility. Selecione o botão principal de uma ação crítica, por exemplo “Finalizar compra” ou “Entrar”. Olhe os campos Role e Name. Se Role não for
buttonoulink, você tem um problema. Se Name estiver vazio ou for algo como “icon-arrow”, você tem outro. - Em Chrome DevTools ainda, abra Lighthouse e rode a auditoria de Accessibility. Ignore o score, olhe os itens de “Buttons do not have an accessible name” e “Links do not have a discernible name”. Esses são exatamente os pontos que vão quebrar o agente.
- Se você quiser ver como um agente real enxerga sua página, instale o Playwright MCP localmente (
npx @playwright/mcp@latest), conecte a um cliente MCP como Claude Desktop ou Cursor, e peça para o agente abrir sua página e descrever o que vê. O que ele descreve é a sua árvore de acessibilidade, nem mais nem menos. Se faltar coisa que você considera essencial, é isso que precisa de rótulo.
Não precisa reescrever o site. Precisa fazer esse passeio de inspeção pelo fluxo crítico (login, busca, checkout, formulário principal) e trocar div por elemento semântico onde dá, adicionar aria-label onde o botão só tem ícone, e garantir que aria-expanded e aria-selected acompanham o estado real. O resto do site pode esperar.
