Contraste de cor WCAG: AA, AAA e APCA — o guia completo de 2026

Você publica um botão. Laranja da marca, texto branco, fica nítido no seu monitor 4K. Aí volta a auditoria de acessibilidade marcada em vermelho: a razão de contraste WCAG é de 1,97:1, abaixo do limite AA de 4,5:1 para corpo de texto. O botão que parecia ótimo para você fica ilegível para cerca de 220 milhões de pessoas com baixa visão no mundo todo. Este guia percorre cada número de que você precisa para resolver isso: ratios WCAG 2, o nível AAA, o algoritmo APCA Lc, oito categorias de deficiência da visão de cores e uma implementação JavaScript funcional que você pode encaixar direto no seu build.

Referência rápida: limites de WCAG e APCA num só olhar

Padrão	Texto normal	Texto grande	UI / ícones	Observações
WCAG AA	≥ 4.5:1	≥ 3:1	≥ 3:1	Mínimo legal
WCAG AAA	≥ 7:1	≥ 4.5:1	≥ 3:1	Meta reforçada
APCA corpo	Lc 75+	Lc 60+	Lc 45+ (ícones)	Rascunho, perceptual

“Texto grande” significa ≥ 18pt regular ou ≥ 14pt em negrito (≈ 24px e ≈ 18,66px em CSS). “UI” cobre bordas de formulário, anéis de foco e qualquer objeto gráfico que o usuário precise perceber para operar a página. Logos e gráficos puramente decorativos estão dispensados dos requisitos de contraste.

O que é o contraste de cor WCAG?

A razão de contraste WCAG é uma medida numérica de 1:1 (sem contraste) a 21:1 (máximo) que compara a luminância relativa do texto com seu fundo. As Web Content Accessibility Guidelines exigem ≥ 4,5:1 (AA) para corpo de texto ou ≥ 7:1 (AAA) para conformidade reforçada.

Essa razão guia a maior parte das auditorias de acessibilidade do mundo. O W3C publicou-a na WCAG 2.0 em 2008, refinou-a na 2.1 (2018) e na 2.2 (2023), e todo grande regulador hoje aponta para ela. A ADA nos Estados Unidos, o European Accessibility Act (em vigor desde junho de 2025), a Section 508 para órgãos federais norte-americanos e a AODA do Canadá adotam a WCAG 2.x AA como piso.

Por que isso importa além do ângulo legal? Cerca de 220 milhões de pessoas no mundo têm baixa visão sem serem cegas; elas leem telas, mas só quando o contraste entre tipo e fundo é alto o suficiente. Cerca de 8% dos homens e 0,5% das mulheres têm alguma deficiência da visão de cores. Leitores mais velhos passam a ter o cristalino amarelado e a pupila menos aberta, o que reduz o contraste percebido em 20–30% depois dos 60 anos. O uso de smartphone ao ar livre tira outros 20–40% por causa do reflexo. Uma página que marca 4,5:1 na sua mesa é o piso em que todos esses usuários ainda conseguem ler.

Quem mais precisa se importar: engenheiros front-end que publicam UI em produção, designers escolhendo paletas de marca, especialistas em acessibilidade rodando auditorias e times de compliance responsáveis pelo risco jurídico. A matemática é curta; as decisões que ela impõe, nem tanto.

Razão de contraste WCAG 2.x: a matemática, os limites

O W3C define contraste em três passos curtos. Para calcular a razão de contraste WCAG: (1) converta cada cor de sRGB com gama aplicada para valores de luz linear, (2) calcule a luminância relativa usando coeficientes fixos para a sensibilidade do olho humano ao vermelho, verde e azul, e (3) divida as duas luminâncias com um pequeno deslocamento constante para tratar valores próximos do preto.

A fórmula de luminância relativa do WCAG 2.1 §1.4.3 é:

L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin

R_lin, G_lin e B_lin são os valores do canal em luz linear depois de desfazer a curva de gama do sRGB. O peso de 0,7152 no verde reflete a forte sensibilidade do olho humano a esse canal: por unidade de energia luminosa, o verde é cerca de 7× mais ruidoso visualmente do que o azul.

