Gerador de paleta de cores acessível

O que é um gerador de paleta de cores acessível?

Um gerador de paleta de cores acessível é uma ferramenta que ajuda voce a montar um conjunto de cores para um site, aplicativo ou design impresso onde cada par de cores destinado a ser exibido junto (texto sobre fundo, botão sobre tela, rótulo sobre campo) atende aos requisitos de contraste WCAG. O objetivo é capturar combinações de baixo contraste em tempo de design em vez de tempo de auditoria. Voce adiciona cores a uma paleta, a ferramenta calcula a relação de contraste entre cada par e rotula cada par como AAA passa, AA passa, ou falha. Voce itera até que cada par que realmente pretende usar passe.

A relação de contraste é um número entre 1:1 (cores identicas, invisível) e 21:1 (preto sobre branco). WCAG 2.2 Critério de Sucesso 1.4.3 requer 4,5:1 para texto do corpo em tamanho padrão (Nível AA), 3:1 para texto grande (24px+ regular ou 18,66px+ negrito) e 4,5:1 para elementos gráficos e controles de UI (SC 1.4.11). WCAG AAA eleva o texto do corpo para 7:1 e o texto grande para 4,5:1. A maioria dos sites voltados ao público deve atender pelo menos a AA por ADA, EAA, AODA e leis semelhantes; sites governamentais em muitas jurisdições devem atender a AAA.

Esta ferramenta é executada no seu navegador. Voce escolhe cores com o seletor de cores, a ferramenta calcula a luminancia relativa e as relações de contraste usando a fórmula especificada por WCAG, e uma grade mostra o status de cada par. Voce pode exportar a paleta final como propriedades personalizadas CSS (var(--brand-primary)), lista HEX, snippet de configuração Tailwind ou JSON para tokens de design. Nada é enviado; toda a paleta permanece no seu dispositivo.

O que há dentro da ferramenta

O topo da ferramenta é um seletor de cores mais um botão adicionar à paleta. Escolha uma cor, nomeie-a (Marca Primária, Superfície, Texto do Corpo, etc.), e adicione. A paleta cresce como uma lista de amostras no lado esquerdo. Voce pode editar qualquer amostra, removê-la ou arrastar para reordenar. Paletas acessíveis predefinidas estão disponíveis como pontos de partida (pares de alto contraste, paletas projetadas estilo IBM Carbon, paletas tonais do Material Design 3); escolha uma, depois personalize.

A grade de contraste pega cada par de amostras e mostra a relação de contraste mais um emblema aprovado/reprovado para cada nível WCAG: AA-normal (4,5:1), AA-large (3:1), AAA-normal (7:1), AAA-large (4,5:1). Um par mostrado como 4,7:1 passa AA-normal mas falha AAA-normal; um par mostrado como 2,1:1 falha em tudo. Passe o cursor sobre uma célula para visualizar o par como texto real. Classifique a grade por relação para detectar primeiro os piores pares.

O painel de exportação formata a paleta da maneira que sua cadeia de ferramentas espera: propriedades personalizadas CSS para CSS moderno, variáveis Sass para pipelines mais antigos, configuração de tema Tailwind para Tailwind CSS, tokens de design JSON (Style Dictionary, especificação W3C Design Tokens Community Group) para sistemas de design multiplataforma, ou apenas uma lista HEX para colar no Figma. As convenções de nomenclatura são preservadas; voce pode copiar e colar diretamente em sua base de código.

História e contexto

A colorimetria CIE estabelece a cor científica (1931)

A Comissão Internacional de Iluminação (CIE) publicou o espaço de cor CIE 1931 em 1931, a primeira descrição matemática formal de como os humanos percebem a cor a partir de espectros eletromagnéticos. Cada sistema de cor moderno (RGB, HSL, OKLCH, Lab, XYZ) é construído sobre CIE 1931 diretamente ou através de transformações derivadas. A fórmula de luminancia relativa que o WCAG usa para calcular o contraste é um cálculo derivado do CIE: ela pondera os canais vermelho, verde e azul pela força com que o olho humano responde a cada um (verde mais, azul menos).

WCAG 1.0 introduz diretrizes de contraste (1999)

