--- title: "Acessibilidade Cromática no Design System: Como Garantir WCAG AA com sua Paleta de Cores" date: 2026-05-03T04:50:45Z modified: 2026-07-29T01:41:49Z permalink: "https://camaraux.com.br/acessibilidade-cores-design-system/" type: post status: publish excerpt: Paleta aprovada no visual, reprovada no WCAG. Veja como validar contraste, daltonismo e dark mode antes que o design system entre em produção. wpid: 5960 categories: - Design Systems tags: - Design Systems - Acessibilidade - acessibilidade digital - contraste de cores - daltonismo - dark mode - Design Inclusivo - Design System - tokens de cor - UI Design - wcag rank_math_title: "Acessibilidade Cromática no Design System: WCAG AA" rank_math_description: "Como garantir WCAG AA na Acessibilidade Cromática do design system: os 5 pares críticos, daltonismo, dark mode e como documentar tokens.\\n" rank_math_focus_keyword: Acessibilidade Cromática,acessibilidade,Design System,cores featured_image: /wp-content/uploads/2026/05/Acessibilidade-cromatica-em-design-system.webp featured_image_alt: Acessibilidade Cromática no Design System Ilustração isométrica minimalista de verificação de contraste de cores e acessibilidade em interface digital em tons de roxo author: Lucas Camara timestamp: 2026-07-29T01:41:49Z --- 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-systems-figma.md), 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](https://camaraux.com.br/ferramentas/gerador-paleta-cores-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: 1. Gere a escala com Contrast Shift em 0 (padrão) 2. Teste o par mais crítico: texto `brand-900` sobre fundo `brand-50` 3. Se reprovar, aumente o Contrast Shift em incrementos de 0.5 e regere 4. Repita até o par mais crítico passar 5. 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. ![Simulação de Deuteranopia na ferramenta de paleta de cores CamaraUX — como a escala 50 a 950 aparece para usuários com daltonismo verde](https://camaraux.com.br/wp-content/uploads/2026/05/Captura-de-Tela-2026-05-03-as-01.57.59-2048x1272.webp "Camaraux, consultoria em UX design, projetos centrados no usuário") Simulação de Deuteranopia (daltonismo verde) ativa via Chrome DevTools — a escala gerada pela ferramenta vista por quem tem dificuldade em distinguir tons de verde. ### 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-inclusivo-praticas-beneficios.md) — 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-tokens-arquitetura-w3c.md) 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: 1. Defina os tokens semânticos de modo escuro (invertendo a hierarquia de superfície) 2. Valide cada par de texto-fundo **independentemente** no modo escuro — não assuma que o que passou no claro vai passar no escuro 3. Documente os pares permitidos para cada tema separadamente Use nosso [gerador de paleta](https://camaraux.com.br/ferramentas/gerador-paleta-cores-design-system/) 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/impacto-financeiro-acessibilidade-digital-lucro.md) 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. ![Comparação de paleta de cores em Light Mode e Dark Mode — Brand Colors, Neutral Colors e Feedback Colors com tokens semânticos](https://camaraux.com.br/wp-content/uploads/2026/05/Dark-mode-e-acessibilidade-digital.webp "Camaraux, consultoria em UX design, projetos centrados no usuário") A mesma paleta em modo claro e escuro, os tokens semânticos invertem a hierarquia de superfície sem alterar a escala primitiva.--- 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/page/contato.md) 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. ## Topics **Categorias:** [Design Systems](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/category/design-systems.md) **Tags:** [Acessibilidade](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/acessibilidade.md), [acessibilidade digital](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/acessibilidade-digital.md), [contraste de cores](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/contraste-de-cores.md), [daltonismo](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/daltonismo.md), [dark mode](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/dark-mode.md), [Design Inclusivo](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/design-inclusivo.md), [Design System](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/design-system.md), [tokens de cor](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/tokens-de-cor.md), [UI Design](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/ui-design.md), [wcag](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/wcag.md)