quem fica de fora do seu site? — boas práticas de acessibilidade na web

𝒃𝒖𝒛𝒊𝒏𝒂 — Sun, 08 Nov 2026 19:54:43 +0000

deixa eu contar por que decidi escrever sobre esse tema. no projeto integrador do meu curso de front-end, fiz um portal de esportes e coloquei um menu de acessibilidade. na apresentação, o professor comentou que tinha sido o único projeto da turma com esse cuidado, e isso me fez pensar: se acessibilidade é tão importante, por que ainda é exceção?

ela devia ser o normal, e não um diferencial. e os números mostram quanta gente fica de fora quando ela falta: segundo o censo 2022 do ibge, o brasil tem 14,4 milhões de pessoas com deficiência, 7,3% da população com 2 anos ou mais. no mundo, a organização mundial da saúde fala em 1,3 bilhão de pessoas com alguma deficiência significativa, uma em cada seis.

VOCÊ NÃO É SEU USUÁRIO

nem todo mundo usa a internet do mesmo jeito que você. tem gente que ouve a página com um leitor de tela, navega só pelo teclado, usa zoom alto ou depende de legenda. são as tecnologias assistivas e, se o site não foi pensado pra elas, ele simplesmente não funciona. e essas pessoas têm o mesmo direito de ler uma notícia, marcar uma consulta ou se candidatar a uma vaga.

POR QUE OVERLAYS DE ACESSIBILIDADE NÃO RESOLVEM

estudando mais depois do projeto, aprendi que o menu é só a parte que aparece. mesmo assim, muita empresa instala um overlay de acessibilidade, um menu pronto colocado com uma linha de script, e acha que o assunto está resolvido.

o problema é que ele não muda o código. depois que a página carrega, ele remenda o html no chute, adivinhando alt, aria-label e role. se erra, o leitor de tela lê algo que não existe; se o script não carrega, nada acontece.

<!-- remendo: o leitor de tela lê "imagem, botão" e não recebe foco -->
<div onclick="comprar()" role="button" aria-label="imagem"></div>

<!-- solução: o elemento certo, direto no código -->
<button type="button" onclick="comprar()">adicionar ao carrinho</button>

a regra do w3c é simples: se já existe um elemento html pra isso, use ele. o próprio guia do aria resume bem: nenhum aria é melhor do que um aria errado.

e os especialistas concordam. o overlay fact sheet, assinado por centenas deles, desaconselha essas ferramentas. em 2025, a ftc dos estados unidos multou uma fornecedora em 1 milhão de dólares por prometer demais. enquanto isso, a webaim analisou as páginas iniciais de um milhão de sites, em 2026, e achou erros detectáveis automaticamente em 95,9% delas, quase todos fáceis de corrigir no código.

no meu portal, o menu faz parte do próprio site e só funciona porque a base está lá: teclado, foco visível, textos alternativos e animações que respeitam quem pede menos movimento.

TAMBÉM É LEI

e cuidar dessa base nem é opcional. no brasil, a lei brasileira de inclusão (lei 13.146/2015), no artigo 63, obriga os sites de empresas com sede ou representação comercial no país e os sites do governo a serem acessíveis. pro governo federal, o emag detalha o que cada página precisa ter. a boa notícia é que quase tudo isso cabe em pequenos hábitos no código.

COMO FAZER NA PRÁTICA

COMO LIDAR COM TEXTOS

comece pela fonte em rem, e não em px: assim o texto respeita o tamanho que a pessoa escolheu no navegador. depois, dê um zoom de 200% e confira se nada ficou cortado.

body { font-size: 1rem; line-height: 1.5; }

na estrutura, use títulos em ordem (h1, h2, h3), links que se explicam sozinhos ("baixar o edital em pdf", não "clique aqui"), frases curtas, nada de texto justificado e <html lang="pt-br"> no topo. o leitor de tela agradece.

COMO LIDAR COM CORES E CONTRASTE

comece pelo contraste: a wcag pede pelo menos 4,5:1 no texto comum e 3:1 no texto grande, e o devtools mostra esse número pra você. depois, nunca passe informação só pela cor: se a borda do campo fica vermelha, escreva o erro do lado. e, se quiser ir além, ofereça um modo de alto contraste feito no próprio css, como o emag exige nos sites do governo federal, com no mínimo 7:1. no meu portal, o contraste+ deixa o fundo preto, o texto branco e os destaques em amarelo. dá pra respeitar até quem já pediu mais contraste no sistema:

@media (prefers-contrast: more) {
  :root { --fundo: #000; --texto: #fff; }
}

COMO LIDAR COM IMAGENS

antes de escrever o alt, pergunte: se a imagem sumisse, o que faltaria?

<img src="foto.jpg" alt="foto"> <!-- não diz nada -->
<img src="foto.jpg" alt="duas pessoas testando um site com leitor de tela"> <!-- diz o que importa -->

imagem decorativa leva alt="", como as fotos de fundo dos banners do meu portal, e o leitor de tela pula ela. já num gráfico, o alt traz a conclusão: "as vendas dobraram no trimestre", e não "barras azuis".

COMO LIDAR COM ANIMAÇÕES

movimento demais pode causar tontura e náusea, principalmente parallax e zoom de tela cheia. a saída é animar só pra quem não ligou o "reduzir movimento" no sistema, com a prefers-reduced-motion:

@media (prefers-reduced-motion: no-preference) {
  .card { transition: transform 0.3s ease-out; }
  .card:hover { transform: translateY(-4px); }
}

e mais duas regras: o que se mexe sozinho por mais de cinco segundos precisa de um jeito de pausar, e nada pode piscar mais de três vezes em um segundo. no meu portal, o banner da home para quando o mouse ou o teclado chega nele e ainda tem botão de pausar.

COMO LIDAR COM BOTÕES, LINKS E FORMULÁRIOS

tudo que é clicável vira <button> ou <a>, nunca <div onclick>, que não recebe foco pelo teclado. e botão só com ícone precisa de nome:

<button aria-label="apagar comentário">
  <svg aria-hidden="true">...</svg>
</button>

por fim, não apague o contorno de foco sem colocar outro destaque no lugar e use <label> em todo campo, porque o placeholder some quando a pessoa começa a digitar.

COMO LIDAR COM VÍDEOS E ÁUDIOS

todo vídeo precisa de legenda revisada, todo áudio de transcrição e, no que for importante, de libras. no meu portal, usei o vlibras, do governo federal, que traduz o texto pra libras de graça. e nada de som tocando sozinho: ele atropela o leitor de tela.

WEB VITALS TAMBÉM É ACESSIBILIDADE

sabe quando você vai clicar e um anúncio empurra tudo pra baixo? isso tem nome: cls (cumulative layout shift), uma das core web vitals, e faz a pessoa perder o ponto onde estava lendo. o ideal é 0,1 ou menos, e o segredo é reservar o espaço da imagem antes de ela carregar:

<img src="evento.jpg" alt="plateia num evento de tecnologia" width="800" height="450">

o outro número pra acompanhar é o inp, o tempo que a página leva pra responder a um clique ou a uma tecla: o ideal é até 200 ms.

FERRAMENTAS PRA TESTAR SEM GASTAR NADA

a boa notícia é que boa parte desses erros aparece em minutos, com ferramentas gratuitas.

LIGHTHOUSE

o lighthouse já vem no chrome: abra o devtools (f12), vá na aba lighthouse e escolha a categoria accessibility. ele dá uma nota de 0 a 100, aponta cada erro e dá pra rodar até pelo terminal:

npx lighthouse https://seusite.com.br --only-categories=accessibility --view

AXE DEVTOOLS

o axe devtools é uma extensão gratuita pro chrome, pro edge e pro firefox. ele usa o mesmo motor do lighthouse, o axe-core, mas vai além e explica como corrigir cada erro.

WAVE

já o wave, da webaim, é o mais visual: marca cada erro com um ícone em cima da própria página.

O DEVTOOLS DO NAVEGADOR

e, sem instalar nada, o próprio devtools mostra o contraste no seletor de cor, o nome que o leitor de tela vai ler (aba elements) e ainda simula diferentes tipos de visão (aba rendering).

E O TESTE QUE NENHUMA FERRAMENTA FAZ

mas nota 100 não garante um site acessível. por isso, largue o mouse e navegue só pelo teclado, ligue um leitor de tela (o nvda é grátis), dê um zoom de 200% e, principalmente, converse com quem usa.

PRA FECHAR

acessibilidade não é favor nem detalhe pro final: é fazer o trabalho direito. então, da próxima vez que criar uma tela, pergunte: quem está ficando de fora disso aqui? e você, tem alguma dica de acessibilidade do dia a dia? conta aqui nos comentários.

DEV Community: 𝒃𝒖𝒛𝒊𝒏𝒂