Como corrigir as 6 falhas mais comuns das WCAG em qualquer site

Abra qualquer um dos um milhão de sites mais acessados agora e há uma chance de 96 em 100 de você encontrar uma violação de WCAG que um scanner automatizado consegue detectar em segundos. Em um milhão de páginas iniciais, foram detectados 56.114.377 erros de acessibilidade distintos — uma média de 56,1 erros por página. O que torna isso especialmente impressionante é que 96% de todos os erros detectados se enquadram em apenas seis categorias, e esses seis tipos de erro mais comuns permanecem os mesmos há sete anos. Isso significa que corrigir um punhado de problemas bem compreendidos melhoraria dramaticamente a acessibilidade em toda a web — e começa pelo seu site.

Por que as Mesmas Seis Falhas Continuam Aparecendo

Você pode se perguntar como, em uma era de ferramentas de desenvolvimento sofisticadas e crescente escrutínio legal, os mesmos erros persistem em escala ano após ano. A resposta é sistêmica. Essa densidade de erros reflete o quão profundamente a inacessibilidade foi incorporada às práticas de desenvolvimento web. Problemas em templates se multiplicam em todas as páginas. Falhas em componentes se repetem em todo o site. Sem atenção deliberada à acessibilidade, fluxos de trabalho padrão de desenvolvimento produzem resultados sistematicamente inacessíveis.

Há também uma falsa sensação de progresso impulsionada pela automação. Testes automatizados capturam apenas 30–40% das potenciais falhas de WCAG. Sites que passam em testes automatizados ainda podem ter problemas significativos de navegação por teclado, leitores de tela ou acessibilidade cognitiva. Isso significa que mesmo a pequena porcentagem de sites que parecem estar em conformidade no papel provavelmente está falhando na prática.

As implicações legais são reais e crescentes. De acordo com a Seyfarth Shaw, 8.800 processos federais com base no Título III da ADA foram ajuizados em 2024, com aproximadamente 2.452 especificamente voltados à acessibilidade web. Sites de e-commerce enfrentam um risco desproporcional — 77% dos processos relacionados à acessibilidade web têm como alvo o varejo online. Conformidade deixou de ser um diferencial. É uma questão de continuidade de negócios.

O lado positivo encorajador? Essa concentração tem implicações práticas. As organizações podem resolver a maioria de seus problemas de acessibilidade concentrando-se em um punhado de tipos de problema. A conformidade abrangente com a WCAG exige atenção a todos os 78 critérios, mas as melhorias de maior impacto vêm da correção dessas falhas comuns. Então vamos analisar cada uma delas, com correções práticas que você pode implementar hoje.

Falha nº 1 — Texto com Baixo Contraste (WCAG 1.4.3)

Texto com baixo contraste — texto que não tem diferenciação de cor suficiente em relação ao seu plano de fundo — aparece em 83,6% das páginas iniciais estudadas. Esta é a falha de WCAG mais comum, afetando mais de quatro em cada cinco sites. A WCAG 1.4.3 (Contraste Mínimo) é brutalmente direta: texto normal deve atingir uma taxa de contraste de pelo menos 4,5:1 em relação ao plano de fundo, e texto grande (18pt ou 14pt em negrito) deve alcançar pelo menos 3:1.

Falhas de contraste geralmente decorrem de decisões de design que priorizam estética em detrimento da legibilidade. Texto cinza claro em fundos brancos parece sofisticado para designers com visão perfeita. Para pessoas com baixa visão, pessoas idosas ou qualquer pessoa lendo em uma tela com reflexo, é ilegível. Rótulos secundários, placeholders de formulários, texto de rodapé e estados de botão desabilitado são os culpados usuais — eles são estilizados para parecer sutis e acabam ficando invisíveis para uma parte significativa do seu público.

A correção quase sempre é um ajuste de CSS. Passe seus pares de cores por um verificador de contraste como a ferramenta de contraste da WebAIM ou o painel de acessibilidade das DevTools do navegador, depois ajuste o valor de primeiro plano ou de fundo até que passe. Aqui está um padrão comum que falha e como corrigi-lo:

