Acessibilidade web (a11y): por que e como tornar seu site inclusivo

Acessibilidade web (abreviada como a11y, porque há 11 letras entre o "a" e o "y") é a prática de construir sites que qualquer pessoa consiga usar, independentemente de deficiência, dispositivo ou contexto. Não é um recurso opcional nem um item de caridade: é uma dimensão fundamental de qualidade que se sobrepõe a usabilidade, SEO e robustez técnica. Neste guia você vai entender por que a acessibilidade importa e como aplicá-la na prática sem reescrever todo o seu projeto.

A boa notícia para quem desenvolve é que a maior parte da acessibilidade não exige tecnologia nova nem bibliotecas pesadas. Ela exige decisões corretas em código que você já escreve todos os dias: qual elemento HTML usar, qual cor de texto escolher, como ordenar os elementos focáveis. Quem trata a11y como disciplina de engenharia — e não como retrabalho de fim de sprint — entrega produtos melhores para todo mundo e gasta menos.

O que significa "a11y" na prática

Quando falamos em acessibilidade, pensamos primeiro em pessoas cegas usando leitores de tela. Mas o público é muito mais amplo: pessoas com baixa visão, daltonismo, deficiências motoras que impedem o uso preciso do mouse, surdez, dislexia e limitações cognitivas. Também inclui situações temporárias (um braço quebrado) ou contextuais (sol forte na tela do celular, ambiente barulhento sem fone).

A regra prática é simples: um site acessível funciona mesmo quando o usuário não pode ver, ouvir, usar o mouse ou processar conteúdo do jeito que você imaginou. Isso obriga você a separar conteúdo de apresentação e a fornecer alternativas para cada modo de interação.

Vale destacar a diferença entre deficiência permanente, temporária e situacional. Uma pessoa cega tem uma limitação permanente para enxergar; alguém que fez cirurgia ocular tem uma limitação temporária; e qualquer pessoa tentando ler a tela sob luz solar intensa enfrenta uma limitação situacional. O mesmo recurso de acessibilidade — alto contraste, legendas, navegação por teclado — atende aos três grupos. Por isso o investimento em a11y tem alcance muito maior do que o percentual de pessoas com deficiência declarada sugere.

WCAG: o padrão que organiza tudo

As WCAG (Web Content Accessibility Guidelines) são as diretrizes internacionais publicadas pelo W3C. Elas se organizam em torno de quatro princípios, lembrados pela sigla POUR:

Cada critério tem três níveis de conformidade: A (mínimo), AA (recomendado e exigido pela maioria das legislações) e AAA (ideal, nem sempre viável). Para a maioria dos projetos, mirar no nível AA é o objetivo correto.

Na prática, "atingir AA" não é um juramento abstrato: cada princípio POUR se desdobra em critérios de sucesso numerados (por exemplo, 1.4.3 para contraste de texto, 2.1.1 para teclado, 2.4.7 para foco visível). Você não precisa decorar a numeração, mas conhecer o mapa ajuda a transformar "o site precisa ser acessível" em uma lista verificável de tarefas. A versão WCAG 2.1 (W3C, 2018) acrescentou critérios importantes para dispositivos móveis e baixa visão, como alvos de toque maiores e suporte a reflow (o conteúdo reflui sem rolagem horizontal quando ampliado a 400%).

Legislação e por que isso importa para o negócio

No Brasil, a Lei Brasileira de Inclusão (Lei 13.146/2015) determina que sites de empresas e órgãos públicos sejam acessíveis, e o eMAG é o modelo de acessibilidade do governo federal. Internacionalmente, o ADA nos EUA e o European Accessibility Act criam obrigações semelhantes. Para a equipe de produto, isso significa que a11y não é só ética: é redução de risco jurídico e ampliação de mercado. Ignorá-la pode custar processos e clientes.

HTML semântico: a base de tudo

