Acessibilidade cromática é o tipo de requisito que todo mundo concorda que é importante — e quase todo mundo deixa para validar depois. O resultado é sempre o mesmo: o design está aprovado, os componentes estão implementados, e aí alguém roda um checker de contraste e descobre que o botão principal do produto não passa nem no nível mínimo da WCAG.
Refatorar cores depois que o design system está em produção custa dez vezes mais do que acertar durante a geração da paleta. Este guia cobre o processo de validação cromática integrado à construção do sistema — não como uma etapa de auditoria tardia, mas como parte do fluxo de criação da escala.
O que é acessibilidade cromática e por que ela entra no design system?
Acessibilidade cromática é a prática de garantir que as cores usadas em um produto digital permitam que todas as pessoas — incluindo aquelas com baixa visão, daltonismo ou sensibilidade ao contraste — consigam perceber, distinguir e compreender as informações visuais sem depender exclusivamente da cor ou de condições ideais de visualização.
No contexto de design systems, acessibilidade cromática não é uma checklist de auditoria. É uma restrição de projeto que precisa ser resolvida na camada de escala de cor — antes de qualquer componente ser criado. Quando a paleta é gerada com requisitos de contraste embutidos, todos os componentes que consomem aquela escala herdam a conformidade automaticamente.
O oposto também é verdade: quando a paleta é criada sem validação de contraste, cada componente precisa ser auditado individualmente — e qualquer mudança de cor no futuro exige uma nova rodada de testes.
Os níveis WCAG explicados sem enrolação
A WCAG (Web Content Accessibility Guidelines) é o padrão internacional de acessibilidade para conteúdo web, mantido pelo W3C. A versão 2.1 é a referência atual para a maioria dos projetos digitais no Brasil e no mundo.
Nível AA — o mínimo que todo produto digital deveria ter
O nível AA é o requisito de mercado para a esmagadora maioria dos produtos digitais. Ele exige:
- 4.5:1 de proporção de contraste para texto normal (abaixo de 18pt ou 14pt em negrito)
- 3:1 para texto grande (18pt ou maior, ou 14pt em negrito)
- 3:1 para componentes de interface e elementos gráficos informativos (botões, ícones de status, bordas de input)
Na prática: se você tem texto escuro sobre fundo claro, a luminância do texto dividida pela luminância do fundo precisa ser pelo menos 4.5. Um texto #333333 sobre fundo #ffffff tem contraste de 12.6:1 — passa fácil. Um texto #767676 (cinza médio) sobre #ffffff tem exatamente 4.54:1 — passa no limite. Um #888888 sobre #ffffff tem 3.54:1 — reprova.
Nível AAA — quando é obrigatório ir além
O nível AAA eleva os requisitos para:
- 7:1 para texto normal
- 4.5:1 para texto grande
Não é realista atingir AAA em todo o produto — o W3C reconhece isso. Mas há contextos onde AAA é necessário: produtos financeiros com dados críticos, plataformas de saúde, sistemas governamentais, e qualquer interface usada por população idosa ou com deficiência visual significativa.
A boa notícia: na escala 50-950, os tons 800 e 900 geralmente atingem nível AAA contra fundo branco sem nenhum ajuste. Se o seu produto precisa de AAA, basta direcionar a tipografia para esses tons.
A diferença entre conformidade em texto e em elementos não-textuais
Um erro comum é validar apenas o par texto-fundo e ignorar os elementos gráficos. A WCAG 2.1 (critério 1.4.11) exige contraste mínimo de 3:1 para componentes de interface — o que inclui:
- Borda de input em estado normal e foco
- Ícones que comunicam informação (não decorativos)
- Indicadores de estado em checkboxes e radio buttons
- Barras de progresso e gráficos informativos
Se o seu input tem borda #cccccc sobre fundo branco #ffffff, o contraste é 1.6:1 — reprova. Uma borda #767676 teria 4.54:1 — passa com folga. Esse detalhe afeta diretamente a experiência de usuários com baixa visão que dependem de bordas para identificar campos interativos.
Os 5 pares de cor mais críticos para validar na sua paleta
Não é necessário testar todas as combinações possíveis. Os pares abaixo cobrem os contextos de maior risco e aparecem em praticamente todo produto digital:
1. Texto de label sobre botão primário O par mais óbvio e o que mais reprova. Texto branco sobre tons de cor saturada (vermelho, laranja, amarelo) frequentemente falha — o amarelo #FFFF00 sobre branco tem contraste de 1.07:1, mas mesmo sobre fundo escuro, texto branco sobre amarelo tem apenas 1.07:1. Valide sempre antes de fixar o tom do botão.
2. Texto de corpo sobre fundo de página Aparentemente simples, mas problemático quando o fundo não é branco puro. Se o fundo é brand-50 (um off-white levemente colorido), o contraste com texto brand-900 pode ser diferente do contraste com #000000. Teste com os valores exatos dos seus tokens.
3. Texto de placeholder sobre fundo de input Placeholder costuma ser um cinza claro por design — mas cinza claro sobre fundo branco frequentemente reprova. O placeholder precisa passar em 4.5:1 tanto quanto o texto preenchido.
4. Ícone de status sobre superfície de card Ícones de erro, alerta e sucesso precisam de 3:1 contra o fundo onde aparecem. Um ícone vermelho #FF4444 sobre fundo branco tem 3.94:1 — passa para elemento não-textual. Mas o mesmo ícone sobre fundo brand-50 (um off-white levemente rosado) pode reprovar.
5. Texto de link no meio de parágrafo Links em contexto de texto precisam ser distinguíveis do texto ao redor por mais de apenas cor — mas se a distinção for só sublinhado, o contraste do link em si ainda precisa passar em 4.5:1 contra o fundo.
Como validar contraste antes de implementar
O fluxo de validação integrado à geração da escala
A forma mais eficiente de garantir conformidade WCAG é validar durante a geração da escala, não depois. No nosso gerador de paleta de cores para design system, o slider de Contrast Shift controla diretamente a separação de luminância entre os tons — quanto maior o valor, maior a diferença entre o 50 e o 950.
O processo prático:
- Gere a escala com Contrast Shift em 0 (padrão)
- Teste o par mais crítico: texto
brand-900sobre fundobrand-50 - Se reprovar, aumente o Contrast Shift em incrementos de 0.5 e regere
- Repita até o par mais crítico passar
- Exporte e documente os pares validados junto com os tokens
Esse fluxo garante que a escala exportada já nasce com os requisitos de contraste incorporados — sem precisar de ajuste manual posterior.
Ferramentas de contraste que funcionam no dia a dia
Colour Contrast Analyser (TPGi) — aplicativo desktop gratuito, funciona com pipeta diretamente na tela. Indispensável para validar designs no Figma sem precisar copiar códigos HEX.
Stark (plugin Figma) — valida contraste, simula daltonismo e gera relatórios de acessibilidade diretamente no arquivo de design. A versão gratuita cobre a maioria dos casos.
WebAIM Contrast Checker — ferramenta web simples e rápida para validar pares específicos. Útil para testes rápidos sem instalar nada.
Chrome DevTools — o painel de acessibilidade do Chrome mostra o contraste de qualquer elemento na página em tempo real. Essencial para validar a implementação no código.
Daltonismo no design system: o erro que aparece depois
Cerca de 8% dos homens e 0,5% das mulheres têm alguma forma de deficiência cromática. Isso significa que em um produto com 100 mil usuários, aproximadamente 4 a 5 mil não percebem as cores da forma como foram projetadas. Em produtos B2B com times predominantemente masculinos, essa proporção pode ser ainda mais relevante.
O problema não é o daltonismo em si — é projetar como se ele não existisse.
Os três tipos de daltonismo e como cada um afeta sua paleta
Protanopia (insensibilidade ao vermelho): afeta a percepção de vermelhos e rosas. Cores de erro em vermelho podem parecer marrons ou cinzas. Afeta aproximadamente 1% dos homens.
Deuteranopia (insensibilidade ao verde): o tipo mais comum, afetando cerca de 5% dos homens. Verdes e vermelhos ficam indistinguíveis — o par clássico de “sucesso vs. erro” colapsa completamente.
Tritanopia (insensibilidade ao azul): mais rara, afeta a percepção de azuis e amarelos. Menos impacto em design systems típicos, mas relevante em paletas com forte uso de azul.
A simulação de daltonismo no Figma (via plugin Stark ou Colour Blind) mostra exatamente como sua paleta aparece em cada condição. Faça isso uma vez por escala gerada — leva menos de cinco minutos e revela problemas que nenhum checker de contraste detecta.
A regra que elimina 90% dos problemas
Nunca use cor como único meio de comunicar informação.
Erro não pode ser apenas vermelho. Sucesso não pode ser apenas verde. Se converter sua interface para escala de cinza tornar alguma informação incompreensível, o design está acessível apenas para parte dos usuários.
A solução é sempre combinar cor com pelo menos um outro sinal visual: ícone, texto, forma, padrão ou posição. Um campo com erro pode ser vermelho e ter um ícone de ⚠ e um texto de erro abaixo — qualquer um dos três sinais, isoladamente, comunica o problema. Para o usuário com daltonismo que não vê o vermelho, o ícone e o texto funcionam. Para o usuário em contexto de alta velocidade que não leu o texto, a cor funciona.
Essa abordagem está diretamente ligada ao design inclusivo — projetar para o espectro completo de usuários, não para a maioria.
Tokens de cor acessíveis: como documentar restrições de uso
Gerar uma escala com bom contraste resolve metade do problema. A outra metade é garantir que ninguém no time use os tokens de forma incorreta — colocando texto sobre um tom que não tem contraste suficiente.
A documentação de design tokens acessíveis precisa incluir, para cada token semântico de cor, as restrições de uso. O formato mais prático é uma tabela de pares permitidos:
| Token de fundo | Texto permitido (≥ 4.5:1) | Texto proibido (< 4.5:1) |
|---|---|---|
color.surface.base (brand-50) | brand-700, brand-800, brand-900 | brand-400, brand-500, brand-600 |
color.action.primary (brand-600) | #ffffff, brand-950 | brand-100, brand-200 |
color.feedback.error (red-600) | #ffffff, red-950 | red-100, red-200, red-300 |
Essa tabela vive na documentação do design system — no Figma, no Storybook ou onde o time consulta as regras de uso. Quando um desenvolvedor precisa colocar texto sobre um fundo de card, a tabela diz imediatamente quais tokens de texto são permitidos. Não há julgamento visual, não há teste manual: a decisão já está documentada.
Acessibilidade em dark mode: o problema que a maioria ignora
Dark mode introduz uma camada adicional de complexidade que a maioria dos times subestima: os mesmos pares de cor que passam no modo claro frequentemente falham no modo escuro, porque a lógica de contraste se inverte.
No modo claro, texto escuro sobre fundo claro é a combinação padrão — fácil de atingir contraste alto. No modo escuro, texto claro sobre fundo escuro parece simétrico, mas as curvas de luminância não são. O olho humano percebe diferenças de luminância de forma não-linear: a mesma proporção matemática de contraste parece menor no modo escuro do que no claro.
O processo correto para dark mode:
- Defina os tokens semânticos de modo escuro (invertendo a hierarquia de superfície)
- Valide cada par de texto-fundo independentemente no modo escuro — não assuma que o que passou no claro vai passar no escuro
- Documente os pares permitidos para cada tema separadamente
Use nosso gerador de paleta para gerar a escala completa e identifique quais tons funcionam como texto no modo escuro (geralmente 50-200) e quais funcionam como fundo (geralmente 800-950). Os tons intermediários (400-600) costumam ser problemáticos em ambos os modos — contraste insuficiente tanto sobre fundo claro quanto sobre fundo escuro.
O impacto financeiro da acessibilidade digital vai muito além do compliance: produtos acessíveis têm menor taxa de abandono, menor volume de suporte e maior alcance de mercado. Resolver acessibilidade cromática na camada de escala custa horas — resolver depois que o sistema está em produção custa semanas.
Se o seu design system está em construção e você quer garantir que a paleta já nasce acessível, a CamaraUX trabalha com equipes nesse processo — da geração de escala à documentação de tokens e validação de componentes. Fale com a gente para entender como podemos ajudar no seu projeto.
Perguntas frequentes sobre acessibilidade cromática
O que é proporção de contraste WCAG?
É a relação entre a luminância relativa de duas cores — geralmente texto e fundo. A fórmula calcula quanto uma cor é mais brilhante que a outra, em uma escala de 1:1 (sem contraste) a 21:1 (máximo, preto sobre branco). A WCAG AA exige mínimo de 4.5:1 para texto normal e 3:1 para texto grande e elementos de interface.
Qual a diferença entre WCAG AA e AAA para cores?
AA exige 4.5:1 para texto normal e 3:1 para texto grande — é o padrão de mercado para a maioria dos produtos. AAA eleva para 7:1 e 4.5:1 respectivamente, e é recomendado para produtos de saúde, financeiros ou governamentais. O W3C reconhece que AAA total nem sempre é viável, mas os critérios AAA devem ser atingidos onde possível.
Preciso validar contraste para ícones também?
Sim. A WCAG 2.1 (critério 1.4.11) exige contraste mínimo de 3:1 para componentes de interface não-textuais que comunicam informação — o que inclui ícones de status, bordas de inputs, indicadores de progresso e qualquer elemento gráfico informativo. Ícones puramente decorativos estão isentos.
Como testar minha paleta para daltonismo?
Use o plugin Stark no Figma ou o Colour Blind (também no Figma) para simular Protanopia, Deuteranopia e Tritanopia diretamente no seu arquivo de design. Para validação no navegador, o Chrome DevTools tem simulação de deficiência visual na aba Rendering. O objetivo não é que as cores pareçam iguais para todos — é que as informações permaneçam compreensíveis independente da percepção cromática.
Dark mode exige validação de contraste separada?
Sim, sempre. Os pares de cor que passam no modo claro não necessariamente passam no modo escuro. Valide cada par texto-fundo para cada tema de forma independente. Na prática, isso significa manter uma tabela de pares permitidos para o tema claro e outra para o tema escuro na documentação do design system.
Existe alguma lei brasileira que exige conformidade WCAG?
A Lei Brasileira de Inclusão (Lei 13.146/2015) e o Decreto 5.296/2004 estabelecem obrigações de acessibilidade digital para sites governamentais e serviços públicos. Para o setor privado, a conformidade não é legalmente obrigatória na maioria dos casos, mas é exigida por contratos com entidades públicas, por políticas de grandes plataformas (Apple App Store, Google Play) e se tornou critério de avaliação em processos de due diligence em investimentos.