/* Falha — taxa aproximadamente 2,3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Aprovado — taxa aproximadamente 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Para texto de placeholder, lembre-se de que a WCAG o trata como texto real — não como um enfeite decorativo — portanto ele também deve atender ao limite de 4,5:1. Evite depender apenas de placeholder para transmitir instruções; sempre combine-o com um elemento <label> visível. Se você usa imagens de texto, não é possível corrigir o contraste com CSS — é preciso gerar novamente essas imagens, o que é mais um motivo para preferir texto HTML vivo em vez de texto embutido em gráficos.

Falha nº 2 — Texto Alternativo de Imagem Ausente (WCAG 1.1.1)

Imagens sem texto alternativo aparecem em 58,2% das páginas iniciais. Quando as imagens não têm texto alternativo, usuários de leitores de tela encontram silêncio ou nomes de arquivo sem sentido onde deveria haver conteúdo significativo. Esse problema não é novo. Texto alternativo é um requisito fundamental de acessibilidade desde a WCAG 1.0 em 1999. Vinte e cinco anos depois, a maioria dos sites ainda falha em implementá-lo de forma consistente.

O motivo de isso persistir é uma lacuna de fluxo de trabalho, não de conhecimento. Essa taxa de falha aponta para lacunas sistemáticas nos fluxos de trabalho de conteúdo. Redatores e editores muitas vezes não sabem que texto alternativo é necessário. Sistemas de gerenciamento de conteúdo nem sempre o exigem. A garantia de qualidade não detecta a ausência. A correção, portanto, tem duas camadas: uma técnica e uma de processo.

No lado técnico, toda imagem significativa precisa de um atributo alt que transmita a mesma informação que a imagem transmite. Imagens decorativas — enfeites puramente visuais que não acrescentam informação — devem receber um alt="" vazio para que leitores de tela as ignorem completamente. Acertar essa distinção é tão importante quanto adicionar o atributo em si. Uma grande porcentagem de imagens tem texto alternativo ausente ou impreciso. Algumas imagens significativas não têm descrição alguma, enquanto imagens decorativas são frequentemente tratadas como conteúdo significativo. Ambos os problemas quebram a conformidade com a WCAG para conteúdo perceptível.

<!-- Imagem significativa: descreva o que ela transmite -->
<img src='team-photo.jpg' alt='A equipe de engenharia da Accsible no encontro de 2024 em Lisboa' />

<!-- Imagem decorativa: alt vazio, sem role necessário -->
<img src='wave-divider.svg' alt='' />

<!-- Imagem com link: descreva o destino, não a imagem -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='Ver planos de preços' />
</a>

No lado de processo, atualize os templates do seu CMS para tornar o campo de alt obrigatório para imagens de conteúdo e treine qualquer pessoa que faça upload de assets. Ferramentas automatizadas como a Accsible podem detectar imagens com texto alternativo ausente ou vazio em todo o site, fornecendo à sua equipe uma lista auditável para ser trabalhada de forma sistemática.

Falha nº 3 — Rótulos de Campos de Formulário Ausentes (WCAG 1.3.1, 3.3.2)

48,6% dos sites têm rótulos de campos de formulário ausentes. Essa falha é particularmente prejudicial porque é nos formulários que as pessoas realmente fazem coisas — se cadastram, finalizam compras, entram em contato, enviam solicitações de suporte. Muitos formulários não têm rótulos acessíveis, dependem apenas de placeholders, não expõem instruções e mensagens de erro ou não oferecem suporte ao uso apenas por teclado. Como os formulários são essenciais para a maioria das experiências digitais, essas falhas criam barreiras sérias de usabilidade.

O erro mais comum é usar texto de placeholder como substituto de um <label>. Placeholders desaparecem assim que a pessoa começa a digitar, deixando qualquer pessoa com comprometimento de memória de curto prazo — ou simplesmente alguém que se distrai no meio do formulário — sem saber para que serve o campo. Leitores de tela variam em como tratam placeholders, e nenhuma das abordagens é tão confiável quanto uma associação adequada de rótulo.

O padrão correto é usar um elemento <label> vinculado ao seu campo por meio de atributos for e id correspondentes. Se um rótulo visível não for possível por motivos de design, use aria-label ou aria-labelledby — mas não recorra a ARIA quando você poderia simplesmente usar um <label>.

<!-- Correto: associação explícita de rótulo -->
<label for='email'>Endereço de e-mail</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Errado: apenas placeholder -->
<input type='email' placeholder='Endereço de e-mail' />

<!-- Aceitável quando o rótulo precisa ficar visualmente oculto -->
<label for='search' class='visually-hidden'>Pesquisar no site</label>
<input type='search' id='search' name='q' />

Mensagens de erro também devem ser associadas de forma programática. Quando um formulário é validado e encontra um erro, a mensagem deve ser vinculada ao campo usando aria-describedby e, idealmente, o foco deve ser movido para o primeiro campo inválido. Erros de validação de formulários devem ser eficientes, intuitivos e acessíveis — o erro precisa ser claramente identificado, o acesso ao elemento problemático deve ser rápido e a pessoa deve conseguir corrigir o erro facilmente e reenviar o formulário.

Falha nº 4 — Links e Botões Vazios (WCAG 2.4.4, 4.1.2)

44,6% dos sites têm hiperlinks vazios. Botões vazios foram encontrados em quase 30% das páginas, e esse número aumentou em relação ao ano anterior. Isso significa que pessoas cegas ou com baixa visão não entenderão a finalidade de botões como enviar, limpar, filtrar ou pesquisar. Juntos, links e botões vazios representam uma das experiências mais frustrantes para usuários de leitores de tela — encontrar elementos interativos sem nome é como apertar uma maçaneta sem rótulo e sem ideia de para onde ela leva.

Links vazios ocorrem mais comumente quando um ícone ou imagem é o único filho de uma tag <a> e nenhum texto alternativo é fornecido. Botões vazios acontecem quando botões apenas com ícone — menus hambúrguer, ícones de fechar, botões de compartilhamento social — não têm nenhum nome acessível. Ambos são simples de corrigir.

<!-- Link vazio — falha -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Corrigido com aria-label -->
<a href='/dashboard' aria-label='Ir para o painel'><svg aria-hidden='true'>...</svg></a>

<!-- Botão vazio — falha -->
<button><svg>...</svg></button>

<!-- Corrigido com texto visualmente oculto -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Fechar menu</span>
</button>

Observe o aria-hidden='true' no SVG em cada exemplo corrigido. Quando você fornece uma alternativa em texto via aria-label ou texto visualmente oculto, é importante suprimir o SVG da árvore de acessibilidade — caso contrário, leitores de tela podem anunciar tanto o rótulo quanto o título ou descrição do próprio SVG, criando um anúncio duplo confuso. Texto de link ambíguo — frases como "clique aqui", "leia mais" ou "saiba mais" — é uma falha relacionada. Outros problemas de hiperlink, como texto de link ambíguo, foram encontrados em quase 14% das páginas iniciais, um aumento em relação ao ano anterior. Hiperlinks com texto adequado são importantes para que as pessoas saibam para onde um link as levará. O nome acessível de cada link deve fazer sentido fora de contexto, porque usuários de leitores de tela frequentemente navegam abrindo uma lista de todos os links de uma página.

Falha nº 5 — Idioma do Documento Ausente (WCAG 3.1.1)

Esta pode parecer menor em comparação com contraste ou texto alternativo, mas cerca de 16% das páginas não têm um idioma de documento definido — e o impacto para usuários de leitores de tela é imediato e chocante. Se a pessoa usuária do leitor de tela tiver o pacote de idioma específico instalado, o conteúdo será lido corretamente. Caso contrário, soará como um sotaque ruim e pode não ser compreensível.

A correção é um único atributo HTML — literalmente uma linha de código — e não há desculpa para deixá-lo de fora. Adicione o atributo lang ao elemento <html> com a tag de idioma BCP 47 apropriada. Se trechos da sua página estiverem em um idioma diferente do restante, adicione um atributo lang também a esses elementos específicos.

<!-- Ausente: sem atributo lang -->
<html>

<!-- Correto: página em inglês -->
<html lang='en'>

<!-- Correto: página em francês -->
<html lang='fr'>

<!-- Troca de idioma em linha dentro de uma página -->
<p>A expressão em francês <span lang='fr'>joie de vivre</span> significa um alegre prazer de viver.</p>

Se você usa um CMS ou gerador de site estático, o atributo lang deve ser definido no template base. Verifique seu template uma vez, corrija uma vez, e todas as páginas do seu site estarão imediatamente corrigidas. Este é talvez o ajuste com maior retorno sobre o esforço em toda esta lista — uma única alteração de template elimina o problema em todo o seu domínio.

Falha nº 6 — Navegação por Teclado e Gestão de Foco Inacessíveis (WCAG 2.1.1, 2.4.7)

A acessibilidade por teclado é onde a lacuna entre testes automatizados e usabilidade real é mais ampla. Ferramentas automatizadas conseguem detectar algumas falhas de teclado — como elementos interativos construídos com tags não semânticas — mas não conseguem simular ordem de tabulação, aprisionamento de foco ou a experiência de navegar em um menu suspenso apenas com as setas do teclado. Sites frequentemente removem indicadores de foco padrão sem fornecer alternativas, tornando a navegação por teclado quase impossível. Isso afeta não apenas pessoas com deficiências motoras, mas qualquer pessoa que prefira navegar por teclado, usuárias avançadas e pessoas que usam dispositivos de varredura (switch).

As falhas de teclado mais comuns são: componentes interativos personalizados construídos com tags <div> ou <span> que nunca recebem foco; regras de CSS que removem o anel de foco padrão do navegador com outline: none ou outline: 0 sem substituí-lo por algo igualmente visível; diálogos modais que não aprisionam o foco (de modo que pessoas que usam teclado podem navegar por tab para trás do overlay); e carrosséis ou acordeões que não podem ser operados sem mouse.

<!-- Botão personalizado inacessível por teclado — falha -->
<div class='btn' onclick='doSomething()'>Enviar</div>

<!-- Correto: use um botão de verdade -->
<button type='button' onclick='doSomething()'>Enviar</button>

<!-- Remover estilos de foco — falha na WCAG 2.4.7 -->
* {
  outline: none; /* nunca faça isso globalmente */
}