A fórmula da razão é:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

O +0,05 evita a divisão por zero quando temos preto puro (L = 0) e gera um máximo de (1 + 0,05) / (0 + 0,05) = 21:1 para branco puro sobre preto puro. O mínimo é 1:1, ou seja, cores idênticas.

Aqui está a implementação completa em cerca de trinta linhas de JavaScript puro. Sem dependências, roda em qualquer lugar:

// hex sRGB → canal em luz linear
function srgbToLinear(channel8bit) {
  const v = channel8bit / 255;
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

// "#RRGGBB" → luminância relativa [0, 1]
function relativeLuminance(hex) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return (
    0.2126 * srgbToLinear(r) +
    0.7152 * srgbToLinear(g) +
    0.0722 * srgbToLinear(b)
  );
}

// Razão de contraste WCAG 2.x entre duas cores hex
function contrastRatio(hexA, hexB) {
  const lA = relativeLuminance(hexA);
  const lB = relativeLuminance(hexB);
  const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
  return (lighter + 0.05) / (darker + 0.05);
}

// Exemplo: corpo de texto cinza-ardósia escuro sobre branco
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58" — bem acima do AA 4.5:1 e logo acima do AAA 7:1

Cole dois códigos hex no Conversor de Cores e os mesmos números voltam, lado a lado com o valor APCA Lc, uma classificação de gamut e um preview de oito canais de CVD. Os limites em si são concretos:

Elemento	AA mín	AAA mín	Observações
Corpo de texto normal	4.5:1	7:1	Abaixo de 18pt regular / abaixo de 14pt negrito
Texto grande	3:1	4.5:1	≥ 18pt regular OU ≥ 14pt negrito
Componentes / ícones de UI	3:1	—	WCAG 2.1 §1.4.11, adicionado em 2018
Logos e decorativos	isentos	isentos	Sem exigência de contraste

As conversões de unidade CSS pegam muita gente desprevenida. 18pt = 24px no padrão do navegador, 14pt = 18,66px. Uma fonte de corpo de 16px (o padrão moderno) fica abaixo do limiar de “texto grande”, então cai na regra mais rigorosa de AA 4,5:1. Um título de 20px com font-weight: 700 se qualifica como grande e ganha o piso mais frouxo de 3:1.

Uma sutileza que pega os times de surpresa: a isenção de “texto grande” do WCAG é sobre legibilidade real para o usuário, não sobre semântica de cabeçalho. Um <h2> de 14px não é texto grande, e continua precisando de 4,5:1. Um parágrafo de copy de marketing com 24px é texto grande e ganha o piso de 3:1. A regra leva em conta o tamanho de pixel renderizado e o peso da fonte, jamais o nome da tag. Auditores apontam essa divergência; seu CSS é a fonte da verdade, não a semântica do HTML.

A constante +0,05 na fórmula da razão tem uma origem específica: representa o termo de flare, a luz ambiente refletida na superfície da tela que eleva a luminância aparente do preto puro até um piso mínimo. Sem ela, um pixel OLED renderizando preto verdadeiro contra branco puro daria divisão por zero. Com ela, a razão máxima possível é 21:1, número que você vai ver destacado em toda ferramenta de acessibilidade. Não há tela física que entregue mais de 21:1 depois de considerar o flare, e é por isso que a escala WCAG para por aí.

AA vs AAA: qual mirar?

AA é o piso legal; AAA é o nível aspiracional. A maior parte dos sites comerciais mira AA porque AAA força as cores da marca para o cinza-claro até passarem, e a maioria dos times de marketing recusa essa concessão. A decisão não é “mais é melhor”; é um trade-off entre alcance de usuários e expressão de marca.

