Contraste de cores em acessibilidade é a razão entre a luminância do texto e a do fundo. A referência prática: 4.5:1 para texto normal e 3:1 para texto grande (a partir de 18pt ou 14pt em negrito) e para componentes de interface, conforme o nível AA das WCAG. No WordPress, o caminho para sustentar esse padrão com vários editores publicando é travar a paleta no theme.json, tornar o texto alternativo obrigatório no fluxo de aprovação e auditar por template, não por página.

Contraste de cores e acessibilidade no WordPress: checklist para times com múltiplos editores

Se você gerencia um WordPress corporativo com dez pessoas publicando na mesma semana, conhece a dor: o design foi aprovado, o conteúdo está no ar, e um botão cinza sobre fundo branco simplesmente não é legível para parte dos visitantes. Não é estética. É engenharia de interface.

Aqui na Apiki, o padrão que vemos em operações de Educação, Tecnologia e Serviços é sempre o mesmo: o time de conteúdo cresce, a padronização se perde e, quando alguém pede uma auditoria, aparecem dezenas de falhas de contraste e imagens sem texto alternativo. Este artigo entrega o processo que usamos para resolver os dois pontos de forma sistemática, incluindo a ordem dos passos da auditoria e o trecho de theme.json que impede o problema de voltar.

Por que o contraste de cores importa tanto?

Acessibilidade não é só conformidade legal. É experiência de uso em condição real: tela ao sol, monitor mal calibrado, olho cansado às 19h. Texto de baixo contraste aumenta o esforço de leitura e derruba a legibilidade justamente nos elementos que carregam conversão (rótulo de botão, label de formulário, mensagem de erro).

O relatório anual WebAIM Million, do WebAIM, analisa o milhão de páginas iniciais mais acessadas da web e aponta o contraste de texto insuficiente como uma das falhas mais comuns, presente na maioria das páginas avaliadas. Ou seja: problema estrutural, não exceção. Consulte a edição mais recente do relatório para os números do ano corrente.

No Brasil, a Lei Brasileira de Inclusão (Lei 13.146/2015) trata a acessibilidade de sites como obrigação, com peso especial para instituições de ensino e prestadores de serviço. Tratar contraste como requisito de projeto, e não como ajuste de última hora, reduz retrabalho e reduz exposição jurídica.

O que as WCAG exigem de contraste?

As diretrizes WCAG 2.1, mantidas pelo W3C Web Accessibility Initiative, definem razões mínimas calculadas entre a cor do texto e a cor do fundo. A versão 2.2 é a recomendação mais recente publicada pelo W3C e mantém os mesmos critérios de contraste, acrescentando requisitos em outras frentes (foco visível, alvos de toque, autenticação). Se o seu contrato de conformidade cita “WCAG 2.1 AA”, os números abaixo continuam valendo.

Os limites que você precisa decorar

• AA, texto normal: razão mínima de 4.5:1 entre texto e fundo. É o patamar adotado pela maioria das empresas como meta contratual.
• AA, texto grande: razão mínima de 3:1, aplicável a fontes a partir de 18pt ou 14pt em negrito.
• AAA, texto normal: razão de 7:1. Patamar mais rigoroso, usado em conteúdo crítico e institucional.
• Componentes de interface e gráficos: botões, ícones, bordas de campo e indicadores de estado precisam de pelo menos 3:1 contra o fundo adjacente.

Na prática, AA como meta padrão cobre a maior parte dos requisitos legais e de usabilidade sem engessar o design. AAA entra por exceção, em páginas de matrícula, contrato, suporte e formulários críticos.

Como conduzimos uma auditoria de contraste em um WordPress corporativo

Quando nosso time recebe um pedido de auditoria de acessibilidade em um portal com centenas de URLs, a primeira decisão é não auditar página por página. Auditamos templates: home, arquivo de blog, post single, landing page de campanha, página de curso ou produto, formulário e área logada, se houver. Uma falha no template se repete em milhares de URLs; corrigir na origem é o que escala.

A ordem dos passos que seguimos:

1. Varredura automatizada por template com o axe DevTools, que devolve o seletor CSS do elemento e a razão calculada. O seletor é o que transforma o achado em tarefa de dev, não em observação vaga.
2. Snapshot com o Lighthouse para ter um registro comparável entre auditorias, incluindo mobile. Serve de linha de base, não de laudo.
3. Checagem manual dos estados interativos: hover, focus, active e disabled. Scanner automático não dispara pseudo-classe. É aqui que a maior parte das falhas aparece.
4. Texto sobre imagem e sobre gradiente: validação manual com o WebAIM Contrast Checker, amostrando os pontos mais claros e mais escuros da área de fundo. Automação costuma ignorar esse caso.
5. Consolidação por causa raiz: agrupamos os achados por token de cor do design system, não por página. Normalmente meia dúzia de tokens explica a maior parte das ocorrências.

