Projetando para daltonismo: por que vermelho e verde nunca bastam

Falhas de acessibilidade são decisões de design. A prova está aqui. contou a história de um desenvolvedor back-end que compensou em silêncio por anos antes de alguém na equipe perceber que ele era daltônico. Veio à tona por acaso, numa conversa sobre a camisa de um time de futebol, não numa revisão de design. Aquele artigo cobriu o formato do problema em poucos parágrafos. Este cobre o resto: a taxonomia real da deficiência de visão de cores, por que vermelho e verde especificamente colapsam antes de qualquer outro par, a correção que funciona independente de qual tipo alguém tem, e como auditar um design system existente em busca de falhas baseadas só em cor.

1.1 Tricromacia, tricromacia anômala, dicromacia

A visão de cores humana típica é tricromática: três tipos de células cone na retina, cada uma sensível a uma faixa diferente de comprimento de onda (aproximadamente vermelho, verde e azul), combinam seus sinais para produzir toda a gama de cores percebidas. A deficiência de visão de cores não é uma condição única. É um espectro de formas pelas quais esse sistema pode variar.

Tricromacia anômala é a forma mais leve e mais comum: os três tipos de cone estão presentes, mas um tem sensibilidade deslocada, então cores que deveriam ser distintas se comprimem uma em direção à outra. Dicromacia é mais severa: um tipo de cone está totalmente ausente, e a parte afetada do espectro de cores colapsa muito mais. "Daltônico" como termo genérico achata uma diferença real de severidade que importa para como um design falha para pessoas diferentes.

1.2 Os quatro nomes que realmente importam

Protanomalia (anômala) e protanopia (dicromática) afetam o cone sensível ao vermelho. Vermelhos parecem mais escuros e deslocam em direção ao verde.

Deuteranomalia e deuteranopia afetam o cone sensível ao verde. É de longe a categoria mais comum, e produz a confusão clássica entre vermelho e verde que a maioria das pessoas associa à palavra "daltônico".

Tritanomalia e tritanopia afetam o cone sensível ao azul. Muito mais raras que os tipos vermelho-verde, e confundem azul com verde e amarelo com violeta: um modo de falha diferente que uma correção pensada só para vermelho/verde não cobre.

Acromatopsia, o daltonismo total, é a forma mais rara: nenhuma visão de cor funcional baseada em cones, só tons de cinza. Genuinamente rara, mas é o pior caso útil para testar contra, porque uma interface que sobrevive à simulação de acromatopsia não tem, por definição, nenhuma falha baseada só em cor restante.

Os mesmos três chips (erro, sucesso, aviso) sob quatro tipos de visão. Vermelho e verde convergem primeiro e mais forte.

1.3 Quem isso realmente afeta

A deficiência de visão de cores vermelho-verde, somada, afeta aproximadamente 8% dos homens e 0,5% das mulheres de descendência norte-europeia, os números mais citados do National Eye Institute. A prevalência varia um pouco por ascendência, mas a ordem de grandeza não: numa equipe de doze pessoas, estatisticamente uma tem algum grau disso. Num produto com qualquer base de usuários relevante, o número de usuários afetados nunca é pequeno o suficiente para arredondar a zero.

2.1 A fisiologia, em um parágrafo

Os cones sensíveis ao vermelho (L) e ao verde (M) têm curvas de absorção que já se sobrepõem bastante em pessoas com visão de cores típica: ficam próximas no espectro visível. A tricromacia anômala desloca uma curva um pouco mais perto da outra; a dicromacia remove uma inteiramente. De qualquer forma, o intervalo entre vermelho e verde já é o menor intervalo em todo o sistema, e é exatamente por isso que é o primeiro a desaparecer. O azul fica longe o suficiente de ambos para que as deficiências do tipo tritan sejam mais raras e se comportem diferente, o que também é por isso que uma correção pensada só em torno de "evitar vermelho e verde" não cobre totalmente a confusão azul-amarelo.

2.2 Onde isso aparece em interfaces reais

Estados de erro e sucesso em vermelho e verde, lado a lado, são o caso mais comum de todos: um campo de formulário, um badge de status, um resultado de pipeline de build. Heatmaps que vão de verde (bom) a vermelho (ruim) falham do mesmo jeito que uma legenda de semáforo. Gráficos de linha que distinguem séries só pelo matiz, sem formato de marcador ou rotulagem direta, ficam ilegíveis no momento em que duas das linhas são um vermelho e um verde. Nenhum desses é um caso extremo exótico. São escolhas padrão na maioria das bibliotecas de componentes.

3.1 A regra do segundo canal

