Accesibilidad de colores para desarrolladores Contraste, simulación de ceguera y solución de problemas

El contraste deficiente es un error. No una omisión de diseño, ni una característica de experiencia de usuario, sino un error que rompe tu interfaz para un porcentaje medible de usuarios. Aquí te explico cómo encontrarlo, simularlo y solucionarlo sin tener que rehacer todo el diseño.

Lo que dice WCAG sobre el contraste

Las Guías de accesibilidad del contenido web (WCAG) definen ratios mínimos de contraste entre el texto y su fondo. Estos ratios van desde 1:1 (colores idénticos, invisibles) hasta 21:1 (negro sobre blanco, máximo).

WCAG 2.1 especifica dos niveles de conformidad:

Nivel WCAG	Relación de contraste	Tamaño del texto	Ejemplo
AA	4.5:1	Texto normal (< 18pt / < 14pt en negrita)	La mayor parte del cuerpo del texto
AA	3:1	Texto grande (≥ 18pt / ≥ 14pt en negrita)	Encabezados
AAA	7:1	Texto normal	Mayor legibilidad
AAA	4.5:1	Texto grande	Encabezados (más estricto)
Cualquier	3:1	Componentes de interfaz y gráficos	Íconos, bordes de formularios

El nivel AA es la base legal en la mayoría de jurisdicciones. El nivel AAA es aspiracional para textos críticos como el cuerpo del texto, pero rara vez se requiere en toda la página.

Cómo se calcula la relación de contraste

La fórmula toma la luminancia relativa de cada color:

Contrast ratio = (L1 + 0.05) / (L2 + 0.05)

Donde L1 es la luminancia del color más claro y L2 es el más oscuro. La luminancia misma proviene de linearizar cada canal RGB y ponderarlos (rojo: 0.2126, verde: 0.7152, azul: 0.0722) — porque los ojos humanos son más sensibles al verde.

No necesitas hacer este cálculo a mano. Pega dos valores hexadecimales en un Cuadro de contraste de colores y obtendrás la relación, el estado de paso/fracaso AA/AAA y una vista en cuadrícula que compara toda tu paleta de colores de forma simultánea.

Lo que la fórmula te dice en la práctica: un gris intermedio #767676 sobre blanco #ffffff alcanza casi exactamente 4.5:1 — el mínimo requerido para AA. Si lo haces más claro, fallas. Si lo haces más oscuro, ganas margen.

Deficiencia de visión de color: más común de lo que crees

Aproximadamente 8% de hombres y 0.5% de mujeres tienen alguna forma de deficiencia de visión de color. Los tipos principales:

• Deuteranopia — sensibilidad reducida al verde. La forma más común (~5% de hombres). El rojo y el verde se vuelven difíciles de distinguir; ambos pueden parecer marrones o amarillentos.
• Protanopia — sensibilidad reducida al rojo (~1% de hombres). Los rojos parecen oscuros y desatenuados; la confusión entre rojo y verde es similar a la deuteranopia, pero los rojos también pierden brillo.
• Tritanopia — sensibilidad reducida al azul (muy rara, ~0.003%). La discriminación entre azul y amarillo se ve afectada; el azul parece verde, el amarillo parece violeta.

Estos no son casos extremos. Si tu producto tiene 10.000 usuarios mensuales, estadísticamente entre 400 y 500 de ellos tienen alguna forma de deficiencia de visión de color.

¿Por qué el color solo no es suficiente (WCAG 1.4.1)?

El criterio de éxito WCAG 1.4.1 — “Uso del color” — dice que el color no puede ser el Los nombres de las cookies son sensibles a mayúsculas y minúsculas medio para transmitir información, indicar una acción o distinguir un elemento visual.

El fallo clásico: un formulario que marca campos inválidos en rojo. Para alguien con protanopia, esos campos se ven como marrón oscuro, lo mismo que los campos válidos en luz tenue. No hay otro indicador.

La solución no es eliminar el color — es añadir una segunda señal. Un ícono, un cambio de borde, una etiqueta, un mensaje de error en línea. El color se convierte en un refuerzo, no en el único portador del significado.

Cómo solucionar realmente los problemas de contraste

