Comprobar el contraste de color WCAG en línea: AA, AAA y texto grande

Un contraste insuficiente entre texto y fondo es el error de accesibilidad más frecuente en la web. Comprueba AA/AAA pegando dos colores, sin plugin ni extensión.

13.09.2026

13 min de lectura

Compartir este artículo:

accessibility

wcag

color-contrast

CSS

Tutorial

El contraste: el error de accesibilidad más frecuente en la web

Cada año, la auditoría WebAIM Million (un análisis de las páginas de inicio más visitadas de la web) sitúa el contraste de texto insuficiente como el fallo WCAG más detectado — por delante del texto alternativo ausente o los enlaces sin etiqueta. Es también uno de los pocos criterios de accesibilidad que se puede verificar en segundos, sin lector de pantalla ni auditoría completa. El comprobador de contraste de FastMinify calcula el ratio WCAG 2.2 entre dos colores CSS (HEX, RGB, HSL, OKLCH, color() o colores con nombre) y muestra al instante los veredictos AA/AAA para texto normal, texto grande y elementos no textuales — sin enviar nada a un servidor. Va más allá de un simple par de colores: un modo matriz permite cruzar toda una paleta de primer plano contra toda una paleta de fondo en un solo paso. El cluster completo vive en el hub de Color y CSS.

Veredictos WCAG 2.2 en vivo — AA, AAA y no-texto 3:1 (SC 1.4.11) para cada par de colores

Modo matriz hasta 16 colores por eje — auditar toda la paleta de un design system de una vez

Control de opacidad — comprobar texto semitransparente compuesto sobre su fondo real

Overlay APCA experimental (candidato a WCAG 3) junto al ratio WCAG 2.2 clásico

URL compartible — envía la comprobación exacta a un diseñador o pégala en un PR

100 % en el navegador — ningún color de marca sale nunca de tu pestaña

Los errores de contraste que se repiten una y otra vez

El texto gris claro "elegante" sobre fondo blanco

Un gris #999999 sobre blanco da un ratio de aproximadamente 2.85:1 — muy por debajo del umbral AA de 4.5:1. Aun así, es una de las elecciones de diseño más comunes para texto secundario, placeholders y leyendas.

Texto de placeholder en formularios en un gris demasiado claro (a menudo por debajo de 3:1)

Leyendas y metadatos ("hace 2h", "250 vistas") en gris pálido sobre fondo claro

Copiar un gris "neutro" de un mockup de Figma sin comprobar el ratio real

Confundir "se lee bien en mi pantalla" con un ratio conforme (brillo, calibración y fatiga visual varían)

Los usuarios con baja visión, las personas en entornos muy luminosos (exterior, pantallas mal calibradas) y las personas daltónicas pierden parte del contenido — y una auditoría Lighthouse/axe falla en CI si el contraste se comprueba automáticamente.

Un botón con el color de marca que falla en silencio

Los colores de marca "suaves" (azul pastel, verde menta, naranja claro) suelen elegirse por identidad visual sin probarlos nunca con texto blanco encima.

Botón primario azul claro + texto blanco: el ratio a veces baja de 3:1

Un estado "disabled" que visualmente parece un estado activo mal contrastado

Iconos monocromos sobre fondo de color sin comprobar el contraste no-texto (3:1)

Probar solo el estado por defecto del botón, nunca hover/focus/disabled

Un call-to-action ilegible o poco visible reduce la tasa de clics — más allá de la accesibilidad, es también un problema de conversión.

Texto sobre una imagen sin capa de oscurecimiento

Un titular blanco funciona sobre la zona oscura del cielo de una foto de cabecera, pero se vuelve ilegible sobre la zona clara de una nube — el contraste varía según el punto de la imagen.

Ningún degradado u overlay oscuro (scrim) bajo el texto

Texto probado solo en la versión de escritorio de la imagen, no en el recorte móvil

Una sombra ligera usada como única garantía de legibilidad

Una imagen de fondo cambiante (carrusel, subida de usuario) sin contraste garantizado