<!-- Melhor: estilize o foco de forma visível preservando a estética -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

A pseudo-classe :focus-visible é sua melhor aliada aqui. Ela exibe estilos de foco quando a pessoa navega por teclado, mas os suprime para cliques de mouse — oferecendo estética limpa sem sacrificar acessibilidade. Para modais e painéis deslizantes, use uma utilidade de aprisionamento de foco que restrinja a navegação por tab ao interior do diálogo enquanto ele estiver aberto e devolva o foco ao elemento acionador quando ele for fechado. Pop-ups frequentemente aparecem sem gestão de foco adequada, sem rótulos ou sem suporte à navegação por teclado. Isso causa interrupções significativas, especialmente em fluxos críticos como cadastro, login e finalização de compra.

Além de componentes individuais, considere adicionar um link de pular navegação — um link visualmente oculto que se torna visível ao receber foco e permite que pessoas que usam teclado saltem a navegação repetitiva e vão direto ao conteúdo principal. Links de pular navegação que permitem às pessoas ignorar navegação repetitiva estão ausentes na maioria dos sites. São três linhas de HTML e um pequeno trecho de CSS, e isso faz uma diferença profunda para qualquer pessoa que navegue por uma página rica em conteúdo usando teclado.

<!-- Coloque isto como o primeiro elemento dentro de <body> -->
<a href='#main-content' class='skip-link'>Ir para o conteúdo principal</a>

