WCAG 1.4.1: Uso de cor

O que Esta Regra Significa

WCAG 1.4.1 Uso de Cor é um critério de Nível A sob o princípio Perceptível. Ele estabelece que a cor não deve ser usada como o único meio visual de transmitir informação, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual. A palavra-chave aqui é "único": a cor não é proibida, mas deve sempre ser acompanhada por pelo menos uma pista visual adicional — como rótulos de texto, padrões, formas, bordas, ícones ou tratamentos tipográficos — para que a mesma informação esteja disponível independentemente de o usuário conseguir perceber diferenças de cor.

Esse critério abrange uma ampla gama de elementos de interface. Campos de formulário que ficam vermelhos para indicar um erro falham nesse critério se a cor vermelha for o único indicador. Gráficos e diagramas que usam apenas cor para distinguir séries de dados falham nesse critério. Links estilizados apenas com uma cor diferente (sem sublinhado, negrito ou outro diferenciador não baseado em cor) falham nesse critério quando aparecem dentro de um bloco de texto corrido. Estados de navegação, selos de status, indicadores de progresso, marcadores de campo obrigatório e affordances interativas estão todos dentro do escopo.

Uma implementação aprovada fornece pelo menos um mecanismo não baseado em cor junto com a cor. Por exemplo: um campo com erro contornado em vermelho e acompanhado por um ícone de erro e um rótulo de texto descritivo; um gráfico de pizza usando cores distintas e preenchimentos com padrões; links em texto corrido que são de uma cor diferente e sublinhados. Uma implementação reprovada depende apenas da mudança de cor — não há forma, borda, padrão, rótulo ou diferença de texto que transmita o mesmo significado.

Há uma importante clarificação de escopo na especificação WCAG: esse critério se aplica especificamente à cor como meio visual de transmitir informação. Ele não exige que toda cor seja removida, nem trata de relações de contraste — isso é abordado por 1.4.3 e 1.4.11. Também não se aplica a logotipos ou imagens decorativas em que a cor não carrega significado informacional. O critério trata estritamente de situações em que um usuário que não consegue distinguir entre duas ou mais cores perderia acesso a informações ou funcionalidades.

Por Que Isso Importa

Aproximadamente 300 milhões de pessoas no mundo vivem com algum tipo de deficiência de visão de cores (daltonismo), e 2,2 bilhões de pessoas globalmente têm deficiência de visão de perto ou de longe, de acordo com a Organização Mundial da Saúde. O daltonismo afeta cerca de 1 em cada 12 homens e 1 em cada 200 mulheres de ascendência do norte da Europa, o que significa que, em um público típico de 100 pessoas, aproximadamente 5–8 delas não conseguem distinguir de forma confiável vermelho de verde — uma das combinações de cores mais comuns usadas em interfaces para sinalizar sucesso versus falha.

Para usuários com deuteranopia ou protanopia (daltonismo vermelho-verde), um formulário que destaca campos inválidos apenas em vermelho é funcionalmente invisível como indicador de erro. Eles enviam o formulário, não veem nenhuma mudança óbvia e concluem que o sistema está com defeito ou que o envio foi aceito. Isso não é um inconveniente menor — pode resultar em transações financeiras fracassadas, consultas médicas perdidas, solicitações malsucedidas de serviços governamentais ou incapacidade de concluir compras em e-commerce.

Usuários com baixa visão que dependem de telas de alto contraste ou esquemas de cores personalizados podem ter substituições de cor em nível de sistema ativas. Em tais ambientes, as cores especificadas pelo autor podem ser totalmente substituídas, tornando qualquer pista baseada apenas em cor sem significado, independentemente da capacidade do usuário de perceber cor. Da mesma forma, usuários que imprimem documentos em preto e branco ou acessam conteúdo em telas monocromáticas de e-ink perdem toda diferenciação de cor.

Além da deficiência, esse critério beneficia uma população ampla: usuários móveis ao ar livre sob luz solar intensa, usuários em telas de baixa qualidade com reprodução de cor ruim e pessoas idosas cuja percepção de cor naturalmente diminui com a idade. O uso acessível de cor também melhora o SEO indiretamente — rótulos de texto descritivos adicionados para satisfazer esse critério fornecem conteúdo semântico adicional que os mecanismos de busca podem indexar. Do ponto de vista de usabilidade, rótulos de texto explícitos e pistas visuais junto com a cor reduzem a carga cognitiva para todos os usuários, tornando o significado da interface redundante e reforçado.

