Generador de paletas de colores accesibles

¿Qué es un generador de paleta de colores accesible?

Un generador de paleta de colores accesible es una herramienta que le ayuda a ensamblar un conjunto de colores para un sitio web, aplicación o diseño impreso donde cada par de colores destinado a mostrarse junto (texto sobre fondo, botón sobre lienzo, etiqueta sobre campo) cumple con los requisitos de contraste WCAG. El punto es detectar combinaciones de bajo contraste en tiempo de diseño en lugar de en tiempo de auditoría. Agrega colores a una paleta, la herramienta calcula la relación de contraste entre cada par, y etiqueta cada par como AAA pasa, AA pasa, o falla. Itera hasta que cada par que realmente pretende usar pase.

La relación de contraste es un número entre 1:1 (colores idénticos, invisible) y 21:1 (negro sobre blanco). WCAG 2.2 Criterio de Éxito 1.4.3 requiere 4.5:1 para texto del cuerpo en tamaño estándar (Nivel AA), 3:1 para texto grande (24px+ regular o 18.66px+ negrita), y 4.5:1 para elementos gráficos y controles de UI (SC 1.4.11). WCAG AAA eleva el texto del cuerpo a 7:1 y el texto grande a 4.5:1. La mayoría de los sitios web orientados al público deben cumplir al menos con AA según ADA, EAA, AODA y leyes similares; los sitios gubernamentales en muchas jurisdicciones deben cumplir con AAA.

Esta herramienta se ejecuta en su navegador. Elige colores con el selector de colores, la herramienta calcula la luminancia relativa y las relaciones de contraste usando la fórmula especificada por WCAG, y una cuadrícula muestra el estado de cada par. Puede exportar la paleta final como propiedades personalizadas CSS (var(--brand-primary)), lista HEX, fragmento de configuración Tailwind o JSON para tokens de diseño. Nada se carga; toda la paleta permanece en su dispositivo.

Qué hay dentro de la herramienta

La parte superior de la herramienta es un selector de colores más un botón agregar a paleta. Elige un color, nómbralo (Marca Primaria, Superficie, Texto del Cuerpo, etc.), y agrega. La paleta crece como una lista de muestras en el lado izquierdo. Puede editar cualquier muestra, eliminarla o arrastrar para reordenar. Las paletas accesibles predefinidas están disponibles como puntos de partida (pares de alto contraste, paletas diseñadas estilo IBM Carbon, paletas tonales de Material Design 3); elige una, luego personaliza.

La cuadrícula de contraste toma cada par de muestras y muestra la relación de contraste más una insignia de aprobado/reprobado para cada nivel WCAG: AA-normal (4.5:1), AA-large (3:1), AAA-normal (7:1), AAA-large (4.5:1). Un par mostrado como 4.7:1 pasa AA-normal pero falla AAA-normal; un par mostrado como 2.1:1 falla todo. Pase el cursor sobre una celda para previsualizar el par como texto real. Ordene la cuadrícula por relación para detectar primero los peores pares.

El panel de exportación formatea la paleta de la manera que su cadena de herramientas espera: propiedades personalizadas CSS para CSS moderno, variables Sass para pipelines más antiguos, configuración de tema Tailwind para Tailwind CSS, tokens de diseño JSON (Style Dictionary, especificación del W3C Design Tokens Community Group) para sistemas de diseño multiplataforma, o simplemente una lista HEX para pegar en Figma. Las convenciones de nomenclatura se conservan; puede copiar y pegar directamente en su base de código.

Historia y contexto

La colorimetría CIE establece el color científico (1931)

La Comisión Internacional de Iluminación (CIE) publicó el espacio de color CIE 1931 en 1931, la primera descripción matemática formal de cómo los humanos perciben el color a partir de espectros electromagnéticos. Cada sistema de color moderno (RGB, HSL, OKLCH, Lab, XYZ) se basa en CIE 1931 directamente o mediante transformaciones derivadas. La fórmula de luminancia relativa que usa WCAG para calcular el contraste es un cálculo derivado de CIE: pondera los canales rojo, verde y azul según la fuerza con la que el ojo humano responde a cada uno (verde más, azul menos).

WCAG 1.0 introduce pautas de contraste (1999)

