Acessibilidade (a11y)

Por que a acessibilidade é importante

Acessibilidade significa construir para pessoas que utilizam tecnologias assistivas, navegam via teclado, precisam de maior contraste ou preferem a redução de movimento. Cerca de uma em cada seis pessoas vive com alguma deficiência, e quase todo mundo se beneficia da acessibilidade em algum momento — seja por causa de um braço quebrado, uma tela com brilho excessivo ou um trem barulhento.

Além disso, ela é cada vez mais exigida. Legislações e regras de contratação em muitos países fazem referência ao WCAG, portanto, a acessibilidade é um requisito profissional básico, e não apenas um “algo a mais”. A parte tranquilizadora é que a maior parte disso vem de fazer o básico bem feito.

WCAG e POUR

As Web Content Accessibility Guidelines definem o padrão. Seus quatro princípios são:

• Percebível (Perceivable) — o conteúdo pode ser percebido, por exemplo, com alternativas em texto para imagens e contraste suficiente.
• Operável (Operable) — tudo funciona via teclado e não exige precisão extrema no apontamento.
• Compreensível (Understandable) — o conteúdo e o comportamento são previsíveis e claros.
• Robusto (Robust) — funciona com agentes de usuário e tecnologias assistivas atuais e futuras.

Cada princípio possui critérios de sucesso testáveis nos níveis A, AA e AAA. A maioria das equipes visa o nível AA.

HTML Semântico é a base

A maior parte da acessibilidade vem do uso dos elementos corretos. Elementos nativos já trazem consigo papéis (roles), estados e comportamentos de teclado.

<!-- semantics.html -->
<header>
  <nav aria-label="Main">
    <a href="/">Home</a>
  </nav>
</header>
<main>
  <h1>Dashboard</h1>
  <button type="button" aria-expanded="false">Filters</button>
</main>

Um <button> é focável, responde às teclas Enter e Space, e é anunciado como um botão. Um <div onclick> não possui nenhuma dessas características. É por isso que o guia de HTML Semântico vem antes deste: a semântica é a vitória mais barata e simples em termos de acessibilidade.

Suporte ao teclado

Todo elemento interativo deve ser acessível e operável apenas com o teclado.

• Use controles nativos, que já possuem foco por padrão.
• Mantenha a ordem do tab lógica; ela deve seguir a ordem visual.
• Forneça um skip link para que os usuários possam pular a navegação repetitiva.
• Nunca prenda o foco dentro de um componente sem oferecer uma saída.
• Exiba um indicador de foco claro e nunca remova outlines sem substituí-los por algo visível.

<!-- skip.html -->
<a href="#main" class="skip-link">Skip to content</a>
<main id="main" tabindex="-1">...</main>

Gerenciamento de foco

O foco é o cursor do usuário que utiliza teclado. Gerencie-o de forma deliberada:

• Quando um diálogo abrir, mova o foco para dentro dele e mantenha-o retido ali.
• Quando ele fechar, retorne o foco para o elemento que o abriu.
• Em navegações client-side, mova o foco para o novo conteúdo.
• Após erros de validação, foque no primeiro campo inválido.

Diálogos modernos podem usar o elemento <dialog> com showModal(), que resolve grande parte disso para você.

Alternativas de texto

As imagens precisam de alternativas de texto que transmitam seu propósito dentro do contexto.

• Imagens informativas recebem uma descrição do que elas transmitem.
• Imagens decorativas recebem alt="" para que sejam ignoradas.
• Imagens funcionais, como um ícone dentro de um link, descrevem a ação.
• Imagens complexas precisam de uma descrição mais detalhada nas proximidades.

O mesmo princípio se aplica a mídias: forneça legendas para vídeos, transcrições para áudios e rótulos (labels) para cada controle de formulário.

ARIA, usado com cautela

O ARIA adiciona semântica que o HTML não consegue expressar, mas é fácil utilizá-lo de forma incorreta. A primeira regra do ARIA é: não use ARIA se um elemento nativo já fizer o trabalho. Um <div role="button"> é pior do que um <button> em quase todos os aspectos.

Quando você realmente precisar dele:

• aria-label nomeia um elemento que não possui texto visível.
• aria-labelledby referencia um texto visível que nomeia o elemento.
• aria-describedby vincula um controle a uma dica ou mensagem de erro.
• aria-expanded, aria-controls e aria-live descrevem estados e atualizações dinâmicas.

Teste o ARIA com um leitor de tela real; um ARIA incorreto é frequentemente pior do que nenhum.

Cor e contraste

O texto precisa de contraste suficiente em relação ao seu plano de fundo:

• 4.5:1 para texto normal, 3:1 para texto grande no nível AA.
• 3:1 para ícones, bordas e indicadores de foco.
• Nunca use apenas a cor para transmitir significado; adicione texto, ícones ou padrões.

Verifique o contraste com uma ferramenta e teste seu design em escala de cinza para identificar comunicações baseadas apenas em cores.

Movimento e preferências

Respeite as preferências do usuário.

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

Paralaxes exagerados e animações de scroll são os culpados mais comuns. Além disso, evite a reprodução automática de mídias com som e forneça controles para qualquer elemento que se mova.

Testes

Ferramentas automatizadas detectam talvez um terço dos problemas. Combine-as com testes manuais:

1. Execute o axe ou o Lighthouse para encontrar violações comuns.
2. Navegue utilizando apenas o teclado, verificando o foco e a ordem de tabulação.
3. Aplique um zoom de 200% e verifique se nada quebra ou se sobrepõe.
4. Experimente um leitor de tela: VoiceOver, NVDA ou Narrator.
5. Verifique o contraste e se há informações transmitidas apenas por cores.
6. Teste formulários com erros e conteúdos dinâmicos.

O guia da Testing Library mostra como queries acessíveis tornam a acessibilidade parte da sua suíte de testes.

Melhores práticas

• Comece com HTML semântico antes de adicionar ARIA.
• Torne tudo operável via teclado com foco visível.
• Forneça alternativas em texto para todas as mídias significativas.
• Atenda ao contraste AA e nunca dependa apenas de cores.
• Gerencie o foco para diálogos, navegação e erros.
• Respeite a redução de movimento e evite a reprodução automática de mídias.
• Teste com ferramentas automatizadas e tecnologias assistivas reais.

Erros comuns

• Usar divs como botões e links.
• Remover outlines de foco por questões estéticas.
• Texto alt ausente ou pouco útil.
• Adicionar ARIA incorretamente e quebrar a semântica nativa.
• Texto com baixo contraste e estados indicados apenas por cores.
• Ignorar usuários de teclado em widgets personalizados.

Próximos passos

Acessibilidade é uma prática, não um checklist. Aprofunde-se em Semantic HTML, torne seus formulários utilizáveis com Forms & Validation e integre isso aos seus testes com Testing Library. Depois, escolha uma página, navegue por ela usando apenas o teclado e corrija o que encontrar.