Regras Relacionadas do Axe-core

WCAG 1.4.1 exige testes manuais porque ferramentas automatizadas não conseguem determinar de forma confiável se a cor está sendo usada como o único meio de transmitir informação. Trata-se de um julgamento semântico e visual: uma ferramenta automatizada pode detectar que dois elementos têm cores diferentes, mas não pode determinar se essas cores são o único fator de diferenciação ou se a informação carregada por essa diferença de cor também é transmitida por outro mecanismo. A ferramenta precisaria entender a intenção de design e todo o contexto de renderização visual para fazer essa determinação.

• Teste manual necessário — Distinção de cor de links: O Axe-core não pode verificar automaticamente se links dentro de texto corrido são distinguíveis do texto não linkado ao redor por meios além da cor. Um testador humano deve inspecionar visualmente a página e confirmar que os links têm uma pista adicional não baseada em cor (como sublinhado, peso em negrito ou um ícone visível) quando aparecem em linha dentro de parágrafos de texto. Ferramentas automatizadas podem detectar que um link existe, mas não se sua apresentação visual depende apenas de uma diferença de matiz.
• Teste manual necessário — Estados de erro em formulários: Quando um campo de formulário entra em estado de erro, ferramentas automatizadas não conseguem determinar se a mudança visual (como uma borda ou fundo vermelho) é a única indicação do erro ou se é acompanhada por um ícone de erro, mensagem de texto ou outra pista não baseada em cor. Um testador deve interagir com o formulário, disparar erros de validação e inspecionar como o erro é comunicado visualmente.
• Teste manual necessário — Visualizações de dados: Gráficos, diagramas, mapas e diagramas que usam cor para distinguir categorias, séries de dados ou regiões não podem ser avaliados automaticamente quanto à conformidade com 1.4.1. Um testador humano deve avaliar se padrões, rótulos ou texturas também estão presentes para diferenciar os elementos codificados por cor.
• Teste manual necessário — Indicadores de status: Selos, tags e indicadores de status (como indicadores online/offline ou rótulos de status de pedido) que dependem de cor para comunicar estado não podem ser sinalizados automaticamente. O testador deve confirmar que cada status também é transmitido por um rótulo de texto, ícone ou mudança de forma.

Como Testar

