Cómo elegir combinaciones de colores accesibles
Las elecciones de color parecen una decisión estética y actúan como una decisión legal. Aproximadamente 4.000 demandas de accesibilidad web al año golpean a los demandados estadounidenses desde 2021, y el contraste de color insuficiente es uno de los tres problemas más citados en demandas basadas en WCAG (junto con texto alternativo faltante y campos de formulario sin etiquetar). La buena noticia: el contraste es el más simple de los tres de corregir. La mala: «accesible» va más allá del ratio principal: daltonismo, indicadores de foco, modo oscuro y tokenización importan todos.
Breve historia de la accesibilidad de color digital
El contraste de color como estándar escrito data del primer trabajo de Web Accessibility Initiative del W3C en 1997. Las Web Content Accessibility Guidelines 1.0 originales (mayo de 1999) recomendaban contraste suficiente en términos cualitativos sin un número duro. WCAG 2.0 (diciembre de 2008) introdujo la fórmula de luminancia relativa hoy familiar y el ratio 4,5:1 al nivel AA, sacado de investigación de Lighthouse International sobre lo que usuarios mayores con gafas podían leer cómodamente en pantalla.
El peso legal vino después. La Sección 508 del Rehabilitation Act referenció WCAG 2.0 en 2018; el ADA, tras el fallo Robles v. Domino's del Noveno Circuito el 15 de enero de 2019 (Corte Suprema rechazó oír el recurso en octubre de 2019), es leído ahora por tribunales de EE. UU. como cubriendo accesibilidad digital bajo el Título III. La European Accessibility Act entró en vigor el 28 de junio de 2025, exigiendo WCAG 2.1 AA en servicios digitales de consumo para el sector público y muchas empresas privadas. En la práctica, 4,5:1 texto normal + 3:1 texto grande + 3:1 componentes UI es el piso de facto.
La ciencia ha seguido evolucionando. WCAG 2.1 (2018) añadió la regla de contraste no-texto 3:1. El algoritmo APCA, desarrollado por Andrew Somers para WCAG 3, modela la percepción de brillo con más precisión; es un Editor's Draft en 2026, no todavía un estándar. OKLAB y OKLCH de Bjorn Ottosson (2020) dieron a los diseñadores un espacio de color perceptualmente uniforme que hace generar escalas de color accesibles mucho más fácil que trabajar en HSL o RGB.
Qué significa realmente «color accesible»
Cuatro cosas importan, no solo el ratio:
- Contraste primer plano vs fondo. El número principal. Texto del cuerpo: 4,5:1, texto grande: 3:1, controles UI e indicadores de foco: 3:1 contra colores adyacentes.
- Daltonismo. Aproximadamente 8 % de los hombres y 0,5 % de las mujeres ven menos colores que asume el diseño. Los tres tipos principales son protanopia y deuteranopia (rojo-verde) y tritanopia (azul-amarillo).
- El color nunca es la única señal. WCAG 1.4.1 prohíbe depender solo del color para transmitir significado. Un borde de error rojo necesita también un icono o etiqueta.
- Indicadores de foco. Los usuarios de teclado necesitan ver dónde está el foco. WCAG 2.4.7 exige un indicador visible, y la actualización 2.4.11 (WCAG 2.2) exige al menos 2 píxeles CSS de grosor y 3:1 de contraste.
Cómo elegir colores accesibles, paso a paso
- Empieza con tokens semánticos, no colores crudos. Define
text-primary,text-secondary,surface-default,surface-elevated,border-default,accent-primary,accent-danger, etc. - Elige la escala de luminosidad. Usa valores de luminosidad OKLCH para construir una escala de 5-9 pasos donde cada paso tiene una diferencia perceptual constante.
- Elige tonos en cada paso. Toma el tono de marca, luego elige tonos complementarios o de acento que mantengan croma similar.
- Calcula los ratios de contraste. Cada par de tokens que se tocan necesita el ratio correcto.
- Pasa un simulador de daltonismo. Toma una pantalla clave y re-rendérizala a través de protanopia, deuteranopia y tritanopia.
- Prueba con tecnología asistiva real. VoiceOver, NVDA, JAWS y TalkBack deberían poder navegar sin depender de pistas de color.
- Añade la señal no-color donde el color lleve significado. Iconos para error/éxito/advertencia, subrayados para enlaces en cuerpo, patrones para series de gráfico.
- Documenta los tokens. Una biblioteca Figma, una página Storybook, o un sitio de design system estático.
Referencia de ratios de contraste
| Par | WCAG 2.1 min | Nivel AA | Nivel AAA |
|---|---|---|---|
| Texto cuerpo (bajo 18 pt regular o 14 pt negrita) | 4,5:1 | 4,5:1 | 7:1 |
| Texto grande (18 pt regular o 14 pt negrita) | 3:1 | 3:1 | 4,5:1 |
| Componentes UI (bordes formulario, estados toggle, foco) | 3:1 | 3:1 | n/a |
| Objetos gráficos (iconos con significado) | 3:1 | 3:1 | n/a |
| Texto dentro de un logo | exento | exento | exento |
| Controles deshabilitados | exento | exento | n/a |
| Texto decorativo | exento | exento | exento |
Tipos de daltonismo y cómo comprobar
| Tipo | Prevalencia | Ve menos de | Fallo común |
|---|---|---|---|
| Protanopia | ~1 % de hombres | Rojo | Error rojo vs éxito verde indistinguibles |
| Deuteranopia | ~5 % de hombres | Verde | Igual: confusión rojo-verde |
| Tritanopia | ~0,005 % | Azul | Azul vs amarillo indistinguibles |
| Acromatopsia | ~0,003 % | Todo color | Solo ve luminancia en escala de grises |
| Tricromasía anómala | ~5 % | Sensibilidad reducida en un canal | Diferencias de color sutiles se fusionan |
Errores comunes
- Diseñar en HSL o RGB. Pasos numéricos iguales en HSL producen pasos percibidos desiguales. OKLCH lo corrige.
- Fiarse solo del color para estado. Rojo y verde para error y éxito: 8 % de usuarios no los distinguen. Añade icono o etiqueta.
- Negro puro sobre blanco puro.
#000sobre#FFFda 21:1 pero es duro para lectura larga. Baja a un casi-negro y un casi-blanco. - Tiranía del color de marca. Tratar el rojo de marca como sagrado y usarlo a 2,1:1 «porque es la marca». Refresca la paleta de marca.
- Indicador de foco invisible en fondos oscuros. Un anillo azul 2px contra un botón azul oscuro puede ser invisible. Prueba el foco contra todas las superficies.
- Placeholder que falla contraste. El texto
placeholder=se renderiza al ~40 % opacidad. En un input blanco cae bajo 4,5:1 fácilmente. - Bordes de campo demasiado tenues. Un borde 1px gris-sobre-blanco a 1,2:1 falla WCAG 1.4.11. Sube a 3:1 o más grueso.
- Hover que solo cambia color. Algunos dispositivos no producen hover. Combina con sombra sutil o transformación.
- Modo oscuro por simple inversión. Invertir produce colores oscuros saturados que son duros. El modo oscuro necesita su propio pase.
- Texto auto-generado sobre imágenes. Texto sobre una imagen subida no puede garantizar contraste. Añade fondo translúcido o text-shadow.
Algoritmos y estándares alternativos
| Algoritmo | Año | Estado | Fuerte |
|---|---|---|---|
| Ratio de contraste WCAG 2.x | 2008 | Requerido por la mayoría de regulación | Matemáticas simples, ampliamente herramentado |
| APCA | 2020 | Editor's Draft WCAG 3 | Mejor en brillo perceptual |
| ISO 9241-302 | 2008 | Estándar de ergonomía de estación de trabajo | Muy estricto, orientado a hardware |
| Avisos de contraste Lighthouse | 2018 | Chrome DevTools | Gratis, en el navegador |
| axe-core | 2015 | Biblioteca open source | Estándar de la industria para test automatizado |
Para trabajo regulado hoy, WCAG 2.1 AA es el piso. APCA vale la pena seguir mientras WCAG 3 madura; muchos equipos de design system ya reportan ambos números.
Herramientas para elegir colores accesibles
| Herramienta | Propósito | Fuerte |
|---|---|---|
| Verificador de contraste (navegador) | Puntuar par primer plano/fondo | Instantáneo, sin subida |
| Generador de paleta accesible | Construir escala completa a croma constante | OKLCH para uniformidad perceptual |
| Simulador de daltonismo | Re-renderizar pantalla como ve un daltónico | Captura problemas rojo-verde antes del lanzamiento |
| Chrome DevTools Lens | Inspeccionar contraste y daltonismo en su sitio | Integrado en el navegador |
| WebAIM Contrast Checker | Referencia WCAG 2 clásica | De confianza, ampliamente citado |
| Stark (plugin Figma) | Auditar diseños Figma | Captura problemas en tiempo de diseño |
| axe DevTools (navegador) | Escaneo WCAG automatizado | Estándar de la industria |
| Escalas Tailwind, Radix, Open Props | Paletas OKLCH pre-testeadas | Accesibilidad curada por equipos de diseño |
Privacidad y las herramientas
El verificador de contraste, generador de paleta accesible y simulador de daltonismo corren enteramente en tu navegador. Los colores que eliges o pegas se procesan por JavaScript en tu dispositivo, los resultados se renderizan en la página, y no se envía nada a un servidor. Sin telemetría, sin analytics sobre la entrada, sin scripts de terceros. Para colores de marca aún no públicos, paletas de producto internas, o diseños bajo embargo, ese flujo estrictamente local es la diferencia entre confiar los activos de marca no lanzados al herramienta de un desconocido y no. Las herramientas pueden correr offline una vez cargada la página, lo que puedes verificar desconectando la red y recomprobando un par.
Preguntas frecuentes
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.