Añade un degradado semiopaco (negro al 40–60 %) entre la imagen y el texto, y luego comprueba el contraste contra el color del degradado compuesto — no contra la imagen en bruto.

El foco visible eliminado para "dejarlo limpio"

outline: none sin sustituto rompe la navegación por teclado — y el contraste no-texto (SC 1.4.11) también se aplica a los indicadores de foco, no solo al texto.

`outline: none` sin anillo de foco alternativo

Un anillo de foco personalizado demasiado pálido frente al fondo (a menudo por debajo de 3:1)

Foco visible probado solo en modo claro, olvidado en modo oscuro

Ninguna comprobación de contraste en los bordes de los campos de formulario

Los usuarios de teclado y de dispositivos de acceso por conmutador pierden por completo la referencia visual de su posición en la página.

AA, AAA y texto grande: ¿qué ratio hay que buscar?

Texto normal: ¿AA (4.5:1) o AAA (7:1)?

El criterio WCAG 1.4.3 (Contrast Minimum) exige un ratio de al menos 4.5:1 para el texto normal en nivel AA. El nivel AAA, más estricto (criterio 1.4.6), eleva la exigencia a 7:1. AA es el nivel que exige prácticamente toda normativa legal de accesibilidad (ADA en EE. UU., EN 301 549 en Europa, RGAA en Francia); AAA sigue siendo recomendado pero rara vez obligatorio para todo un sitio.

AA (4.5:1): el mínimo legal en la mayoría de las normativas de accesibilidad

AAA (7:1): recomendado para contenido crítico (formularios de pago, contenido médico/legal)

Un ratio de 21:1 (negro puro sobre blanco puro) es el máximo teórico — no tiene sentido ir más allá

Un ratio que parece correcto a simple vista (p. ej. 4.2:1) puede fallar AA por poco — comprueba siempre la cifra exacta, no la impresión visual

Texto grande: el umbral baja a 3:1 (AA) / 4.5:1 (AAA)

WCAG define "texto grande" como texto de al menos 24px (18pt), o de al menos 18.67px (14pt) si está en negrita (grosor ≥ 700). Por debajo de esos umbrales, el texto se considera normal aunque visualmente parezca grande. FastMinify calcula automáticamente el umbral aplicable a partir del tamaño y el grosor indicados.

≥ 24px, cualquier grosor: texto grande → AA = 3:1, AAA = 4.5:1

≥ 18.67px Y grosor ≥ 700 (negrita): texto grande → mismos umbrales reducidos

17px en negrita NO cuenta como texto grande — una trampa habitual

Un H1 de 40px se beneficia del umbral reducido; una insignia de 12px en negrita nunca

Contraste no-texto (SC 1.4.11): 3:1 para la interfaz

Desde WCAG 2.1, el criterio 1.4.11 (Non-text Contrast) exige un ratio de al menos 3:1 para los componentes de interfaz (bordes de campos de formulario, casillas de verificación, iconos con significado, indicadores de foco) frente a su color adyacente — no solo para el texto.

Borde de campo de formulario sin foco: mínimo 3:1 contra el fondo de la página

Anillo de foco (outline/box-shadow): mínimo 3:1 contra el fondo Y contra el elemento

Los iconos puramente decorativos (sin información) están exentos de este criterio

El comprobador de FastMinify muestra este veredicto por separado — un par puede aprobar en no-texto y fallar en texto normal

Cómo se calcula realmente el ratio de contraste

La fórmula WCAG: luminancia relativa, no solo una diferencia de tono

El ratio WCAG 2.x compara la luminancia relativa de los dos colores (un valor de 0 a 1 derivado de los canales RGB linealizados, ponderados con 0.2126 para el rojo, 0.7152 para el verde y 0.0722 para el azul — el ojo humano percibe el verde con mucha más intensidad que el azul). El ratio final es (L1 + 0.05) / (L2 + 0.05), donde L1 es la luminancia del color más claro. Por eso dos colores "claramente diferentes" pueden dar un ratio parecido, mientras que dos tonos que parecen similares pueden tener luminancias muy distintas.