1. Base de varredura automatizada: Execute axe DevTools, Lighthouse ou o verificador de acessibilidade Accsible na página. Embora essas ferramentas não sinalizem diretamente violações de 1.4.1, elas podem revelar problemas relacionados, como alternativas de texto ausentes, contraste insuficiente ou rótulos de formulário ausentes que se correlacionam com uso apenas de cor. Anote quaisquer problemas sinalizados e use-os como pontos de partida para inspeção manual. No axe DevTools, abra a extensão do navegador, clique em "Analyze" e revise a categoria "Needs Review" além da lista de violações, pois alguns problemas relacionados a cor podem aparecer ali.
2. Simulação em escala de cinza: Use uma extensão de navegador ou recurso de acessibilidade do sistema operacional para visualizar a página em escala de cinza (saturação zero). No macOS, vá em Ajustes do Sistema > Acessibilidade > Tela e ative "Usar escala de cinza". No Windows, vá em Configurações > Facilidade de Acesso > Filtros de cor e selecione "Escala de cinza". Alternativamente, use as DevTools do navegador: no Chrome, abra as DevTools, pressione Ctrl+Shift+P (ou Cmd+Shift+P no Mac), digite "Emulate vision deficiencies" e selecione "Achromatopsia". Revise todos os elementos interativos, indicadores de status, campos de formulário, gráficos e links em escala de cinza e confirme que todas as informações permanecem compreensíveis sem cor.
3. Simulação de daltonismo: Use o emulador de deficiência de visão do Chrome DevTools (mesmo caminho acima) para simular Deuteranopia, Protanopia e Tritanopia. Para cada simulação, percorra todos os fluxos de usuário — envio de formulários com erros, interpretação de dados em gráficos, navegação entre estados ativos e inativos — e verifique se nenhuma informação é perdida. Ferramentas como o Coblis Color Blindness Simulator ou o Colour Oracle (um aplicativo desktop) também podem ser usadas para simular daltonismo em toda a tela.
4. Links em texto corrido — verificação manual: Identifique todos os hiperlinks que aparecem dentro de parágrafos de texto corrido (em oposição a menus de navegação ou listas de links isolados). Para cada link, confirme que ele é visualmente distinguível do texto não linkado ao redor por pelo menos um mecanismo não baseado em cor. O mecanismo aceitável mais comum é o sublinhado. Se o link depender apenas de uma diferença de cor, isso é uma falha.
5. Validação de formulários — verificação manual: Usando navegação por teclado (Tab para mover o foco, Enter ou Espaço para ativar controles), preencha um formulário e deixe deliberadamente campos obrigatórios vazios ou insira dados inválidos. Envie o formulário. Inspecione visualmente como os erros são comunicados. Confirme que a indicação de erro não é fornecida apenas por cor — cada erro deve ter uma descrição de texto visível, um ícone ou ambos, além de qualquer mudança de cor.
6. Verificação com leitor de tela (NVDA + Firefox): Abra a página no Firefox com o NVDA em execução. Navegue por todos os campos de formulário, gráficos e indicadores de status usando o cursor virtual. Confirme que mensagens de erro, rótulos de status e descrições de dados são anunciados pelo leitor de tela. Isso valida a camada programática, embora o acesso via leitor de tela sozinho não satisfaça o requisito visual de 1.4.1 para usuários daltônicos que enxergam.
7. Revisão de gráficos e diagramas: Para cada visualização de dados, tente interpretar os dados usando apenas forma, padrão ou rótulos de texto, ignorando deliberadamente a cor. Se a visualização se tornar ininterpretável sem cor, ela falha. Confirme que uma alternativa baseada em texto (tabela de dados, legenda com padrões, rótulos de dados diretos) está disponível.

Como Corrigir

Link em linha em texto corrido — Incorreto

<!-- Link é distinguível do texto ao redor apenas pela cor.
     Um usuário com daltonismo não consegue identificá-lo como um link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: none;'>privacy policy</a>
  before continuing.
</p>

Link em linha em texto corrido — Correto

<!-- Link é sublinhado além de ter uma cor diferente.
     O sublinhado fornece uma pista visual não baseada em cor que o identifica como link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: underline;'>privacy policy</a>
  before continuing.
</p>

Estado de erro em formulário — Incorreto

<!-- Erro é comunicado apenas por uma borda vermelha.
     Um usuário daltônico não consegue distinguir isso de um campo normal. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-label='Email address'