As Diretrizes de Acessibilidade para Conteúdo Web 1.0 (W3C, maio de 1999) introduziram o contraste como critério formal de acessibilidade (Ponto de Verificação 2.2: certifique-se de que as combinações de cores de primeiro plano e fundo forneçam contraste suficiente). A primeira versão era qualitativa; o limiar era vago. WCAG 2.0 (dezembro de 2008) foi a primeira a especificar relações de contraste numéricas usando a fórmula de luminancia relativa WCAG. Os limiares 4,5:1 e 7:1 em 2.0 foram mantidos inalterados em 2.1 (2018) e 2.2 (2023) porque equilibram a legibilidade na maioria das deficiencias (baixa visão, perda de sensibilidade ao contraste relacionada à idade, daltonismo) com restrições práticas de design.

Sistemas de design codificados por cor amadurecem (2014 em diante)

Material Design do Google (2014), Carbon Design System da IBM (2015) e a ascensão mais ampla dos tokens de design (Salesforce 2014, Atlassian 2016) colocaram em primeiro plano a cor acessível como uma preocupação em nível de sistema. Material Design 3 (2021) introduziu paletas tonais (uma rampa de luminosidade de 13 etapas por matiz) explicitamente projetadas para que qualquer tom 600+ na escala de luminosidade passe pelo contraste 4,5:1 em branco. Essa mudança tornou as paletas acessíveis por padrão prática padrão em sistemas de design modernos, substituindo a antiga abordagem de marca primeiro acessibilidade depois.

APCA proposto como alternativa mais precisa (2019 em diante)

O Algoritmo de Contraste Perceptual Acessível (APCA) foi proposto por Andrew Somers a partir de 2019 como uma substituição perceptualmente mais precisa para a fórmula de contraste WCAG. O contraste WCAG superestima a legibilidade de cores claras e subestima o texto escuro em fundos escuros; APCA corrige isso. Espera-se que o WCAG 3.0 (o rascunho sucessor do 2.x, em desenvolvimento por muitos anos agora) adote APCA ou um algoritmo melhorado similar. Até que WCAG 3 seja lançado e adotado na lei, as relações de contraste WCAG 2.x permanecem o padrão legal e industrial. Esta ferramenta usa a fórmula WCAG 2.x.

Os tokens de design se tornam o padrão multiplataforma (2020 em diante)

O W3C Design Tokens Community Group foi formado em 2020 para padronizar os tokens de design (valores nomeados de cor, espaçamento, tipografia que se traduzem em CSS, iOS, Android, Figma e outras plataformas). Ferramentas como Style Dictionary, Tokens Studio e a especificação W3C emergente dependem todas de formatos de token legíveis por máquina. Paletas de cores acessíveis são cada vez mais entregues como tokens de design para que a mesma paleta verificada seja usada em todos os lugares, eliminando o modo de falha onde o site passa o contraste mas o aplicativo móvel não.

OKLCH e espaços de cor perceptualmente uniformes (2020 em diante)

CSS Color Module Level 4 (Recomendação Candidata 2024) adicionou OKLCH, OKLab, Lab, LCH e outros espaços de cor perceptualmente uniformes ao CSS nativo. OKLCH (introduzido por Bjorn Ottosson em 2020) é particularmente útil para gerar paletas acessíveis porque etapas de luminosidade iguais parecem iguais ao olho, ao contrário de HSL onde etapas de luminosidade produzem saltos visuais desiguais. Geradores de paleta modernos (Leonardo da Adobe, Polychrom, esta ferramenta quando definida no modo de entrada OKLCH) aproveitam esses espaços para produzir paletas visualmente mais consistentes que atendem aos alvos de contraste no mesmo nível de luminosidade.

Fluxos de trabalho práticos

Projetando uma nova paleta de marca

Comece com a cor da marca que voce deve manter (a cor do logotipo, a primária abençoada pela equipe de marketing). Adicione-a à paleta, depois construa tonalidades (versões mais claras) e sombras (versões mais escuras) junto com neutros (branco, superfície, variante de superfície, texto). Verifique cada par texto-sobre-fundo contra AA-normal. Se sua cor de marca primária falhar em branco, voce tem duas opções: use-a apenas para elementos grandes (logotipos, acentos decorativos) e pareie o texto do corpo com uma variante mais escura, ou comprometa ligeiramente a cor da marca. Esta ferramenta traz à tona essas escolhas em tempo de design.

Auditando as decisões de cor de um site existente