Contexto	Nível recomendado	Por quê
Site comercial geral	AA	Linha de base ADA / EAA; tribunais citam WCAG 2 AA
Governo / serviços públicos	AAA	Section 508 e estatutos europeus equivalentes recomendam AAA
Saúde / educação	AAA	Base de usuários inclina-se para maior necessidade de acessibilidade
Dashboard interno	AA	Público conhecido; trade-off de ROI aceitável
Landing page de marketing	AA + exceção da marca	Cores da marca permitidas em hero/CTAs; corpo continua AA

O custo escondido do AAA aparece na primeira vez que você tenta fazer um laranja saturado da marca passar 7:1 contra o branco. Não passa. Ou você escurece o laranja até ele deixar de ser a sua marca, ou aceita AA e usa o laranja em fundos escuros, onde ele atinge AAA com folga. Muitas empresas, inclusive algumas das mais atentas à acessibilidade, miram AA explicitamente no conteúdo do corpo e só perseguem AAA em textos críticos, como mensagens de erro ou avisos legais.

Os reguladores não esperaram o AAA virar moda. A regulamentação de acessibilidade web da ADA de 2024 cita a WCAG 2.1 AA. O European Accessibility Act, em vigor desde junho de 2025, exige WCAG 2.1 AA em todos os serviços digitais cobertos. A Section 508 no governo federal dos EUA usa WCAG 2.0 AA como linha de base (com AAA recomendado quando viável). A AODA do Canadá, lei de acessibilidade de Ontário, aponta para WCAG 2.0 AA. O padrão é consistente: AA é a barra, AAA é a meta.

APCA: o novo algoritmo perceptual

O APCA (Advanced Perceptual Contrast Algorithm), criado por Andrew Somers sob o rótulo Myndex, é um algoritmo candidato para a WCAG 3. Ele substitui a razão simétrica da WCAG 2 por uma pontuação Lc com sinal de polaridade, de -108 a +108, em que o sinal indica a direção do contraste (texto escuro em fundo claro vs texto claro em fundo escuro) e a magnitude reflete o contraste percebido em uma tela emissora real.

O APCA importa porque a fórmula simétrica da WCAG 2 ignora dois efeitos do mundo real:

• Assimetria de polaridade. Texto claro em fundo escuro lê de forma diferente de texto escuro em fundo claro, mesmo com a mesma razão WCAG. A WCAG 2 devolve o mesmo número nos dois sentidos; o APCA, não.
• Modelagem do display. A fórmula da WCAG 2 foi derivada de modelos de luminância de papel impresso. O APCA foi calibrado contra displays sRGB sob iluminação típica de escritório, mais próximo do que seus usuários realmente enxergam.

O custo do troco: o APCA é mais complexo (envolve expoentes sensíveis à polaridade e ajustes por peso de fonte) e ainda não é um padrão regulatório. A análise de abril de 2026 do Adrian Roselli continua sendo o resumo mais claro de onde o APCA está hoje: tecnicamente promissor, mas a própria WCAG 3 ainda está em desenvolvimento inicial dentro da trilha Silver, e o APCA ainda não foi ratificado como algoritmo oficial.

Os limites APCA de nível Bronze (o piso prático que a maior parte dos times mira) ficam assim:

Caso de uso	Lc recomendado	Lc mínimo
Corpo de texto (16px, peso 400)	90+	75
Texto grande (24px, peso 400)	75+	60
Elementos de UI e ícones sem texto	60+	45
Texto pontual / placeholders	30+	30

O motivo de o APCA ser interessante (e o motivo de o Conversor de Cores mostrar as duas métricas lado a lado) são os casos em que ele discorda da WCAG 2:

• #FFA500 (laranja) sobre #FFFFFF: a WCAG 2 devolve 1,97:1, falha clara em AA. O APCA concorda, marcando cerca de Lc 38, também reprova. Até aqui os dois algoritmos dizem não, mas a maioria dos designers que vi continua publicando essa combinação porque “fica bonita”.
• #767676 (cinza médio) sobre #FFFFFF: a WCAG 2 devolve 4,54:1, ou seja, passa em AA 4,5:1 e fica tecnicamente aprovado. O APCA pontua esse par em aproximadamente Lc 60, abaixo do limite Bronze de 75 para corpo de texto. WCAG aprova; APCA reprova. A experiência vivida pelo usuário fica mais perto do veredicto do APCA: esse cinza sobre branco é mais difícil de ler em tamanho de corpo do que a razão sugere.
• #3b82f6 (azul-500 do Tailwind) sobre #000000: a WCAG 2 devolve 5,71:1, aprovação confortável em AA. O APCA pontua em torno de Lc 65, abaixo do mínimo Lc 75 para corpo de texto. Texto azul-claro sobre fundo escuro, padrão queridinho do modo escuro, é o caso canônico de “WCAG aprova, APCA alerta”.

Você não precisa escolher um lado. A postura pragmática a que a maioria dos times de produção chegou: mantenha WCAG 2 AA como linha de base regulatória, porque é o que as auditorias de compliance verificam, e rode APCA em paralelo como um “isso é realmente legível?” de checagem rápida, sobretudo em designs de modo escuro e cores de marca saturadas. O Conversor de Cores mostra os dois números em uma só linha para você não ficar pulando entre checkers.

Daltonismo e o que vai além do contraste

A razão de contraste é só metade da acessibilidade de cor. Cerca de 8% dos homens e 0,5% das mulheres veem cores de forma diferente do tricromata-padrão, e a variante mais comum, a deuteranomalia, fica bem no meio do par vermelho/verde que usamos por toda parte para estados de sucesso/erro. A WCAG 1.4.1 (“Uso da Cor”) proíbe explicitamente que a cor seja o único veículo de informação; é essa a regra que existe para reforçar o ponto.

A taxonomia completa das diferenças de visão de cores se divide em três grupos: dicromacia (um cone faltando), tricromacia anômala (um cone deslocado) e as raras monocromacias.

Tipo	Nome popular	Canal afetado	Prevalência (H / M)
Protanopia	Cego para vermelho	Cone L ausente	1,0% / 0,01%
Deuteranopia	Cego para verde	Cone M ausente	1,1% / 0,01%
Tritanopia	Cego para azul	Cone S ausente	0,003% / 0,003%
Protanomalia	Vermelho fraco	Cone L deslocado	1,3% / 0,02%
Deuteranomalia	Verde fraco	Cone M deslocado	5,0% / 0,4%
Tritanomalia	Azul fraco	Cone S deslocado	0,01% / 0,01%
Acromatopsia	Sem cor	Todos os cones ausentes	0,003% (muito raro)
Monocromacia de cone	Cinza parcial	Apenas um cone	0,001%

Só a deuteranomalia é 5% dos homens, um em cada vinte. É a população que vê um indicador de erro vermelho e um indicador de sucesso verde como praticamente o mesmo tom oliva-amarronzado. A correção não é redesenhar todo o sistema de cores; é adicionar um segundo canal. Um ícone vermelho de erro acompanhado de um símbolo ”×” e da palavra “Erro” sobrevive a todas as variantes da tabela. Um simples ponto vermelho, não.

Simular CVD em código usa dois conjuntos-padrão de matrizes: Brettel–Viénot–Mollon (1997) para as dicromacias e Machado–Oliveira–Fernandes (2009) para as tricromacias anômalas. A abordagem Brettel projeta a cor de entrada do usuário num plano formado pelas duas respostas de cone remanescentes; a Machado parametriza o deslocamento do cone pela gravidade. As duas dá para implementar como filtros SVG ou matrizes CSS. O Conversor de Cores traz todas as oito variantes como prévias de um clique, então você pode varrer uma cor de marca por todo o espectro sem sair da página.

Um filtro SVG curto (cole na sua página e referencie pelo ID) dá uma simulação de protanopia direto no navegador para testes ad hoc:

<svg style="display: none">
  <filter id="protanopia">
    <feColorMatrix type="matrix" values="
      0.567 0.433 0.000 0 0
      0.558 0.442 0.000 0 0
      0.000 0.242 0.758 0 0
      0.000 0.000 0.000 1 0"/>
  </filter>