<!-- Depois, no seu CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Uma Observação sobre ARIA: Use com Cuidado

Muitas equipes recorrem a atributos ARIA (Accessible Rich Internet Applications) como um conserto rápido para lacunas de acessibilidade. Os dados sugerem que isso dá mais errado do que certo. Aproximadamente 79% das páginas iniciais avaliadas usaram ARIA, um aumento em relação ao ano anterior. Páginas iniciais com ARIA tinham mais que o dobro de erros em comparação com páginas sem ARIA. A ARIA em si não é o problema — geralmente é o uso indevido ou incorreto de ARIA. Muitos desenvolvedores bem-intencionados acham que estão tornando o conteúdo mais acessível ao adicionar ARIA, quando na verdade muitas vezes o tornam menos acessível.

O princípio orientador é simples: use HTML semântico primeiro. Um <button> é melhor que um <div role='button'>. Um <nav> é melhor que um <div role='navigation'>. Elementos nativos de HTML vêm com comportamento de teclado embutido, gestão de foco e roles ARIA implícitos que marcação personalizada exige que você replique manualmente — e é nessa replicação manual que os erros surgem. Reserve ARIA para casos em que o HTML realmente não consegue expressar a semântica de que você precisa, como regiões dinâmicas (live regions), widgets compostos complexos ou mudanças de estado dinâmicas.

