Como Verificar o Contraste de Cores para a WCAG

Para verificar o contraste de cores conforme a WCAG, compare a luminância relativa do texto em primeiro plano com a do seu fundo e, em seguida, confirme se a razão resultante atende ao limite exigido para aquele tipo de elemento: no Nível AA, isso significa 4,5:1 para texto normal, 3:1 para texto grande e 3:1 para elementos de interface não textuais.

A maioria de nós aprende isso da forma mais difícil: publicando um rótulo em cinza-claro que parecia perfeito na nossa própria tela e reprovou na auditoria dois sprints depois. Você não calcula isso à mão: um verificador faz o trabalho a partir de dois valores hexadecimais em segundos. Este guia apresenta os limites exatos, as formas mais rápidas de medir uma razão, as falhas que derrubam a maioria das equipes e as regras que vão além do texto corrido, alcançando componentes de interface, indicadores de foco e significados codificados por cor.

Qual razão de contraste a WCAG exige?

A razão de contraste mede a diferença de luminância entre duas cores. O piso é 1:1, o que acontece quando o primeiro plano e o fundo têm a mesma cor, e o teto é 21:1, preto sobre branco. A WCAG calcula essa razão como (L1 + 0,05) / (L2 + 0,05), onde L1 e L2 são a luminância relativa da cor mais clara e da mais escura. Estes são os limites que todo verificador aplica:

No Nível AA, isso significa 4,5:1 para texto normal e 3:1 para texto grande; o Nível AAA eleva esse mesmo par para 7:1 e 4,5:1. O que conta como “grande” é uma questão de tamanho e peso: 18pt (cerca de 24px) para cima, ou 14pt (cerca de 18,66px) para cima se o texto estiver em negrito. O WebAIM Contrast Checker avalia exatamente com base nesses limites. Uma única regra de decisão cobre a maioria dos casos: o texto é grande? → 3:1; caso contrário → 4,5:1.

Um mito que merece ser derrubado: a WCAG 2.2, publicada em outubro de 2023, acrescentou orientações sobre a aparência do foco, mas deixou os mínimos de contraste intactos. As versões posteriores apenas adicionam critérios de sucesso, em vez de reescrever os já existentes, com o 4.1.1 Parsing sendo a única exceção — portanto, 4,5:1 / 3:1 / 7:1 se mantiveram estáveis nas versões 2.0, 2.1 e 2.2. O baixo contraste continua sendo o defeito de acessibilidade mais comum da web. O relatório WebAIM Million de 2026 encontrou texto com baixo contraste em 83,9% do primeiro milhão de páginas iniciais.

Como verificar o contraste de cores?

O fluxo de trabalho mais rápido é: obtenha os dois valores hexadecimais renderizados, cole-os em um verificador e leia o resultado (aprovado/reprovado). Capture a cor renderizada, não o valor do seu arquivo de design: sobreposições, gradientes e transparência alteram o que o usuário efetivamente vê.

• WebAIM Contrast Checker: cole os hexadecimais do primeiro plano e do fundo. Você recebe a razão mais cinco veredictos, já que texto normal e texto grande são avaliados em AA e AAA, e elementos não textuais têm sua própria linha de AA. Se o par não atingir o limite, os controles deslizantes de Lightness permitem ajustar qualquer uma das cores até que ela passe, conforme mostra o tutorial da WebAIM sobre a ferramenta.
• TPGi Colour Contrast Analyser: um aplicativo desktop para Windows e macOS. Escolha qualquer cor diretamente da tela com seus conta-gotas, digite valores em hexadecimal, RGB, HSV ou HSL, defina um valor de alfa no primeiro plano e arraste os controles deslizantes até que um par reprovado passe. Ele também prevê como suas cores aparecem sob oito configurações de deficiência visual.
• Chrome DevTools: inspecione o elemento, abra o Color Picker a partir da amostra ao lado da declaração color e expanda a seção Contrast ratio. Ele informa se o par atinge AA e AAA, oferece um botão Use suggested color que aplica um valor aprovado e desenha os limites de AA e AAA como linhas na pré-visualização de tonalidades, para que você possa arrastar o seletor abaixo delas manualmente.
• Firefox: abra o DevTools → o painel Accessibility → selecione um nó → leia seu contraste e o resultado de aprovação/reprovação.

