← Voltar ao blog

Mais de 97% dos sites brasileiros falham em acessibilidade. O seu vai continuar nessa conta?

Leitura de 7 minutos

Mulher idosa segura o celular perto do rosto enquanto usa o leitor de tela para navegar em um site

Em fevereiro de 2026, o WebAIM Million encontrou falhas de acessibilidade detectáveis automaticamente em 95,9% das um milhão de páginas iniciais analisadas. A média foi de 56,1 erros por página. A proporção de páginas com falhas subiu em relação a 2025, interrompendo seis anos de pequenas melhorias nesse indicador. Fonte: WebAIM Million 2026.

São 23h40 de uma terça-feira. Imagine uma mulher de 62 anos, com baixa visão, tentando remarcar uma consulta pelo celular. Ela usa o leitor de tela do aparelho. A página carrega. O leitor anuncia: “botão”. Outro “botão”. Mais um “botão”. Nenhum diz o quê.

Ela tenta o campo de data. O leitor fica em silêncio. O prazo para remarcar termina à meia-noite.

A cena é hipotética. O problema, não.

A web brasileira está fechando portas

Em 2024, o Movimento Web para Todos e a BigDataCorp analisaram 26,3 milhões de sites ativos no Brasil. Só 2,9% passaram em todos os testes de acessibilidade aplicados (pesquisa Web para Todos/BigDataCorp 2024).

Leia de novo: mais de 97% falharam em pelo menos um teste.

E os testes eram básicos. Imagens, links, formulários e marcação HTML. Mesmo assim, segundo a metodologia do estudo:

  • 83,98% dos sites falharam em acessibilidade de links;
  • 57,17% falharam em imagens;
  • 49,59% falharam em formulários.

Nem o poder público escapa. Entre os sites governamentais analisados, 90% apresentaram algum problema.

Isso não é falta de norma. Não é falta de ferramenta. É falta de decisão.

Quem fica do lado de fora

Segundo a PNAD Contínua 2022 do IBGE, o Brasil tinha 18,6 milhões de pessoas com deficiência, com 2 anos ou mais de idade. São 8,9% dessa população.

Tem mais. Quase metade delas (47,2%) tem 60 anos ou mais. Acessibilidade não é assunto de um nicho. É o seu pai, a sua avó e, um dia, você.

A desigualdade já existe fora da tela. Entre pessoas com deficiência, a participação na força de trabalho era de 29,2%. Entre pessoas sem deficiência, 66,4%. Cada site inacessível empurra esse abismo um pouco mais fundo: uma vaga que não dá para aplicar, um curso que não dá para fazer, um serviço que não dá para usar.

O que é acessibilidade responsável

Acessibilidade digital é garantir que qualquer pessoa consiga perceber, entender, navegar e interagir com um produto digital. Inclusive quem usa leitor de tela, navega só pelo teclado, tem baixa visão, deficiência auditiva, motora ou cognitiva.

Acessibilidade responsável é assumir isso como dever do time inteiro, desde o primeiro dia. Não é auditoria no fim. Não é plugin. Não é tarefa de uma pessoa só.

  • Produto escreve critérios de aceite com acessibilidade.
  • Design define contraste, foco e ordem de leitura no protótipo.
  • Desenvolvimento usa HTML semântico e escreve testes.
  • QA testa com teclado e leitor de tela.
  • Conteúdo escreve texto alternativo e linguagem simples.

Quando todos respondem, ninguém precisa implorar.

Não é opcional. É lei.

No Brasil, a régua já está dada.

A LBI completou dez anos em 2025. O tempo de “estamos estudando o assunto” acabou.

As desculpas que não se sustentam

Acessibilidade não entra na reunião de priorização para disputar espaço com a próxima feature. Ela é requisito, como segurança. Ninguém pergunta se vale a pena proteger senhas neste sprint.

“É caro.” Caro é retrabalho. Corrigir um componente no design system custa uma vez. Corrigir a mesma falha em cem telas custa cem vezes.

“Não temos prazo.” Prazo apertado é motivo para fazer certo de primeira. Acessibilidade deixada para o fim é a mais lenta e a mais cara.

“Quase nenhum usuário nosso tem deficiência.” Você não tem poucos usuários com deficiência. Você tem poucos usuários com deficiência que conseguem usar o seu produto. São 18,6 milhões de pessoas no país.

“Vamos instalar um plugin.” Widget não reescreve o seu código. Botão sem nome continua sem nome. Atalho não é solução.

Como fazer no seu próprio projeto

A estratégia tem nome: levar a acessibilidade para o começo do ciclo e não tirá-la mais de lá.

Acessibilidade na Definition of Done

Uma história só está pronta quando:

  • funciona inteira pelo teclado, com foco visível;
  • passa nos testes automatizados de acessibilidade do pipeline;
  • tem nomes acessíveis em botões, links e campos;
  • atende ao contraste mínimo da NBR 17225;
  • foi verificada com pelo menos um leitor de tela.

Não cumpriu? Não está pronta. Sem exceção.

Um design system que já nasce acessível

Componente acessível multiplica acessibilidade. Componente quebrado multiplica barreira. Documente contraste, estados de foco, tamanho de alvo, comportamento de teclado e o que o leitor de tela deve anunciar.