Puxe os valores de cor dos seus tokens de design existentes (propriedades personalizadas CSS, configuração Tailwind, variáveis Sass), insira-os nesta ferramenta e revise a grade de contraste. Falhas comuns: texto cinza fosco em branco (frequentemente #999 ou #aaa, que dá 2,8:1 ou 2,5:1), botões cor de marca com texto branco onde o botão é de meio-tom, cores de link em fundos ocupados. Documente as falhas com suas relações e qual critério WCAG elas violam; essa documentação é o início de um plano de remediação.

Escolhendo cores de acento para gráficos e visualização de dados

Para visualização de dados, voce precisa de cores de acento que passem pelo contraste contra o fundo do gráfico e que também sejam distinguíveis entre si para usuários com deficiencia de visão de cores. Pareie esta ferramenta com ColorBrewer (Cynthia Brewer, Penn State, 2002) que publica paletas projetadas para permanecerem distinguíveis sob simulações de daltonismo. Execute paletas candidatas através de ambas as ferramentas: contraste contra fundo (esta ferramenta), distinguibilidade entre cores da paleta (ColorBrewer ou Viz Palette).

Construindo complementos de modo escuro para uma paleta clara

Modo escuro não é apenas modo claro invertido; os requisitos de contraste ainda se aplicam, mas o olho percebe texto claro sobre escuro diferente de texto escuro sobre claro (o debate APCA é em grande parte sobre isso). Construa a paleta escura como um conjunto paralelo de tokens nomeados (surface-dark, text-dark, accent-dark) e verifique cada par do modo escuro contra AA. Falhas comuns do modo escuro: branco puro (#fff) sobre preto puro (#000) causa halação (luz sangrando), então designers frequentemente usam #e5e5e5 sobre #121212; isso ainda passa AA mas é mais confortável de ler.

Gerando variantes de paleta para diferentes superfícies

UIs modernas tem múltiplos níveis de superfície (fundo, cartão, cartão-elevado, modal, popover). Cada superfície deve emparelhar corretamente com cada cor de texto e acento usada por cima. Adicione cada superfície como amostra de paleta e verifique cada cor de texto contra cada superfície. A grade de contraste mostra rapidamente se seu par texto-sobre-modal falha quando texto-sobre-cartão passa (o modal geralmente tem uma tonalidade de fundo ligeiramente diferente para indicar elevação, o que pode reduzir o contraste abaixo de AA sem voce perceber).

Documentação de conformidade para submissão legal ou auditoria

Para documentação de conformidade ADA ou EAA, voce geralmente precisa mostrar que cada combinação de cores em seu sistema de design passa pelo nível WCAG relevante. Exporte a paleta mais a grade de contraste como parte da declaração de acessibilidade ou VPAT (Voluntary Product Accessibility Template) para seu produto. O JSON exportado é suficientemente estruturado para alimentar relatórios de conformidade automatizados; a grade visual é boa para revisão humana.

Armadilhas comuns

Tratar a cor da marca como intocável

O padrão mais comum: marketing insiste na cor primária corporativa, mas ela falha no contraste AA em branco. Opções: use a cor da marca apenas para elementos grandes ou decorativos (passa pela barra mais indulgente de 3:1 texto grande), escureça a cor ligeiramente para uso de texto (a maioria das marcas tem flexibilidade para uma variante mais escura), ou mude a cor do texto do corpo de preto para um cinza escuro menos duro para que a cor da marca se leia como um acento. Ferramentas como Leonardo (da Adobe) geram variantes acessíveis de uma cor de marca automaticamente; pareie com esta ferramenta para verificação.

Usar o contraste como única verificação de acessibilidade

Passar pelo contraste não garante legibilidade. Uma relação 4,5:1 é o chão; alguns usuários (baixa visão, perda de sensibilidade ao contraste relacionada à idade, dislexia) beneficiam-se de relações mais altas. WCAG SC 1.4.6 (Contraste Aprimorado, AAA) recomenda 7:1 para texto do corpo precisamente porque 4,5:1 é o mínimo, não o alvo. Combine alto contraste com tamanho de fonte suficiente (16px+ para o corpo), altura de linha adequada (1,5x tamanho da fonte) e escolhas de fonte que preservem as formas das letras (evite pesos ultrafinos para o texto do corpo).

Esquecer o contraste não-textual (SC 1.4.11)

WCAG 1.4.11 (adicionado em WCAG 2.1, 2018) requer contraste 3:1 para componentes UI e elementos gráficos: bordas de campo de formulário, contornos de botão, ícones, indicadores de foco. Isso é fácil de perder porque os designers pensam que o contraste só se aplica ao texto. Um formulário limpo com bordas de campo cinza sutis em branco pode falhar 1.4.11 mesmo se todo o texto passar 1.4.3. Audite cada elemento visual que transmite significado ou estado, não apenas texto sobre fundo.

Confundir regras de texto grande

O limiar de texto grande do WCAG (3:1 em vez de 4,5:1) se aplica a texto que é 18pt ou maior (cerca de 24px), ou 14pt negrito (cerca de 18,66px negrito). Qualquer coisa menor é texto normal e precisa de 4,5:1. Designers às vezes aplicam a regra 3:1 de texto grande a todos os níveis de cabeçalho, mas um h5 em 16px é texto normal pela definição do WCAG. Verifique o tamanho renderizado, não o nível de cabeçalho. O modificador negrito importa: 18px negrito passa como texto grande; 18px regular não.

Depender da cor sozinha para transmitir informação

WCAG 1.4.1 (Uso da Cor, Nível A) é separado do contraste. Mesmo com relações de contraste perfeitas, voce não pode usar a cor como único indicador de estado (vermelho significa inválido, verde significa válido, azul significa link). Pareie a cor com uma segunda pista: ícone (triangulo de aviso para erros), padrão (sublinhado para links) ou rótulo de texto (Obrigatório ao lado de campos obrigatórios). Usuários daltonicos (cerca de 8% dos homens, 0,5% das mulheres) e usuários em telas monocromáticas em escala de cinza dependem dessas pistas secundárias.

Esquecer os estados hover, focus e active

Um botão passa o contraste em seu estado padrão mas o estilo :hover o clareia abaixo do limiar; o contorno :focus é um cinza sutil que falha 3:1 contra o fundo do botão; o estado :active inverte as cores e a nova combinação falha. Teste cada estado interativo em sua grade de contraste, não apenas o padrão. O indicador de foco em particular é crítico (SC 2.4.7 Foco Visível, AA): se o foco não está claramente visível, usuários apenas-teclado perdem seu lugar na página.

Privacidade e tratamento de dados

As cores que voce adiciona, os nomes de paleta e os tokens exportados permanecem todos no seu navegador. Os cálculos de contraste são executados em JavaScript na sua máquina; nada é enviado. Isso importa menos para paletas de cores do que para documentos mas ainda importa quando a paleta faz parte de uma atualização de marca não anunciada ou de um projeto de cliente confidencial: voce não quer que vaze para um validador SaaS de terceiros antes do lançamento.

Uma vez que a página é carregada, a ferramenta funciona offline. Voce pode desconectar da internet, construir a paleta, executar verificações e exportar. Os tokens exportados são baixados diretamente através da caixa de diálogo de salvar normal do navegador. Muitas ferramentas de cor em nuvem (Coolors, Adobe Color, até mesmo alguns verificadores de acessibilidade) armazenam paletas no servidor e podem usá-las para análise ou treinamento; para trabalho confidencial, prefira ferramentas do lado do cliente.

Quando não usar esta ferramenta

Para simulação completa de daltonismo (use uma ferramenta dedicada)

Contraste não é o mesmo que compatibilidade com daltonismo. Uma paleta pode passar todas as verificações de contraste e ainda confundir um usuário daltonico (vermelho e verde na mesma luminancia parecem identicos para um deuteranopa). Para simulação de daltonismo, use o Simulador de Daltonismo da Absolutool ou a visualização de acessibilidade do Adobe Color, ambos aplicam as transformações reais de cor de deuteranopia, protanopia e tritanopia. Execute paletas candidatas através desta ferramenta e de um simulador.

Para gerar esquemas de cores do zero (use Leonardo ou Coolors)

Esta ferramenta verifica e audita paletas; ela não as gera a partir de uma única cor semente. Para geração de paleta do zero (esquemas análogos, complementares, triádicos, complementares divididos), use Adobe Color, Coolors ou Leonardo (que gera variantes acessíveis de uma cor de marca). Gere com essas ferramentas, depois valide com esta. Leonardo especificamente gera cores direcionadas a relações de contraste específicas, que é o formato de entrada natural para a etapa de verificação desta ferramenta.

Para contraste baseado em APCA (quando WCAG 3 for lançado)

Esta ferramenta usa a fórmula de contraste WCAG 2.x, que é o padrão legal e industrial atual. Se voce especificamente precisar projetar para APCA (o algoritmo proposto WCAG 3), use a Calculadora de Contraste APCA da Myndex Research. APCA produz classificações diferentes (e provavelmente mais precisas perceptualmente), especialmente para texto escuro-sobre-escuro e claro-sobre-claro. Até que WCAG 3 seja ratificado e adotado na lei (provavelmente vários anos no futuro), WCAG 2.x é o que auditores de conformidade verificarão.

Para auditorias WCAG completas (use uma ferramenta abrangente)

Contraste é um critério entre dezenas. Para uma auditoria de acessibilidade completa, use axe DevTools, Lighthouse, WAVE ou uma solução paga como Tenon ou PowerMapper. Estas verificam contraste, texto alt, ARIA, rótulos de formulário, ordem de foco, estrutura de cabeçalho e muito mais em uma única passagem. Use esta ferramenta durante o design da paleta, e as ferramentas abrangentes durante os testes de integração.

Mais perguntas

Qual é a diferença entre contraste AA e AAA?

AA é o padrão, legalmente exigido pela maioria das leis de acessibilidade (ADA, EAA, AODA, etc.) e o que cada site voltado ao público deve atender. AAA é mais rigoroso: 7:1 para texto do corpo, 4,5:1 para texto grande. AAA geralmente é exigido apenas para conteúdo de alto risco (sites governamentais em algumas jurisdições, informações médicas e jurídicas, conteúdo para usuários com baixa visão como audiencia primária). Projetar para AAA é restritivo; poucas marcas podem atender sem limitações significativas de cor. Vise AA por padrão e AAA onde a audiencia do conteúdo justificar.

Por que o WCAG usa 4,5:1 especificamente?

O limiar 4,5:1 foi escolhido para que o texto permaneça legível para usuários com visão 20/40 (o limiar para cegueira legal em muitas jurisdições) sem ampliação assistiva. Também é aproximadamente a relação de contraste na qual usuários com deficiencia de visão de cor podem distinguir de forma confiável o primeiro plano do fundo. O número é calibrado empiricamente a partir de pesquisa visual; não é arbitrário. O 7:1 do AAA corresponde aproximadamente à visão 20/80, acomodando significativamente mais deficiencia.

Como a fórmula de contraste funciona?

Converta cada cor de sRGB para luminancia relativa usando a fórmula: corrija gamma cada canal (R, G, B) aplicando uma função por partes (linear para valores baixos, exponencial para altos), depois pondere por 0,2126 R + 0,7152 G + 0,0722 B (a sensibilidade relativa do olho humano a cada canal). A relação de contraste entre duas cores é (L1 + 0,05) / (L2 + 0,05) onde L1 é a luminancia mais clara e L2 a mais escura. O deslocamento 0,05 leva em conta o reflexo ambiente da tela. O resultado é um número entre 1 (identico) e 21 (máximo).

Devo me preocupar com o contraste do texto de espaço reservado em campos de formulário?

Sim. O texto de espaço reservado conta como texto sob WCAG e deve atender ao contraste 4,5:1. O padrão do navegador para espaço reservado é cinza claro (#a9a9a9 na maioria dos navegadores), que falha em branco. Substitua com CSS: ::placeholder { color: #595959; } ou similar que passe AA. Melhor ainda, evite espaços reservados completamente para campos importantes; use rótulos visíveis acima do campo e reserve espaços reservados para formatação de exemplo. Padrões de rótulo flutuante combinam o rótulo visível e a clareza do exemplo.

O contraste se aplica a botões e campos de formulário desabilitados?

Não. WCAG SC 1.4.3 explicitamente isenta controles desabilitados porque a aparencia silenciada é em si um sinal visual de que o controle está indisponível. Botões desabilitados são tipicamente desbotados para cerca de 38% de opacidade e falhariam o contraste em seu estado desabilitado por design. No entanto, o estado desabilitado ainda deve ser claramente distinguível do estado habilitado, então não apenas remova todo o tratamento visual; use uma diferença visual clara mais um atributo desabilitado acessível ao leitor de tela.

E quanto ao contraste para conteúdo gráfico como gráficos e ícones?

WCAG 1.4.11 Contraste Não-textual (adicionado em 2.1) requer contraste 3:1 para componentes UI (botões, bordas de formulário, indicadores de foco) e elementos gráficos significativos (ícones que transmitem estado, elementos de gráfico que distinguem séries de dados). O limiar 3:1 é mais baixo que o 4,5:1 para texto porque os gráficos geralmente tem áreas visíveis maiores. Gráficos decorativos que não transmitem significado são isentos. Aplique 3:1 a cada ícone que transmite estado (olho aberto para visível, X para excluir, marca de seleção para selecionado) e cada segmento de gráfico que precisa ser distinguível.