Como auditar contraste de cores sem instalar nada

Auditorias de contraste de cores muitas vezes são tratadas como uma tarefa especializada de acessibilidade: abrir um arquivo de design, instalar um plugin, exportar capturas de tela, executar um relatório, discutir sobre cores da marca. Isso pode ser útil, mas não é por onde a maioria das equipes deveria começar.

Para um site em produção, a auditoria confiável mais rápida geralmente é feita no navegador que você já tem aberto. DevTools de navegadores modernos conseguem inspecionar cores computadas, mostrar relações de contraste, revelar estilos de estado e ajudar você a testar os casos incômodos que relatórios automatizados deixam passar.

Este guia parte do princípio de que você não vai instalar nada. Sem extensões de navegador. Sem plugins de design. Sem suíte de auditoria paga. Apenas a página, o navegador e um método simples.

As regras de contraste de que você realmente precisa

Para a maioria dos trabalhos na web, o contraste segundo a WCAG se resume a alguns limites:

• Texto normal: contraste de pelo menos 4.5:1 em relação ao fundo.
• Texto grande: pelo menos 3:1. A WCAG define isso como aproximadamente 24 pixels CSS, ou cerca de 18.66 pixels CSS se estiver em negrito.
• Componentes de UI e objetos gráficos: pelo menos 3:1 para contornos significativos, ícones, estados e partes de gráficos necessárias para entender a interface.
• Contraste aprimorado: 7:1 para texto normal e 4.5:1 para texto grande se você estiver mirando além da linha de base.

Há exceções, como controles inativos, elementos decorativos e logotipos. Use essas exceções com moderação. “Faz parte da marca” não é uma exceção; é uma restrição de design.

Lembre também que contraste é apenas uma parte do uso acessível de cores. Se um estado de erro em vermelho tem contraste suficiente, mas não tem texto, rótulo de ícone ou indicação programática, ele ainda pode falhar para usuários que não conseguem distinguir o vermelho de cores próximas.

Comece pela página renderizada, não pelo arquivo de design

Arquivos de design são úteis, mas não incluem todas as variáveis do mundo real: sobrescritas de CSS, opacidade, estados de hover, renderização de fonte pelo navegador, zoom do usuário, modo escuro, estilos herdados, conteúdo de CMS e incorporações de marketing.

Audite a página como os usuários a recebem.

Abra a página em um navegador desktop atual. Chrome, Edge, Firefox e Safari têm ferramentas de inspeção úteis. Os rótulos exatos variam, mas o fluxo de trabalho é o mesmo:

1. Clique com o botão direito no texto ou elemento de UI.
2. Escolha Inspecionar.
3. Encontre os valores computados de color e background-color.
4. Use a amostra de cor do navegador ou o painel de acessibilidade para ler a relação de contraste.
5. Registre aprovação, falha e incerteza.

Em navegadores baseados em Chromium, o seletor de cores frequentemente mostra uma relação de contraste e orientação de aprovação/falha da WCAG para texto. O Firefox DevTools também expõe informações de acessibilidade e ferramentas de cor. O Web Inspector do Safari consegue mostrar estilos computados e informações de acessibilidade, embora o fluxo seja um pouco diferente.

O ponto principal não é o navegador específico. O ponto principal é ler o resultado computado, não o valor que alguém acha que o componente usa.

Monte uma pequena lista de auditoria primeiro

Não inspecione textos aleatórios até se cansar. Faça um inventário curto de padrões:

• Texto de corpo no fundo principal da página.
• Texto atenuado, legendas, metadados e placeholders.
• Links nos estados normal, hover, visitado e foco.
• Botões primários, secundários e destrutivos.
• Rótulos de formulário, texto de ajuda, erros e mensagens de sucesso.
• Itens de navegação, breadcrumbs e abas.
• Cards, badges, pills e tags.
• Ícones que comunicam significado.
• Gráficos, mapas, barras de progresso e cores de status.
• Texto sobre imagens, vídeo, gradientes ou sobreposições translúcidas.

Isso é suficiente para encontrar a maioria das falhas em um site típico. Também mantém a auditoria ligada a componentes, não a pixels isolados.

Se sua auditoria inclui botões, combine a verificação de contraste com os fundamentos em nossa checklist de botões web acessíveis. Problemas de contraste em botões muitas vezes aparecem ao lado de estados de foco ausentes, rótulos pouco claros ou comportamento de teclado quebrado.