HTML semântico primeiro, ARIA com parcimônia

Um <button> já vem com foco, teclado e papel acessível. Uma <div> clicável não vem com nada. Use o elemento nativo sempre que existir. ARIA mal aplicado piora a experiência em vez de melhorar.

Conteúdo também é código

  • Texto alternativo que descreve a função da imagem; imagem decorativa com alt=””.
  • Links que dizem para onde levam, nunca “clique aqui”.
  • Frases curtas, títulos claros, legendas em vídeos.

Como testar sem sair do repositório

Fluxo de entrega com acessibilidade em cada etapa: lint, testes unitários, testes de ponta a ponta, revisão manual com teclado e leitor de tela, testes com pessoas com deficiência e publicação.

Teste de acessibilidade mora no mesmo repositório e no mesmo pipeline que os outros testes. Quebrou? O build quebra.

Automação em camadas

  • No editor: eslint-plugin-jsx-a11y aponta imagem sem alt e elemento clicável sem teclado.
  • Nos componentes: jest-axe testa cada peça do design system.
  • No pipeline: Playwright com axe-core testa as páginas reais a cada pull request.

Um exemplo enxuto com Playwright e axe:

import { test, expect } from ‘@playwright/test’;

import AxeBuilder from ‘@axe-core/playwright’;

for (const caminho of [‘/’, ‘/login’, ‘/agendamento’]) {

  test(`sem violações detectáveis em ${caminho}`, async ({ page }) => {

    await page.goto(caminho);

    const resultado = await new AxeBuilder({ page })

      .withTags([‘wcag2a’, ‘wcag2aa’, ‘wcag21aa’, ‘wcag22aa’])

      .analyze();

    expect(resultado.violations).toEqual([]);

  });

}

O que nenhuma ferramenta faz por você

Automação encontra parte dos problemas, não todos. Ela não sabe se o texto alternativo faz sentido nem se a ordem de leitura é lógica.

  • Teclado: desligue o mouse e complete os fluxos principais.
  • Leitores de tela: NVDA no Windows, VoiceOver no iPhone e no Mac, TalkBack no Android.
  • Zoom: amplie para 200% e veja se nada some.
  • Pessoas reais: inclua pessoas com deficiência nos testes de usabilidade e remunere o trabalho delas.

Checklist de cada entrega

  • Lint de acessibilidade sem erros
  • Testes com axe passando no pipeline
  • Fluxo completo feito só com teclado
  • Foco visível e em ordem lógica
  • Teste com pelo menos um leitor de tela
  • Contraste conferido
  • Imagens com texto alternativo adequado
  • Campos com rótulo e mensagens de erro claras
  • Títulos em hierarquia correta e idioma da página definido

2027 e além: os compromissos que vamos cumprir

O futuro da acessibilidade no Brasil não vai chegar por decreto. Vai chegar pelo que cada time decide entregar. Estes são os compromissos que equipes sérias assumem a partir de 2027.

NBR 17225 como critério de aceite e de contratação

Todo edital, contrato e briefing passa a exigir conformidade com a NBR 17225 para web e a NBR 17060 para apps. Sem conformidade, não há aceite. O governo federal já publica uma cartilha de boas práticas para acessibilidade na contratação. O mercado privado vai seguir o mesmo caminho.

IA que ajuda, gente que responde

A IA vai sugerir descrições de imagem, gerar legendas e revisar código. Vamos usar tudo isso, com uma regra: a IA sugere, uma pessoa revisa e o time responde pelo resultado. O próprio estudo do Web para Todos registrou o salto de imagens com descrição de 15,8% em 2022 para 42,8% em 2024 e alertou: a quantidade subiu, mas a qualidade dessas descrições não foi medida.

Templates e plataformas acessíveis por padrão

A maior parte dos sites pequenos nasce de plataformas prontas. Quem constrói essas plataformas carrega a maior alavanca do país: um template acessível corrige milhares de sites de uma vez.

Acessibilidade como métrica de qualidade

Violações abertas, tempo de correção e fluxos críticos testados com leitor de tela entram no painel do time, ao lado de desempenho e segurança. O que não se mede não melhora.

Transparência com quem usa

Todo produto publica uma declaração de acessibilidade e um canal simples para relatar barreiras. Quem relatou recebe resposta.

Pessoas com deficiência dentro do time

Não só como usuárias testadas. Como designers, devs, QAs e líderes. É assim que a acessibilidade deixa de ser tema e vira cultura.

Voltando para as 23h40

Lembra da mulher tentando remarcar a consulta? O botão dela precisava de um nome. O campo de data precisava de um rótulo. Duas linhas de código. Um teste no pipeline teria pegado as duas.

Acessibilidade responsável não é um projeto paralelo. É o jeito certo de construir software no Brasil.

Comece esta semana:

  • Escolha um fluxo crítico do seu produto.
  • Adicione o teste com Playwright e axe ao pipeline.
  • Faça o fluxo inteiro só com o teclado e depois com um leitor de tela.
  • Corrija o que encontrar.
  • Coloque acessibilidade na Definition of Done do time.

Depois, conte nos comentários o que você encontrou. Os 97% não vão mudar sozinhos. Vão mudar projeto por projeto, a começar pelo seu.


Fontes