Para auditorias de páginas inteiras, execute o WAVE, o axe DevTools ou o Lighthouse. O WAVE lê as cores de texto e de fundo nos seus estilos e detecta a maior parte do texto corrido que fica abaixo da linha de 4,5:1 do AA, aplicando o limite menor de 3:1 ao texto grande. O que ele não consegue avaliar é texto sobre imagens, composição com alfa ou estados de hover e foco — portanto, verifique manualmente os componentes importantes.

Falhas Comuns de Contraste e Como Corrigi-las

A maioria das falhas se resume a um punhado de reincidentes, com correções rápidas e verificáveis.

Texto cinza-claro sobre branco. #767676 sobre branco é o cinza mais claro que ainda atinge o AA com 4,5:1, enquanto #999 alcança apenas 2,85:1 e reprova. Escureça o texto corrido para #595959, que atinge exatamente 7:1 e passa tanto em AA quanto em AAA.

/* FAIL: ~2.85:1 */  color: #999999; background: #fff;
/* PASS: 7:1 */      color: #595959; background: #fff;

Texto de placeholder. Definir placeholders com 40–50% de opacidade é a causa mais comum de uma falha no critério 1.4.3, porque o fundo transparece e puxa a razão para baixo de 4,5:1. Em vez disso, atribua a eles um valor hexadecimal real de #767676 ou mais escuro. E use um <label> persistente para qualquer informação que o usuário precise ler, já que os placeholders desaparecem ao digitar.

Links identificados apenas pela cor. Adicione text-decoration: underline para que o link não seja distinguido apenas pela matiz. Se você remover o sublinhado, assume um requisito adicional: o texto do link passa a precisar de 3:1 em relação ao texto corrido ao redor, além dos 4,5:1 que ambas as cores devem ter em relação ao fundo.

Texto sobre imagens. A luminância varia ao longo de uma foto, então o mesmo texto passa em uma área e reprova em outra. Adicione uma camada semitransparente (scrim):