Antes

color: #999999;
background: #ffffff;
/* Ratio ≈ 2.85:1 → falla AA (texto normal) */

Después

color: #595959;
background: #ffffff;
/* Ratio ≈ 7.0:1 → aprueba AAA (texto normal) */

El resultado va de 1:1 (colores idénticos) a 21:1 (negro puro / blanco puro)

El verde pesa más que el azul en la fórmula — un azul intenso sobre blanco suele fallar antes que un verde de brillo similar percibido

La fórmula ignora el tono percibido — para el ratio WCAG clásico solo cuenta la luminancia

FastMinify acepta HEX, RGB, HSL, OKLCH y color() como entrada y los convierte a sRGB antes de calcular (vía colorjs.io)

APCA, el candidato para WCAG 3 (vista previa experimental)

El ratio WCAG 2.x tiene una limitación conocida: trata "negro sobre blanco" y "blanco sobre negro" de forma simétrica, lo cual no siempre coincide con la percepción real. APCA (Advanced Perceptual Contrast Algorithm), candidato para WCAG 3, tiene en cuenta la polaridad (texto claro sobre fondo oscuro frente a lo contrario) y el tamaño de fuente para un juicio más preciso. FastMinify ofrece un overlay APCA opcional además del ratio WCAG 2.2 oficial — no como sustituto, ya que WCAG 3 todavía no es un estándar publicado.

APCA devuelve una puntuación "Lc" (Lightness Contrast) en lugar de un ratio clásico

La polaridad (normal o invertida) afecta a la puntuación — el mismo par de colores no tiene el mismo Lc según cuál sea el primer plano y cuál el fondo

A día de hoy, solo el ratio WCAG 2.2 (AA/AAA) cuenta para el cumplimiento legal

Útil para anticipar una futura migración a WCAG 3, no para una auditoría de cumplimiento actual

Flujo de trabajo de color-contrast-checker: de un par de colores a una paleta completa

Comprobar un par de colores en segundos

Abre el comprobador de contraste, pega tu color de primer plano y de fondo en cualquier formato CSS (HEX, RGB, HSL, OKLCH, con nombre). El ratio y las insignias AA/AAA/no-texto se recalculan en vivo. Ajusta el tamaño y el grosor del texto para ver cómo se aplica automáticamente el umbral de "texto grande".

Paso 1 — Pega ambos colores

Primer plano y fondo, en cualquier formato CSS válido. No se necesita conversión manual.

Paso 2 — Ajusta tamaño y grosor del texto

16px/400 por defecto (texto normal). Cambia a 24px o 18.67px+negrita para probar un titular — el umbral de "texto grande" (3:1/4.5:1) se aplica automáticamente.

Paso 3 — Lee el veredicto

Ratio exacto (p. ej. 4.87:1), insignia AA/AAA/AA-large/fallo para el texto, y un veredicto separado para el contraste no-texto (3:1, SC 1.4.11).

Escenario — auditar un botón y su estado disabled

Un botón primario suele tener tres variantes de color (normal, hover, disabled) que a menudo no se prueban individualmente.

Prueba el texto del botón sobre el fondo "normal" — apunta a AA (4.5:1) como mínimo

Prueba el mismo par en el estado "hover" — el color suele cambiar, y el ratio también

Prueba el estado "disabled" por separado — un ratio bajo es aceptable si el estado es realmente no interactivo y se anuncia como tal (aria-disabled)

Comprueba el borde del botón (si es visible) contra el fondo de la página — es contraste no-texto, umbral 3:1

Modo matriz: auditar toda una paleta de una vez

En lugar de probar una a una las combinaciones de un design system, pega tu lista de colores de texto en filas y tu lista de colores de fondo en columnas (hasta 16 colores por eje). El resultado muestra una cuadrícula con el veredicto de cada cruce, filtrable por nivel de conformidad (AAA / AA / AA-large / fallo).

Útil para validar todos los tokens de color de un design system en un solo paso

