Contraste de color accesible: WCAG sin la papilla gris
Cómo diseñar para contraste WCAG 2.2 sin aplanar tu marca. Ratios, APCA, sistemas de diseño reales y un flujo de pruebas tokenizado.
La accesibilidad y la personalidad de 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 contraste, y también es por qué tantas rebrandings "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 tokens, 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 se equivocan, y saber dónde realmente ocurre el trabajo.
Por qué el contraste es la única regla que no puedes saltar
Cerca de 300 millones de personas ven el color de manera diferente a lo que tu paleta base asume, y aún más usan interfaces con poca luz, pantallas malas, o pérdida parcial de visión de la que nadie ha reportado 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 arreglar. Puntos ciegos, deficiencias de color, brillos, ojos envejecidos, monitores baratos, luz solar directa en la pantalla de un teléfono. Todos colapsan en la misma solución: suficiente contraste entre el texto y el fondo para que el mensaje sobreviva al caso más difícil, no solo a la pantalla Retina del diseñador.
El costo de equivocarse aquí no es solo exclusión. Es exposición legal. El Acta Europea de Accesibilidad en la UE, la Sección 508 en EE.UU., AODA en Ontario y una lista creciente de leyes nacionales usan WCAG como su referencia legal. El contraste es una de las primeras cosas que una auditoría revisa porque es una de las primeras cosas que se rompe en producción.
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 se aplica a un tipo específico de elemento de UI.
| Elemento | AA mínimo | AAA mínimo | Notas |
|---|---|---|---|
| Texto de cuerpo | 4.5:1 | 7:1 | Cualquier texto menor a 18pt regular o 14pt bold |
| Texto grande | 3:1 | 4.5:1 | 18pt+ regular o 14pt+ bold |
| Componentes y gráficos de UI | 3:1 | No especificado | Botones, iconos, bordes de formulario, anillos de foco |
| Texto en logos o imágenes decorativas | Exento | Exento | Elementos de marca y texto incidental no cuentan |
AA es el nivel al que apuntan la mayoría de los productos comerciales y el que la mayoría de las leyes de accesibilidad requieren. AAA es un objetivo más estricto, usado principalmente en trabajo gubernamental, de salud y educativo. A menos que alguien te entregue un documento de cumplimiento diciendo AAA, AA es el piso.
La trampa en la que caen la mayoría de los diseñadores es olvidar la regla 3:1 para elementos no textuales. Un borde de campo de formulario a 2:1 contra el fondo de la página falla incluso si la etiqueta dentro pasa.
Un anillo de foco con contraste insuficiente falla. Un icono cuyo significado depende del color a 2.5:1 falla. El contraste de elementos no textuales no es opcional.
Por qué las matemáticas de WCAG a menudo están mal
Las ratios de contraste de WCAG son una fórmula de hace 30 años que ignora la visión perceptual, y por eso a veces aprueban colores que se ven terribles y rechazan colores que se ven bien.
La fórmula de WCAG 2 se basa solo en luminancia. Trata la relación entre texto y fondo como una relación lineal entre la luminosidad relativa de dos colores. Eso no es cómo el sistema visual humano lee el contraste en realidad.
El contraste perceptual real depende del peso de fuente, tamaño de fuente, temperatura de color, y qué ha estado mirando el ojo un segundo antes. WCAG 2 no maneja nada de esto. El resultado es una ratio que trata texto gris claro sobre blanco igual que texto negro sobre gris claro, aunque uno es legible y el otro es doloroso.
Cómo APCA resuelve el problema perceptual
APCA, el Algoritmo de Contraste Perceptual Accesible, mide el contraste tal como funciona la visión humana, y por eso el borrador de WCAG 3 lo propone como reemplazo.
Las puntuaciones 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 y oscuro-sobre-claro se comportan de forma diferente al ojo).
Umbrales APCA aproximados para texto común:
- Cuerpo de texto (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 aún no es legalmente requerido 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 WCAG 2 AA para cumplimiento y cumplir APCA para calidad real. 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, así que los diseñadores eligen un rol en lugar de calcular una ratio.
Radix Colors
Radix Colors entrega escalas de 12 pasos con cada paso pre-asignado a un rol. Los pasos 11 y 12 son los pasos de texto de alto contraste, garantizados para pasar WCAG AA contra los pasos más bajos. Los tokens de rol (text, textContrast, solid, solidHover) significan que los diseñadores nunca calculan una ratio. Eligen un rol.
Qué robar: el modelo de contraste-por-rol numerado. Cualquier diseñador que alcance el paso 11 sabe que pasa contra los pasos más claros de la misma escala. La ratio está codificada en el número del paso.
Material Design 3
Vérlo 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é robar: el patrón on-. Cuando un diseñador alcanza on-primary para texto, la accesibilidad es automática. No hay decisión que equivocarse.
Dos más: ratios y sistemas perceptuales
Radix y Material resuelven el contraste mediante el emparejamiento de roles. Los siguientes dos lo resuelven mediante ratios documentadas y escalas perceptualmente uniformes. Ambos enfoques funcionan. Ambos valen la pena robar.
GitHub Primer
Primer separa los tokens de primer plano, fondo y borde en niveles explícitos con ratios de contraste documentadas. Su fg.default y bg.default se publican con ratios exactas, y cada token semántico basado en rol tiene el mismo tratamiento.
Qué robar: publicar las ratios junto a los tokens. Cuando el contraste de cada token contra cada fondo relevante está documentado, diseñadores y desarrolladores pueden saltarse el checker por completo.
Adobe Spectrum
Vérlo 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 entre matices. Eso significa que intercambiar matices dentro de un tema preserva las relaciones de contraste. No más "pasó en azul pero falla en naranja".
Qué robar: uniformidad perceptual. Escalas construidas sobre modelos perceptuales (como HSLuv, OKLCH, o el enfoque personalizado de Spectrum) hacen la accesibilidad portable entre temas de marca.
Cómo mantenerte accesible sin perder personalidad
La accesibilidad no significa texto negro sobre blanco y una marca mutea, y los equipos que entregan los productos más inclusivos son los que lo descifraron.
El truco está en dónde vive la accesibilidad en la pila. Si vive en la capa de tokens, la marca puede ser vívida y los diseñadores aún obtienen salidas accesibles. Si vive como revisión final, cada color de marca es un pasivo esperando fallar una auditoría.
Tres técnicas mantienen personalidad y 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 cada superficie.
- Usa escalas perceptualmente uniformes. OKLCH y HSLuv mapean valores de color a brillo percibido, así que puedes rotar matices sin romper el contraste. Radix, Spectrum, y Material 3 hacen variaciones de esto.
- Entrega el modo oscuro como un conjunto de tokens paralelo, no como un pensamiento 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 un color distinto en oscuro, ambos valores deben pasar contra su superficie emparejada.
El peor resultado es el compromiso que nadie pidió: una marca mutea que todavía no es accesible. Eso sucede cuando los equipos reaccionan a retroalimentación de contraste desaturando cada color en lugar de arreglar los emparejamientos. La desaturación no es lo mismo que la accesibilidad. Las relaciones sí.
El flujo de pruebas de accesibilidad
Probar el contraste es barato, automatizado y completamente inútil si lo dejas hasta la revisión de diseño.
El flujo que funciona ejecuta pruebas de contraste en cuatro puntos, no en uno.
- En la definición del token. Cuando se crea un token, sus superficies permitidas se definen también.
text-defaultsolo está permitido enbg-default,bg-subtle, ybg-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 axe-core o pa11y ejecuta checks de accesibilidad en cada variante de componente como parte de CI. Cualquier nueva variante que falle se bloquea antes del merge.
- En la entrega del archivo de diseño. Plugins de Figma como Stark o el verificador WCAG integrado marcan problemas dentro de la herramienta de diseño. Atrapa al tiempo de diseño, no al tiempo de revisión.
- En el nivel de página. Lighthouse, axe DevTools, o pa11y se ejecutan en páginas vivas en staging o producción. Esto atrapa fallos del mundo real (embebidos de terceros, contenido generado por usuario, temas dinámicos) que las pruebas de componentes pierden.
El punto no es ejecutar más herramientas. El punto es mover el check más temprano. Un fallo de contraste encontrado por un pipeline CI es un arreglo de cinco minutos. El mismo fallo atrapado en una auditoría pre-lanzamiento le cuesta al equipo una semana.
Para la razón estructural de por qué este enfoque por capas funciona, la guía de sistemas de diseño cubre por qué el pensamiento en capa de tokens gana. Y el artículo la regla 60-30-10 está rota explica por qué el color basado en roles (del cual depende la accesibilidad) reemplazó al pensamiento basado en proporciones.
Preguntas frecuentes
¿Es WCAG AA suficiente 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, salud, educación) y es caro de alcanzar sin aplanar la paleta. Apunta a AA como el piso, APCA-ideal como el techo.
¿Cada elemento no textual necesita cumplir ratios de contraste?
Los componentes de UI no textuales que transmiten significado necesitan 3:1 mínimo bajo WCAG 2.2. Eso cubre botones, bordes de formulario, anillos de foco, iconos con significado, y elementos gráficos. La decoración pura (patrones de fondo, gradientes ambientales) está exenta. Texto incidental (un logotipo, un pie de foto superpuesto) 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 reemplazo propuesto en el borrador de WCAG 3, basado en cómo funciona la percepción humana en realidad. Las puntuaciones APCA correlacionan mejor con la legibilidad real pero aún no son legalmente requeridas. Los productos en producción usan ambos: WCAG 2 para cumplimiento, APCA para calidad.
Integra 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 entregan los productos más inclusivos y con mayor fuerza de marca son los que dejaron de tratar la accesibilidad como un pensamiento posterior y empezaron a tratarla como una propiedad de la paleta de colores misma.
Los tokens codifican las ratios. Las escalas codifican los emparejamientos. Las pruebas ocurren en cuatro puntos en el flujo. Nadie está sosteniendo un checker de contraste contra una pantalla antes de un lanzamiento.
Si tu proceso actual involucra a un diseñador mirando de reojo una paleta buscando "legibilidad", vas a fallar una auditoría. Si tu proceso involucra una herramienta de checker más revisiones manuales, vas a fallar a escala. Si tu proceso involucra tokens basados en roles que codifican la accesibilidad en la capa de definición, vas a entregar.
Construye los tokens. Publica las ratios. Automatiza las pruebas. La marca se mantiene vívida, la interfaz se mantiene legible, y la auditoría se vuelve 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
