Cómo verificar el contraste de color para WCAG (sin abrir DevTools)

El fallo de accesibilidad más común en la web no es el texto alternativo faltante ni la navegación por teclado rota. Es el texto que se confunde con su fondo. Los diseñadores que trabajan con zoom completo en monitores calibrados no lo ven. Los desarrolladores que copian un valor de color de un archivo de diseño no lo ven. El equipo de QA lo deja pasar porque se ve bien.

Después, alguien que usa una pantalla más económica, o con sensibilidad reducida al contraste, abre la página y no puede leer el texto.

Lo bueno: el contraste es una de las pocas comprobaciones de accesibilidad sin juicio subjetivo de por medio. O el ratio pasa o no pasa. No hay nada que discutir en una revisión de diseño.

Los ratios de contraste WCAG, explicados

WCAG 2.1 (y 2.2) define los requisitos de contraste en el nivel AA, que es el estándar al que hace referencia la mayoría de los requisitos de cumplimiento:

• Texto normal (menos de 18pt / 24px en regular, o 14pt / 19px en negrita): mínimo 4,5:1 de ratio de contraste
• Texto grande (18pt / 24px o más en regular, 14pt / 19px o más en negrita): mínimo 3:1 de ratio de contraste
• Componentes de interfaz y elementos gráficos: mínimo 3:1 contra los colores adyacentes

El nivel AAA eleva el texto normal a 7:1 y el texto grande a 4,5:1. A menos que se esté construyendo para un contexto con un requisito AAA específico, AA es el objetivo.

El ratio de contraste se calcula a partir de la luminancia relativa de los dos colores — una medida perceptual que tiene en cuenta cómo procesa el ojo las diferentes longitudes de onda. Un ratio de 1:1 significa sin contraste (mismo color). Un ratio de 21:1 es negro sobre blanco — el máximo posible.

Un ratio de 3,8:1 falla el umbral de 4,5:1 para texto normal por bien que se vea en tu monitor. A las matemáticas no les importa tu pantalla.

Por qué el texto gris “sutil” casi siempre falla

El texto gris claro sobre fondo blanco o casi blanco está en todas partes en las interfaces modernas. Se ve refinado, se lee como jerarquía visual, y falla WCAG más que cualquier otra combinación de colores que me cruzo.

El sospechoso habitual:

/* Patrón de texto "secundario" común */
.secondary-text {
  color: #9ca3af;       /* Tailwind gray-400 */
  background: #ffffff;  /* blanco */
}
/* Ratio de contraste: ~2,5:1 — falla el requisito de 4,5:1 */