A forma mais barata e poderosa de tornar um site acessível é usar HTML semântico — ou seja, escolher o elemento certo para cada função. Um leitor de tela navega pela estrutura do documento; se você usa <div> para tudo, ele não tem como saber o que é cabeçalho, navegação ou botão.

<!-- Ruim: nada disso comunica significado -->
<div class="botao" onclick="enviar()">Enviar</div>
<div class="titulo">Meu artigo</div>

<!-- Bom: o navegador e o leitor de tela entendem -->
<button type="submit">Enviar</button>
<h1>Meu artigo</h1>

Use marcos de navegação (<header>, <nav>, <main>, <footer>), hierarquia correta de cabeçalhos (<h1> a <h6>, sem pular níveis) e listas reais (<ul>, <ol>) para conteúdo em lista. Esses elementos vêm com comportamento de acessibilidade embutido — foco de teclado, papéis e estados — que você teria que reconstruir manualmente em uma <div>.

Os marcos de página (landmarks) são especialmente úteis. Leitores de tela permitem ao usuário pular diretamente para a região "main" ou listar todas as regiões "navigation" da página. Uma estrutura bem marcada transforma uma página densa em algo navegável em segundos:

<body>
  <header>
    <nav aria-label="Principal">...</nav>
  </header>
  <main>
    <h1>Título da página</h1>
    <article>...</article>
  </main>
  <aside aria-label="Conteúdo relacionado">...</aside>
  <footer>...</footer>
</body>

Repare no aria-label nos elementos <nav>: quando há mais de uma navegação na página, rotulá-las distingue "Principal" de "Conteúdo relacionado" para quem usa leitor de tela. Esse é um dos poucos casos em que ARIA complementa o HTML semântico de forma legítima.

Formulários acessíveis

Formulários concentram boa parte das falhas de a11y. A regra de ouro: todo campo precisa de um rótulo associado por programação. Não basta um texto visualmente próximo; o <label> precisa apontar para o id do campo.

<!-- Errado: o leitor de tela anuncia "campo de edição" sem contexto -->
<span>E-mail</span>
<input type="email">

<!-- Certo: rótulo associado -->
<label for="email">E-mail</label>
<input type="email" id="email" name="email" autocomplete="email"
       aria-describedby="email-dica">
<small id="email-dica">Usaremos apenas para enviar o recibo.</small>

O atributo autocomplete ajuda quem tem dificuldade motora ou cognitiva a preencher o formulário com dados salvos, e o aria-describedby conecta a dica ao campo para que o leitor de tela a leia junto.

Vale lembrar que toda essa estrutura é entregue ao navegador via requisições e respostas; se você quer entender o que acontece nos bastidores, vale revisar O que é HTTP? Métodos, status e como a web conversa.

Texto alternativo e mídia

Toda imagem que carrega informação precisa de um atributo alt descritivo. Imagens puramente decorativas devem ter alt="" (vazio, mas presente), para que o leitor de tela as ignore em vez de anunciar o nome do arquivo.

<!-- Imagem informativa -->
<img src="grafico-vendas.png" alt="Vendas cresceram 40% entre janeiro e junho">

<!-- Imagem decorativa -->
<img src="enfeite.svg" alt="">

Escrever bom texto alternativo é uma habilidade. O alt deve transmitir a função e a informação da imagem no contexto, não descrever pixels. Para o logotipo que leva à home, o alt certo é o nome da empresa, não "logotipo azul redondo". Para um gráfico, descreva a conclusão ("Vendas cresceram 40%"), não o tipo de gráfico. E nunca comece com "imagem de" — o leitor de tela já anuncia que é uma imagem.

Para vídeos, ofereça legendas e, idealmente, transcrições. Para áudio, transcrições. Isso ajuda surdos, mas também quem está em ambiente silencioso ou prefere ler. Conteúdo com áudio essencial também se beneficia de audiodescrição, uma narração das informações visuais para quem não enxerga a tela.

Contraste, cor e tipografia

