WCAG 1.4.11: Contraste não textual

O Que Esta Regra Significa

WCAG 1.4.11 Contraste Não Textual é um critério de Nível AA introduzido na WCAG 2.1 e mantido na WCAG 2.2. Ele exige uma taxa de contraste mínima de 3:1 entre a apresentação visual das duas categorias de conteúdo a seguir e suas cores adjacentes:

• Componentes de Interface do Usuário (UI): Os limites visuais ou indicadores que identificam controles interativos, como campos de texto, caixas de seleção, botões de opção, interruptores (toggle), menus suspensos e botões. Isso inclui tanto o próprio componente quanto quaisquer mudanças de estado visuais (por exemplo, hover, foco, selecionado, erro).
• Objetos Gráficos: Partes de ícones, gráficos, diagramas e outras imagens significativas que são necessárias para entender o conteúdo. Cada parte do gráfico que transmite informação deve atender ao limite de 3:1 em relação à sua cor ao redor.

A taxa de contraste é medida entre o elemento em primeiro plano e a cor imediatamente adjacente a ele — normalmente sua cor de fundo, cor de borda ou um segmento vizinho de um gráfico. O cálculo usa a mesma fórmula de luminância relativa definida em WCAG 1.4.3, mas o limite é 3:1 em vez de 4.5:1 porque elementos não textuais podem ter um contraste ligeiramente menor e ainda permanecer discerníveis.

Um aprovado significa que todo indicador visual que identifica um componente de UI ou comunica informação em um gráfico atinge pelo menos uma taxa de 3:1. Uma falha ocorre quando uma borda, traço de ícone, segmento de gráfico ou indicador de estado fica abaixo dessa taxa e o componente ou gráfico não pode ser identificado ou compreendido sem aquela informação visual.

A especificação WCAG define várias exceções importantes:

• Componentes inativos: Componentes de UI que estão desabilitados e indisponíveis para interação estão isentos. Um botão esmaecido que não pode ser clicado não precisa atender ao requisito de contraste.
• Aparência controlada pelo user agent: Componentes cuja apresentação visual é inteiramente controlada pelo estilo padrão do navegador (não sobrescrito pelo CSS do autor) estão isentos, porque a responsabilidade recai sobre o fornecedor do navegador.
• Gráficos essenciais ou decorativos: Objetos gráficos em que a apresentação específica é essencial para a informação transmitida (por exemplo, bandeiras nacionais representando países) ou que são puramente decorativos estão isentos. Logotipos também são geralmente isentos sob esta cláusula.
• Texto: Texto e imagens de texto já são cobertos por 1.4.3 e 1.4.6 e não se enquadram em 1.4.11.

Indicadores de foco merecem atenção especial na WCAG 2.2. O critério 2.4.11 (Aparência do Foco) adiciona requisitos mais rígidos para a visibilidade do foco, mas 1.4.11 ainda se aplica ao contraste de qualquer anel de foco personalizado em relação ao seu fundo. Um outline ou box-shadow personalizado usado como indicador de foco deve atingir 3:1 em relação à cor adjacente para satisfazer este critério de forma independente.

Por Que Isso Importa

Aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, de acordo com a Organização Mundial da Saúde. Uma proporção significativa dessas pessoas — incluindo os estimados 253 milhões de pessoas vivendo com perda de visão moderada a grave — depende de contraste suficiente para perceber e interagir com interfaces digitais sem necessariamente usar um leitor de tela. Usuários com baixa visão que navegam com software de ampliação, modos de alto contraste ou simplesmente em condições de iluminação desafiadoras estão entre os mais diretamente afetados por falhas em 1.4.11.