El gray-500 de Tailwind (#6b7280) sobre blanco queda en alrededor de 4,8:1, así que pasa el 4,5:1 por muy poco. Ese margen es tan estrecho que cualquier tinte, opacidad o fondo no del todo blanco puede empujarlo por debajo. Si quieres holgura cómoda, el gray-600 (#4b5563) ronda los 7,6:1 y deja de ser una duda.

El mismo fallo aparece con:

• Texto placeholder en campos de formulario (extremadamente común)
• Etiquetas de botones deshabilitados
• Texto de leyendas y texto de ayuda debajo de los campos de formulario
• Enlaces del pie de página y texto legal
• Botones solo con icono con colores de icono claros

Cómo verificar el contraste en la práctica

Opción 1: DevTools del navegador

Chrome y Firefox muestran un ratio de contraste en el selector de color al inspeccionar el color o background-color de un elemento. Muestra el ratio y un indicador de aprobado/fallido. Útil, pero lento — hay que inspeccionar cada elemento individualmente, cambiar de contexto y volver a verificar cuando los colores cambian.

Opción 2: Herramientas específicas

• WebAIM Contrast Checker — pega dos valores hexadecimales y obtén aprobado/fallido inmediato para AA y AAA en ambos tamaños de texto. Rápido para comprobaciones puntuales.
• Plugins de Figma como Contrast o Stark — útiles durante el diseño, no durante el despliegue.
• Extensión axe DevTools para el navegador — escaneo automatizado que detecta fallos de contraste en toda la página.

Opción 3: automatiza el resto de la revisión WCAG

El contraste se resuelve mejor con las herramientas dedicadas de arriba — el selector de color de tu navegador para comprobaciones puntuales, el WebAIM Contrast Checker para pares exactos, o axe DevTools para un barrido de toda la página. PxGuard deliberadamente no calcula el contraste (un ratio confiable necesita el emparejamiento exacto texto-sobre-fondo en el que esas herramientas se especializan); en cambio, señala los otros fallos de WCAG que son igual de comunes y más difíciles de detectar a ojo — nombres accesibles faltantes, orden de teclado y foco, roles ARIA, estructura de encabezados y texto alternativo faltante — directamente en la página. Usa axe (o WebAIM) para el contraste y PxGuard para el resto.

Complementa esto con el flujo de trabajo de verificación WCAG en 5 minutos para cubrir los otros fallos de accesibilidad comunes junto al contraste.

Los casos más frecuentes a verificar primero

Al hacer una auditoría de contraste, empieza por aquí:

1. Texto del cuerpo sobre fondos casi blancos — verifica el color base del texto en el fondo más claro, no solo en blanco puro
2. Texto secundario o silenciado — cualquier clase llamada text-muted, text-secondary, caption o similar
3. Texto placeholder — los navegadores suelen renderizarlo con opacidad reducida sobre el valor de color CSS, haciéndolo aún más claro de lo esperado
4. Texto de enlaces sobre fondos de colores — especialmente común en secciones de llamada a la acción con fondos de colores
5. Texto dentro de badges y etiquetas — los contenedores pequeños con colores de fondo suelen tener texto claro que falla con tamaños pequeños
6. Texto en botones fantasma — los botones con borde sobre fondos claros suelen quedar cerca del umbral de fallo

/* Ejemplo: botón fantasma que falla */
.button-ghost {
  color: #94a3b8;        /* demasiado claro */
  border: 1px solid #94a3b8;
  background: transparent;
}

/* Corrección: oscurecer el color del texto/borde */
.button-ghost {
  color: #475569;        /* supera el 4,5:1 sobre blanco */
  border: 1px solid #475569;
  background: transparent;
}

¿Qué pasa con el modo oscuro?

El modo oscuro no resuelve el contraste automáticamente. Introduce sus propios fallos comunes:

• El texto saturado brillante (como el verde #00ff00 puro) sobre fondos oscuros suele tener demasiada diferencia de luminancia — no es un fallo WCAG, pero puede causar efectos de halo para usuarios con ciertas condiciones visuales
• Los grises claros sobre fondos gris oscuro replican el mismo patrón de bajo contraste del modo claro, pero invertido
• Las superposiciones semitransparentes sobre imágenes o degradados son impredecibles en ambos modos

La misma regla de 4,5:1 aplica en modo oscuro. Verifícalo por separado — no se puede asumir que invertir la paleta aprueba automáticamente.

Detéctalo antes de que alguien tenga que reportarlo

Los fallos de contraste llegan a producción por una razón aburrida: nada en el flujo normal los marca. Ni un linter, ni una advertencia en consola, ni un test que falle. Aparecen cuando un usuario se queja, o cuando por fin se corre una auditoría meses después.

Así que haz que la comprobación sea lo bastante barata como para que ocurra sola. Mira el contraste de cualquier componente nuevo con texto antes de lanzarlo. Ese solo hábito elimina toda una categoría de bugs que cuesta explicar después y que, para algunos usuarios, es genuinamente difícil de sortear.

Si también quieres verificar la accesibilidad del teclado junto al contraste, los posts sobre etiquetas ARIA para botones con icono y problemas con tabindex positivo cubren las siguientes violaciones más comunes.

Instala PxGuard gratis →