La intuición es cambiar el tono — cambiar el azul por otro azul. Esto normalmente no ayuda. Cambios de tono afectan muy poco el ratio de contraste. Lo que sí afecta es la luminosidad.

En HSL, el valor L controla la luminancia. Para solucionar un fallo de contraste:

1. Aumenta la luminancia del color de fondo (aumenta la diferencia de L frente al fondo) — o reduce la luminancia del fondo
2. Mantén el tono y la saturación — solo ajusta la luminosidad
3. Revisa nuevamente el ratio

Un culpable común: colores de marca elegidos por estética, no por legibilidad. El teal característico de una marca #00b4a2 sobre blanco da aproximadamente 2.4:1 — falla en AA. Aumenta su luminosidad a #007a6e y llegas a 4.7:1 — pasa. Mismo tono de familia, cambio casi imperceptible en la identidad de marca.

Para el texto de placeholder — a menudo estilizado con color: #999 o similares — la historia es peor. Gris sobre blanco suele dar 2.5–3:1. Aumenta a #767676 mínimo, o reconsidera usar el texto de placeholder como etiqueta principal (lo que WCAG desaconseja de hecho).

Flujo de pruebas

Un buen flujo de accesibilidad tiene tres capas:

1. Verificaciones automatizadas (rápidas, pero incompletas)
Los linters y las herramientas de CI detectan fallos evidentes. axe-core se integra con Jest, Playwright y Cypress. Lighthouse (integrado en Chrome DevTools) da una puntuación rápida de accesibilidad. Estas herramientas detectan fallos de contraste, textos ausentes y mal uso de ARIA — pero solo evalúan lo visible en el DOM en el momento de la prueba. alt 2. Simulación (rápida, detecta problemas reales de diseño)

Simula cómo se ve tu interfaz bajo diferentes condiciones de visión antes de lanzarla. El
Simulador de deficiencia de visión te permite subir una captura de pantalla y verla desde modos de deuteranopia, protanopia, tritanopia y otros. Chrome DevTools también tiene un emulador de deficiencia de visión en la configuración de renderizado. La simulación revela problemas que las herramientas automatizadas no detectan: un dashboard donde la barra de “error” es indistinguible de la barra de “éxito” porque ambas parecen marrones bajo deuteranopia. El ratio de contraste de cada barra podría pasar AA — pero siguen siendo visualmente idénticas para un usuario con deficiencia de color.

3. Pruebas con usuarios reales (lentas, autoritativas)

Nada reemplaza el feedback de personas con deficiencia real de visión. Incluye la accesibilidad en tu investigación de usuarios. Organizaciones como el Paciello Group ofrecen servicios de pruebas; también funciona reclutar a través de comunidades específicas de discapacidad.
Herramientas para mantener en el flujo

— pega tu paleta completa de colores, ve todas las combinaciones de fondo/frente y su estado de paso/fracaso según WCAG en una vista única

• Cuadro de contraste de colores — sube una captura de pantalla, prevé cómo se ve bajo todos los tipos principales de deficiencia
• te permite subir una captura de pantalla y verla desde modos de deuteranopia, protanopia, tritanopia y otros. Chrome DevTools también tiene un emulador de deficiencia de visión en la configuración de renderizado. axe DevTools
• (extensión de navegador) — ejecúta en cualquier página en vivo, marca violaciones con referencias a elementos Plugins de Figma
• — “Stark” y “A11y – Color Contrast Checker” funcionan directamente en los archivos de diseño antes de que se construya nada CLI
• color-contrast — verificación scriptable del ratio, útil en hooks de pre-commit o en CI Verifica los ratios de contraste durante el diseño, no después de QA. 4.5:1 para el cuerpo del texto, 3:1 para el texto grande y los componentes de interfaz. Cuando corriges un color que falla, ajusta la luminosidad — no el tono. Realiza simulaciones para tu paleta principal de colores y cualquier visualización de datos. Y nunca uses el color como único indicador de estado.

La versión breve

La accesibilidad no es una lista de verificación que se ejecuta al final. El contraste deficiente es un error que se envía silenciosamente, afecta a usuarios reales y casi siempre se puede solucionar en menos de cinco minutos una vez que se sabe dónde buscar.

Accesibilidad de colores para desarrolladores: contraste, simulación de deficiencia de color y solución de problemas 2

También te puede interesar