Contraste de cores acessível: WCAG sem a massa cinzenta.
Como projetar para o contraste das WCAG 2.2 sem deixar sua marca completamente cinza. Proporções, APCA, exemplos reais de sistemas de design e um fluxo de trabalho de teste tokenizado.
A acessibilidade e a personalidade do design não são conflitantes. Esse é o mito que a maioria das equipes de branding conta a si mesmas quando evitam a discussão sobre contraste, e é também por isso que tantas reformulações de marcas "acessíveis" acabam parecendo placas de aeroporto.
O contraste de cores acessível é um problema de mensuração. Os sistemas de design modernos já o resolveram na camada token, o que significa que você não precisa escolher entre atingir o WCAG e manter a marca interessante. Você só precisa conhecer as regras, saber onde as regras falham e saber onde o trabalho realmente acontece.
Por que o contraste é a única regra que você não pode ignorar
Cerca de 300 milhões de pessoas enxergam as cores de forma diferente da paleta básica, e ainda mais usam interfaces em ambientes com pouca luz, em telas de baixa qualidade ou com perda parcial de visão que ninguém relatou.
O baixo contraste é a falha de acessibilidade mais comum na web. E também a mais fácil de corrigir. Pontos cegos, daltonismo, brilho excessivo, cansaço visual, monitores de baixa qualidade, luz solar direta na tela do celular. Todos esses fatores se resumem à mesma solução: contraste suficiente entre o texto e o fundo para que a mensagem sobreviva mesmo nas situações mais adversas, e não apenas na tela Retina do designer.
O custo de errar nesse ponto não é apenas a exclusão. É a exposição a problemas de conformidade. A Lei Europeia de Acessibilidade, a Seção 508 nos EUA, a Lei de Acessibilidade para Ontarianos com Deficiência (AODA) em Ontário e uma lista crescente de leis nacionais utilizam as WCAG como referência legal. O contraste é um dos primeiros aspectos verificados em uma auditoria, pois é um dos primeiros a apresentar problemas.
Regras de Contraste das WCAG 2.2 em Linguagem Simples
As WCAG fornecem três números: 4,5:1, 3:1 e 3:1, e cada um se aplica a um tipo específico de elemento de interface do usuário.
| Elemento | Mínimo AA | Mínimo AAA | Notas |
|---------|-----------|-------------|-------| | Texto principal | 4,5:1 | 7:1 | Qualquer texto menor que 18pt normal ou 14pt negrito | | Texto grande | 3:1 | 4,5:1 | 18pt ou mais normal ou 14pt ou mais negrito | | Componentes e gráficos da interface do usuário | 3:1 | Não especificado | Botões, ícones, bordas de formulários, anéis de foco | | Texto em logotipos ou imagens decorativas | Isento | Isento | Elementos da marca e texto incidental não contam |
AA é o nível que a maioria dos produtos comerciais busca e que a maioria das leis de acessibilidade exige. AAA é uma meta mais rigorosa, usada principalmente por órgãos governamentais, instituições de saúde e educação. A menos que alguém lhe entregue um documento de conformidade dizendo AAA, AA é o mínimo exigido.
A armadilha em que a maioria dos designers cai é esquecer a regra de 3:1 para textos não textuais. Uma borda de campo de formulário com proporção de 2:1 em relação ao fundo da página falha, mesmo que o rótulo dentro dela seja aprovado. Um anel de foco com contraste insuficiente falha. Um ícone cujo significado depende da cor em uma proporção de 2,5:1 falha. O contraste em elementos não textuais não é opcional.
Por que a matemática do WCAG frequentemente está errada
O WCAG relações de contraste é uma fórmula de 30 anos que ignora a percepção visual, razão pela qual às vezes aprova cores que parecem terríveis e reprova cores que parecem boas.
A fórmula do WCAG 2 baseia-se apenas na luminância. Ela trata o texto sobre fundo como uma relação linear entre o brilho relativo de duas cores. Não é assim que o sistema visual humano realmente lê o contraste.
O contraste perceptual real depende da espessura da fonte, do tamanho da fonte, da temperatura da cor e do que o olho estava observando um segundo antes. O WCAG 2 não leva em consideração nenhum desses fatores. O resultado é uma proporção que trata o texto cinza claro sobre fundo branco da mesma forma que o texto preto sobre fundo cinza claro, embora um seja legível e o outro seja desconfortável.
Como o APCA resolve o problema de percepção
O APCA, Algoritmo de Contraste Perceptual Acessível, mede o contraste da maneira como a visão humana realmente funciona, e é por isso que a versão preliminar do WCAG 3 o propõe como substituto.
As pontuações do APCA variam de 0 (nenhum contraste) a aproximadamente 108 (contraste extremo). Ao contrário do WCAG 2, ele leva em conta a espessura do texto, o tamanho do texto e a polaridade (claro sobre escuro versus escuro sobre claro se comportam de maneira diferente para o olho).
Limiares aproximados de acessibilidade (APCA) para textos comuns:
- Corpo do texto (16px normal): 75+ (obrigatório), 90+ (ideal)
- Corpo do texto pequeno (14px normal): 90+ (obrigatório)
- Texto grande (24px+): 60+ (obrigatório)
- Interface de usuário não textual: 45+ mínimo
A acessibilidade (APCA) ainda não é legalmente exigida em nenhum lugar. Mas produtos comerciais já a utilizam como padrão interno, pois ela se correlaciona melhor com o que realmente proporciona boa legibilidade. A estratégia inteligente é atender aos requisitos de conformidade com as Diretrizes de Acessibilidade para Conteúdo Web (WCAG) versão 2.0 (AA) e aos requisitos de acessibilidade (APCA) para qualidade real. Alcançar ambos os objetivos simultaneamente não é difícil se seus fichas de cor forem projetados para isso.
Quatro Sistemas de Design: Tokenização de Contraste
Esses sistemas já codificam a acessibilidade na camada de tokens, portanto, os designers escolhem uma função em vez de calcular uma proporção.
Cores Radix
O Radix Colors oferece escalas de 12 níveis, com cada nível pré-atribuído a uma função. Os níveis 11 e 12 são os níveis de texto de alto contraste, com garantia de aprovação no WCAG AA em comparação com os níveis inferiores. Os tokens de função (text, textContrast, solid, solidHover) significam que os designers nunca precisam calcular uma proporção. Eles escolhem uma função.
O que aproveitar: o modelo de contraste numerado por função. Qualquer designer que utilize o nível 11 sabe que ele é aprovado em comparação com os níveis mais claros da mesma escala. A proporção está codificada no próprio número do nível.
Material Design 3
Veja ao vivo em m3.material.io
O Material 3 emparelha cada função de cor com uma contraparte on- (on-primary, on-surface, on-error) que garante uma proporção de 4,5:1 em relação à sua cor original. Os tokens emparelhados formam a camada de acessibilidade, integrada diretamente ao sistema.
O que aproveitar: o padrão on-. Quando um designer usa on-primary para texto, a acessibilidade é automática. Não há como errar na escolha.
Mais dois: Proporções e Sistemas Perceptuais
Radix e Material resolvem o contraste por meio do emparelhamento de funções. Os dois próximos resolvem por meio de proporções documentadas e escalas perceptualmente uniformes. Ambas as abordagens funcionam. Vale a pena aproveitar ambas.
GitHub Primer
O Primer separa os tokens de primeiro plano, plano de fundo e borda em camadas explícitas com taxas de contraste documentadas. Seus fg.default e bg.default são publicados com as taxas exatas, e cada token semântico baseado em função recebe o mesmo tratamento.
O que aproveitar: publicar as taxas ao lado dos tokens. Quando o contraste de cada token em relação a cada plano de fundo relevante é documentado, designers e desenvolvedores podem ignorar completamente a verificação.
Adobe Spectrum
Veja ao vivo em spectrum.adobe.com
O Spectrum usa escalas de cores perceptualmente uniformes, de modo que dois tokens com o mesmo número de etapa tenham o mesmo peso visual em todas as tonalidades. Isso significa que a troca de tonalidades dentro de um tema preserva as relações de contraste. Chega de "aprovado em azul, mas reprovado em laranja".
O que aproveitar: uniformidade perceptual. Escalas baseadas em modelos perceptuais (como HSLuv, OKLCH ou a abordagem personalizada da Spectrum) tornam a acessibilidade portátil em diferentes temas de marca.
Como manter a acessibilidade sem perder a personalidade
A acessibilidade não significa texto preto sobre fundo branco e uma marca apagada, e as equipes que entregam os produtos mais inclusivos são as que descobriram isso.
O segredo está em onde a acessibilidade reside na estrutura. Se estiver na camada de tokens, a marca pode ser vibrante e os designers ainda obtêm resultados acessíveis. Se estiver na revisão final, cada cor da marca se torna um problema, pronta para reprovar em uma auditoria.
Três técnicas mantêm personalidade e acessibilidade no mesmo ambiente:
-
Divida a camada de cores de destaque em uma cor da marca e uma cor de ação acessível. ⟦MARCA1⟧ usa um roxo específico para momentos da marca e um roxo ligeiramente diferente para elementos interativos. Ambos são reconhecidamente da marca. Apenas um deles é garantido em todas as superfícies.
-
Use escalas perceptualmente uniformes. OKLCH e HSLuv mapeiam valores de cor para o brilho percebido, permitindo que você alterne entre tonalidades sem quebrar o contraste. Radix, Spectrum e Material 3 fazem variações disso.
-
Inclua o modo escuro como um conjunto de tokens paralelo, não como uma solução posterior. Um token que falha no modo escuro não está pronto para o modo escuro. Se o seu sistema resolve
text-defaultpara uma cor no modo claro e uma cor diferente no modo escuro, ambos os valores devem ser aprovados em sua superfície correspondente.
O pior resultado é o compromisso que ninguém pediu: uma marca apagada que ainda não é acessível. Isso acontece quando as equipes reagem ao feedback de contraste dessaturando todas as cores em vez de corrigir os pares. Dessaturação não é o mesmo que acessibilidade. Relações, sim.
O Fluxo de Trabalho de Teste de Acessibilidade
Testar o contraste é barato, automatizado e completamente inútil se você deixar para a revisão do design.
O fluxo de trabalho que funciona executa verificações de contraste em quatro pontos, não apenas um.
- Na definição do token. Quando um token é criado, suas superfícies permitidas também são definidas.
text-defaultsó é permitido embg-default,bg-subtleebg-raised. O contraste do token em relação a cada um é verificado uma vez e bloqueado. - No commit do componente. O Storybook, juntamente com uma integração com axe-core ou pa11y, executa verificações de acessibilidade em cada variante do componente como parte da CI. Qualquer nova variante que falhe é bloqueada antes da mesclagem.
- Na entrega do arquivo de design. Plugins como o Stark ou o verificador WCAG integrado sinalizam problemas dentro da ferramenta de design. Detecte-os em tempo de design, não em tempo de revisão.
- No nível da página. O Lighthouse, o axe DevTools ou o pa11y são executados em páginas ativas em ambientes de teste ou produção. Isso detecta falhas do mundo real (embeds de terceiros, conteúdo gerado pelo usuário, temas dinâmicos) que os testes de componentes não detectam.
O objetivo não é executar mais ferramentas. O objetivo é antecipar a verificação. Uma falha de contraste encontrada por um pipeline de CI é corrigida em cinco minutos. A mesma falha detectada em uma auditoria pré-lançamento custa à equipe uma semana. Pelo motivo estrutural que essa abordagem em camadas funciona, o guia de sistemas de projeto explica por que o pensamento baseado em tokens é mais eficaz. E o artigo A regra 60-30-10 foi quebrada. explica por que a cor baseada em funções (da qual a acessibilidade depende) substituiu o pensamento baseado em proporções.
Perguntas Frequentes
O nível AA das WCAG é suficiente ou preciso do AAA?
O AA é o padrão para a maioria dos produtos comerciais e para a maioria das leis de acessibilidade. O AAA só é legalmente exigido em contextos específicos (governo, saúde, educação) e é caro de alcançar sem simplificar a paleta de cores. Busque o AA como mínimo e o ideal APCA como máximo.
Todos os elementos não textuais precisam atender às taxas de contraste?
Componentes de interface do usuário não textuais que transmitem significado precisam de uma taxa de contraste mínima de 3:1, de acordo com as WCAG 2.2. Isso inclui botões, bordas de formulários, anéis de foco, ícones com significado e elementos gráficos. Elementos puramente decorativos (padrões de fundo, gradientes de ambiente) são isentos. Textos incidentais (como um logotipo ou uma legenda sobreposta em uma foto) também são isentos.
Qual a diferença entre WCAG e APCA?
WCAG 2 é o padrão legal atual, baseado em uma fórmula de luminância de 30 anos. APCA é a proposta de substituição na versão preliminar do WCAG 3, baseada em como a percepção humana realmente funciona. As pontuações do APCA têm melhor correlação com a legibilidade real, mas ainda não são legalmente exigidas. Produtos comercializados utilizam ambos: WCAG 2 para conformidade e APCA para qualidade.
Incorporando Acessibilidade aos Tokens
O contraste de cores acessível não é uma escolha de estilo. É uma propriedade do sistema.
As equipes que lançam os produtos mais inclusivos e alinhados à marca são aquelas que deixaram de tratar a acessibilidade como uma reflexão tardia e passaram a tratá-la como uma propriedade do próprio paleta de cores.
Os tokens codificam as proporções. As escalas codificam os pares. Os testes são realizados em quatro pontos do fluxo de trabalho. Ninguém está usando um verificador de contraste na tela antes do lançamento.
Se o seu processo atual envolve um designer avaliando visualmente uma paleta de cores para verificar se "parece legível", você vai falhar na auditoria. Se o seu processo envolve uma ferramenta de verificação mais revisões manuais, você vai falhar em grande escala. Se o seu processo envolve tokens baseados em funções que codificam a acessibilidade na camada de definição, você vai lançar o produto com sucesso.
Crie os tokens. Publique as proporções. Automatize as verificações. A marca permanece vibrante, a interface permanece legível e a auditoria se torna uma formalidade em vez de uma reconstrução.
Need a color system that hits WCAG without flattening the brand? Brainy builds token-layer accessibility into every palette.
Get Started
