Guia Prático de Acessibilidade WCAG e Contraste de Cores

Guia Prático de Acessibilidade WCAG e Contraste de Cores para interfaces reais

A WCAG 2.2 é um conjunto de diretrizes criado para tornar experiências digitais perceptíveis, operáveis, compreensíveis e robustas. Quando falamos de cores, o ponto mais conhecido é o contraste entre texto e fundo, mas a lógica vai além disso. Um link precisa ser reconhecível, um campo com erro precisa se comunicar sem depender apenas do vermelho, um botão desabilitado precisa continuar legível e um gráfico precisa manter significado mesmo para pessoas com baixa visão ou daltonismo.

O contraste é calculado a partir da luminância relativa das cores. O resultado é uma razão matemática entre a cor mais clara e a cor mais escura. Essa razão varia de 1:1, quando não há contraste perceptível, até 21:1, que é o contraste entre preto puro e branco puro. Por isso, duas cores visualmente bonitas em uma paleta podem falhar quando uma delas vira texto sobre a outra.

Critérios AA e AAA na WCAG 2.2

O nível AA costuma ser a meta prática para produtos digitais, sites institucionais, sistemas internos e aplicações SaaS. Ele representa um equilíbrio entre acessibilidade, liberdade visual e viabilidade de implementação. Para texto normal, a proporção mínima exigida é 4.5:1. Para texto grande, a exigência AA cai para 3:1 porque letras maiores e mais pesadas são mais fáceis de reconhecer.

O nível AAA é mais rigoroso. Ele pede 7:1 para texto normal e 4.5:1 para texto grande. Nem sempre é possível aplicar AAA a todos os pontos de uma interface sem limitar bastante a identidade visual, mas ele é excelente para áreas críticas, como leitura longa, documentação, painéis financeiros, conteúdo educacional, avisos importantes e fluxos públicos de alto impacto.

Na prática, texto grande significa pelo menos 18 pt em peso normal ou 14 pt em negrito. Em CSS, isso costuma equivaler aproximadamente a 24 px para texto regular ou 18.66 px para texto em negrito. Mesmo assim, tamanho não deve ser usado como desculpa para contraste fraco. A melhor interface é aquela em que hierarquia, peso, espaçamento e cor trabalham juntos.

Exemplos práticos de combinações que passam e falham

A tabela abaixo mostra combinações comuns em interfaces. O objetivo não é decorar pares de cores, mas treinar o olhar para perceber padrões. Tons claros sobre branco falham com frequência. Cinzas médios em fundos claros podem parecer elegantes no layout, mas cansam a leitura. Já fundos escuros com texto claro costumam passar, desde que o texto não use transparência excessiva.

CSS acessível para botões, textos e estados de foco

Uma boa prática é centralizar cores em tokens semânticos. Em vez de espalhar hexadecimais pelo projeto, defina variáveis para superfície, texto, destaque, foco e erro. Isso facilita auditoria, modo escuro, testes automatizados e manutenção de contraste em componentes reutilizáveis.

:root {
  --color-page: #f8fafc;
  --color-surface: #ffffff;
  --color-text: #0f172a;
  --color-muted: #475569;
  --color-primary: #2563eb;
  --color-primary-text: #ffffff;
  --color-focus: #facc15;
}

.button-primary {
  background: var(--color-primary);
  color: var(--color-primary-text);
  border: 2px solid transparent;
}

.button-primary:focus-visible {
  outline: 3px solid var(--color-focus);
  outline-offset: 3px;
}

.helper-text {
  color: var(--color-muted);
}

Outro ponto importante é nunca depender apenas da cor para comunicar estado. Um campo inválido pode usar vermelho, mas também deve exibir texto de erro, ícone, borda perceptível e associação semântica com a mensagem. Para leitores de tela, atributos como aria-describedby ajudam a conectar o campo ao erro exibido.

<label for="email">E-mail</label>
<input
  id="email"
  name="email"
  type="email"
  aria-describedby="email-error"
  aria-invalid="true"
>
<p id="email-error" class="field-error">
  Informe um e-mail válido.
</p>

Como aplicar o guia no fluxo de desenvolvimento frontend

Comece validando as cores principais da marca contra os fundos reais da interface. Depois, teste variações de hover, foco, ativo, desabilitado e erro. Em seguida, valide textos pequenos, badges, labels de formulário, menus, breadcrumbs e legendas de gráficos. Esses elementos costumam receber menos atenção visual, mas são usados o tempo todo por pessoas que dependem de leitura clara.

Design systems maduros tratam contraste como contrato. Um botão primário não é apenas azul. Ele é uma combinação entre fundo, texto, borda, foco, hover e contexto. Quando cada token já nasce com contraste aprovado, o time passa a criar telas mais rápido e com menos retrabalho.