Contraste de Color Accesible: WCAG Sin el Pantano Gris
Cómo diseñar para el contraste WCAG 2.2 sin aplanar tu marca en gris. Ratios, APCA, ejemplos reales de sistemas de diseño y un flujo de trabajo de testing tokenizado.
La accesibilidad y la personalidad del diseño no están en conflicto. Ese es el mito que la mayoría de los equipos de marca se cuentan cuando evitan la conversación sobre el contraste, y también es la razón por la que tantas rebrands "accesibles" terminan pareciendo señalización de aeropuerto.
El contraste de color accesible es un problema de medición. Los sistemas de diseño modernos ya lo han resuelto en la capa de token, lo que significa que no tienes que elegir entre cumplir con WCAG y mantener la marca interesante. Solo tienes que conocer las reglas, saber dónde las reglas están mal, y saber dónde ocurre realmente el trabajo.
Por qué el Contraste Es la Única Regla que No Puedes Ignorar
Aproximadamente 300 millones de personas ven el color de forma distinta a lo que asume tu paleta base, y aún más usan interfaces con poca luz, en pantallas malas, o con pérdida parcial de visión sobre la que nadie ha abierto un ticket.
El bajo contraste es el fallo de accesibilidad más común en la web. También es el más fácil de corregir. Puntos ciegos, deficiencias de color, deslumbramiento, ojos envejecidos, monitores baratos, luz solar directa en la pantalla del móvil. Todos estos colapsan en la misma solución: suficiente contraste entre texto y fondo para que el mensaje sobreviva al caso más difícil, no solo a la pantalla Retina del diseñador.
El coste de equivocarse aquí no es solo exclusión. Es exposición a incumplimiento normativo. La Ley de Accesibilidad Europea de la UE, la Sección 508 en EE.UU., la AODA en Ontario, y una lista creciente de leyes nacionales todas usan WCAG como referencia legal. El contraste es una de las primeras cosas que verifica una auditoría porque es una de las primeras que llega rota a producción.
Las Reglas de Contraste de WCAG 2.2 en Lenguaje Claro
WCAG te da tres números: 4.5:1, 3:1 y 3:1, y cada uno aplica a un tipo específico de elemento de UI.
| Elemento | Mínimo AA | Mínimo AAA | Notas |
|---|---|---|---|
| Texto de cuerpo | 4.5:1 | 7:1 | Cualquier texto menor de 18pt regular o 14pt negrita |
| Texto grande | 3:1 | 4.5:1 | 18pt+ regular o 14pt+ negrita |
| Componentes de UI y gráficos | 3:1 | No especificado | Botones, iconos, bordes de formulario, anillos de foco |
| Texto en logos o imágenes decorativas | Exento | Exento | Los elementos de marca y el texto incidental no cuentan |
AA es el nivel al que apunta la mayoría de los productos comerciales y el que exigen la mayoría de las leyes de accesibilidad. AAA es un objetivo más estricto, usado principalmente en gobierno, sanidad y educación. A menos que alguien te entregue un documento de cumplimiento que diga AAA, AA es el mínimo.
La trampa en la que caen la mayoría de los diseñadores es olvidar la regla del 3:1 para elementos no textuales. Un borde de campo de formulario a 2:1 contra el fondo de la página falla aunque la etiqueta dentro pase.
Un anillo de foco con contraste insuficiente falla. Un icono cuyo significado depende del color a 2.5:1 falla. El contraste en elementos no textuales no es opcional.
Por qué las Matemáticas de WCAG Suelen Estar Mal
Los ratios de contraste de WCAG son una fórmula de 30 años que ignora la visión perceptual, por eso a veces aprueban colores que se ven terribles y reprueban colores que se ven bien.
La fórmula de WCAG 2 se basa únicamente en la luminancia. Trata el texto sobre fondo como una relación lineal entre el brillo relativo de dos colores. Así no es como el sistema visual humano lee el contraste.
El contraste perceptual real depende del peso de la fuente, el tamaño de la fuente, la temperatura del color y en qué ha estado mirando el ojo un segundo antes. WCAG 2 no contempla nada de esto. El resultado es un ratio que trata el texto gris claro sobre blanco igual que el texto negro sobre gris claro, aunque uno sea legible y el otro sea doloroso.
Cómo APCA Soluciona el Problema Perceptual
APCA, el Accessible Perceptual Contrast Algorithm, mide el contraste de la forma en que funciona realmente la visión humana, por eso el borrador de WCAG 3 lo propone como sustituto.
Las puntuaciones de APCA van de 0 (sin contraste) a aproximadamente 108 (contraste extremo). A diferencia de WCAG 2, tiene en cuenta el peso del texto, el tamaño del texto y la polaridad (claro sobre oscuro frente a oscuro sobre claro se comportan de forma distinta para el ojo).
Umbrales aproximados de APCA para texto común:
- Texto de cuerpo (16px regular): 75+ (requerido), 90+ (ideal)
- Cuerpo pequeño (14px regular): 90+ (requerido)
- Texto grande (24px+): 60+ (requerido)
- UI no textual: 45+ mínimo
APCA todavía no es un requisito legal en ningún lugar. Pero productos en producción ya lo usan como estándar interno porque correlaciona mejor con lo que realmente se lee bien. La jugada inteligente es cumplir con WCAG 2 AA para el cumplimiento normativo y cumplir con APCA para la calidad real. Alcanzar ambos objetivos a la vez no es difícil si tus tokens de color están diseñados para ello.
Cuatro Sistemas de Diseño que Tokenizan el Contraste
Estos sistemas ya codifican la accesibilidad en la capa de tokens, para que los diseñadores elijan un rol en lugar de calcular un ratio.
Radix Colors
Radix Colors incluye escalas de 12 pasos con cada paso preasignado a un rol. Los pasos 11 y 12 son los pasos de texto de alto contraste, garantizados para pasar WCAG AA contra los pasos inferiores. Los tokens de rol (text, textContrast, solid, solidHover) significan que los diseñadores nunca calculan un ratio. Eligen un rol.
Qué robarse: el modelo de contraste por número de rol. Cualquier diseñador que use el paso 11 sabe que pasa contra los pasos más claros de la misma escala. El ratio está codificado en el número de paso.
Material Design 3
Vélo en vivo en m3.material.io
Material 3 empareja cada rol de color con un contraparte on- (on-primary, on-surface, on-error) garantizado para cumplir 4.5:1 contra su padre. Los tokens emparejados son la capa de accesibilidad, construida directamente en el sistema.
Qué robarse: el patrón on-. Cuando un diseñador usa on-primary para texto, la accesibilidad es automática. No hay decisión que puedas tomar mal.
Dos Más: Ratios y Sistemas Perceptuales
Radix y Material resuelven el contraste a través del emparejamiento de roles. Los siguientes dos lo resuelven mediante ratios documentados y escalas perceptualmente uniformes. Ambos enfoques funcionan. Vale la pena robarse de ambos.
GitHub Primer
Primer separa los tokens de primer plano, fondo y borde en niveles explícitos con ratios de contraste documentados. Su fg.default y bg.default se publican con ratios exactos, y cada token semántico basado en roles recibe el mismo tratamiento.
Qué robarse: publicar los ratios junto a los tokens. Cuando el contraste de cada token contra cada fondo relevante está documentado, diseñadores y desarrolladores pueden saltarse el comprobador por completo.
Adobe Spectrum
Vélo en vivo en spectrum.adobe.com
Spectrum usa escalas de color perceptualmente uniformes para que dos tokens con el mismo número de paso tengan el mismo peso visual en todos los tonos. Eso significa que cambiar tonos dentro de un tema preserva las relaciones de contraste. Nada de "pasó en azul pero falla en naranja."
Qué robarse: la uniformidad perceptual. Las escalas construidas sobre modelos perceptuales (como HSLuv, OKLCH o el enfoque personalizado de Spectrum) hacen que la accesibilidad sea portable entre temas de marca.
Cómo Mantener la Accesibilidad Sin Perder Personalidad
Accesibilidad no significa texto negro sobre blanco y una marca apagada, y los equipos que lanzan los productos más inclusivos son los que lo entendieron.
El truco está en dónde vive la accesibilidad en el stack. Si vive en la capa de tokens, la marca puede ser vívida y los diseñadores obtienen outputs accesibles. Si vive como una revisión final, cada color de marca es un pasivo esperando fallar una auditoría.
Tres técnicas mantienen la personalidad y la accesibilidad en la misma habitación:
- Divide el nivel de acento en un color de marca y un color de acción accesible. Linear usa un morado específico para momentos de marca y un morado ligeramente diferente para elementos interactivos. Ambos son reconociblemente la marca. Solo uno está garantizado contra todas las superficies.
- Usa escalas perceptualmente uniformes. OKLCH y HSLuv mapean los valores de color al brillo percibido, para que puedas rotar entre tonos sin romper el contraste. Radix, Spectrum y Material 3 hacen variaciones de esto.
- Lanza el modo oscuro como un conjunto de tokens paralelo, no como un añadido posterior. Un token que falla en modo oscuro no está listo para modo oscuro. Si tu sistema resuelve
text-defaulta un color en claro y a uno diferente en oscuro, ambos valores deben pasar contra su superficie emparejada.
El peor resultado es el compromiso que nadie pidió: una marca apagada que todavía no es accesible. Eso sucede cuando los equipos reaccionan a los comentarios sobre contraste desaturando todos los colores en lugar de corregir los emparejamientos. La desaturación no es lo mismo que la accesibilidad. Las relaciones, sí.
El Flujo de Trabajo de Testing de Accesibilidad
Testear el contraste es barato, automatizable y completamente inútil si lo dejas para la revisión de diseño.
El flujo de trabajo que funciona ejecuta verificaciones de contraste en cuatro puntos, no en uno.
- En la definición del token. Cuando se crea un token, también se definen sus superficies permitidas.
text-defaultsolo está permitido enbg-default,bg-subtleybg-raised. El contraste del token contra cada uno se verifica una vez y se bloquea. - En el commit del componente. Storybook más una integración de axe-core o pa11y ejecuta verificaciones de accesibilidad en cada variante de componente como parte del CI. Cualquier variante nueva que falle se bloquea antes del merge.
- En la entrega del archivo de diseño. Los plugins de Figma como Stark o el verificador WCAG integrado marcan problemas dentro de la herramienta de diseño. Detéctalos en tiempo de diseño, no en tiempo de revisión.
- A nivel de página. Lighthouse, axe DevTools o pa11y se ejecuta en páginas en vivo en staging o producción. Esto detecta fallos del mundo real (embeds de terceros, contenido generado por el usuario, temas dinámicos) que las pruebas de componentes no capturan.
El punto no es ejecutar más herramientas. El punto es mover la verificación antes. Un fallo de contraste encontrado por un pipeline de CI es una corrección de cinco minutos. El mismo fallo detectado en una auditoría previa al lanzamiento le cuesta al equipo una semana.
Para entender la razón estructural por la que este enfoque en capas funciona, la guía de sistemas de diseño explica por qué el pensamiento a nivel de tokens gana. Y el artículo sobre la regla 60-30-10 está rota explica por qué el color basado en roles (del que depende la accesibilidad) reemplazó al pensamiento basado en proporciones.
Preguntas Frecuentes
¿Es suficiente WCAG AA o necesito AAA?
AA es el estándar para la mayoría de los productos comerciales y la mayoría de las leyes de accesibilidad. AAA solo es legalmente requerido en contextos específicos (gobierno, sanidad, educación) y es costoso de alcanzar sin aplanar la paleta. Apunta a AA como mínimo, APCA-ideal como techo.
¿Cada elemento no textual necesita cumplir los ratios de contraste?
Los componentes de UI no textuales que transmiten significado necesitan un mínimo de 3:1 bajo WCAG 2.2. Eso incluye botones, bordes de formulario, anillos de foco, iconos con significado y elementos gráficos. La decoración pura (patrones de fondo, degradados ambientales) está exenta. El texto incidental (un logotipo, una superposición de leyenda de foto) también está exento.
¿Cuál es la diferencia entre WCAG y APCA?
WCAG 2 es el estándar legal actual, basado en una fórmula de luminancia de 30 años. APCA es el sustituto propuesto en el borrador de WCAG 3, basado en cómo funciona realmente la percepción humana. Las puntuaciones de APCA correlacionan mejor con la legibilidad real, pero todavía no son un requisito legal. Los productos en producción usan ambos: WCAG 2 para el cumplimiento, APCA para la calidad.
Hornea la Accesibilidad en los Tokens
El contraste de color accesible no es una elección de estilo. Es una propiedad del sistema.
Los equipos que lanzan los productos más inclusivos y con mayor identidad de marca son los que dejaron de tratar la accesibilidad como un añadido posterior y empezaron a tratarla como una propiedad de la propia paleta de color.
Los tokens codifican los ratios. Las escalas codifican los emparejamientos. El testing ocurre en cuatro puntos del flujo de trabajo. Nadie está poniendo un comprobador de contraste frente a una pantalla antes de un lanzamiento.
Si tu proceso actual implica que un diseñador ojea una paleta para ver si "parece legible", vas a fallar una auditoría. Si tu proceso implica una herramienta de comprobación más revisiones manuales, vas a fallar a escala. Si tu proceso implica tokens basados en roles que codifican la accesibilidad en la capa de definición, vas a lanzar.
Construye los tokens. Publica los ratios. Automatiza las verificaciones. La marca sigue siendo vívida, la interfaz sigue siendo legible, y la auditoría se convierte en una formalidad en lugar de una reconstrucción.
Need a color system that hits WCAG without flattening the brand? Brainy builds token-layer accessibility into every palette.
Get Started