A falha mais recorrente que encontramos nesse tipo de projeto não está no corpo do texto. Está no cinza claro dos elementos secundários: legenda de imagem, placeholder de campo, breadcrumb, texto de rodapé, contador de caracteres e, quase sempre, o estado disabled de botão. São elementos que passaram na aprovação visual porque ninguém mediu, e que reprovam no primeiro scanner. A segunda mais comum: link diferenciado só pela cor, sem sublinhado nem outro sinal, dentro de blocos de texto.

Checklist de contraste no WordPress

Um bom processo começa no design system e termina na publicação diária. Este é o checklist que aplicamos:

1. Documente a paleta aprovada com as razões calculadas: registre cada combinação texto/fundo permitida e a razão ao lado. Editor não improvisa cor quando existe uma lista fechada.
2. Valide título, corpo e link separadamente: tamanho e peso mudam o limiar aplicável (4.5:1 ou 3:1).
3. Teste os estados de botão e formulário: hover, foco e desabilitado. É onde a maioria dos temas quebra.
4. Confira texto sobre imagem de fundo: banner com frase sobreposta exige camada de sobreposição sólida o bastante para sustentar a razão mínima no pior ponto da imagem.
5. Trave a paleta no theme.json: o editor de blocos passa a oferecer apenas cores aprovadas, sem seletor livre.

O trecho de theme.json que resolve 80% do problema

Documentar a paleta em um PDF não impede ninguém de digitar um hexadecimal no editor. Remover o seletor de cor livre, sim. É este o bloco que colocamos no theme.json em projetos com muitos editores (valores de cor abaixo são ilustrativos; use os tokens já validados da sua marca):

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "custom": false,            // remove o seletor de cor livre do editor
      "customGradient": false,    // idem para gradientes
      "defaultPalette": false,    // desliga a paleta padrão do core
      "defaultGradients": false,
      "palette": [
        { "slug": "texto-base",     "name": "Texto base",     "color": "#1A1A1A" },
        { "slug": "texto-suave",    "name": "Texto suave",    "color": "#4A4A4A" },
        { "slug": "fundo-claro",    "name": "Fundo claro",    "color": "#FFFFFF" },
        { "slug": "acao-primaria",  "name": "Ação primária",  "color": "#0B4FD1" }
      ]
    }
  }
}

Três observações do nosso time sobre esse arquivo. Primeira: defaultPalette: false é o que realmente fecha a porta, porque a paleta do core traz combinações que não passam em AA sobre os seus fundos. Segunda: cada entra na nossa documentação com a razão de contraste calculada contra os fundos permitidos, e combinação não medida não vira token. Terceira: confirme o número em version conforme a versão de theme.json suportada pelo core que você roda, e valide em ambiente de staging antes de subir, porque desligar a paleta padrão altera cores de conteúdo legado que usava slugs do core.

A referência oficial está no manual do editor de blocos do WordPress, seção de global settings and styles.

Como garantir textos alternativos corretos nas imagens?

O texto alternativo (atributo alt) descreve o conteúdo ou a função da imagem para leitores de tela e para quando o arquivo não carrega. É o complemento natural do trabalho de contraste.

• Descreva a função, não a aparência: se a imagem é link ou botão, o alt indica a ação, como “Baixar e-book de acessibilidade”.
• Imagem decorativa recebe alt=”: vazio, não ausente. Alt ausente faz o leitor de tela anunciar o nome do arquivo.
• Evite “imagem de” e “foto de”: o leitor de tela já anuncia o papel do elemento.
• Transcreva texto embutido em imagem: se o banner traz uma frase que importa, ela precisa existir no alt (ou, melhor, virar texto real sobre a imagem).
• Torne o preenchimento um bloqueio de publicação: item obrigatório no checklist de aprovação, não sugestão.

O teste de 10 minutos que mudou nosso fluxo editorial

Em auditorias, fazemos uma checagem que convence qualquer gestor mais rápido que um relatório: abrimos a página com um leitor de tela (NVDA no Windows, VoiceOver no macOS) e navegamos apenas pela lista de imagens e links, sem olhar a tela. Em páginas sem governança de alt, o que se ouve é uma sequência de nomes de arquivo: “banner-home-final-2”, “grupo-137”, “asset-3-copy”. Em cards de curso ou de produto, o efeito é pior, porque o link inteiro é a imagem, e a navegação vira uma lista de itens sem rótulo.