Considere um cenário prático: uma pessoa com glaucoma está preenchendo um formulário de sinistro de seguro no site de um hospital. Os campos do formulário usam uma borda cinza clara (#cccccc) em um fundo branco (#ffffff), o que resulta em uma taxa de contraste de apenas 1.6:1 — muito abaixo dos 3:1 exigidos. A pessoa não consegue ver onde os campos de entrada começam e terminam, portanto não consegue clicar neles de forma confiável nem entender a estrutura do formulário. Ela abandona o formulário por completo, o que tem tanto um custo pessoal quanto uma responsabilidade legal para a instituição.

Além da deficiência visual, deficiências cognitivas também podem tornar componentes de UI com baixo contraste mais difíceis de interpretar. Pessoas com transtornos de atenção ou dificuldades de processamento dependem de uma forte diferenciação visual entre elementos interativos e não interativos para entender rapidamente a estrutura da página. Da mesma forma, pessoas com tremores ou deficiências motoras que usam alvos de ponteiro grandes precisam ver claramente os limites dos controles para mirar com precisão.

Do ponto de vista de negócios, atender ao 1.4.11 melhora a usabilidade para todas as pessoas em condições subótimas — luz solar intensa em uma tela de celular, monitores de baixa qualidade ou telas antigas com baixa precisão de cor. Isso reduz custos de suporte, amplia o alcance do público e fortalece o SEO indiretamente ao reduzir taxas de rejeição ligadas à baixa usabilidade. Para organizações sujeitas a exigências legais de acessibilidade, falhar neste critério em Nível AA representa um risco direto de conformidade.

Regras Relacionadas do Axe-core

• color-contrast (cobertura parcial): A regra color-contrast do axe-core tem como alvo principal o contraste de texto sob a WCAG 1.4.3, mas também realiza verificações parciais para elementos não textuais em certos contextos. O axe sinaliza componentes de UI como botões e controles de formulário quando consegue determinar programaticamente que o limite visual ou o fundo do componente falha na taxa de 3:1. No entanto, a cobertura da regra é explicitamente marcada como parcial para 1.4.11 porque muitas falhas de contraste em elementos não textuais são invisíveis à análise automatizada. Por exemplo, o contraste do traço de um ícone SVG em relação ao seu fundo, ou a borda de uma caixa de seleção personalizada implementada com pseudo-elementos CSS, não pode ser extraído de forma confiável do DOM sem o contexto de renderização. O estilo computado de uma borda CSS pode estar presente na árvore de acessibilidade, mas o fundo adjacente — especialmente quando é um gradiente, imagem ou elemento sobreposto — nem sempre é computável de forma programática. É por isso que o axe relata violações de 1.4.11 sob a regra color-contrast com a designação needs review em muitos casos, significando que a ferramenta detectou um possível problema, mas uma pessoa deve confirmá-lo inspecionando visualmente o elemento e usando uma ferramenta de análise de contraste de cores para amostrar os pixels realmente renderizados.

Como ferramentas automatizadas só conseguem detectar uma fração das falhas de contraste não textual, o teste manual é essencial. Ferramentas como o Colour Contrast Analyser (TPGi), seletores de cor das DevTools do navegador ou a ferramenta Accessible Colors devem ser usadas para amostrar diretamente as cores de primeiro plano e de fundo na interface renderizada. Varreduras automatizadas devem ser tratadas como uma primeira passada, não como uma auditoria abrangente.

Como Testar

1. Execute uma varredura automatizada com axe DevTools ou Lighthouse: Instale a extensão de navegador axe DevTools e execute uma varredura de página inteira. No painel de resultados, filtre por problemas marcados com WCAG 1.4.11 ou revise quaisquer violações de color-contrast. Observe quaisquer itens marcados como Needs Review na categoria de contraste não textual — eles exigem acompanhamento manual. No Lighthouse (Chrome DevTools > aba Lighthouse), execute uma auditoria de Acessibilidade e revise as descobertas relacionadas a contraste, tendo em mente que a cobertura do Lighthouse também é parcial para elementos não textuais.
2. Inspeção manual com um analisador de contraste de cores: Baixe e abra o aplicativo de desktop TPGi Colour Contrast Analyser. Use a ferramenta conta-gotas para amostrar a cor de primeiro plano de cada limite de componente de UI (por exemplo, a borda de um campo de texto, o traço de um ícone, o preenchimento de uma barra de gráfico) e depois amostre a cor de fundo adjacente. A ferramenta exibirá a taxa de contraste calculada. Qualquer taxa abaixo de 3:1 é uma falha. Percorra sistematicamente todos os controles de formulário interativos, botões apenas com ícone, indicadores de foco e visualizações de dados.
3. Navegação por teclado e teste de indicador de foco: Percorra toda a página usando apenas o teclado (Tab). Para cada elemento interativo que recebe foco, verifique se o indicador de foco (anel, contorno ou mudança de fundo) é visível. Use o analisador de contraste para confirmar que a cor do indicador de foco atinge 3:1 em relação ao fundo do elemento. Teste em NVDA + Firefox e JAWS + Chrome para confirmar que o elemento recebe foco na ordem esperada e que o indicador visual não é suprimido por CSS outline: none sem uma substituição equivalente.
4. Teste em modos de alto contraste e forced-color: No Windows, ative o Modo de Alto Contraste (Configurações > Facilidade de Acesso > Alto Contraste) e recarregue a página. Em navegadores baseados em Chromium, abra as DevTools, vá em Rendering e habilite a opção Emulate CSS media feature forced-colors: active. Verifique se os limites dos componentes de UI permanecem visíveis. Embora a conformidade com o modo forced-color não seja estritamente exigida por 1.4.11, testar nesse modo revela elementos que dependem apenas de pistas de cor de baixo contraste.
5. Verifique objetos gráficos em contexto: Para cada gráfico, ícone, diagrama ou imagem informativa, identifique todos os segmentos ou caminhos que transmitem significado. Use a ferramenta conta-gotas para amostrar cores adjacentes dentro do próprio gráfico (por exemplo, dois segmentos vizinhos de um gráfico de pizza) e em relação ao fundo da página ao redor. Cada parte distinta que comunica informação deve individualmente atingir 3:1.
6. Verifique todos os estados de componentes: Elementos interativos têm vários estados — padrão, hover, foco, ativo, selecionado, marcado, erro e sucesso. Teste cada estado separadamente. A borda de um botão que passa no estado padrão pode falhar no estado hover se a cor mudar para uma variante de baixo contraste.

Como Corrigir

Borda de Campo de Formulário — Incorreto

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Borda de Campo de Formulário — Correto

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Botão Apenas com Ícone — Incorreto

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Botão Apenas com Ícone — Correto

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Checkbox Personalizada — Incorreto

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

Checkbox Personalizada — Correto

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

Gráfico de Dados — Incorreto

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

Gráfico de Dados — Correto

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

Erros Comuns

• Usar uma borda de um pixel que atende 3:1 mas se torna invisível em baixa DPI: Mesmo uma cor em conformidade pode se tornar imperceptível se a borda tiver apenas 1px de largura em uma tela de baixa resolução. Use border: 2px solid ou um box-shadow visível junto com uma cor em conformidade para garantir que o limite seja fisicamente perceptível.
• Assumir que o fundo é sempre branco: Quando um campo de formulário ou ícone aparece dentro de um card ou barra lateral com fundo cinza claro (#f5f5f5), o contraste deve ser medido em relação a esse cinza, não em relação ao branco. Uma borda que passa no branco pode falhar em um fundo levemente colorido.
• Remover o contorno de foco padrão com outline: none e não fornecer um equivalente: Este é um dos erros mais comuns em 1.4.11. Definir :focus { outline: none; } globalmente destrói a visibilidade do foco para usuários de teclado. Sempre substitua por um estilo de foco personalizado que atinja pelo menos 3:1 de contraste em relação ao fundo.
• Tratar o estado desabilitado como desculpa para ignorar todas as verificações de contraste: Componentes desabilitados estão isentos, mas desenvolvedores às vezes marcam elementos como visualmente desabilitados por meio de estilo de baixo contraste sem realmente adicionar o atributo disabled ou aria-disabled='true'. Um elemento que parece desabilitado mas ainda é interativo deve continuar atendendo ao 1.4.11.
• Confiar apenas na cor para diferenciar segmentos de gráfico sem um traço separador: Dois segmentos de gráfico adjacentes em que o único diferenciador é o matiz (por exemplo, azul claro vs. verde claro) podem falhar se a taxa de contraste entre eles for inferior a 3:1. Adicionar um traço separador de 2px branco ou escuro entre os segmentos é uma correção confiável.
• Aplicar correções de contraste apenas ao estado padrão e esquecer estados de hover, foco, erro e sucesso: Cada estado interativo tem sua própria apresentação visual. A borda de um botão que passa no estado padrão pode mudar para uma cor de baixo contraste no hover. Todos os estados devem ser testados de forma independente.
• Incorporar ícones como imagens de fundo e depender da cor CSS para contraste: Ícones SVG embutidos em HTML respondem a color e currentColor, mas ícones usados como background-image em CSS não podem ter sua cor alterada via CSS. Se o próprio arquivo de imagem do ícone tiver contraste insuficiente, nenhuma correção em CSS pode resolver o problema sem substituir o recurso.
• Esquecer que o texto placeholder em campos de entrada não é coberto por 1.4.11, mas ainda é regulado: Texto placeholder se enquadra em 1.4.3 (contraste de texto em 4.5:1), não em 1.4.11. Desenvolvedores às vezes aplicam o limite de 3:1 ao texto placeholder por engano, criando uma falha separada e despercebida em 1.4.3.
• Usar transições CSS que animam por uma cor intermediária não conforme: Um elemento pode animar de uma cor em conformidade, passando por uma cor intermediária que falha, até outra cor em conformidade. Mesmo que os estados inicial e final passem, o componente visual é tecnicamente não conforme durante a transição. Use media queries prefers-reduced-motion de forma cuidadosa e evite que transições passem por estados de baixo contraste.
• Ignorar barras de progresso, inputs de faixa (range) e interruptores (toggle): Esses componentes de UI personalizados são frequentemente estilizados sem considerar o 1.4.11. A parte preenchida de uma barra de progresso deve ter 3:1 de contraste em relação à sua trilha; o botão (knob) de um toggle deve contrastar com o fundo do toggle; o thumb de um input de faixa deve contrastar com a trilha.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial nº 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade web e móvel para uma ampla gama de entidades públicas e privadas que operam na Turquia. A Circular adota a WCAG 2.2 como seu padrão técnico normativo, e a conformidade em Nível AA é o limite exigido para conformidade.

WCAG 1.4.11 Contraste Não Textual, como critério de Nível AA, é portanto diretamente aplicável sob a Circular. Organizações sujeitas ao regulamento devem garantir que todos os limites de componentes de UI, estados de controles interativos e objetos gráficos significativos em suas propriedades digitais atendam ao requisito de contraste não textual de 3:1.

As entidades cobertas pela Circular Presidencial 2025/10 incluem instituições e agências públicas em todos os níveis de governo, plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde privados, operadoras de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Para essas organizações, deixar de implementar 1.4.11 não é apenas uma falha de boa prática, mas uma não conformidade regulatória.

O Logotipo de Acessibilidade (Erişilebilirlik Logosu), emitido pelo Ministério da Família e Serviços Sociais, serve como uma marca de certificação visível ao público para serviços digitais em conformidade. Para obter e exibir esse logotipo, uma organização deve demonstrar conformidade total em Nível AA em todos os critérios WCAG 2.2 aplicáveis, incluindo 1.4.11. Como muitos portais de governo eletrônico turcos, interfaces bancárias e formulários de saúde fazem uso extensivo de controles de formulário personalizados e visualizações de dados, o contraste não textual é um critério que os auditores têm particular probabilidade de avaliar durante o processo de certificação.

Organizações que utilizam o widget de overlay Accsible devem estar cientes de que a tecnologia de overlay pode ajudar a remediar certos ajustes de contraste em tempo de execução — como permitir que as pessoas ativem um tema de alto contraste — mas falhas estruturais persistentes, como um campo de formulário renderizado com uma borda de contraste 1.6:1, devem ser corrigidas no nível do código-fonte para alcançar conformidade genuína e se qualificar para o Erişilebilirlik Logosu. Combinar correções em nível de código com os recursos de aprimoramento voltados ao usuário de um widget de acessibilidade representa a postura de conformidade mais defensável sob a lei turca.