Acessibilidade no WordPress não é um extra de compliance nem um capítulo só de tema novo. É o conjunto de nomes, papéis e estados que a página já expõe: o que o teclado alcança, o que o leitor de tela anuncia e, cada vez mais, o que um agente no navegador consegue interpretar sem adivinhar o visual.
Você abre o site do cliente. O Tab some no menu. O botão do formulário é um ícone sem nome. O carrossel do plugin só responde ao mouse. Trocar o tema “do zero” não está na mesa, e o formulário veio de um builder de terceiros. Este texto entrega três caminhos práticos para melhorar o que já está no ar (ou o que você está montando agora), o mapa das falhas mais comuns, e o argumento que ouvi no WordCamp Brasil e que a documentação do Chrome reforça: um site mais acessível ainda é a melhor base para ficar compatível com agentes. Iniciativas como o WebMCP somam contrato de ação; não substituem essa base.
O que a web ainda erra (e a IA não apaga sozinha)
No WebAIM Million de fevereiro de 2026, 95,9% das homepages do milhão de sites mais influentes tinham pelo menos uma falha WCAG detectável automaticamente. A média foi de 56,1 erros por homepage. Quase tudo se concentra em seis tipos, os mesmos há anos:
| Tipo de falha | Homepages afetadas (aprox.) |
|---|---|
| Texto com pouco contraste | 83,9% |
| Imagem sem texto alternativo | 53,1% |
| Campo de formulário sem rótulo | 51% |
| Link vazio | 46,3% |
| Botão vazio | 30,6% |
| Página sem idioma declarado | 13,5% |
Esses números são auditoria automática (WAVE), não um laudo WCAG completo. Ainda assim, bastam para o diagnóstico: a dívida não é exótica. É contraste, nome, rótulo e idioma. Modelos de linguagem treinados nessa média tendem a reproduzir o defeito com confiança. Acelerar a geração sem uma checagem humana só publica o erro mais rápido, no tema novo ou no plugin antigo.
Quem vende para a União Europeia já convive com o European Accessibility Act em vigor desde 28 de junho de 2025. Aqui o ponto não é parecer jurídico brasileiro: é timing. A pressão regulatória empurra overlays e “widgets de acessibilidade” como atalho. O time de acessibilidade do WordPress não recomenda overlays. Eles não consertam HTML semântico na origem e, em vários casos, criam barreiras novas.
Por que agentes dependem disso
Agentes no navegador não “veem” a página só como screenshot. A documentação do Chrome e do web.dev descreve três leituras comuns: HTML bruto, renderização visual e a árvore de acessibilidade (roles, nomes e estados dos controles). O Lighthouse, na categoria de navegação agêntica, trata acessibilidade para agentes de forma explícita: label ausente atrapalha pessoa com deficiência visual e o agente que precisa completar a tarefa. O guia Build agent-friendly websites recomenda HTML semântico (button, a, label), nomes acessíveis e layout estável, e só depois tools explícitas (WebMCP) para tarefas declaradas.
No WordCamp Brasil ouvi o mesmo raciocínio em tom de prática: melhorar acessibilidade continua sendo o caminho mais sólido para o site “conversar” com agentes. Não atribuo a frase a um speaker sem registro; o embasamento técnico está nas fontes acima.
Isso encaixa nas três camadas que já descrevi em WordPress e WebMCP: formulários como tools para agentes:
- Base humana: contraste, teclado, rótulos, foco. Se o formulário é ruim para pessoa, piora para agente.
- Descoberta:
llms.txte equivalentes ajudam o modelo a saber o que o site é. Não executam a ação na página. - Ação: WebMCP declara tools (preencher, filtrar, enviar com confirmação).
WebMCP responde a uma lacuna real: a árvore de acessibilidade descobre o botão “Enviar”; não define, sozinha, o contrato da ação (entradas, pré-condições, efeitos). A ordem correta é a inversa do marketing de atalho: acessibilidade primeiro, anotações de agente depois. Sem a camada 1, a camada 3 decora um formulário que o Tab já não alcança.
Trilha 1: conteúdo e editor (vale em site novo e em site antigo)
Muita falha do WebAIM nasce no conteúdo, não no PHP do tema.
- Imagens: alt informativo quando a imagem comunica; alt vazio (
alt="") quando é decorativa. “Imagem de…” raramente ajuda. A IA pode sugerir alt; você decide se a imagem precisa de texto. - Títulos: um
h1coerente por vista (template + conteúdo). Não pular deh2parah4só por estética. - Links: “clique aqui” e “leia mais” soltos viram link vazio de significado. Inclua o contexto no texto do link ou no nome acessível.
- Idioma: o WordPress costuma emitir
langa partir da configuração do site. Confirme no código-fonte. - Formulários no editor: placeholder não substitui
<label>. Erro de validação precisa ser perceptível além da cor.
Checagem mínima antes de publicar um post ou página: teclado na página, um leitor de tela rápido no bloco crítico (ou pelo menos a árvore de acessibilidade no DevTools), contraste do texto sobre o fundo. Isso não exige rebuild.
Trilha 2: tema e casca do site, sem jogar o tema fora
Quando o problema está no cabeçalho, no menu ou no CSS do tema, a ordem que eu uso:
- Corrigir na origem (tema filho, CSS do personalizador,
theme.jsonse for tema de blocos, template part). Skip link, foco visível e contraste de pares de cor pertencem aqui. - Filtro PHP pontual quando o markup vem de um
wp_nav_menuou de um gancho conhecido. - Remediação cirúrgica com o plugin WP Accessibility (Joe Dolson): skip links, contorno de foco, labels em busca/comentário, remoção de
title/targetproblemáticos em conteúdo. O próprio autor deixa claro: o plugin não torna o site conforme WCAG; é stopgap enquanto a origem não muda. Ligar tudo “no automático” e esquecer é o mesmo erro conceitual do overlay, só que com ferramentas honestas.
Site novo: prefira fechar contraste e nomes no theme.json e nos padrões de bloco antes do go-live. Site antigo: child theme e CSS costumam desbloquear 80% do que o visitante sente no teclado, sem migração completa.
Trilha 3: o que o plugin de terceiro acoplou
Forms, popups, cookies, chats, carrosséis e page builders carregam HTML e ARIA que o tema não controla. Inventário curto:
- Consigo chegar ao controle só com teclado?
- O controle tem nome acessível (não só ícone)?
- O modal devolve o foco ao fechar?
- Há
aria-<em>decorativo demais (páginas com ARIA mal usada correlacionam com mais* erros no WebAIM)?
Cascata de decisão:
- Trocar por bloco nativo ou plugin com markup mais limpo, se o custo for baixo.
- Usar os filtros/hooks do próprio plugin para label,
aria-labelou classes (no lab de WebMCP, builders como Fluent Forms expõem ganchos úteis no HTML real). - Abrir issue ou suporte com evidência (WAVE + teclado).
- Documentar a dívida se a troca estiver fora de escopo: melhor dívida explícita do que overlay prometendo “100% acessível”.
Formulários de conversão são o caso especial. Em WordPress e WebMCP eu mostrei que anotar toolname / toolparamdescription só faz sentido depois de rótulos e teclado funcionarem. Agente e humano compartilham o mesmo <form>.
Checklist reutilizável (antes de publicar ou de “dar por pronto”)
- Tab percorre menu, conteúdo, formulário e rodapé sem armadilha
- Foco visível (não remova
outlinesem substituto) - Cada botão, link e ícone clicável tem nome acessível
- Imagens: alt decidido (informativo ou decorativo)
- Campos de formulário com rótulo associado
- Contraste dos textos principais (incluindo hover/estados)
langno documento- Nenhum overlay comercial “resolvendo” acessibilidade no ar
- (Opcional) Lighthouse com auditorias de navegação agêntica na URL de conversão
- (Opcional) Inspecionar a árvore de acessibilidade no DevTools no bloco que o agente precisaria operar
O que este texto não promete
Não é laudo WCAG 2.2 AA. Ferramenta automática não pega tudo: zero erro detectado não é conformidade. Não substitui teste com pessoas que usam tecnologia assistiva. Não aprofunda a API WebMCP (isso está no artigo do lab). E não vende o mito de que um plugin sozinho “acessibiliza” o WordPress.
Por onde começar amanhã
Escolha uma URL de conversão (contato, orçamento, checkout). Rode o teclado e uma varredura automática. Corrija primeiro as seis falhas do WebAIM que aparecerem. Só então discuta WebMCP, llms.txt ou troca de builder.
A acessibilidade bem feita continua sendo o mapa compartilhado entre visitante humano, leitor de tela e agente. O restante (descoberta para modelos, tools declarativas) empilha em cima, não no lugar.
Perguntas frequentes
Acessibilidade no WordPress serve só para quem usa leitor de tela?
Não. Melhora teclado, contraste, formulários e estrutura de headings para qualquer visitante, e alimenta a árvore de acessibilidade que muitos agentes no navegador consultam para achar controles.
Preciso trocar o tema para melhorar acessibilidade?
Não necessariamente. Conteúdo, CSS, tema filho, filtros e remediação pontual resolvem muita coisa. Trocar o tema ajuda quando a arquitetura inteira impede foco, skip link e semântica; não é o único caminho.
Overlay ou widget de acessibilidade deixa o site conforme?
Não. O time de acessibilidade do WordPress não recomenda overlays. Eles não substituem correção na origem e podem criar barreiras novas.
WebMCP substitui acessibilidade?
Não. WebMCP declara ações para agentes. A acessibilidade (e a árvore de acessibilidade) continua sendo a base para humanos e para a descoberta de controles. Detalhe e lab: WordPress e WebMCP.
O que priorizar se só tenho uma tarde?
URL de conversão, teclado, nomes de botões/links, labels do formulário, contraste do texto principal, alt das imagens acima da dobra. Deixe rebuild de tema e WebMCP para o ciclo seguinte.