</svg>

<style>
  .preview-protanopia { filter: url(#protanopia); }
</style>

Aplique .preview-protanopia no wrapper da sua página para ver o que enxerga uma pessoa com protanopia. Repita com as matrizes de deuteranopia e tritanopia (os coeficientes estão documentados no paper do Brettel e vêm embutidos na maioria das bibliotecas simuladoras de CVD). O painel Rendering do Chrome DevTools tem os mesmos simuladores incorporados em “Emulate vision deficiencies” — útil para checagens rápidas, menos útil para capturar screenshots em CI.

A regra mais profunda, além da simulação: nunca deixe a cor ser a única diferença entre dois estados. Ícones devem variar de forma (× vs ✓), estados devem ter rótulo de texto (“Erro” vs “Sucesso”), categorias devem ter padrão (sólido vs hachurado). A cor é um multiplicador desses outros sinais, não um substituto.

Existe uma classe de falhas que checkers de contraste não pegam, mas simuladores de CVD pegam. Fatias de gráfico de pizza distinguidas só por matiz, legendas de mapa que codificam países por cor, pílulas de status que dependem de um gradiente verde/amarelo/vermelho: todas elas podem passar no contraste WCAG 2 contra o fundo e mesmo assim ficar ilegíveis para uma pessoa com deuteranopia tentando lê-las umas em relação às outras. A regra é checar legibilidade entre cores adjacentes no design, não só contra a tela ao redor. Dois segmentos slate-500 lado a lado, com a mesma claridade, são indistinguíveis, independentemente da rotação de matiz. Coloque um degrau de luminância entre regiões adjacentes e o gráfico sobrevive a toda variante de CVD.

Acromatopsia e monocromacia de cone são raras, mas vale projetar explicitamente para elas porque colapsam todas as distinções de matiz. Quem tem acromatopsia percebe apenas luminância, então sua UI codificada por cor parece uma fotografia em escala de cinza. Se o seu design se sustenta quando você roda um filter: grayscale(1) sobre a página inteira (teste no DevTools), você passou na versão mais rigorosa da regra “a cor não é o único sinal”. Esse teste é simples de rodar e costuma revelar falhas que passavam despercebidas.

Auditando paletas Tailwind e Material

A maior parte do trabalho front-end usa uma paleta pré-construída: Tailwind v4, Material 3, Radix ou shadcn. A pergunta de acessibilidade passa a ser “em qual stop dessa escala o texto começa a ser legível?”, e a resposta é mais regra de bolso do que a documentação admite.

Para a escala slate do Tailwind v4 contra branco puro, os números WCAG e APCA caem assim:

Classe Tailwind	Hex aprox.	WCAG vs branco	AA corpo	AAA corpo	APCA Lc (aprox.)
slate-400	#94a3b8	2.56:1	✗	✗	~38 ✗
slate-500	#64748b	4.76:1	✓	✗	~60 ✗ corpo
slate-600	#475569	7.58:1	✓	✓	~78 ✓ corpo
slate-700	#334155	10.35:1	✓	✓	~90 ✓ corpo

As regras práticas que saem daí:

• Corpo de texto precisa de slate-600 ou mais escuro. Slate-500 passa em WCAG AA mas reprova no limiar de corpo do APCA, ou seja, é compliance, mas desconfortável. Slate-600 é o piso seguro.
• Rótulos de UI e texto secundário podem usar slate-500. Componentes de UI só precisam de 3:1; o 4,76:1 do slate-500 é confortável, e o texto em geral carrega contexto visual de apoio.
• Placeholders devem usar slate-400 ou mais claro. Texto de placeholder é isento da WCAG 1.4.3 como decorativo somente se você mantiver um rótulo visível acima do campo. Padrões de “rótulo embutido como placeholder” precisam atingir o limiar de corpo de texto.
• Preto puro sobre slate-100 / slate-200 é tinta desperdiçada. Você está em 17:1+; considere usar slate-700 ou slate-800 como cor de texto para um toque mais suave sem perder legibilidade.

O Material 3 usa uma estrutura tonal de paleta parecida. Seu surface-container-high fica em torno do tom 92 (muito claro); o on-surface fica em torno do tom 10 (quase preto). O contraste entre qualquer on-surface e qualquer token surface-* da mesma família é garantido pelo spec do Material para passar em AA. Não combine on-surface-variant (tom 30) com surface-container (tom 94) sem checar — esse é um erro do mundo real que já vi ir para produção.

Se você tem uma paleta existente que reprova no contraste, o OKLCH oferece o caminho de correção mais limpo. Em vez de empurrar códigos hex no escuro, converta sua cor para OKLCH, mantenha C (croma) e H (matiz) fixos e reduza L (luminosidade) até o contraste passar. Como o canal L do OKLCH é perceptual, o reconhecimento da marca permanece intacto enquanto o contraste melhora. A ferramenta HEX para OKLCH faz essa conversão em um passo; o artigo irmão OKLCH explicado cobre a matemática a fundo.

Modo escuro merece um parágrafo só dele. A razão simétrica da WCAG 2 aprova, por definição, as mesmas combinações em modo claro e modo escuro. O APCA, por ser sensível à polaridade, frequentemente sinaliza que o corpo de texto em modo escuro é mais difícil de ler do que o mesmo par hex seria em modo claro. Claro-sobre-escuro sempre perde algum contraste percebido em relação a escuro-sobre-claro na mesma razão numérica; é um efeito conhecido de como o olho se adapta. Reaplique o APCA em cada par de modo escuro antes de publicar.

Checkers de contraste e fluxos de CI

Designers e engenheiros têm cada um seu checker favorito; a pergunta prática é qual combinação de ferramentas você costura num fluxo real. Aqui está o cenário em 2026:

Ferramenta	WCAG 2	APCA	Sim. CVD	Auditoria de paleta
WebAIM Contrast Checker	✓	✗	✗	✗
Adobe Color	✓	✗	✓	✓
Stark (plugin do Figma)	✓	✓	✓	✓
Polypane (navegador)	✓	✓	✓	✓
Color picker do Chrome DevTools	✓	✓ (exp.)	✗	✗
axe DevTools	✓	✗	✗	✓ (nível de página)
Conversor de Cores Go Tools	✓	✓	✓ (8 tipos)	✓ (Tints/Shades)

Um fluxo que aguenta a pressão real de produto se parece com isto:

1. No Figma, designers rodam o Stark em cada frame para identificar pares reprovados cedo. O Stark pega os ofensores óbvios antes que qualquer código hex chegue ao codebase.
2. No handoff do código hex, engenheiros colam o valor no Conversor de Cores e recebem razão WCAG + Lc APCA + classificação de gamut + preview de CVD em uma só linha. Se o par é de modo escuro ou de marca saturada, a métrica dupla pega os casos “WCAG passa mas APCA reprova” que o Stark pode deixar escapar.
3. No momento do PR, o axe-core/playwright varre as páginas construídas em busca de qualquer violação de contraste no DOM renderizado, incluindo estados dinâmicos. Isso pega anéis de foco, estados de hover e botões desabilitados que arquivos de design estáticos não veem.
4. No QA, o Rendering do Chrome DevTools simula protanopia/deuteranopia/tritanopia para checagens pontuais em fluxos críticos. O Color Picker do DevTools também mostra uma razão WCAG inline quando você passa o mouse sobre qualquer elemento.

Pa11y, Lighthouse CI e @axe-core/playwright expõem todos assertions de contraste como parte de suas auditorias de acessibilidade mais amplas. Nenhum deles checa APCA hoje; todos checam WCAG 2. O acordo realista é “force WCAG 2 AA no CI, faça sanity-check de APCA Lc manualmente em cores de marca e modo escuro”.

Um padrão que vale roubar de times maiores de design system: cole a checagem de contraste no passo de validação de tokens, não só no QA em nível de página. Se seus design tokens compilam a partir de um arquivo-fonte (JSON, YAML ou um módulo TypeScript), adicione um script que enumere cada pareamento --text-* × --surface-* que o sistema permite e exija uma razão WCAG mínima. O script roda em milissegundos, pega regressões quando alguém mexe num valor de token e produz uma matriz de contraste que serve como documentação para o time de design. A checagem é independente de qualquer página renderizada: opera puramente sobre os tokens, então pega a falha antes que qualquer UI saia.

Para conversões ad hoc durante esse fluxo, alternando entre hex, RGB, HSL e OKLCH enquanto você depura, os spokes HEX para RGB, HEX para HSL, HEX para OKLCH e RGB para HEX cobrem ida e volta entre qualquer formato de cor que sua toolchain espere.

Erros comuns e como corrigir

Depois de anos de auditorias de acessibilidade, as mesmas seis falhas continuam aparecendo. Cada uma tem uma correção objetiva:

1. Placeholder em cinza claro. #999999 sobre branco dá 2,85:1, reprova em AA. Ou aprofunde para #666666 (5,74:1, passa em AA), ou, melhor, substitua o padrão de placeholder-como-rótulo por um rótulo visível persistente acima do campo. Placeholders não devem carregar informação.

2. Botão laranja da marca com texto branco. #FFA500 sobre branco dá 1,97:1, reprova feio em AA. A correção que preserva a marca é inverter a direção do contraste: texto escuro (por exemplo #451a03) sobre o fundo laranja, ou manter o texto branco e escurecer o botão para um marrom-laranja profundo e saturado. Confira no Conversor de Cores antes de publicar.

3. Link azul brilhante em modo escuro. #3b82f6 sobre #000000 dá 5,71:1 e aprova em WCAG AA, mas APCA Lc ~65, abaixo do limiar Lc 75 para corpo. Recorra ao OKLCH e suba L de ≈ 0,63 para 0,75, mantendo C e H fixos; você vai cair perto de #7aa5f8 com um APCA Lc confortável de 80+ e o mesmo matiz.

4. Texto desabilitado em #CCCCCC. 1,61:1 contra branco. A WCAG 1.4.3 isenta texto puramente decorativo da regra de razão, mas controles de UI desabilitados não são decorativos: eles comunicam “isto está indisponível no momento”. Combine a cor apagada com uma pista não cromática (riscado, ícone de cadeado, tooltip “Desabilitado”) para que uma pessoa com CVD ou baixa visão ainda entenda o estado.

5. Ícones de status que diferem só no matiz. Um × vermelho e um ✓ verde está ok porque a forma já os distingue. Um ponto vermelho vs um ponto verde, não. Use forma e cor juntos: o preview de CVD do Conversor de Cores deixa o caso de falha óbvio em um segundo.

6. Texto sobre fundo em gradiente. Um gradiente que vai de #3b82f6 a #a78bfa contra texto branco passa no contraste no meio e reprova perto da ponta lavanda. A correção é exigir o contraste contra o pior ponto do gradiente, ou sobrepor um scrim escuro semitransparente para que a luminância de fundo efetiva fique sempre abaixo de um limite conhecido.

Cada correção leva minutos; o ciclo de auditoria que elas evitam leva semanas.

FAQ

O que é a razão de contraste WCAG AA?

WCAG AA exige ≥ 4,5:1 entre corpo de texto e fundo, ou ≥ 3:1 para texto grande (≥ 18pt regular ou ≥ 14pt em negrito) e componentes de UI como bordas de formulário. AA é a linha de base legal sob ADA, EAA e Section 508; a maioria dos sites comerciais mira AA porque cobre o requisito regulatório sem empurrar as cores da marca para o cinza.

Qual razão de contraste preciso para AAA?

WCAG AAA exige ≥ 7:1 para corpo de texto normal e ≥ 4,5:1 para texto grande. AAA é recomendado para sites de saúde, educação e governo, onde a base de usuários inclina-se para maior necessidade de acessibilidade. Cores de marca quase sempre precisam ser achatadas para valores próximos do cinza para passar em AAA, e é por isso que muitos produtos comerciais param em AA.

O que é o APCA e ele é WCAG 3.0?

APCA (Advanced Perceptual Contrast Algorithm), desenhado por Andrew Somers / Myndex, é um algoritmo candidato dentro do projeto Silver da WCAG 3. Ele usa pontuações Lc sensíveis à polaridade, de -108 a +108, em vez de razões simétricas. Em 2026 a WCAG 3 ainda está em rascunho inicial e o APCA não foi formalmente ratificado; WCAG 2.1 / 2.2 AA continua sendo o padrão regulatório que você precisa atingir hoje.

Modo escuro ajuda na acessibilidade do contraste?

Às vezes, mas não automaticamente. A razão simétrica da WCAG 2 aprova as mesmas combinações em modo claro e modo escuro, mas o APCA (que é sensível à polaridade) frequentemente sinaliza corpo de texto em modo escuro como mais difícil de ler do que o mesmo par hex em modo claro. Sempre retest modo escuro contra WCAG e APCA antes de publicar; claro-sobre-escuro perde contraste percebido de um jeito que a razão simétrica não enxerga.

Por que a cor da minha marca reprova em WCAG AA?

Cores saturadas de luminância média (a maioria dos laranjas, amarelos, verdes-limão, azuis-claros) têm valores de luminância relativa próximos demais do branco para passar em 4,5:1. A correção: mantenha o matiz da marca para acentos e títulos grandes, mas combine o corpo de texto com um tom mais escuro da mesma família de matiz. Use OKLCH para baixar o canal L sem deslocar o matiz; o Conversor de Cores acha o tom aprovado mais próximo em um passo.

Razões WCAG 2 e pontuações APCA são compatíveis?

Não. WCAG 2 devolve uma razão simétrica (1–21); o APCA devolve uma pontuação Lc com sinal de polaridade (-108 a +108). A relação é não linear: um par que dá 4,5:1 no WCAG pode pontuar Lc 60 ou Lc 75 no APCA dependendo de qual cor fica por cima. Trate-os como duas checagens independentes, não como traduções uma da outra.

Posso usar contraste de cor para ícones pequenos de UI?

Sim, com ressalvas. A WCAG 2.1 §1.4.11 exige ≥ 3:1 para componentes de UI e objetos gráficos. Para ícones decorativos acompanhados de um rótulo de texto visível, os requisitos de contraste afrouxam — o rótulo carrega o significado. Para ícones isolados (uma lupa de busca sem rótulo, por exemplo), exija o 3:1 completo contra o fundo ao redor.

Como testar daltonismo sem simular?

Use Chrome DevTools → Rendering → “Emulate vision deficiencies” para protanopia, deuteranopia, tritanopia e acromatopsia. Combine com o preview de 8 tipos de CVD do Conversor de Cores para as variantes de tricromacia anômala (deuteranomalia é a mais comum, em 5% dos homens). Para relatórios de auditoria, capture screenshots sob cada simulação para que revisores vejam os modos de falha inline.

Conclusão

Cinco pontos carregam o guia inteiro:

• AA 4,5:1 é o piso legal. Atinja em todo corpo de texto ou conte com ruído de compliance.
• AAA 7:1 é para saúde, educação e governo. A maioria das marcas comerciais para em AA por opção.
• APCA Lc é o sanity check da legibilidade real. Rode em paralelo com WCAG 2, principalmente em modo escuro e cores de marca saturadas.
• A cor nunca é o único sinal. Combine cada pista cromática com forma, texto ou padrão; só a deuteranomalia é 5% dos usuários homens.
• L do OKLCH é o botão certo. Quando uma cor reprova no contraste, reduza L (não S, não B) para consertar sem deslocar o matiz.

Cole dois códigos hex no Conversor de Cores para ver razão WCAG, Lc APCA, classificação de gamut e o preview de 8 tipos de CVD lado a lado. Essa única tela cobre o que costuma exigir várias ferramentas separadas e fecha as auditorias que este guia descreve.