O que mudamos no fluxo depois desse teste, em projetos que operamos: a acessibilidade saiu do fim da esteira e entrou em dois pontos. No design, a paleta só é aprovada com as razões calculadas anexas. Na publicação, o card de revisão passa a ter dois itens travados (alt preenchido ou marcado como decorativo, e nenhuma cor fora da paleta do tema). O ganho não é estético: é que a correção deixou de depender de auditoria e passou a acontecer antes do conteúdo ir ao ar.

Quais ferramentas usar para auditar contraste e alt?

A abordagem certa depende da maturidade do time e da escala do site. A comparação abaixo cobre os três caminhos mais comuns.

Comparativo de abordagens de auditoria de contraste e texto alternativo.

Em operação enterprise, as três camadas se somam: paleta validada no design, checagem por template antes de publicar e verificação automatizada no deploy para pegar regressão. Vale lembrar o limite conhecido das ferramentas automatizadas: elas detectam uma parte dos critérios das WCAG. Contraste é justamente um dos itens que a automação cobre bem, mas texto alternativo adequado nenhum scanner avalia, porque ele checa presença, não pertinência.

Perguntas frequentes sobre contraste de cores e acessibilidade

Qual é a razão de contraste mínima recomendada?

Para texto normal, 4.5:1 no nível AA das WCAG 2.1 (critério 1.4.3). Para texto grande, a partir de 18pt ou 14pt em negrito, o mínimo cai para 3:1. Componentes de interface e gráficos exigem 3:1 contra o fundo adjacente (critério 1.4.11). Os mesmos limites permanecem na WCAG 2.2.

Como testar o contraste de um site?

Use o WebAIM Contrast Checker para combinações específicas de cor e o axe DevTools ou o Lighthouse para varrer a página inteira e receber o seletor de cada elemento fora do padrão. Depois, faça manualmente o que a automação não cobre: estados de hover, foco e desabilitado, e texto sobre imagem. Valide a paleta ainda no design e repita a checagem por template antes de publicar.

Textos alternativos influenciam no SEO?

Sim. O alt ajuda mecanismos de busca a entender o conteúdo da imagem e participa da indexação de imagens. Mas o objetivo principal continua sendo acessibilidade. Alt descritivo e honesto atende leitor de tela e busca ao mesmo tempo, sem forçar palavra-chave.

Toda imagem precisa de texto alternativo?

Não. Imagem puramente decorativa recebe alt=””, vazio, para não gerar ruído. Imagem que transmite informação, funciona como link ou contém texto relevante precisa de alt descritivo que comunique o conteúdo ou a ação.

Vale a pena usar plugins de acessibilidade no WordPress?

Plugins de auditoria dentro do editor ajudam a pegar falha antes da publicação. Já os widgets que prometem acessibilidade com um clique sobrepõem uma camada de controles ao site e não corrigem contraste no CSS nem escrevem alt pertinente. Não é plugin. É arquitetura: resolver no tema, no theme.json e no fluxo editorial.

Como manter o padrão com vários editores publicando?

Limite as escolhas. Paleta travada no theme.json com custom: false e defaultPalette: false, alt obrigatório no fluxo de aprovação e auditoria periódica por template. Padronização reduz a dependência de revisão manual, que é o que sempre falha quando o volume de publicação sobe.

WCAG 2.1 ou 2.2: qual usar como referência em 2026?

Para contraste, tanto faz: os critérios são os mesmos. A diferença está em outros requisitos adicionados na 2.2, como foco visível e alvos de toque. Se o seu contrato ou edital cita uma versão específica, siga a citada e trate a mais recente como meta de evolução. Confirme sempre a versão vigente na página oficial das WCAG no W3C.

Conclusão

Contraste e texto alternativo são os dois ajustes de maior impacto e menor custo em um WordPress corporativo. Bem tratados, melhoram legibilidade, reduzem risco jurídico e ampliam alcance. Mal tratados, viram dívida técnica que cresce na mesma velocidade em que o time publica.

Documentamos a paleta. Travamos no theme.json. Auditamos por template. Bloqueamos a publicação sem alt. É processo, não força de vontade.

Se você quer estruturar isso em escala, com um WordPress rápido, estável e acessível, sem travar a rotina de publicação do time de marketing, fale com o nosso time sobre o WP Care e peça um diagnóstico da sua operação WordPress.