Incorporando Acessibilidade ao seu Fluxo de Trabalho

Corrigir violações existentes é necessário, mas impedir que novas apareçam é o que diferencia programas de acessibilidade maduros de corridas pontuais por conformidade. Acessibilidade não é um conserto único. Cada atualização de conteúdo, mudança de design ou implantação de código pode introduzir novos problemas. As seis categorias de falha abordadas neste guia tendem a ser problemas em nível de template — corrija o cabeçalho, o rodapé e os componentes compartilhados e você elimina o problema em centenas de páginas simultaneamente.

Integre varredura automatizada ao seu pipeline de CI/CD para que violações sejam detectadas antes de chegar à produção. Ferramentas como axe-core podem ser incorporadas a testes de unidade e suítes de testes de ponta a ponta. Combine isso com passagens periódicas manuais por teclado e testes com leitores de tela — VoiceOver em macOS e iOS, NVDA no Windows — porque testes automatizados conseguem detectar erros comuns de acessibilidade, mas testes manuais ajudam a preencher as lacunas. Para equipes que precisam de uma rampa de entrada mais rápida, um widget de overlay de acessibilidade como a Accsible pode identificar e remediar uma classe significativa de problemas na camada de renderização enquanto correções de longo prazo em nível de código são planejadas e implantadas.

Por fim, trate do ponto de maior alavancagem no seu código: seus templates. A maioria dos sites usa templates — um cabeçalho, rodapé, navegação e layout de página que se repetem em todas as páginas. Problemas nesses templates se multiplicam em todo o site. Corrija-os primeiro para obter o máximo impacto. Um único template base corrigido pode transformar 10.000 falhas de WCAG em zero com uma única implantação.

Principais Lições

• Seis tipos de problema dominam o cenário. Texto com baixo contraste, texto alternativo ausente, campos de formulário sem rótulo, links e botões vazios, idioma de documento ausente e navegação por teclado quebrada respondem pela esmagadora maioria das falhas de WCAG. Corrigir essas seis categorias gera resultados desproporcionais em relação ao esforço.
• A maioria das correções é de CSS ou mudanças de uma linha em HTML. Adicionar lang='en' à sua tag <html>, substituir outline: none por estilos com :focus-visible e associar rótulos a campos são horas de trabalho, não meses — e ainda assim eliminam falhas que afetam toda pessoa com deficiência que visita seu site.
• Templates são o local de correção com maior alavancagem. Bugs de acessibilidade em componentes compartilhados e templates de página se replicam em todo o site. Audite primeiro seu cabeçalho, rodapé, navegação e formulários — corrigi-los ali significa corrigi-los em todos os lugares.
• ARIA é uma ferramenta de último recurso, não a primeira resposta. Sites que dependem fortemente de ARIA sem uma base sólida de HTML semântico tendem a ter significativamente mais erros de acessibilidade, não menos. Prefira elementos nativos de HTML sempre que possível.
• Varredura automatizada captura menos da metade dos problemas reais. Complete suas ferramentas com passagens manuais por teclado e testes com leitores de tela para encontrar falhas que nenhum scanner revelará, incluindo armadilhas de foco, problemas de ordem lógica de tabulação e conteúdo dinâmico que não anuncia mudanças.