Inspecione contraste de texto no DevTools

Para texto simples sobre um fundo sólido, o navegador geralmente consegue calcular o contraste para você.

Inspecione o elemento e procure a propriedade color. Abra o seletor de cores a partir da amostra. Se o navegador conseguir determinar o fundo, ele mostrará uma relação de contraste. Algumas ferramentas também desenham uma linha no seletor de cores indicando onde a cor passaria em 3:1, 4.5:1 ou 7:1.

Quando o navegador relatar uma falha, acredite nele até conseguir provar o contrário. Quando ele relatar aprovação, ainda assim use julgamento. Tipos pequenos e finos, telas de baixa qualidade, anti-aliasing pesado e fundos carregados podem fazer um texto tecnicamente aprovado parecer fraco.

Uma regra prática: se o texto de corpo passa por pouco em 4.55:1, não comemore. Dê mais margem. Requisitos de contraste são mínimos, não metas ideais.

Tipografia também importa. Um sistema tipográfico maior e mais claro reduz o esforço antes mesmo de você recorrer a ajustes de cor. Se a página parece difícil de ler apesar de passar no contraste, reavalie comprimento de linha, tamanho, peso e espaçamento com uma lente mais ampla de legibilidade, como este guia prático para tipografia legível.

Verifique o fundo real, incluindo opacidade

Muitos erros de contraste acontecem porque o fundo visível não é o fundo declarado.

Armadilhas comuns incluem:

• Texto dentro de um card semitransparente.
• Texto em um elemento pai com opacity aplicada.
• Sobreposições usando rgba() ou color-mix().
• Gradientes atrás de títulos.
• Imagens de fundo que variam ao longo da área do texto.
• Variáveis de tema que mudam no modo escuro.

Se o DevTools não conseguir calcular o contraste com confiança, identifique manualmente as cores renderizadas de primeiro plano e fundo. Use o painel de estilos computados, desative camadas temporariamente ou amostre a cor visível com o seletor de cores integrado, se seu navegador oferecer suporte.

Para texto sobre imagens, não amostre a parte mais favorável da imagem. Amostre a pior área plausível atrás do texto. Se a imagem muda por uploads no CMS, carrosséis ou recortes responsivos, isso não é um sistema de contraste estável. Adicione uma sobreposição confiável, sombra de texto, contêiner sólido ou tratamento em gradiente que proteja o texto independentemente da imagem.

Um bom sistema de sobreposição de imagem é sem graça: mesma intensidade de sobreposição, área de recorte previsível, contraste suficiente mesmo com fotos claras. Sem graça está ótimo. Os usuários estão tentando ler.

Não esqueça os estados

Capturas de tela estáticas deixam passar muitas falhas de contraste. Audite estados de interação diretamente no navegador.

No DevTools, force pseudoclasses como:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Depois inspecione as cores computadas novamente.

Indicadores de foco merecem atenção especial. A WCAG 2.2 reforçou expectativas sobre aparência de foco, e um contorno azul claro em um card cinza claro ainda é uma falha comum. O indicador de foco precisa ter contraste suficiente em relação às cores adjacentes e área suficiente para ser perceptível.

Para controles desativados, as regras de contraste da WCAG têm uma exceção para componentes inativos. Isso não significa que controles desativados devam ser ilegíveis por padrão. Se o estado desativado carrega informação útil, torne-o legível. Se não carrega, considere se ele deveria estar presente.

Use o Lighthouse, mas não terceirize seu julgamento para ele

Auditorias de navegador como o Lighthouse conseguem capturar rapidamente algumas falhas de contraste. Execute a auditoria integrada se seu navegador a oferecer, depois trate os resultados como ponto de partida.

Verificações automatizadas são boas para encontrar nós de texto com falhas óbvias de contraste computado. Elas são mais fracas em:

• Texto incorporado em imagens.
• Rótulos renderizados em canvas.
• Casos extremos de SVG.
• Falhas que aparecem apenas em hover.
• Qualidade do indicador de foco.
• Gráficos em que relações de cor carregam significado.
• Componentes escondidos atrás de autenticação, menus ou etapas de formulário.

