Uma landing page criada por IA pode usar a paleta pedida e ainda esconder conteúdo. Texto cinza sobre fundo escuro, botão que perde a borda no hover e mensagem de erro indicada só por vermelho são falhas comuns porque a revisão visual costuma parar na primeira tela e no estado padrão.

O teste de contraste precisa acontecer na página renderizada. Ler dois tokens CSS isolados não captura transparência, gradiente, imagem de fundo, sobreposição nem a cor que aparece quando o controle recebe foco.

Este guia transforma contraste em um roteiro reproduzível. Você vai definir o que medir, registrar pares de cores, corrigir a menor camada responsável e repetir o teste na URL publicada.

Entenda quais critérios entram na revisão

A WCAG 2.2 separa problemas que parecem iguais à primeira vista.

Critério O que revisar Referência de nível AA
contraste de texto texto e imagens de texto contra o fundo 4,5:1 para texto comum e 3:1 para texto grande
contraste não textual limites e estados visuais necessários para operar componentes 3:1 contra cores adjacentes
uso de cor informação, ação e estado comunicados apenas pela cor exige outra pista visual

Texto de logotipo, decoração e componentes inativos têm exceções específicas. Não aplique uma exceção a um botão ativo só porque a cor veio da marca.

O critério de contraste mínimo também cobre placeholder, texto exibido no hover e texto visível no foco. Já o critério de uso de cor impede que verde e vermelho sejam a única diferença entre sucesso e erro, mesmo quando ambos passam na relação com o fundo.

Defina o escopo antes de abrir a ferramenta

Registre a versão e os estados que serão comparados:

URL ou build:
versão ou commit:
páginas incluídas:
viewports:
tema claro ou escuro:
componentes críticos:
estados interativos:
ferramenta e navegador:

Em uma landing page, priorize conteúdo e ações que decidem a tarefa:

  • título, subtítulo, preço e texto legal;
  • CTA primário e secundário;
  • links dentro de parágrafos;
  • campos, placeholders e mensagens do formulário;
  • foco, hover, seleção, erro, sucesso e estado desabilitado;
  • texto sobre fotografia, vídeo ou gradiente;
  • banner de cookies, modal e navegação mobile.

Não limite o escopo às cores mais usadas. Uma mensagem que aparece por três segundos pode ser a única explicação de por que o formulário falhou.

Meça a combinação realmente renderizada

Abra a página no navegador e inspecione o elemento no estado que precisa ser testado. Use o seletor de cores do DevTools ou uma ferramenta de contraste para capturar primeiro plano e fundo visíveis.

A relação deve considerar as cores que aparecem lado a lado. Isso fica menos óbvio em casos como:

  • texto com opacidade sobre um fundo colorido;
  • overlay semitransparente sobre fotografia;
  • gradiente que muda atrás da mesma linha;
  • sombra usada como único limite de um campo;
  • botão translúcido sobre vídeo;
  • estado de foco que troca borda e fundo ao mesmo tempo.

Para fundo variável, meça os pontos de menor contraste previstos durante o uso normal. A revisão inicial da W3C recomenda combinar ferramentas automáticas com seleção direta das cores porque tabelas de pares podem incluir combinações que nunca aparecem ou ignorar o resultado composto.

Registre cada achado com contexto:

elemento: botão "Enviar"
estado: focus-visible
primeiro plano: #ffffff
fundo adjacente: #6f2d78
relação medida: [valor]
critério: [referência]
resultado: passa ou falha
evidência: captura e URL

Sem estado e fundo, o número não permite reproduzir a falha.

Não confunda texto grande com texto importante

A exigência de 3:1 não vale porque o texto é um título ou porque recebeu font-weight: 700. Ela depende do tamanho e do peso definidos pela WCAG.

Em CSS responsivo, o mesmo heading pode ser grande no desktop e cair abaixo do limite em uma largura menor. Um botão em negrito também pode continuar sendo texto comum. Verifique o tamanho computado em cada breakpoint antes de usar a relação menor.

Quando houver dúvida, buscar 4,5:1 reduz a dependência de classificação e costuma sobreviver melhor a mudanças de fonte, peso e viewport.

Revise controles e estados, não só palavras

O texto pode passar enquanto o componente desaparece. O critério de contraste não textual alcança informação visual necessária para identificar um controle e seu estado.

Teste:

  • borda do campo quando ela é necessária para localizar a área de entrada;
  • indicador de foco contra o fundo e contra o próprio componente;
  • ícone que comunica a ação sem texto equivalente;
  • estado selecionado de radio, checkbox, tab e opção;
  • controle de carrossel ou player;
  • linhas e partes de gráfico necessárias para entender os dados.

