Acessibilidade no Front-End: o guia prático para quem está começando

Você não precisa ser especialista para escrever HTML acessível.

Por que isso importa?

Segundo o IBGE, cerca de 18 milhões de brasileiros têm alguma deficiência visual. Somando deficiências motoras, auditivas e cognitivas, o número cresce muito mais. Quando ignoramos acessibilidade, estamos essencialmente construindo uma porta que só abre para uma parte das pessoas.

Acessibilidade não é um recurso extra. É uma parte fundamental de escrever bom HTML — e muita coisa já vem de graça quando você usa as tags certas.

1. Use HTML semântico (isso já resolve metade dos problemas)

Leitores de tela como o NVDA e o VoiceOver “lêem” a estrutura do seu HTML. Se você usa <div> para tudo, eles não conseguem identificar o que é título, o que é botão, o que é navegação.

Evite
  <div class="btn" onclick="...">
    Enviar
  </div>
  <div class="titulo">
    Sobre nós
  </div>

Prefira
  <button type="submit">
    Enviar
  </button>
  <h2>Sobre nós</h2>

A tag <button> já é focável pelo teclado, já ativa com Enter e Espaço, e já é anunciada como "botão" pelo leitor de tela. Com um <div>, você teria que recriar tudo isso na mão — e ainda assim faria pior.

2. Texto alternativo em imagens

O atributo alt é o que um leitor de tela anuncia quando encontra uma imagem. Ele deve descrever o conteúdo da imagem — não o arquivo.

Evite

Evite
  <img src="foto.jpg">

  <img src="foto.jpg"
    alt="foto.jpg">

  <img src="logo.png"
    alt="imagem">

Prefira
  <img src="foto.jpg"
    alt="Mulher sorrindo
    segurando uma xícara
    de café">

  <img src="logo.png"
    alt="Logo da empresa">

Imagens decorativas (ícones de fundo, separadores) devem ter alt="" — vazio mesmo. Isso sinaliza para o leitor de tela que a imagem pode ser ignorada.

3. Labels em formulários

Todo campo de formulário precisa de um <label> associado. Sem isso, o usuário de leitor de tela não sabe o que está preenchendo.

Evite
  <input type="text"
    placeholder="Nome">

Prefira
  <label for="nome">Nome</label>
  <input type="text"
    id="nome"
    name="nome">

O atributo for do label deve ter o mesmo valor do id do input. Quando o usuário clica no label, o foco vai direto para o campo — isso também ajuda quem usa mouse e tem dificuldade de precisão.

4. Contraste de cores

Textos com pouco contraste são difíceis de ler para pessoas com baixa visão ou daltonismo. As diretrizes WCAG recomendam uma relação de contraste de pelo menos 4.5:1 para texto normal.

/* Ruim: cinza claro em fundo branco */
.texto { color: #aaaaaa; background: #ffffff; }

/* Bom: contraste suficiente */
.texto { color: #595959; background: #ffffff; }

Você pode checar o contraste de qualquer cor no WebAIM Contrast Checker — é gratuito e leva segundos.

5. Navegação por teclado

Muitos usuários navegam apenas com o teclado: pessoas com limitações motoras, usuários avançados, e quem usa leitor de tela. Teste seu site pressionando Tab e veja se você consegue acessar tudo.

Nunca escreva outline: none sem oferecer um substituto visual. O outline é o indicador visual de foco — sem ele, o usuário de teclado fica completamente perdido na página.

/* Ruim */
button:focus { outline: none; }

/* Bom: substitua por um foco visível */
button:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

6. ARIA: use com moderação

ARIA (Accessible Rich Internet Applications) é um conjunto de atributos que adicionam semântica onde o HTML nativo não chega. Mas existe uma regra de ouro:

Não use ARIA se existe uma tag HTML nativa que já faz o trabalho. ARIA mal usado é pior do que nenhum ARIA.

Quando você precisar de ARIA, os casos mais comuns para iniciantes são aria-label (nomear elementos sem texto visível) e aria-hidden (esconder elementos decorativos).

<!-- Botão com apenas ícone: precisa de nome acessível -->
<button aria-label="Fechar menu">
  <svg aria-hidden="true">...</svg>
</button>

Checklist rápido antes de publicar

✓ Todas as imagens têm atributoalt?

✓ Todos os campos do formulário têm<label>associado?

✓ Você está usando tags semânticas (button,nav,main,h1–h6)?

✓ O contraste de texto passa pelo mínimo de 4.5:1?

✓ Dá pra navegar em toda a página só com o teclado?

✓ O foco do teclado está visível em todos os elementos interativos?

Conclusão

Acessibilidade começa no HTML. Você não precisa dominar WCAG inteiro agora — comece pelos fundamentos: semântica, labels, alt text e contraste. Esses quatro pontos já resolvem a maioria dos problemas mais comuns.

A cada projeto novo, adicione um item a mais nessa lista. Com o tempo, escrever código acessível vira hábito — e você vai perceber que também melhora a qualidade do código como um todo.

Gostou do conteúdo? Compartilhe com alguém que está aprendendo front-end. A acessibilidade cresce quando a comunidade cresce junto.