O WebAIM encontrou 56.114.377 erros detectáveis de acessibilidade nas homepages de um milhão de sites em fevereiro de 2026. A média foi de 56,1 erros por página, 10,1% acima do levantamento anterior. Em 95,9% das páginas havia ao menos uma falha detectável de conformidade com WCAG 2, contra 94,8% em 2025.
Os números interromperam seis anos de melhora gradual. Também chegaram num momento em que gerar uma interface inteira ficou barato. O relatório cita práticas automatizadas ou assistidas por IA, o chamado vibe coding, entre as mudanças que provavelmente participam desse cenário.
Essa frase merece precisão. O estudo não separou código humano de código gerado por modelo e não mediu causalidade. Ele analisou o DOM renderizado, tecnologias detectáveis e barreiras que a ferramenta WAVE consegue identificar. A conclusão é uma hipótese apoiada em tendências de complexidade, não um julgamento de cada ferramenta de IA. Mesmo com essa limitação, o recado operacional é forte: aumentar a velocidade de produção sem elevar a barra de aceite multiplica padrões ruins junto com os bons.
A página cresceu mais rápido que a revisão
As homepages avaliadas tinham, em média, 1.437 elementos. Esse total subiu 22,5% em um ano e quase dobrou desde 2019. Mais elementos abrem mais lugares para contraste insuficiente, nomes acessíveis ausentes, hierarquia de headings quebrada e estados que só funcionam com mouse.
Seis categorias responderam por 96% dos erros detectados. Baixo contraste apareceu em 83,9% das páginas. Imagens sem texto alternativo estavam em 53,1%; campos sem rótulo, em 51%; links vazios, em 46,3%; botões vazios, em 30,6%; idioma do documento ausente, em 13,5%.
Nada nessa lista exige uma solução exótica. São problemas conhecidos, com critérios de aceite que cabem em componentes, linters, testes e revisão. O volume persiste porque a entrega aceita código sem essas condições.
Geradores de interface absorvem o mesmo ambiente. Se o prompt pede apenas uma tela parecida com a referência, o agente otimiza aparência e funcionamento visível. Um botão com ícone pode responder ao clique e continuar sem nome para leitor de tela. Um modal pode parecer correto e perder foco ao abrir. O resultado passa numa inspeção visual rápida porque a inspeção perguntou pouco.
ARIA cresce, mas semântica não nasce da quantidade
O relatório contou mais de 133 milhões de atributos ARIA, cerca de 133 por página. O uso aumentou 27% em um ano e ficou mais de seis vezes acima de 2019. Páginas com ARIA tinham, em média, 59,1 erros detectados, contra 42 nas páginas sem ARIA.
O próprio WebAIM adverte que isso não prova que ARIA causou os erros. Páginas mais complexas tendem a precisar de mais estados, controles e integrações. Ainda assim, 22% dos menus com role="menu" introduziam barreiras por falta da marcação e das interações necessárias.
ARIA é uma promessa de comportamento. Adicionar role="button" a uma div não entrega teclado, foco, nome e estado. A primeira escolha deveria ser o elemento HTML nativo correspondente. Quando um padrão complexo é necessário, o ARIA Authoring Practices Guide documenta teclado e semântica esperados. Copiar apenas o atributo visível no exemplo produz metade do componente.
Para coding agents, eu colocaria essa preferência nas regras do repositório: HTML nativo primeiro; componente compartilhado antes de variação local; interação de teclado e foco dentro da definição de pronto. O agente precisa encontrar uma rota curta e correta no próprio ambiente.
A barra de aceite precisa testar uso
Um scanner automático encontra muito e deve rodar cedo. O WebAIM lembra que nenhuma ferramenta detecta todas as falhas e que uma página sem erros automáticos não está necessariamente acessível. O teste precisa combinar camadas.
Na camada estática, dá para bloquear imagens informativas sem alt, campos sem nome, IDs duplicados e violações conhecidas de contraste. No navegador, um fluxo crítico deve funcionar por teclado, manter foco visível e anunciar mudanças de estado. A revisão manual cobre o que depende de contexto: ordem coerente, texto alternativo útil, linguagem, zoom e entendimento do fluxo.
Essa combinação também melhora o trabalho do agente. Um erro detectado logo depois da alteração volta como feedback local e barato. Sem essa resposta, ele continua construindo sobre uma base defeituosa e entrega um diff maior para alguém decifrar.
Eu escolheria poucos fluxos críticos antes de tentar uma auditoria total: autenticação, busca, formulário principal, compra ou solicitação de serviço. Cada um ganha um roteiro de teclado e uma checagem automatizada. Componentes encontrados no caminho voltam para a biblioteca compartilhada, onde uma correção reduz repetição.
O prazo legal mudou, a obrigação não sumiu
O post original que motivou este artigo citava 24 de abril de 2026 como prazo do Title II da ADA para entidades públicas maiores nos Estados Unidos. Essa informação ficou desatualizada. Em 20 de abril de 2026, o Departamento de Justiça publicou uma regra interina que prorrogou as datas.
O guia atual aponta 26 de abril de 2027 para entidades estaduais e locais com população de 50 mil pessoas ou mais. Entidades menores e governos de distritos especiais ficaram com 26 de abril de 2028. O padrão técnico continua WCAG 2.1 nível AA, sujeito às exceções previstas na regra.
Para uma equipe brasileira, esse calendário pode não ser a norma aplicável, mas oferece uma lição de produto: requisitos de acessibilidade alcançam conteúdo e aplicativos fornecidos também por contratos e fornecedores. Comprar uma interface gerada ou terceirizar seu desenvolvimento não terceiriza a experiência entregue.
O uso de IA só altera a escala e o ritmo. Se o sistema consegue produzir cinco variações no tempo de uma, a revisão precisa eliminar quatro caminhos ruins antes que virem componentes oficiais. O ganho aparece quando a automação traz evidência junto com o código.
No próximo prompt de interface, eu acrescentaria critérios verificáveis e pediria ao agente que os execute. O WebAIM já mostrou o resultado coletivo de tratar acessibilidade como acabamento posterior.