Cerca de 8% dos homens têm algum tipo de daltonismo, então nunca use cor como único indicador de informação. Um campo de formulário com erro não pode estar apenas vermelho — precisa de um ícone e de um texto explicativo.

O contraste entre texto e fundo deve atender ao mínimo das WCAG: 4,5:1 para texto normal e 3:1 para texto grande. Ferramentas como o verificador de contraste do navegador ou extensões dedicadas medem isso automaticamente. Evite também texto sobre imagens sem uma camada de proteção, e permita que o usuário aumente a fonte sem quebrar o layout.

Sobre tipografia, algumas práticas reduzem a carga cognitiva sem custo: use unidades relativas (rem, em) em vez de pixels fixos, para que o zoom de fonte do navegador funcione; mantenha o comprimento de linha confortável (em torno de 60 a 80 caracteres); e prefira alinhamento à esquerda, que é mais fácil de ler do que texto justificado para pessoas com dislexia. Respeitar a preferência prefers-reduced-motion é outro ganho importante:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Animações exuberantes podem causar náusea ou desorientação em pessoas com distúrbios vestibulares. Respeitar essa preferência do sistema operacional é um ato simples de inclusão.

Navegação por teclado e foco

Muitos usuários navegam apenas com o teclado: a tecla Tab move entre elementos interativos, Enter e Espaço os acionam. Se você usa elementos semânticos, isso funciona de graça. Se reinventa botões com <div>, você quebra tudo.

Garanta três coisas:

<a href="#conteudo" class="skip-link">Pular para o conteúdo</a>
<!-- ... menu de navegação ... -->
<main id="conteudo">...</main>

Um erro frequente é o uso indiscriminado de tabindex. Use tabindex="0" para tornar focável um elemento customizado que precise receber foco, e tabindex="-1" para mover foco via JavaScript sem entrar na ordem de tabulação. Mas evite valores positivos como tabindex="3": eles sobrescrevem a ordem natural do documento e quase sempre criam uma sequência confusa que você terá de manter manualmente para sempre.

Em interações dinâmicas, gerenciar o foco é decisivo. Ao abrir um modal, o foco deve mover-se para dentro dele e ficar "preso" (focus trap) até o usuário fechar; ao fechar, o foco volta para o elemento que abriu o modal. Sem isso, o usuário de teclado fica perdido navegando por uma página atrás do modal que nem consegue ver.

ARIA: use com parcimônia

O WAI-ARIA é um conjunto de atributos (role, aria-label, aria-expanded, etc.) que adiciona semântica a componentes que o HTML nativo não cobre, como menus dropdown ou abas customizadas. A primeira regra do ARIA, porém, é: não use ARIA se um elemento HTML nativo resolve o problema. ARIA mal aplicado piora a experiência mais do que a ausência dele.

<!-- Componente customizado que precisa comunicar estado -->
<button aria-expanded="false" aria-controls="menu-conta">
  Minha conta
</button>
<ul id="menu-conta" hidden>...</ul>

Atualize os estados ARIA via JavaScript sempre que a interface mudar — um aria-expanded estático mente para o leitor de tela.

Outro recurso valioso são as regiões dinâmicas (live regions). Quando conteúdo muda sem recarregar a página — uma notificação de "item adicionado ao carrinho", o resultado de uma busca ao vivo — o leitor de tela precisa ser avisado. O atributo aria-live faz isso:

<div aria-live="polite" id="status"></div>
<script>
  // Ao concluir uma ação, atualize o conteúdo da região
  document.getElementById('status').textContent =
    'Produto adicionado ao carrinho.';
</script>

Use polite para mensagens que podem esperar e assertive apenas para alertas urgentes, já que assertive interrompe o que o leitor estiver anunciando. Em formulários, conecte mensagens de erro ao campo com aria-describedby e marque o campo inválido com aria-invalid="true".

Erros comuns de a11y

A relação direta com SEO e performance

