Contraste WCAG para Painéis SaaS: A Auditoria de 5 Minutos que Pega a Maioria dos Pecados

TL;DR

• Texto de corpo normal precisa de contraste de 4.5:1 (AA); texto grande precisa de 3:1.
• Componentes de UI, ícones, anéis de foco e elementos de gráficos precisam de 3:1 (SC 1.4.11).
• Cerca de três quartos dos painéis SaaS falham no contraste em pelo menos um elemento crítico — geralmente métricas apagadas, verde de sucesso sobre branco, rótulos de gráficos, anéis de foco ou estados apenas ao passar o mouse.
• Armadilhas comuns: texto secundário slate-400 (3.1:1, falha) e green-500 sobre branco (2.5:1, falha).
• Uma auditoria de 5 minutos (captura de tela → verificador de contraste → modo de alto contraste do SO → linter automatizado) detecta as falhas óbvias antes que os clientes o façam.

Seu painel provavelmente está falhando no WCAG. O meu também estava.

Eu faço uma pequena auditoria em todos os painéis SaaS que vejo. O padrão é consistente: as páginas de marketing geralmente estão bem. As páginas de configurações geralmente estão bem. O painel em si (a parte que o produto realmente faz) falha no contraste WCAG em pelo menos um elemento crítico cerca de três quartos das vezes.

Os suspeitos de sempre:

• Métricas secundárias apagadas — os números pequenos e de baixa ênfase.
• Rótulos dos eixos dos gráficos — linhas finas e texto minúsculo.
• Botões "fantasma" — baixo contraste por design.
• Texto verde de sucesso sobre branco — parece bom, mas tem medidas péssimas.
• O estado desativado do botão principal.

São exatamente os elementos com os quais os designers mais iteram e exatamente os elementos que são ajustados para fora da paleta de marca segura devido à pressão de entrega.

Este post cobre a auditoria de 5 minutos que eu executo, as quatro regras de contraste que valem a pena memorizar e as ferramentas (incluindo um verificador de taxa de contraste gratuito) que detectam as falhas antes que um cliente registre uma reclamação de acessibilidade.

As regras de contraste, destiladas

As Diretrizes de Acessibilidade para Conteúdo Web do W3C definem dois níveis de contraste para texto. Após anos depurando painéis reais, eu as resumi em uma única tabela que vive em um post-it ao lado do meu monitor:

Estas regras vêm do Critério de Sucesso WCAG 2.1 1.4.3 (Contraste Mínimo) e do 1.4.11 (Contraste Não Textual). Elas não são negociáveis para conformidade legal na maioria das jurisdições e surpreendentemente correspondem muito bem ao que parece legível.

Duas implicações práticas que a maioria das equipes não percebe:

1. Minigráficos e traços de gráficos são componentes de UI, não texto. Eles se enquadram na regra de 3:1, mas #cbd5e1 (slate-300) no branco é 1.65:1. A maioria dos gráficos de painel que vejo falha nisso e ninguém está aplicando a regra.

2. Estados desativados estão isentos dos requisitos de contraste no SC 1.4.3, mas apenas se forem genuinamente não interativos. Se um botão "desativado" ainda aciona uma dica de ferramenta ou mostra um erro ao clicar, ele é interativo, e as regras se aplicam.

Os 5 padrões que falham em todos os painéis que audito

Após auditar dezenas de UIs SaaS, estes são as mesmas cinco falhas repetidas vezes:

1. Métricas secundárias apagadas. "Atualizado pela última vez há 2 horas" em #94a3b8 (slate-400) em um fundo #f8fafc. Isso dá 3.1:1, o que falha no nível AA para texto de corpo. A correção é um tom mais escuro (slate-500 é 4.6:1). Os designers usam o slate-400 por padrão porque "parece elegante"; também é ilegal.

2. Texto de sucesso/perigo sobre branco. #22c55e (Tailwind green-500) no branco é 2.5:1. Falha catastrófica. Use green-700 (#15803d) com no mínimo 4.7:1. Isso engana quase todos os painéis que usam um framework de cores padrão sem ajustes.

3. Rótulos dos eixos dos gráficos. Linhas e texto pequeno em #94a3b8 falham. Os gráficos precisam de pelo menos slate-500 (4.6:1) para os rótulos e contraste de ≥ 3:1 para as próprias linhas.

4. Anéis de foco. A tendência do reset "sem anel de foco" quebra o critério 2.4.7 (Foco Visível) inteiramente. Se você removeu o anel de foco padrão, precisa de um personalizado com contraste de ≥ 3:1 em relação ao fundo. O A11y Project tem um guia completo sobre visibilidade de foco que vale a pena ler uma vez.

5. Contraste apenas no hover. Um botão que falha no contraste em repouso, mas passa no hover não atende ao critério. O estado de repouso é o que é auditado.

A auditoria de 5 minutos

Este é o fluxo de trabalho que eu executo em qualquer painel antes de lançar um redesenho. Cinco passos, cinco minutos:

1. Abra a página em questão. Escolha a tela mais carregada, não o estado vazio.

2. Tire uma captura de tela. Arraste-a para um verificador de contraste. Para cada par de cores que você está preocupado, amostre os valores de pixel e verifique a taxa.

3. Gere uma paleta "segura" candidata usando um gerador de paleta de cores. Mesmo que você não use o resultado, as taxas de contraste que ele mostra para cada par são uma verificação de sanidade rápida contra sua paleta atual.

4. Teste com a configuração de acessibilidade "Aumentar contraste" no nível do sistema operacional ativada (macOS: Configurações do Sistema → Acessibilidade → Monitor). Cerca de 8% dos usuários têm isso ativado. Se os seus elementos "sutis" desaparecerem completamente, você tem um problema.

5. Execute a página através de um linter automatizado (Axe DevTools, Lighthouse, WAVE). Eles capturam talvez 30-40% dos problemas, mas pegam aqueles pelos quais você ficaria mais envergonhado.

Esta auditoria não substitui a contratação de um consultor de acessibilidade para um produto real. Ela é suficiente para detectar as falhas óbvias que são lançadas toda sexta-feira à tarde.

Onde as ferramentas automatizadas erram

Três modos de falha que os verificadores automatizados não detectam:

• Contraste dependente de dados. Se o seu estado "baixo" é gray-300 e o "alto" é red-600, o contraste entre eles está fine. O contraste de cada um individualmente em relação ao fundo ainda precisa ser ≥ 3:1, e um verificador não saberá que o estado "baixo" pode ocorrer sozinho.
• Contraste composto. Sobreposições translúcidas empilhadas (o visual moderno do glassmorfismo) mudam o contraste com base no que está atrás delas. Verificadores estáticos veem apenas a cor do primeiro plano.
• Mudanças de estado que alteram o contexto. Um rótulo de status que muda de cinza para âmbar não muda em contraste em relação ao fundo; muda em significado. Usuários daltônicos podem perder a mudança completamente. O guia da Smashing Magazine sobre padrões de acessibilidade em painéis cobre bem esse tipo de sinalização multicanal.

A correção para todos os três é a mesma: emparelhe cada sinal de cor com uma dica sem cor (ícone, rótulo, peso). Prevenção em dobro.

Uma paleta pragmática

Se você quiser um ponto de partida que quase sempre passe no nível AA quando usado corretamente:

• Texto de corpo: slate-700 (#334155) no slate-50 (#f8fafc) = 10.8:1
• Texto secundário: slate-500 (#64748b) = 5.3:1 (passa no AA para corpo, falha no AAA)
• Cor de destaque no branco: qualquer coisa na faixa de peso 600 dos principais frameworks
• Sucesso: green-700 (#15803d) = 4.7:1
• Perigo: red-700 (#b91c1c) = 6.0:1

Passe qualquer valor personalizado por um verificador de contraste de cores antes de lançar. Dois minutos economizados argumentando com um designer valem duas horas não gastas reajustando a paleta depois que um cliente registra uma reclamação de a11y.

A mudança de mentalidade

A maioria das falhas de contraste não é de designers ignorando a acessibilidade. São designers buscando "elegância" e não percebendo que a escolha elegante também é a ilegível. A correção é colocar uma verificação de contraste ao lado de cada decisão de cor no sistema de design, não no final como uma etapa de conformidade.

Se você não fizer mais nada deste post: abra seu painel atual, abra um verificador de contraste de cores e verifique as três cores de texto mais apagadas. Você quase certamente encontrará pelo menos uma falha. Gaste os 10 minutos para corrigi-la antes da próxima revisão de design. É a única tarefa de acessibilidade com maior ROI na sua lista de afazeres.

Resumo: Memorize as três proporções (4.5:1 para corpo, 3:1 para texto grande, 3:1 para UI/gráficos) e verifique o contraste ao lado de cada decisão de cor, não como uma etapa de conformidade de última hora. Cinco minutos hoje evitam uma reclamação de acessibilidade de um cliente amanhã.

Não se esqueça do anel de foco

O contraste não é apenas sobre texto e ícones — é também sobre o indicador de foco que mostra em qual controle o usuário do teclado pousou. O WCAG 2.4.7 (Foco Visível, nível AA) exige que esse indicador seja perceptível, e um contorno fraco de um pixel que desaparece contra um botão colorido falha com as pessoas que navegam sem mouse. A versão mais comum desse erro é remover o contorno padrão do navegador por causa da "limpeza visual". Não faça isso: mantenha um estilo de foco visível com contraste real tanto em relação ao componente quanto à página, e verifique o estado de foco de cada elemento interativo, não apenas suas cores de repouso e de hover.

Fontes

1. W3C: WCAG 2.1 Success Criterion 1.4.3: Contrast (Minimum)
2. The A11y Project: Never remove CSS outlines
3. Smashing Magazine: Accessibility best practices for tabs and dashboards