Acessibilidade: 95,9% das home pages falham, diz WebAIM 2026

Todo ano, a WebAIM, organização ligada à Utah State University, passa um teste automático nas home pages do 1 milhão de sites mais visitados do mundo. O resultado de 2026, com dados coletados em fevereiro e atualizado em 30 de março, foi pior que o de 2025.

Segundo o WebAIM Million 2026, 95,9% das home pages tinham falhas de acessibilidade detectáveis, contra 94,8% no ano anterior. É a primeira piora depois de seis anos de melhoras pequenas. Como o teste só conta o que uma máquina consegue achar, menos de 4,1% das páginas podem estar de fato em conformidade.

O que o WebAIM Million 2026 encontrou

A média foi de 56,1 erros detectados por página, contra 51 em 2025. Cerca de 10% a mais em um ano.

Os seis erros mais comuns são os mesmos há sete anos e respondem por 96% de tudo o que foi detectado:

• Texto com contraste baixo: 83,9% das páginas (eram 79,1%).
• Imagem sem texto alternativo: 53,1% (eram 55,5%).
• Campo de formulário sem rótulo: 51% (eram 48,2%).
• Link vazio: 46,3% (eram 45,4%).
• Botão vazio: 30,6% (eram 29,6%).
• Página sem idioma declarado: 13,5% (eram 15,8%).

Quatro dos seis pioraram. Só texto alternativo e idioma melhoraram.

Por que as páginas estão piorando

O relatório aponta a complexidade. A home page média tem 1.437 elementos, 14,3% a mais que os 1.257 de 2025. Páginas com mais elementos tendem a ter mais erros. Nas palavras da WebAIM, as home pages estão ficando “larger and more technologically complex at an alarming rate” (maiores e mais complexas num ritmo alarmante).

Outro dado chama atenção: o uso de ARIA, o conjunto de atributos criado para ajudar tecnologias assistivas, cresceu 27% em um ano, para mais de 133 atributos por página. Páginas com ARIA tiveram em média 59,1 erros, contra 42 nas páginas sem. O relatório é cuidadoso: correlação não prova que o ARIA causou os erros, já que essas páginas também são mais complexas. Mas ARIA mal aplicado não conserta o que o HTML deixou quebrado.

O que isso significa para quem tem um SaaS

O estudo olha home pages, não sistemas logados. Mas os seis erros da lista são exatamente os que aparecem dentro de um SaaS: telas cheias de formulários, botões só com ícone, texto cinza-claro sobre fundo branco para parecer elegante.

Três motivos práticos para um founder se importar:

1. Conversão. Campo sem rótulo e contraste baixo atrapalham todo mundo, não só quem usa leitor de tela. Um cadastro que a pessoa não entende é um cadastro abandonado.
2. Alcance. Gente com baixa visão, daltonismo ou limitação motora usa software no trabalho todo dia. Se o seu sistema não funciona com teclado, ele não entra em algumas empresas.
3. Retrabalho. Quase todos os seis erros nascem no design system: a cor do texto, o componente de campo, o botão de ícone. Errou no componente, errou em todas as telas.

Como reduzir os erros mais comuns

A boa notícia do relatório é que o problema é concentrado. Seis tipos de erro, 96% do total. Dá para atacar no começo do projeto:

• Contraste: defina as cores do design system já testadas contra o fundo. Texto secundário também precisa passar.
• Rótulos: todo campo com rótulo visível ligado ao input. Placeholder não é rótulo.
• Botões e links: todo botão de ícone com nome acessível. Todo link com texto que diga para onde vai.
• Imagens: texto alternativo para o que informa, vazio para o que é só decoração.
• Idioma: declare o idioma da página. É uma linha de código.
• Teste manual: navegue o fluxo principal só com o teclado antes de lançar.

A WebAIM deixa um aviso que vale repetir: “Absence of detected errors does not indicate that a page is accessible or conformant” (não ter erros detectados não significa que a página é acessível). Teste automático é o piso, não o teto.

WebAIM Million Brasil: o estudo que estamos preparando

O WebAIM Million mede o mundo. Ainda não existe um retrato parecido para os SaaS brasileiros. Por isso estamos preparando o [WebAIM Million Brasil: estudo do Studio com SaaS brasileiros, a publicar].

A ideia é aplicar uma análise semelhante a [amostra e critério de seleção dos SaaS brasileiros] e publicar os resultados aqui no News Responsivo. Não temos resultados ainda, e não vamos antecipar números antes de medir. [Data prevista de publicação].

O que isso muda para você

Se você está construindo um SaaS agora, coloque acessibilidade no design system, não na lista de pendências pós-lançamento. Custa pouco no componente e caro na tela pronta.

Se o seu produto já está no ar, rode um teste automático nas telas principais e comece pelos seis erros da lista. A maior parte se resolve em poucos componentes.

Como fazemos no Studio

Desenhamos e construímos no Figma e com Claude Code, e o design system é a base de cada projeto. [Checklist de acessibilidade aplicado nos projetos do Studio]. Todo sistema que entregamos sai com um agente de IA que roda todo dia e aponta falhas, o que inclui [se o agente verifica itens de acessibilidade].

Se o seu site ou a página do seu SaaS precisa ser refeita com acessibilidade desde o começo, o nosso serviço de sites parte do design system.