Como escolher combinações de cores acessíveis
Escolhas de cor parecem uma decisão estética e agem como uma decisão jurídica. Cerca de 4.000 processos de acessibilidade web por ano atingem réus americanos desde 2021, e contraste de cor insuficiente é um dos três problemas mais citados em processos baseados em WCAG (junto com texto alternativo ausente e campos de formulário não rotulados). A boa notícia: contraste é o mais simples dos três para consertar. A má: «acessível» vai além do ratio principal: daltonismo, indicadores de foco, modo escuro e tokenização todos importam.
Breve história da acessibilidade de cor digital
Contraste de cor como padrão escrito remonta ao primeiro trabalho da Web Accessibility Initiative do W3C em 1997. As Web Content Accessibility Guidelines 1.0 originais (maio de 1999) recomendavam contraste suficiente em termos qualitativos sem número concreto. WCAG 2.0 (dezembro de 2008) introduziu a fórmula de luminância relativa hoje familiar e o ratio 4,5:1 no nível AA, vindo de pesquisa da Lighthouse International sobre o que usuários idosos com óculos podiam ler confortavelmente na tela.
O peso jurídico veio depois. A Seção 508 do Rehabilitation Act referenciou WCAG 2.0 em 2018; o ADA, após o julgamento do Nono Circuito em Robles v. Domino's em 15 de janeiro de 2019 (Suprema Corte recusou ouvir o recurso em outubro de 2019), é lido agora por tribunais americanos como cobrindo acessibilidade digital sob o Título III. A European Accessibility Act entrou em vigor em 28 de junho de 2025, exigindo WCAG 2.1 AA em serviços digitais voltados ao consumidor para setor público e muitas empresas privadas. Na prática, 4,5:1 texto normal + 3:1 texto grande + 3:1 componentes UI é o piso de facto.
A ciência continuou evoluindo. WCAG 2.1 (2018) adicionou a regra de contraste não-texto 3:1. O algoritmo APCA, desenvolvido por Andrew Somers para WCAG 3, modela a percepção de brilho com mais precisão; é Editor's Draft em 2026, ainda não padrão. OKLAB e OKLCH de Bjorn Ottosson (2020) deram aos designers um espaço de cor perceptualmente uniforme que torna gerar escalas de cor acessíveis muito mais fácil que em HSL ou RGB.
O que «cor acessível» realmente significa
Quatro coisas importam, não só o ratio:
- Contraste primeiro plano vs fundo. O número principal. Texto do corpo: 4,5:1, texto grande: 3:1, controles UI e indicadores de foco: 3:1 contra cores adjacentes.
- Daltonismo. Cerca de 8 % dos homens e 0,5 % das mulheres veem menos cores do que o design assume. Os três tipos principais são protanopia e deuteranopia (vermelho-verde, os mais comuns) e tritanopia (azul-amarelo).
- Cor nunca é o único sinal. WCAG 1.4.1 proíbe depender só de cor para transmitir significado. Uma borda de erro vermelha precisa também de ícone ou rótulo.
- Indicadores de foco. Usuários de teclado precisam ver onde está o foco. WCAG 2.4.7 exige indicador visível, e a atualização 2.4.11 (WCAG 2.2) exige pelo menos 2 pixels CSS de espessura e 3:1 de contraste.
Como escolher cores acessíveis, passo a passo
- Comece com tokens semânticos, não cores cruas. Defina
text-primary,text-secondary,surface-default,surface-elevated,border-default,accent-primary,accent-danger, etc. - Escolha a escala de luminosidade. Use valores de luminosidade OKLCH para construir uma escala de 5 a 9 degraus com diferença perceptual constante.
- Escolha tons em cada degrau. Pegue o tom de marca, depois escolha tons complementares ou de destaque mantendo croma similar.
- Calcule os ratios de contraste. Cada par de tokens que se tocam precisa do ratio certo.
- Rode um simulador de daltonismo. Pegue uma tela-chave e re-renderize via protanopia, deuteranopia e tritanopia.
- Teste com tecnologia assistiva real. VoiceOver, NVDA, JAWS e TalkBack devem conseguir navegar sem depender de pistas de cor.
- Adicione o sinal não-cor onde a cor carrega significado. Ícones para erro/sucesso/aviso, sublinhados para links no corpo, padrões para séries de gráfico.
- Documente os tokens. Uma biblioteca Figma, página Storybook ou site de design system estático.
Referência de ratios de contraste
| Par | WCAG 2.1 min | Nível AA | Nível AAA |
|---|---|---|---|
| Texto corpo (abaixo de 18 pt regular ou 14 pt negrito) | 4,5:1 | 4,5:1 | 7:1 |
| Texto grande (18 pt regular ou 14 pt negrito) | 3:1 | 3:1 | 4,5:1 |
| Componentes UI (bordas, estados toggle, foco) | 3:1 | 3:1 | n/a |
| Objetos gráficos (ícones com significado) | 3:1 | 3:1 | n/a |
| Texto dentro de logo | isento | isento | isento |
| Controles desabilitados | isento | isento | n/a |
| Texto decorativo | isento | isento | isento |
Tipos de daltonismo e como verificar
| Tipo | Prevalência | Vê menos de | Falha comum |
|---|---|---|---|
| Protanopia | ~1 % dos homens | Vermelho | Erro vermelho vs sucesso verde indistinguíveis |
| Deuteranopia | ~5 % dos homens | Verde | Igual: confusão vermelho-verde |
| Tritanopia | ~0,005 % | Azul | Azul vs amarelo indistinguíveis |
| Acromatopsia | ~0,003 % | Todas as cores | Vê só luminância em escala de cinza |
| Tricromacia anômala | ~5 % | Sensibilidade reduzida em um canal | Diferenças sutis de cor se fundem |
Armadilhas comuns
- Designar em HSL ou RGB. Passos numéricos iguais em HSL produzem passos percebidos desiguais. OKLCH conserta.
- Confiar só na cor para estado. Vermelho e verde para erro e sucesso: 8 % de usuários não distinguem. Adicione ícone ou rótulo.
- Preto puro sobre branco puro.
#000sobre#FFFdá 21:1 mas cansa para leitura longa. Desça para quase-preto e quase-branco. - Tirania da cor de marca. Tratar o vermelho de marca como sagrado e usá-lo a 2,1:1 «porque é a marca». Atualize a paleta de marca.
- Indicador de foco que some em fundo escuro. Um anel azul de 2px contra um botão azul escuro pode sumir. Teste o anel de foco contra todas as superfícies.
- Placeholder que falha contraste. Texto
placeholder=é renderizado com ~40 % de opacidade. Em input branco cai abaixo de 4,5:1 fácil. - Contornos de campo fracos demais. Borda 1px cinza-sobre-branco a 1,2:1 falha WCAG 1.4.11. Aumente para 3:1 ou mais grossa.
- Hover que só muda cor. Alguns dispositivos não produzem hover. Combine com sombra sutil ou transformação.
- Modo escuro por inversão simples. Inverter produz cores escuras saturadas duras. Modo escuro precisa do seu próprio passe de design.
- Texto auto-gerado sobre imagens. Texto sobre imagem enviada não pode garantir contraste. Adicione fundo translúcido ou text-shadow.
Algoritmos e padrões alternativos
| Algoritmo | Ano | Status | Força |
|---|---|---|---|
| Ratio de contraste WCAG 2.x | 2008 | Exigido pela maioria das regulações | Matemática simples, amplamente ferramentado |
| APCA | 2020 | Editor's Draft WCAG 3 | Melhor em brilho perceptual |
| ISO 9241-302 | 2008 | Padrão de ergonomia de estação de trabalho | Orientado a hardware, muito estrito |
| Avisos de contraste Lighthouse | 2018 | Chrome DevTools | Grátis, no navegador |
| axe-core | 2015 | Biblioteca open source | Padrão da indústria para teste automatizado |
Para trabalho regulado hoje, WCAG 2.1 AA é o piso. APCA vale acompanhar conforme WCAG 3 amadurece; muitos times de design system já reportam ambos os números.
Ferramentas para escolher cores acessíveis
| Ferramenta | Propósito | Força |
|---|---|---|
| Verificador de contraste (navegador) | Pontuar par primeiro plano/fundo | Instantâneo, sem upload |
| Gerador de paleta acessível | Construir escala completa com croma constante | Usa OKLCH para uniformidade perceptual |
| Simulador de daltonismo | Re-renderizar tela como um daltônico vê | Captura problemas vermelho-verde antes do lançamento |
| Chrome DevTools Lens | Inspecionar contraste e daltonismo no lugar | Embutido no navegador |
| WebAIM Contrast Checker | Referência WCAG 2 clássica | Confiável, amplamente citado |
| Stark (plugin Figma) | Auditar designs Figma | Captura problemas em tempo de design |
| axe DevTools (navegador) | Varredura WCAG automatizada | Padrão da indústria |
| Escalas Tailwind, Radix, Open Props | Paletas OKLCH pré-testadas | Acessibilidade curada por times de design |
Privacidade e as ferramentas
O verificador de contraste, gerador de paleta acessível e simulador de daltonismo rodam inteiramente no seu navegador. As cores que você escolhe ou cola são processadas por JavaScript no seu dispositivo, os resultados são renderizados na página, e nada é enviado a um servidor. Sem telemetria, sem analytics sobre a entrada, sem scripts de terceiros. Para cores de marca ainda não públicas, paletas de produto internas, ou designs sob embargo, esse fluxo estritamente local é a diferença entre confiar os ativos de marca não lançados à ferramenta de um estranho e não. As ferramentas podem rodar offline depois que a página carrega, o que você pode verificar desligando a rede e re-verificando um par.
Perguntas frequentes
What contrast ratio does WCAG require?
WCAG 2.1 Level AA requires at least 4.5:1 for normal body text and 3:1 for large text (18 pt regular or 14 pt bold). Level AAA raises that to 7:1 for normal text and 4.5:1 for large text. Non-text UI components and graphical objects need 3:1 against adjacent colors.
Are WCAG contrast ratios scientifically accurate?
They are based on the WCAG 2.0 algorithm from 2008, which compares the relative luminance of two colors using the sRGB color space. The formula is imperfect for very dark and very light combinations and for some color hues; the APCA (Accessible Perceptual Contrast Algorithm) being developed for WCAG 3 produces more perceptually accurate results. For 2026 work, WCAG 2.x is still the standard most regulations cite.
How do I check whether my colors work for color-blind users?
Run them through a color-blindness simulator that converts your palette to what someone with protanopia, deuteranopia, or tritanopia sees. About 8% of men and 0.5% of women have some form of color vision deficiency, so this matters.
Should I use the same color palette for light and dark mode?
Usually not. Dark mode needs slightly desaturated colors at the same hue, otherwise vivid colors that look fine on white become eye-strain on black. Define semantic tokens (text-primary, surface-secondary) and map them to different physical colors per mode.
What does OKLCH have to do with accessibility?
OKLCH is a perceptually uniform color space (Bjorn Ottosson, 2020) where equal numerical changes produce equal perceptual changes. That makes it much easier to generate accessible color scales because you can step the lightness in equal increments and the perceived brightness step is consistent, which is hard to do in HSL or RGB. CSS supports OKLCH directly since 2023 in all major browsers.