Nem toda borda decorativa precisa atingir 3:1. Pergunte o que desaparece se aquela diferença de cor deixar de ser percebida. Se a pessoa perde o controle, o estado ou a informação, a diferença participa da tarefa.

O roteiro de navegação por teclado ajuda a revelar todos os estados de foco que entram nessa medição.

Retire a cor do papel de única pista

Um formulário que pinta a borda de vermelho sem texto ou ícone identificável continua ambíguo. Uma tabela que usa apenas verde e amarelo para classificar planos também.

Acrescente uma pista que preserve o significado:

  • texto curto junto ao campo;
  • ícone com alternativa ou nome acessível quando ele comunica informação;
  • sublinhado em links dentro de texto;
  • padrão, forma ou rótulo em gráficos;
  • posição e texto estáveis para seleção e status.

Depois desligue a cor, use escala de cinza ou uma simulação de deficiência de visão de cores como teste exploratório. O resultado não substitui a medição de luminância. Ele encontra dependências de matiz que uma relação numérica não responde.

Corrija na camada certa

Evite remendos por componente quando o problema vem de um token compartilhado. Procure primeiro a origem do par:

  1. token de texto ou superfície;
  2. variante do componente;
  3. estado interativo;
  4. overlay ou opacidade;
  5. imagem e posição do conteúdo;
  6. exceção local.

Altere uma camada por vez. Se um token secundário atende corpo de texto, legenda e estado desabilitado, talvez esses usos precisem de tokens diferentes. Clarear tudo até passar pode apagar a hierarquia sem resolver o modelo.

Para texto sobre imagem, as correções mais previsíveis são mudar a posição, usar uma superfície sólida atrás do conteúdo ou escolher outra imagem. Aumentar uma sombra raramente cria um resultado estável em todos os pixels e larguras.

Teste temas, breakpoints e preferências

Rode o mesmo inventário em cada combinação que o produto oferece:

  • tema claro e escuro;
  • largura desktop e mobile;
  • zoom de 200%;
  • hover, foco, ativo, selecionado, erro e sucesso;
  • modo de alto contraste ou cores forçadas quando faz parte do suporte;
  • conteúdo longo e traduções previstas.

Um CTA pode passar no desktop e falhar no mobile porque muda de superfície. O foco pode ser visível no tema escuro e sumir no claro. Texto ampliado pode quebrar sobre outra parte do gradiente.

Não some resultados de estados diferentes. Registre cada combinação que falha e a correção que a cobre.

Use automação para cobertura, não para encerrar a revisão

Scanners ajudam a percorrer muitos elementos, mas dependem do DOM, do estado aberto e da capacidade de calcular o fundo. Eles podem deixar de fora conteúdo em modal fechado, canvas, vídeo, pseudo-elemento ou imagem.

Combine:

  1. scanner automático nas rotas e estados que podem ser abertos por script;
  2. medição manual dos pares críticos e fundos variáveis;
  3. teste sem cor para informação e estados;
  4. navegação por teclado para revelar foco e controles;
  5. revisão visual nos viewports e temas suportados.

O checklist de acessibilidade organiza os outros checks de estrutura, conteúdo, formulários e movimento. Contraste aprovado não significa que a página inteira está acessível.

Publique e repita na URL final

No Site no Ar, mantenha a correção vinculada a uma Version:

  1. consulte o Site e chame get_context;
  2. localize tokens, estilos e assets com as file tools;
  3. corrija os pares sem publicar;
  4. execute os checks do projeto e gere o pacote completo;
  5. publique com deploy;
  6. acompanhe deploy_status até um estado terminal;
  7. abra a URL pública e repita os estados críticos;
  8. registre Version, URL, ferramenta e evidências.

Arquivos, fontes e imagens servidos na URL final podem diferir do ambiente usado durante a edição. A documentação de Publicação explica como a Session vira uma Version. Se a correção causar regressão, preserve o Site e restaure ou ajuste a partir do histórico em vez de criar outro endereço.

Prompt para conduzir a revisão

Teste o contraste desta landing page sem publicar ainda.


Escopo:
- URL ou build: [origem]
- versão: [identificador]
- páginas e viewports: [lista]
- temas: [lista]
- nível WCAG de referência: [nível]


1. Inventarie texto, controles e estados visuais críticos.
2. Meça as cores realmente renderizadas, incluindo transparência,
   gradientes e imagens.
3. Registre elemento, estado, par de cores, relação e critério.
4. Verifique informação transmitida somente por cor.
5. Classifique falhas confirmadas e casos que exigem revisão manual.
6. Proponha a menor correção na camada de token ou componente correta.
7. Não declare conformidade e não publique antes da aprovação.

Depois de corrigir, rode o inventário novamente e reteste na URL pública. O resultado útil não é “as cores parecem melhores”. É uma lista curta de pares, estados, versões e evidências que outra pessoa consegue reproduzir.