Las Pautas de Accesibilidad para el Contenido Web 1.0 (W3C, mayo de 1999) introdujeron el contraste como un criterio formal de accesibilidad (Punto de Control 2.2: asegúrese de que las combinaciones de color de primer plano y fondo proporcionen suficiente contraste). La primera versión era cualitativa; el umbral era vago. WCAG 2.0 (diciembre de 2008) fue la primera en especificar relaciones de contraste numéricas usando la fórmula de luminancia relativa WCAG. Los umbrales 4.5:1 y 7:1 en 2.0 se han mantenido sin cambios a través de 2.1 (2018) y 2.2 (2023) porque equilibran la legibilidad en la mayoría de las discapacidades (baja visión, pérdida de sensibilidad al contraste relacionada con la edad, daltonismo) con limitaciones prácticas de diseño.

Los sistemas de diseño codificados por color maduran (2014 en adelante)

Material Design de Google (2014), Carbon Design System de IBM (2015) y el auge más amplio de los tokens de diseño (Salesforce 2014, Atlassian 2016) pusieron en primer plano el color accesible como una preocupación a nivel de sistema. Material Design 3 (2021) introdujo paletas tonales (una rampa de 13 pasos de luminosidad por tono) diseñadas explícitamente para que cualquier tono 600+ en la escala de luminosidad pase el contraste 4.5:1 sobre blanco. Este cambio convirtió las paletas accesibles por defecto en práctica estándar en sistemas de diseño modernos, reemplazando el enfoque anterior de marca primero accesibilidad después.

APCA propuesto como alternativa más precisa (2019 en adelante)

El Algoritmo de Contraste Perceptual Accesible (APCA) fue propuesto por Andrew Somers comenzando en 2019 como un reemplazo perceptualmente más preciso para la fórmula de contraste WCAG. El contraste WCAG sobrevalora la legibilidad de los colores claros y subvalora el texto oscuro sobre fondos oscuros; APCA corrige estos. Se espera que WCAG 3.0 (el borrador sucesor de 2.x, en desarrollo durante muchos años ahora) adopte APCA o un algoritmo mejorado similar. Hasta que WCAG 3 sea publicado y adoptado en la ley, las relaciones de contraste WCAG 2.x siguen siendo el estándar legal e industrial. Esta herramienta usa la fórmula WCAG 2.x.

Los tokens de diseño se convierten en el estándar multiplataforma (2020 en adelante)

El W3C Design Tokens Community Group se formó en 2020 para estandarizar los tokens de diseño (valores nombrados de color, espaciado, tipografía que se traducen a través de CSS, iOS, Android, Figma y otras plataformas). Herramientas como Style Dictionary, Tokens Studio y la especificación W3C emergente dependen de formatos de token legibles por máquina. Las paletas de colores accesibles se entregan cada vez más como tokens de diseño para que la misma paleta verificada se use en todas partes, eliminando el modo de falla donde el sitio web pasa el contraste pero la aplicación móvil no.

OKLCH y espacios de color perceptualmente uniformes (2020 en adelante)

El Módulo de Color CSS Nivel 4 (Recomendación Candidata 2024) agregó OKLCH, OKLab, Lab, LCH y otros espacios de color perceptualmente uniformes a CSS nativo. OKLCH (introducido por Bjorn Ottosson en 2020) es particularmente útil para generar paletas accesibles porque los pasos de luminosidad iguales se ven iguales al ojo, a diferencia de HSL donde los pasos en luminosidad producen saltos visuales desiguales. Los generadores de paleta modernos (Leonardo de Adobe, Polychrom, esta herramienta cuando se establece en modo de entrada OKLCH) aprovechan estos espacios para producir paletas visualmente más consistentes que cumplen con los objetivos de contraste en el mismo nivel de luminosidad.

Flujos de trabajo prácticos

Diseñar una nueva paleta de marca

Comience con el color de marca que debe conservar (el color del logotipo, el primario bendecido por el equipo de marketing). Agréguelo a la paleta, luego construya tintes (versiones más claras) y sombras (versiones más oscuras) junto con neutros (blanco, superficie, variante de superficie, texto). Verifique cada par texto-sobre-fondo contra AA-normal. Si su color de marca primaria falla en blanco, tiene dos opciones: úselo solo para elementos grandes (logos, acentos decorativos) y empareje el texto del cuerpo con una variante más oscura, o comprometa ligeramente el color de marca. Esta herramienta expone esas opciones en tiempo de diseño.

Auditar las decisiones de color de un sitio existente