Acessibilidade e SEO compartilham a mesma raiz: conteúdo estruturado e legível por máquina. O Google rastreia seu site de forma parecida com um leitor de tela — ele depende de cabeçalhos, alt, links descritivos e HTML semântico. Quem investe em a11y normalmente ganha SEO de brinde, como detalha o guia de SEO técnico: o guia completo para devs. Entender Como funciona o Google: crawling, indexação e ranking deixa essa sobreposição ainda mais evidente.

Há também conexão com performance. Sites rápidos e estáveis são mais usáveis por todos, especialmente quem usa tecnologia assistiva em dispositivos modestos. As Core Web Vitals: meça e melhore a experiência do usuário penalizam, por exemplo, layouts que pulam durante o carregamento — algo que confunde tanto humanos quanto leitores de tela. Otimizações descritas em Performance web: técnicas para um site ultrarrápido reforçam diretamente a inclusão. O Google Web.dev (2020) defende justamente essa visão integrada de "saúde do site", em que métricas de experiência e qualidade andam juntas.

Links descritivos são um exemplo perfeito dessa sobreposição. "Clique aqui" não diz nada nem para o leitor de tela (que permite listar todos os links da página) nem para o buscador. "Leia o guia de SEO técnico" comunica destino para os dois. Pequenas escolhas de texto melhoram acessibilidade e relevância ao mesmo tempo.

Como testar a acessibilidade

Nenhuma ferramenta automatizada cobre 100% — elas pegam talvez 30% a 50% dos problemas. Combine três abordagens:

Esse ciclo de teste com pessoas reais é o coração da usabilidade, como Jakob Nielsen (1993) já argumentava: você só descobre os problemas que importam observando usuários de verdade interagindo com a interface.

Para integrar a11y ao fluxo de desenvolvimento, automatize o que der. A biblioteca axe-core roda dentro de testes e barra regressões antes do merge:

import { axe } from 'jest-axe';

test('a página inicial não tem violações de acessibilidade', async () => {
  const { container } = render(<HomePage />);
  const resultado = await axe(container);
  expect(resultado).toHaveNoViolations();
});

Esse teste no CI não substitui o teste manual, mas garante que erros já corrigidos não voltem. A combinação de checagem automática contínua, navegação por teclado em cada PR e testes periódicos com leitor de tela cobre a maior parte dos problemas reais.

Um checklist mínimo para começar hoje

Perguntas frequentes

Preciso atingir o nível AAA? Não na maioria dos casos. O nível AA é o alvo prático e o exigido pela maioria das legislações. AAA tem critérios que nem sempre são viáveis para todo conteúdo (como contraste 7:1 ou linguagem de sinais em todo vídeo). Mire AA de forma consistente e aplique AAA onde fizer sentido.

Um overlay de acessibilidade (plugin de um botão) resolve? Não. Esses widgets que prometem "tornar o site acessível com uma linha de script" costumam mascarar problemas em vez de corrigi-los, e frequentemente atrapalham usuários reais de leitores de tela. Acessibilidade se constrói no código-fonte, não com uma camada por cima.

a11y deixa o site mais feio ou limitado? Não. Foco visível, contraste e estrutura semântica são compatíveis com qualquer design. O que muda é a disciplina de projetar pensando em todos desde o início, o que normalmente melhora também a experiência de quem não tem deficiência.

Por onde começar em um projeto legado? Priorize os fluxos críticos de negócio (cadastro, checkout, busca) e os erros mais frequentes: campos sem rótulo, contraste baixo e ausência de navegação por teclado. Conserte por impacto, não tente refatorar tudo de uma vez.

Conclusão

Acessibilidade não é um item de checklist de última hora — é uma forma de pensar a construção do site desde o primeiro <div> (ou, melhor, o primeiro <main>). Comece pelo HTML semântico, garanta contraste e navegação por teclado, use ARIA com cautela e teste com pessoas reais. O retorno é triplo: você inclui mais gente, melhora seu SEO e entrega uma experiência mais robusta para todos. Construir para os limites acaba beneficiando o centro.

Referências