.hero {
  background:
    linear-gradient(rgba(0,0,0,.6), rgba(0,0,0,.6)),
    url("hero.jpg");
}
.hero-text { color: #fff; } /* now has guaranteed contrast */

Além do Texto: Componentes de Interface, Foco e Uso da Cor

As regras de contraste vão além dos parágrafos. O critério de sucesso 1.4.11 estabelece um piso de 3:1 para controles e para as partes de um gráfico que o leitor precisa enxergar para acompanhar o conteúdo, medido em relação a qualquer cor que esteja adjacente a eles. Bordas de campos de entrada, contornos de botões, ícones que carregam significado e séries de gráficos se enquadram nessa regra. Os estados também contam, com uma ressalva: o estado padrão precisa de 3:1 e nenhum estado pode reduzir o componente abaixo disso, mas um efeito de hover que você adiciona por cima não está, ele próprio, sujeito ao limite de 3:1, desde que não elimine o contraste que o controle já possuía.

Os indicadores de foco são onde a numeração da especificação costuma se confundir, então vale mapeá-los com precisão. A visibilidade do foco é o critério 2.4.7 Focus Visible. O contraste de 3:1 para o indicador vem do 1.4.11 Non-text Contrast, e não do 2.4.11, que é Focus Not Obscured (Minimum) e trata de sobreposições que ocultam um elemento em foco. O critério de nível AAA 2.4.13 Focus Appearance acrescenta, além disso, exigências de tamanho mínimo e de contraste na mudança de estado.

Por fim, o WCAG 1.4.1 Use of Color (Nível A) determina que a cor sozinha nunca pode carregar significado: acompanhe um status vermelho/verde com um rótulo de texto ou ícone, e dê sublinhado aos links. Uma isenção a lembrar: componentes inativos (desabilitados) estão excluídos dos mínimos de contraste, textual e não textual, mas mantê-los legíveis ainda é uma experiência de uso melhor do que esmaecê-los até a invisibilidade.

Incorpore o Contraste ao Seu Fluxo de Trabalho

Detecte problemas de contraste antes que eles cheguem à produção. Verifique durante o design com um plugin como o Stark dentro do Figma e, depois, registre os resultados em uma camada de tokens que documente a razão de cada cor:

:root {
  --text-primary:   #171717; /* 18.8:1 — headings, body */
  --text-secondary: #595959; /* 7:1  — secondary text */
  --border-input:   #767676; /* 4.5:1 — meets 1.4.11 */
  --border-subtle:  #d4d4d4; /* 1.6:1 — decorative only */
}

O texto corrido deve ficar bem acima do mínimo (10:1 ou mais é confortável), enquanto textos secundários e grandes podem se manter em 4,5:1 e as bordas em 3:1. Teste para daltonismo em Chrome DevTools → Rendering → Emulate vision deficiencies para confirmar que o significado sobrevive sem a cor. Depois, automatize: execute o axe ou o Lighthouse na CI para que uma regressão de contraste quebre o build em vez de chegar aos usuários. E dê ao modo escuro sua própria verificação: inverter a luminância quebra razões que passavam no modo claro, então recalcule cada token por tema.

O contraste é um dos problemas de acessibilidade mais baratos de corrigir e um dos mais fáceis de prevenir. Escolha um verificador, defina seus limites como tokens, conecte uma varredura automatizada à CI, e as falhas acima deixarão de ir para produção. Comece hoje auditando o texto corrido e os estilos de foco atuais em relação às linhas de 4,5:1 e 3:1.

Perguntas Frequentes

O contraste da WCAG mede matiz e saturação, ou apenas luminosidade?

A razão de contraste mede apenas a luminância relativa, o brilho percebido de cada cor, e não a matiz ou a saturação. É por isso que duas cores que parecem diferentes, como texto vermelho sobre fundo verde, ainda podem reprovar se suas luminâncias forem próximas. A razão é calculada como (L1 + 0,05) / (L2 + 0,05) a partir dos valores de luminância mais claro e mais escuro, de modo que o significado transmitido apenas pela matiz é regido separadamente pelo critério WCAG 1.4.1 Use of Color.

Qual é a diferença entre o WCAG 1.4.11 Non-text Contrast e o 2.4.11 Focus Not Obscured?

O WCAG 1.4.11 Non-text Contrast (Nível AA) exige uma razão de contraste de 3:1 para componentes de interface e gráficos significativos, incluindo o indicador de foco, em relação às cores adjacentes. Já o WCAG 2.4.11 Focus Not Obscured (Minimum, Nível AA), novo na WCAG 2.2, não tem relação com contraste: ele exige que um elemento em foco não fique totalmente oculto por conteúdo criado pelo autor, como cabeçalhos fixos ou sobreposições. Contraste é 1.4.11; visibilidade diante de obstruções é 2.4.11.

Por que o mesmo texto passa no contraste do meu arquivo de design, mas reprova no navegador?

Os plugins de arquivos de design verificam os valores de cor planos que você atribui, mas os navegadores compõem o resultado renderizado. Opacidade, sobreposições semitransparentes, gradientes, imagens de fundo e modos de mesclagem alteram a luminância real que o usuário enxerga. Um placeholder definido com 50 por cento de opacidade ou um texto sobre uma foto pode passar no mockup e reprovar depois de renderizado. Sempre capture o hexadecimal renderizado no DevTools ou com uma ferramenta conta-gotas de tela, em vez de confiar na cor de origem.

Botões desabilitados e controles inativos precisam atender aos mínimos de contraste da WCAG?

Não. O WCAG 1.4.3 Contrast (Minimum) isenta explicitamente componentes de interface inativos, e elementos desabilitados também estão excluídos do requisito de contraste não textual 1.4.11. Isso significa que um botão desabilitado esmaecido não reprovará em uma auditoria automatizada de contraste. Manter controles desabilitados legíveis continua sendo melhor em termos de usabilidade, já que controles totalmente invisíveis confundem os usuários, mas isso não é um requisito de conformidade com a WCAG para esse estado.