/>
<!-- .input-error { border: 2px solid #cc0000; } -->

Estado de erro em formulário — Correto

<!-- Erro é comunicado por uma borda vermelha E um ícone de erro visível E uma mensagem de texto.
     A mensagem de texto também é vinculada via aria-describedby para tecnologia assistiva. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
/>
<p id='email-error' class='error-message'>
  <svg aria-hidden='true' focusable='false' class='error-icon'>
    <!-- dados de path do ícone de erro em SVG -->
  </svg>
  Please enter a valid email address.
</p>

Legenda de gráfico apenas por cor — Incorreto

<!-- Gráfico de barras em que categorias são diferenciadas apenas pela cor de preenchimento.
     Usuários com daltonismo não conseguem distinguir as categorias. -->
<svg role='img' aria-label='Quarterly sales by region'>
  <rect x='10' y='50' width='40' height='100' fill='#e63946' />
  <rect x='60' y='20' width='40' height='130' fill='#2a9d8f' />
  <rect x='110' y='70' width='40' height='80' fill='#e9c46a' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch red'></span> North</li>
  <li><span class='swatch green'></span> South</li>
  <li><span class='swatch yellow'></span> West</li>
</ul>

Legenda de gráfico apenas por cor — Correto

<!-- Barras usam cores distintas E preenchimentos com padrões distintos (via padrões SVG).
     Itens da legenda incluem um rótulo de texto. Uma tabela de dados acessível também é fornecida. -->
<svg role='img' aria-label='Quarterly sales by region — data table below'>
  <defs>
    <pattern id='pattern-north' patternUnits='userSpaceOnUse' width='6' height='6'>
      <line x1='0' y1='6' x2='6' y2='0' stroke='#e63946' stroke-width='1.5'/>
    </pattern>
    <pattern id='pattern-south' patternUnits='userSpaceOnUse' width='6' height='6'>
      <circle cx='3' cy='3' r='2' fill='#2a9d8f'/>
    </pattern>
    <pattern id='pattern-west' patternUnits='userSpaceOnUse' width='6' height='6'>
      <rect x='0' y='0' width='3' height='3' fill='#e9c46a'/>
    </pattern>
  </defs>
  <rect x='10' y='50' width='40' height='100' fill='url(#pattern-north)' />
  <rect x='60' y='20' width='40' height='130' fill='url(#pattern-south)' />
  <rect x='110' y='70' width='40' height='80' fill='url(#pattern-west)' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch swatch-north' aria-hidden='true'></span> North (diagonal lines)</li>
  <li><span class='swatch swatch-south' aria-hidden='true'></span> South (dots)</li>
  <li><span class='swatch swatch-west' aria-hidden='true'></span> West (squares)</li>
</ul>
<table>
  <caption>Quarterly sales by region (data table)</caption>
  <thead><tr><th>Region</th><th>Sales (units)</th></tr></thead>
  <tbody>
    <tr><td>North</td><td>100</td></tr>
    <tr><td>South</td><td>130</td></tr>
    <tr><td>West</td><td>80</td></tr>
  </tbody>
</table>

Badge de status — Incorreto

<!-- Status do pedido comunicado apenas pela cor de fundo.
     "Pending" (amarelo), "Shipped" (azul) e "Delivered" (verde) são
     visualmente idênticos para muitos usuários daltônicos. -->
<span class='badge badge-pending'></span>
<span class='badge badge-shipped'></span>
<span class='badge badge-delivered'></span>

Badge de status — Correto

<!-- Status é comunicado por cor E um rótulo de texto visível.
     O rótulo de texto é o principal portador de significado. -->
<span class='badge badge-pending'>Pending</span>
<span class='badge badge-shipped'>Shipped</span>
<span class='badge badge-delivered'>Delivered</span>

Erros Comuns

• Remover sublinhados de links em linha e depender apenas da cor: Definir text-decoration: none em elementos âncora dentro de parágrafos de texto corrido é uma das falhas mais comuns de 1.4.1. O sublinhado é a pista não baseada em cor padrão para links; removê-lo sem adicionar outro diferenciador não baseado em cor (como peso em negrito ou um ícone) causa uma falha imediata sempre que esse link aparece dentro de texto ao redor de cor diferente.
• Usar pares de cores vermelho/verde para estados de aprovação/reprovação sem ícones ou texto adicionais: Vermelho para falha e verde para sucesso é culturalmente intuitivo, mas inacessível para usuários com deuteranopia ou protanopia, que são precisamente as formas mais comuns de daltonismo. Sempre combine essas cores com ícones distintos (um tique versus um X) e rótulos de texto explícitos ("Válido" versus "Erro").
• Marcar campos obrigatórios de formulário apenas com um asterisco colorido: Um asterisco vermelho (*) ao lado de um rótulo de campo comunica status obrigatório por meio da cor se o próprio asterisco não tiver uma legenda ou explicação de texto visível. A correção é incluir uma nota visível como "* indica campo obrigatório" perto do formulário, garantindo que o próprio asterisco carregue significado além de sua cor.
• Usar estados ativos/selecionados apenas por cor em menus de navegação: Destacar o item de navegação atualmente ativo apenas alterando sua cor de texto ou de fundo — sem também mudar o peso da fonte, adicionar um sublinhado ou um indicador de borda — significa que usuários daltônicos não conseguem identificar em qual página estão.
• Tooltips de gráficos que repetem a pista de cor sem adicionar rótulos: Algumas bibliotecas de gráficos exibem tooltips que mostram um bloco de cor correspondente à série de dados, mas nenhum rótulo de texto para o nome da série. Se o tooltip for o único lugar onde os dados são desambiguados e ele depender apenas de um bloco de cor, isso é uma falha.
• Etapas de progresso que mudam apenas de cor para indicar conclusão: Assistentes de formulários em múltiplas etapas frequentemente estilizam etapas concluídas com fundo verde e etapas futuras com fundo cinza. Se nenhum texto ("Concluído", "Atual", "Próximo") ou ícone (tique) acompanhar a mudança de cor, o estado da etapa é comunicado apenas por cor.
• Confiar na cor do texto placeholder para indicar validação de entrada: Alterar a cor do texto placeholder (por exemplo, deixá-lo vermelho em caso de erro) é tanto uma pista apenas por cor quanto inacessível por motivos adicionais (texto placeholder não é substituto para rótulos ou mensagens de erro). O estado de validação deve ser comunicado por meio de um elemento de mensagem de erro persistente e visível.
• Presumir que rótulos ARIA por si só satisfazem 1.4.1: Adicionar aria-label ou aria-describedby a um elemento torna a informação disponível para usuários de leitores de tela, mas 1.4.1 é um critério visual. Ele exige uma pista visual não baseada em cor para usuários daltônicos que enxergam, não apenas uma alternativa de texto programática. Ambos são necessários, mas ARIA sozinho não atende 1.4.1.
• Diferenciar linhas ou células de tabela usando apenas cores de fundo alternadas: Embora cores alternadas de linha (zebra) sejam geralmente decorativas e não um problema de 1.4.1 por si só, qualquer tabela que use apenas cor de fundo para agrupar, categorizar ou destacar linhas ou células específicas como informacionalmente distintas deve fornecer um rótulo textual, ícone ou cabeçalho para transmitir o mesmo agrupamento ou distinção.
• Tratar pistas apenas por cor como isentas por serem "apenas decorativas": Desenvolvedores às vezes argumentam que um ponto colorido de status ou um rótulo de categoria colorido é decorativo em vez de informacional. Se remover a cor (ou visualizar em escala de cinza) fizer com que um usuário perca acesso a qualquer informação de que precisa para entender ou usar a interface, então é informacional por definição e deve cumprir 1.4.1.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 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 alinhados com a WCAG 2.2. WCAG 1.4.1 Uso de Cor é um critério de Nível A, o que significa que se enquadra no nível básico obrigatório de conformidade sob essa circular.

A circular determina conformidade com WCAG 2.2 Nível A dentro de um ano para instituições públicas e dois anos para entidades do setor privado. As seguintes categorias de organizações são explicitamente abrangidas: instituições públicas e órgãos governamentais, plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, operadoras de telecomunicações com 200.000 ou mais assinantes, agências de viagens licenciadas, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

Para essas entidades, o não cumprimento de WCAG 1.4.1 constitui uma violação regulatória. Em termos práticos, uma instituição pública turca cujo portal web use apenas cor para indicar erros de formulário, ou um banco cuja interface de internet banking use indicadores de status apenas por cor para estados de transação, estaria em descumprimento dos requisitos da circular. Plataformas de e-commerce — um setor grande e em rápido crescimento na Turquia — comumente usam indicadores de disponibilidade de produto codificados por cor, selos promocionais e mensagens de erro do carrinho, todos os quais devem fornecer alternativas não baseadas em cor sob os requisitos da circular.

A conformidade com 1.4.1 é particularmente impactante no contexto turco, dado o número significativo de usuários que acessam serviços governamentais, bancários e de e-commerce em dispositivos móveis, onde a qualidade da tela e as condições de iluminação ambiente reduzem ainda mais a confiabilidade da cor como único portador de informação. As organizações abrangidas pela circular são aconselhadas a auditar todo uso de cor como mecanismo de informação em suas propriedades digitais, priorizar a adição de rótulos de texto e pistas iconográficas junto com estados codificados por cor e incluir 1.4.1 tanto em pipelines de varredura automatizada de acessibilidade quanto em protocolos estruturados de teste manual como parte de seu programa de conformidade.