Filtro por nivel: aísla rápidamente solo las combinaciones que fallan

Detecta pares "límite" (p. ej. 4.4:1, justo por debajo del umbral AA) que una comprobación manual par a par pasaría por alto fácilmente

Funciona con los mismos formatos de color que el modo par (se pueden mezclar HEX/RGB/HSL en la misma lista)

Compartir una comprobación con tu equipo

Cada comprobación (colores, tamaño de texto, modo matriz o par, opciones APCA) se codifica en la URL. Copia el enlace desde la barra de direcciones y pégalo en un pull request, un ticket o un mensaje a tu diseñador — la página se reabre exactamente en el mismo estado.

Ningún dato se almacena en el servidor — todo el estado vive en los parámetros de la URL

Práctico para documentar un fallo de contraste detectado en una revisión

El enlace sigue siendo válido indefinidamente mientras la herramienta esté en línea

Convertir el contraste en un criterio de CI, no solo un vaivén de diseño

Automatizar la detección con axe-core o Lighthouse CI

Un comprobador manual es perfecto para diseñar una paleta; para evitar regresiones, el contraste también debe verificarse automáticamente en cada pull request. axe-core y Lighthouse CI detectan la mayoría de los fallos de contraste en texto estático (les cuesta más con texto sobre imágenes o degradados).

Ejemplo básico

// axe-core con Playwright — falla el test si el contraste es insuficiente
import { test, expect } from '@playwright/test'
import AxeBuilder from '@axe-core/playwright'

test('sin regresión de contraste', async ({ page }) => {
  await page.goto('/')
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2aa'])
    .analyze()

  const contrastIssues = results.violations.filter(
    (v) => v.id === 'color-contrast'
  )
  expect(contrastIssues).toEqual([])
})

FastMinify color-contrast-checker

Comprobación manual rápida, sin instalación ni datos enviados. El modo matriz, único entre estas opciones, permite auditar un design system completo en un solo paso, y la URL compartible facilita la colaboración entre diseño y desarrollo. Límite: es una comprobación manual que no sustituye una auditoría automatizada en CI, y no detecta el contraste sobre una imagen o un degradado complejo.

DevTools del navegador (Chrome/Firefox)

El selector de color integrado muestra el ratio de contraste directamente sobre el elemento seleccionado en la página real, con los estilos calculados — no requiere ninguna herramienta externa. Límite: un elemento a la vez, lo que resulta tedioso en una paleta completa, sin modo matriz ni enlace compartible.

axe-core / Lighthouse CI

Una auditoría automatizada integrada en el pipeline de CI detecta sistemáticamente las regresiones de contraste en cada pull request, y cubre la accesibilidad más allá del contraste. Límite: no sustituye la fase previa de diseño de la paleta, y puede producir falsos negativos con texto superpuesto a una imagen.

Conclusión

El contraste de color sigue siendo el error de accesibilidad más frecuente en la web — y uno de los más fáciles de corregir una vez detectado. AA (4.5:1) para texto normal, 3:1 para texto grande y elementos no textuales: tres cifras que conviene recordar antes de dar por buena una paleta. El comprobador de contraste de FastMinify ofrece el veredicto al instante, en modo par o en modo matriz para todo un design system, sin enviar nunca tus colores de marca a un servidor. Combínalo con una auditoría axe-core en CI para evitar regresiones, y con el resto del hub de Color y CSS para construir una paleta coherente de principio a fin.

Comprueba tu contraste ahora

Apunta a AA (4.5:1) en texto normal, 3:1 en texto grande y elementos no textuales (bordes, foco, iconos)

Prueba todos los estados de un componente interactivo — normal, hover, focus, disabled — no solo el estado por defecto

Usa el modo matriz para validar un design system completo en lugar de par por par

Añade axe-core o Lighthouse CI a tu pipeline para evitar regresiones de contraste tras publicar

El ratio WCAG 2.2 es lo que cuenta legalmente hoy — trata APCA como un adelanto del futuro, no como referencia de cumplimiento

Compartir este artículo