A correção não depende de saber qual tipo de deficiência de visão de cores um usuário específico tem, porque não tenta escolher cores "mais seguras". Ela adiciona um canal que não depende nada da percepção de cor: um ícone, um rótulo de texto, uma posição, um padrão. Estados de erro recebem uma borda vermelha, um ícone de erro e uma mensagem escrita. Estados de sucesso recebem a confirmação verde, um check explícito e uma frase de confirmação. A cor pode continuar exatamente como foi projetada. Só deixa de ser a única coisa carregando o significado.

Os mesmos dois estados. Passe as duas colunas pelo filtro de deuteranopia acima: só uma coluna ainda diz qual campo tem problema.

3.2 Visualização de dados precisa da sua própria versão da regra

Gráficos e dashboards falham nisso de um jeito que estados de UI simples geralmente não falham: muitas vezes não há espaço para um ícone ao lado de um ponto de dado, e um rótulo escrito ao lado de cada linha anula o propósito do gráfico. As correções equivalentes são rotulagem direta no final de cada linha em vez de uma legenda codificada só por cor, formatos de marcador ou padrões de traço distintos por série além da cor, e escolher paletas construídas para isso. Os conjuntos qualitativos e divergentes do Color Brewer, ou o Okabe-Ito, são referências padrão e testadas, não tons escolhidos no olho.

As mesmas duas séries. Sólido vs. tracejado mais um rótulo direto sobrevive a um leitor daltônico; um ponto colorido ao lado de uma palavra não.

4.1 O que já está na sua máquina

Nenhuma compra ou instalação é necessária para a primeira verificação. O Chrome DevTools tem um emulador de deficiência de visão embutido: abra o DevTools, Command/Ctrl+Shift+P, rode "Show Rendering", e use "Emulate vision deficiencies" para ver a página ao vivo como protanopia, deuteranopia, tritanopia, ou acromatopsia. O macOS traz um simulador parecido dentro das configurações de Acessibilidade (Tela → Filtros de Cor). Nenhum dos dois exige que o arquivo de design esteja finalizado. Os dois funcionam num produto real, em execução.

Escolha um. O importante é rodar antes do handoff, não qual deles.

4.2 A verificação de dois minutos

Ligue um simulador. Percorra todo estado que sua interface comunica só por cor: erros de formulário, confirmações de sucesso, banners de aviso, legendas de gráfico, indicadores de status, indicadores de disponibilidade. Se algum deles ficar ambíguo ou indistinguível, esse estado falha, independente do que a proporção de contraste entre as cores mede. Deficiência de visão de cores e baixo contraste são eixos diferentes do mesmo problema de fundo, abordado em AA vs AAA: o que esses níveis realmente significam e por que seu botão desabilitado está falhando nos dois: um par de cores pode passar na matemática de contraste e ainda assim ser indistinguível para um usuário daltônico.

5.1 O checklist

Percorra a biblioteca de componentes estado por estado, não tela por tela. Uma falha baseada só em cor num componente compartilhado de botão ou badge se repete em todo lugar onde esse componente é usado, então corrigi-la uma vez na fonte corrige todas as instâncias.

Para todo componente que comunica um estado: erro, sucesso, aviso, informação, desabilitado, selecionado, ativo. Para cada estado, confirme que existe um sinal não baseado em cor presente (um ícone, um rótulo, uma mudança de posição, um sublinhado, um estilo de borda) e que o sinal fica visível quando a cor é totalmente removida (rode o filtro de acromatopsia como o teste mais rigoroso; se um estado ainda faz sentido em escala de cinza, toda forma menos severa de deficiência de visão de cores também faz).

Faça a mesma passagem separadamente para componentes de visualização de dados. Gráficos, plotagens e heatmaps quase sempre vivem fora da biblioteca de componentes principal e ficam de fora de uma auditoria só de UI, mesmo quando os componentes de UI em si já foram corrigidos.

5.2 Documente a correção uma vez, não por instância

Uma vez que o sinal não baseado em cor de um estado é decidido no nível do token ou componente (este estado de erro sempre recebe este ícone, este padrão), toda equipe construindo sobre esse sistema herda a correção automaticamente. Deixar para as telas individuais lembrarem significa que a correção precisa ser redescoberta, e reesquecida, toda vez que alguém constrói uma tela nova.

Fontes

• National Eye Institute. Color Blindness. nei.nih.gov/learn-about-eye-health/eye-conditions-and-diseases/color-blindness
• National Library of Medicine, MedlinePlus. Color vision deficiency. medlineplus.gov/genetics/condition/color-vision-deficiency
• W3C Web Accessibility Initiative. Understanding SC 1.4.1: Use of Color. w3.org/WAI/WCAG22/Understanding/use-of-color
• Okabe, M. e Ito, K. Color Universal Design (CUD): How to make figures and presentations that are friendly to Colorblind people. jfly.uni-koeln.de/color
• Colblindor. Coblis: Color Blindness Simulator. color-blindness.com/coblis-color-blindness-simulator
• WebAIM. Screen Reader User Survey #10 Results. webaim.org/projects/screenreadersurvey10