Extraiga los valores de color de sus tokens de diseño existentes (propiedades personalizadas CSS, configuración de Tailwind, variables Sass), ingréselos en esta herramienta y revise la cuadrícula de contraste. Fallas comunes: texto gris apagado sobre blanco (a menudo #999 o #aaa, que da 2.8:1 o 2.5:1), botones color marca con texto blanco donde el botón es de tono medio, colores de enlace en fondos ocupados. Documente las fallas con sus relaciones y qué criterio WCAG violan; esa documentación es el comienzo de un plan de remediación.

Elegir colores de acento para gráficos y visualización de datos

Para visualización de datos, necesita colores de acento que pasen el contraste contra el fondo del gráfico y que también sean distinguibles entre sí para usuarios con deficiencia de visión del color. Empareje esta herramienta con ColorBrewer (Cynthia Brewer, Penn State, 2002) que publica paletas diseñadas para permanecer distinguibles bajo simulaciones de daltonismo. Ejecute paletas candidatas a través de ambas herramientas: contraste contra fondo (esta herramienta), distinguibilidad entre colores de paleta (ColorBrewer o Viz Palette).

Construir complementos de modo oscuro a una paleta clara

El modo oscuro no es solo modo claro invertido; los requisitos de contraste aún se aplican pero el ojo percibe el texto claro sobre oscuro diferente del texto oscuro sobre claro (el debate APCA es en gran parte sobre esto). Construya la paleta oscura como un conjunto paralelo de tokens nombrados (surface-dark, text-dark, accent-dark) y verifique cada par de modo oscuro contra AA. Fallas comunes de modo oscuro: blanco puro (#fff) sobre negro puro (#000) causa halación (luz sangrante), por lo que los diseñadores a menudo usan #e5e5e5 sobre #121212; esto aún pasa AA pero es más cómodo de leer.

Generar variantes de paleta para diferentes superficies

Las UI modernas tienen múltiples niveles de superficie (fondo, tarjeta, tarjeta-elevada, modal, popover). Cada superficie debe emparejarse correctamente con cada color de texto y acento usado encima. Agregue cada superficie como muestra de paleta y verifique cada color de texto contra cada superficie. La cuadrícula de contraste muestra rápidamente si su par texto-sobre-modal falla cuando texto-sobre-tarjeta pasa (el modal generalmente tiene un tinte de fondo ligeramente diferente para indicar elevación, lo que puede reducir el contraste por debajo de AA sin que se dé cuenta).

Documentación de cumplimiento para presentación legal o auditoría

Para documentación de cumplimiento ADA o EAA, generalmente necesita demostrar que cada combinación de color en su sistema de diseño pasa el nivel WCAG relevante. Exporte la paleta más la cuadrícula de contraste como parte de la declaración de accesibilidad o VPAT (Voluntary Product Accessibility Template) para su producto. El JSON exportado es lo suficientemente estructurado para alimentar informes de cumplimiento automatizados; la cuadrícula visual es buena para revisión humana.

Errores comunes

Tratar el color de marca como intocable

El patrón más común: marketing insiste en el color primario corporativo, pero falla el contraste AA en blanco. Opciones: use el color de marca solo para elementos grandes o decorativos (pasa la barra más indulgente de 3:1 texto grande), oscurezca el color ligeramente para uso de texto (la mayoría de las marcas tienen flexibilidad para una variante más oscura), o cambie el color de texto del cuerpo del negro a un gris oscuro menos duro para que el color de marca se lea como un acento. Herramientas como Leonardo (de Adobe) generan variantes accesibles de un color de marca automáticamente; empareje con esta herramienta para verificación.

Usar el contraste como única verificación de accesibilidad

Pasar el contraste no garantiza la legibilidad. Una relación 4.5:1 es el piso; algunos usuarios (baja visión, pérdida de sensibilidad al contraste relacionada con la edad, dislexia) se benefician de relaciones más altas. WCAG SC 1.4.6 (Contraste Mejorado, AAA) recomienda 7:1 para texto del cuerpo precisamente porque 4.5:1 es el mínimo, no el objetivo. Combine alto contraste con tamaño de fuente suficiente (16px+ para el cuerpo), altura de línea adecuada (1.5x tamaño de fuente) y opciones de fuente que preserven las formas de las letras (evite pesos ultradelgados para el texto del cuerpo).

Olvidar el contraste no textual (SC 1.4.11)

WCAG 1.4.11 (agregado en WCAG 2.1, 2018) requiere contraste 3:1 para componentes UI y elementos gráficos: bordes de campos de formulario, contornos de botones, iconos, indicadores de foco. Esto es fácil de pasar por alto porque los diseñadores piensan que el contraste solo se aplica al texto. Un formulario limpio con bordes de campo gris sutiles sobre blanco puede fallar 1.4.11 incluso si todo el texto pasa 1.4.3. Audite cada elemento visual que transmita significado o estado, no solo texto sobre fondo.

Malinterpretar las reglas de texto grande

El umbral de texto grande de WCAG (3:1 en lugar de 4.5:1) se aplica al texto que es 18pt o más grande (alrededor de 24px), o 14pt negrita (alrededor de 18.66px negrita). Cualquier cosa más pequeña es texto normal y necesita 4.5:1. Los diseñadores a veces aplican la regla 3:1 de texto grande a todos los niveles de encabezado, pero un h5 en 16px es texto normal según la definición de WCAG. Verifique el tamaño renderizado, no el nivel de encabezado. El modificador negrita importa: 18px negrita pasa como texto grande; 18px regular no.

Confiar solo en el color para transmitir información

WCAG 1.4.1 (Uso del Color, Nivel A) está separado del contraste. Incluso con relaciones de contraste perfectas, no puede usar el color como único indicador de estado (rojo significa inválido, verde significa válido, azul significa enlace). Empareje el color con una segunda señal: icono (triángulo de advertencia para errores), patrón (subrayado para enlaces) o etiqueta de texto (Requerido junto a campos obligatorios). Los usuarios daltónicos (alrededor del 8% de los hombres, 0.5% de las mujeres) y los usuarios en pantallas monocromas en escala de grises dependen de estas señales secundarias.

Olvidar los estados hover, focus y active

Un botón pasa el contraste en su estado predeterminado pero el estilo :hover lo aclara por debajo del umbral; el contorno :focus es un gris sutil que falla 3:1 contra el fondo del botón; el estado :active invierte los colores y la nueva combinación falla. Pruebe cada estado interactivo en su cuadrícula de contraste, no solo el predeterminado. El indicador de foco en particular es crítico (SC 2.4.7 Foco Visible, AA): si el foco no es claramente visible, los usuarios solo de teclado pierden su lugar en la página.

Privacidad y manejo de datos

Los colores que agrega, los nombres de paleta y los tokens exportados permanecen todos en su navegador. Los cálculos de contraste se ejecutan en JavaScript en su máquina; nada se carga. Esto importa menos para paletas de colores que para documentos pero aún importa cuando la paleta es parte de una actualización de marca no anunciada o un proyecto de cliente confidencial: no quiere que se filtre a un validador SaaS de terceros antes del lanzamiento.

Una vez que la página está cargada, la herramienta funciona sin conexión. Puede desconectarse de internet, construir la paleta, ejecutar verificaciones y exportar. Los tokens exportados se descargan directamente a través del cuadro de diálogo de guardar normal del navegador. Muchas herramientas de color en la nube (Coolors, Adobe Color, incluso algunos verificadores de accesibilidad) almacenan paletas en el servidor y pueden usarlas para análisis o entrenamiento; para trabajo confidencial, prefiera herramientas del lado del cliente.

Cuándo no usar esta herramienta

Para simulación completa de daltonismo (use una herramienta dedicada)

El contraste no es lo mismo que la compatibilidad con daltonismo. Una paleta puede pasar todas las verificaciones de contraste y aún así confundir a un usuario daltónico (rojo y verde a la misma luminancia se ven idénticos para un deuteranope). Para simulación de daltonismo, use el Simulador de Daltonismo de Absolutool o la vista de accesibilidad de Adobe Color, ambos aplican las transformaciones de color reales de deuteranopia, protanopia y tritanopia. Ejecute paletas candidatas a través de esta herramienta y un simulador.

Para generar esquemas de color desde cero (use Leonardo o Coolors)

Esta herramienta verifica y audita paletas; no las genera desde un solo color semilla. Para generación de paleta desde cero (esquemas análogos, complementarios, triádicos, complementarios divididos), use Adobe Color, Coolors o Leonardo (que genera variantes accesibles de un color de marca). Genere con esas herramientas, luego valide con esta. Leonardo específicamente genera colores apuntados a relaciones de contraste específicas, que es el formato de entrada natural para el paso de verificación de esta herramienta.

Para contraste basado en APCA (cuando WCAG 3 se lance)

Esta herramienta usa la fórmula de contraste WCAG 2.x, que es el estándar legal e industrial actual. Si específicamente necesita diseñar para APCA (el algoritmo propuesto WCAG 3), use la Calculadora de Contraste APCA de Myndex Research. APCA produce calificaciones diferentes (y posiblemente más precisas perceptualmente), especialmente para texto oscuro sobre oscuro y claro sobre claro. Hasta que WCAG 3 sea ratificado y adoptado en la ley (probablemente varios años en el futuro), WCAG 2.x es lo que los auditores de cumplimiento verificarán.

Para auditorías WCAG completas (use una herramienta completa)

El contraste es un criterio entre docenas. Para una auditoría de accesibilidad completa, use axe DevTools, Lighthouse, WAVE o una solución de pago como Tenon o PowerMapper. Estos verifican contraste, texto alt, ARIA, etiquetas de formulario, orden de foco, estructura de encabezados y muchos más en una sola pasada. Use esta herramienta durante el diseño de paleta, y las herramientas completas durante las pruebas de integración.

Más preguntas

¿Cuál es la diferencia entre contraste AA y AAA?

AA es el estándar, legalmente requerido por la mayoría de las leyes de accesibilidad (ADA, EAA, AODA, etc.) y lo que cada sitio orientado al público debe cumplir. AAA es más estricto: 7:1 para texto del cuerpo, 4.5:1 para texto grande. AAA generalmente se requiere solo para contenido de alta importancia (sitios web gubernamentales en algunas jurisdicciones, información médica y legal, contenido para usuarios con baja visión como audiencia principal). Diseñar para AAA es restrictivo; pocas marcas pueden cumplirlo sin limitaciones significativas de color. Apunte a AA por defecto y AAA donde la audiencia del contenido lo justifique.

¿Por qué WCAG usa 4.5:1 específicamente?

El umbral 4.5:1 fue elegido para que el texto siga siendo legible para usuarios con visión 20/40 (el umbral para la ceguera legal en muchas jurisdicciones) sin amplificación asistiva. También es aproximadamente la relación de contraste a la que los usuarios con deficiencia de visión del color pueden distinguir de manera confiable el primer plano del fondo. El número está calibrado empíricamente a partir de investigación visual; no es arbitrario. El 7:1 de AAA corresponde aproximadamente a la visión 20/80, acomodando significativamente más discapacidad.

¿Cómo funciona la fórmula de contraste?

Convierta cada color de sRGB a luminancia relativa usando la fórmula: corrija gamma cada canal (R, G, B) aplicando una función por tramos (lineal para valores bajos, exponencial para altos), luego pondere por 0.2126 R + 0.7152 G + 0.0722 B (la sensibilidad relativa del ojo humano a cada canal). La relación de contraste entre dos colores es (L1 + 0.05) / (L2 + 0.05) donde L1 es la luminancia más clara y L2 la más oscura. El desplazamiento 0.05 tiene en cuenta el reflejo ambiental de la pantalla. El resultado es un número entre 1 (idéntico) y 21 (máximo).

¿Debería preocuparme por el contraste del texto de marcador de posición en los campos de formulario?

Sí. El texto de marcador de posición cuenta como texto bajo WCAG y debe cumplir con el contraste 4.5:1. El predeterminado del navegador para marcador de posición es gris claro (#a9a9a9 en la mayoría de los navegadores), que falla en blanco. Sobrescriba con CSS: ::placeholder { color: #595959; } o similar que pase AA. Mejor aún, evite completamente los marcadores de posición para campos importantes; use etiquetas visibles encima del campo y reserve marcadores de posición para formato de ejemplo. Los patrones de etiqueta flotante combinan la etiqueta visible y la claridad del ejemplo.

¿El contraste se aplica a botones y campos de formulario deshabilitados?

No. WCAG SC 1.4.3 exime explícitamente los controles deshabilitados porque la apariencia atenuada es en sí misma una señal visual de que el control no está disponible. Los botones deshabilitados generalmente se atenúan a aproximadamente 38% de opacidad y fallarían el contraste en su estado deshabilitado por diseño. Sin embargo, el estado deshabilitado aún debe ser claramente distinguible del estado habilitado, así que no solo elimine todo el tratamiento visual; use una diferencia visual clara más un atributo deshabilitado accesible para lector de pantalla.

¿Qué pasa con el contraste para contenido gráfico como gráficos e iconos?

WCAG 1.4.11 Contraste No Textual (agregado en 2.1) requiere contraste 3:1 para componentes UI (botones, bordes de formulario, indicadores de foco) y elementos gráficos significativos (iconos que transmiten estado, elementos de gráfico que distinguen series de datos). El umbral 3:1 es más bajo que el 4.5:1 para texto porque los gráficos generalmente tienen áreas visibles más grandes. Los gráficos decorativos que no transmiten significado están exentos. Aplique 3:1 a cada icono que transmita estado (ojo abierto para visible, X para eliminar, marca de verificación para seleccionado) y cada segmento de gráfico que necesite ser distinguible.