Se um relatório voltar verde, você ainda precisa inspecionar componentes representativos. Se um relatório voltar vermelho, evite pânico e faça a triagem das falhas por impacto no usuário. O mesmo princípio se aplica a relatórios de desempenho e acessibilidade em geral: leia a saída da ferramenta como evidência, não como veredito. Usamos essa mentalidade em nosso guia para ler um relatório do Lighthouse sem entrar em pânico, e ela se aplica muito bem aqui.

Audite também o contraste não textual

Texto recebe a maior parte da atenção, mas a WCAG também cobre conteúdo não textual necessário para entender ou operar a interface.

Verifique pelo menos estes casos:

• Bordas de campos em relação ao fundo da página.
• Contornos de checkbox e radio.
• Estados de toggle.
• Botões apenas com ícone.
• Ícones de erro e símbolos de aviso.
• Linhas, barras e rótulos de gráficos.
• Indicadores de progresso.
• Indicadores de aba selecionada ou navegação ativa.

A meta geralmente é 3:1 em relação às cores adjacentes. Por exemplo, uma borda cinza-clara de campo sobre fundo branco pode ficar quase invisível. Um gráfico com cinco linhas em tons pastel pode parecer elegante e ainda assim ser inutilizável.

Para gráficos, contraste não basta por si só. Use rótulos, padrões, estilos de linha, anotação direta ou espaçamento para que a informação não dependa apenas de cor. Isso ajuda usuários daltônicos, usuários com baixa visão, pessoas visualizando sob reflexo e qualquer pessoa lendo uma captura de tela em um documento.

Registre descobertas em um formato que desenvolvedores consigam usar

Uma auditoria de contraste útil não diz “alguns cinzas falham”. Ela identifica o componente, o estado, os valores atuais, o limite esperado e a correção sugerida.

Um formato compacto funciona bem:

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | Metadados do card | Padrão | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Falha | Use --color-text-muted-strong | | Botão primário | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Aprovado | Manter | | Borda do campo | Padrão | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Falha | Escurecer o token de borda |

Vincule correções a design tokens se o site os tiver. Não remende vinte componentes individuais se um token fraco é o problema real.

Faça correções um pouco mais fortes que o mínimo

Falhas de contraste muitas vezes são fáceis de corrigir mal. Equipes ajustam uma cor até o verificador dizer 4.51:1 e seguem em frente. Isso não deixa margem para renderização de fonte, transparência, diferenças entre navegadores, temas, variação de imagem ou futuras alterações de marca.

Prefira metas confortáveis:

• Texto de corpo: mais perto de 7:1 quando for prático.
• Texto atenuado: ainda acima de 4.5:1 se for conteúdo real.
• Bordas e ícones de UI: confortavelmente acima de 3:1.
• Texto sobre imagens: use uma sobreposição controlada em vez de estimativas por imagem.

A web é vista em laptops baratos, celulares com brilho baixo, calçadas iluminadas, monitores com tonalidade e telas envelhecidas. Conformidade mínima não é o mesmo que leitura confortável.

<!-- tool-cta:start -->

💡 Experimente isto: Ao verificar pares de contraste que você extraiu do DevTools, Color Converter ajuda a converter entre hex, RGB e HSL para que os valores coincidam com suas notas de auditoria.

<!-- tool-cta:end -->

Uma checklist de auditoria de contraste sem instalação

Use esta sequência quando precisar de uma auditoria rápida, mas confiável:

1. Abra a página de produção em um navegador moderno.
2. Liste os principais padrões de texto, UI e estados.
3. Inspecione as cores computadas de primeiro plano e fundo no DevTools.
4. Use o seletor de cores integrado ou o painel de acessibilidade para ler o contraste.
5. Force estados de hover, foco, active, visited e invalid.
6. Verifique texto sobre imagens e gradientes em relação ao pior fundo plausível.
7. Verifique partes de UI não textuais em relação ao requisito de 3:1.
8. Execute uma auditoria automatizada integrada como rede de segurança, não como a auditoria inteira.
9. Registre falhas por componente e token.
10. Corrija com margem, não apenas cruzando o limite por pouco.

Isso é suficiente para capturar a maioria dos problemas de contraste sem adicionar outra ferramenta ao seu stack. Auditorias mais avançadas ainda têm seu lugar, especialmente em grandes design systems, produtos regulados ou visualizações de dados complexas. Mas, para muitos sites, o navegador já dá a você as evidências de que precisa. A parte difícil é ser sistemático o bastante para usá-las.