Cómo auditar el contraste de color sin instalar nada

Las auditorías de contraste de color a menudo se tratan como una tarea especializada de accesibilidad: abrir un archivo de diseño, instalar un plugin, exportar capturas de pantalla, ejecutar un informe y discutir sobre los colores de marca. Eso puede ser útil, pero no es por donde la mayoría de los equipos debería empezar.

Para un sitio web en producción, la auditoría fiable más rápida suele hacerse en el navegador que ya tienes abierto. Las DevTools de los navegadores modernos pueden inspeccionar colores computados, mostrar ratios de contraste, revelar estilos de estado y ayudarte a probar los casos incómodos que los informes automatizados pasan por alto.

Esta guía asume que no vas a instalar nada. Sin extensiones de navegador. Sin plugins de diseño. Sin suites de auditoría de pago. Solo la página, el navegador y un método simple.

Las reglas de contraste que realmente necesitas

Para la mayor parte del trabajo web, el contraste según WCAG se reduce a unos pocos umbrales:

• Texto normal: al menos 4.5:1 de contraste contra su fondo.
• Texto grande: al menos 3:1. WCAG lo define como aproximadamente 24 píxeles CSS, o unos 18.66 píxeles CSS si está en negrita.
• Componentes de UI y objetos gráficos: al menos 3:1 para límites significativos, iconos, estados y partes de gráficos necesarias para entender la interfaz.
• Contraste mejorado: 7:1 para texto normal y 4.5:1 para texto grande si apuntas más allá de la línea base.

Hay excepciones, como controles inactivos, elementos decorativos y logotipos. Usa esas excepciones con moderación. “Es parte de la marca” no es una excepción; es una restricción de diseño.

Recuerda también que el contraste es solo una parte del uso accesible del color. Si un estado de error rojo tiene suficiente contraste pero no tiene texto, etiqueta de icono ni indicación programática, aun así puede fallar para usuarios que no pueden distinguir el rojo de colores cercanos.

Empieza por la página renderizada, no por el archivo de diseño

Los archivos de diseño son útiles, pero no incluyen todas las variables del mundo real: sobrescrituras de CSS, opacidad, estados hover, renderizado de fuentes del navegador, zoom del usuario, modo oscuro, estilos heredados, contenido del CMS e incrustaciones de marketing.

Audita la página tal como la reciben los usuarios.

Abre la página en un navegador de escritorio actual. Chrome, Edge, Firefox y Safari tienen herramientas de inspección útiles. Las etiquetas exactas varían, pero el flujo de trabajo es el mismo:

1. Haz clic derecho en el texto o elemento de UI.
2. Elige Inspect.
3. Busca los valores computados de color y background-color.
4. Usa la muestra de color del navegador o el panel de accesibilidad para leer el ratio de contraste.
5. Registra aprobado, fallido e incertidumbre.

En navegadores basados en Chromium, el selector de color a menudo muestra un ratio de contraste y orientación de aprobado/fallido de WCAG para texto. Firefox DevTools también expone información de accesibilidad y herramientas de color. Web Inspector de Safari puede mostrar estilos computados e información de accesibilidad, aunque el flujo de trabajo es ligeramente distinto.

La clave no es el navegador específico. La clave es leer el resultado computado, no el valor que alguien cree que usa el componente.

Crea primero una pequeña lista de auditoría

No inspecciones texto al azar hasta cansarte. Haz un inventario breve de patrones:

• Texto de cuerpo sobre el fondo principal de la página.
• Texto atenuado, leyendas, metadatos y placeholders.
• Enlaces en estados normal, hover, visitado y foco.
• Botones primarios, secundarios y destructivos.
• Etiquetas de formularios, texto de ayuda, errores y mensajes de éxito.
• Elementos de navegación, migas de pan y pestañas.
• Tarjetas, insignias, pills y etiquetas.
• Iconos que comunican significado.
• Gráficos, mapas, barras de progreso y colores de estado.
• Texto sobre imágenes, video, degradados o superposiciones translúcidas.

Esto basta para encontrar la mayoría de los fallos en un sitio típico. También mantiene la auditoría vinculada a componentes, no a píxeles aislados.

Si tu auditoría incluye botones, combina la comprobación de contraste con los aspectos básicos de nuestra lista de comprobación de botones web accesibles. Los problemas de contraste en botones a menudo aparecen junto a estados de foco ausentes, etiquetas poco claras o comportamiento de teclado roto.

Inspecciona el contraste del texto en DevTools

Para texto simple sobre un fondo sólido, el navegador normalmente puede calcular el contraste por ti.

Inspecciona el elemento y busca la propiedad color. Abre el selector de color desde la muestra. Si el navegador puede determinar el fondo, mostrará un ratio de contraste. Algunas herramientas también dibujan una línea en el selector de color indicando dónde el color pasaría 3:1, 4.5:1 o 7:1.

Cuando el navegador informe de un fallo, créelo hasta que puedas demostrar lo contrario. Cuando informe de un aprobado, aun así usa el criterio. Tipos pequeños y finos, pantallas de baja calidad, anti-aliasing intenso y fondos recargados pueden hacer que un texto técnicamente aprobado se perciba débil.

Una regla práctica: si el texto de cuerpo apenas aprueba con 4.55:1, no lo celebres. Dale más margen. Los requisitos de contraste son mínimos, no objetivos ideales.

La tipografía también importa. Un sistema tipográfico más grande y claro reduce la fatiga incluso antes de tocar los colores. Si la página se siente difícil de leer pese a aprobar el contraste, revisa la longitud de línea, el tamaño, el peso y el espaciado con una mirada más amplia sobre legibilidad, como en esta guía práctica para una tipografía legible.

Comprueba el fondo real, incluida la opacidad

Muchos errores de contraste ocurren porque el fondo visible no es el fondo declarado.

Trampas comunes incluyen:

• Texto dentro de una tarjeta semitransparente.
• Texto en un padre con opacity aplicada.
• Superposiciones que usan rgba() o color-mix().
• Degradados detrás de encabezados.
• Imágenes de fondo que varían a lo largo del área de texto.
• Variables de tema que cambian en modo oscuro.

Si DevTools no puede calcular el contraste con confianza, identifica manualmente los colores renderizados de primer plano y fondo. Usa el panel de estilos computados, desactiva capas temporalmente o toma una muestra del color visible con el selector de color integrado si tu navegador lo permite.

Para texto sobre imágenes, no tomes la muestra de la parte más favorable de la imagen. Toma la muestra del peor área plausible detrás del texto. Si la imagen cambia mediante subidas del CMS, carruseles o recortes responsivos, esto no es un sistema de contraste estable. Añade una superposición fiable, sombra de texto, contenedor sólido o tratamiento de degradado que proteja el texto independientemente de la imagen.

Un buen sistema de superposición de imágenes es aburrido: misma intensidad de superposición, área de recorte predecible, contraste suficiente incluso con fotos brillantes. Aburrido está bien. Los usuarios están intentando leer.

No olvides los estados

Las capturas estáticas pasan por alto muchos fallos de contraste. Audita los estados de interacción directamente en el navegador.

En DevTools, fuerza pseudoclases como:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Luego inspecciona de nuevo los colores computados.

Los indicadores de foco merecen atención especial. WCAG 2.2 reforzó las expectativas sobre la apariencia del foco, y un contorno azul pálido sobre una tarjeta gris clara sigue siendo un fallo común. El indicador de foco necesita suficiente contraste contra los colores adyacentes y suficiente área para ser perceptible.

Para controles deshabilitados, las reglas de contraste de WCAG tienen una excepción para componentes inactivos. Eso no significa que los controles deshabilitados deban ser ilegibles por defecto. Si el estado deshabilitado transmite información útil, hazlo legible. Si no lo hace, considera si debería estar presente.

Usa Lighthouse, pero no le delegues el criterio

Las auditorías del navegador como Lighthouse pueden detectar rápidamente algunos fallos de contraste. Ejecuta la auditoría integrada si tu navegador la ofrece y trata los resultados como un punto de partida.

Las comprobaciones automatizadas son buenas para encontrar nodos de texto con fallos evidentes de contraste computado. Son más débiles en:

• Texto incrustado en imágenes.
• Etiquetas renderizadas en canvas.
• Casos límite de SVG.
• Fallos que solo aparecen en hover.
• Calidad del indicador de foco.
• Gráficos donde las relaciones de color transmiten significado.
• Componentes ocultos tras autenticación, menús o pasos de formulario.

Si un informe vuelve en verde, todavía necesitas inspeccionar componentes representativos. Si vuelve en rojo, evita el pánico y prioriza los fallos por impacto en el usuario. El mismo principio aplica al rendimiento y a los informes de accesibilidad en general: lee la salida de la herramienta como evidencia, no como veredicto. Usamos esa mentalidad en nuestra guía para leer un informe de Lighthouse sin entrar en pánico, y aplica limpiamente aquí.

Audita también el contraste no textual

El texto recibe la mayor parte de la atención, pero WCAG también cubre el contenido no textual necesario para entender u operar la interfaz.

Comprueba al menos estos casos:

• Bordes de inputs contra el fondo de la página.
• Contornos de checkboxes y radios.
• Estados de toggles.
• Botones solo con icono.
• Iconos de error y símbolos de advertencia.
• Líneas, barras y etiquetas de gráficos.
• Indicadores de progreso.
• Indicadores de pestaña seleccionada o navegación activa.

El objetivo suele ser 3:1 contra colores adyacentes. Por ejemplo, un borde gris claro de input sobre fondo blanco puede ser casi invisible. Un gráfico con cinco líneas pastel puede verse elegante y aun así ser inutilizable.

Para gráficos, el contraste no basta por sí solo. Usa etiquetas, patrones, estilos de línea, anotación directa o espaciado para que la información no dependa únicamente del color. Esto ayuda a usuarios daltónicos, usuarios con baja visión, personas que ven la pantalla con reflejos y cualquiera que lea una captura de pantalla en un documento.

Registra hallazgos en un formato útil para desarrolladores

Una auditoría de contraste útil no dice “algunos grises fallan”. Identifica el componente, el estado, los valores actuales, el umbral esperado y la corrección sugerida.

Un formato compacto funciona bien:

| Componente | Estado | Primer plano | Fondo | Ratio | Objetivo | Resultado | Corrección sugerida | |---|---:|---:|---:|---:|---:|---|---| | Metadatos de tarjeta | Predeterminado | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Falla | Usar --color-text-muted-strong | | Botón primario | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Aprueba | Mantener | | Borde de input | Predeterminado | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Falla | Oscurecer el token de borde |

Vincula las correcciones a design tokens si el sitio los tiene. No parches veinte componentes individuales si el problema real es un token débil.

Haz correcciones ligeramente más fuertes que el mínimo

Los fallos de contraste suelen ser fáciles de corregir mal. Los equipos ajustan un color hasta que el comprobador dice 4.51:1 y siguen adelante. Eso no deja margen para renderizado de fuentes, transparencia, diferencias entre navegadores, temas, variación de imágenes o futuros cambios de marca.

Prefiere objetivos cómodos:

• Texto de cuerpo: más cerca de 7:1 cuando sea práctico.
• Texto atenuado: aún por encima de 4.5:1 si es contenido real.
• Bordes e iconos de UI: cómodamente por encima de 3:1.
• Texto sobre imágenes: usa una superposición controlada en lugar de adivinar imagen por imagen.

La web se ve en portátiles baratos, teléfonos con poco brillo, aceras soleadas, monitores tintados y pantallas envejecidas. El cumplimiento mínimo no es lo mismo que una lectura cómoda.

<!-- tool-cta:start -->

💡 Prueba esto: Al comprobar pares de contraste que extrajiste de DevTools, Color Converter ayuda a convertir entre hex, RGB y HSL para que los valores coincidan con tus notas de auditoría.

<!-- tool-cta:end -->

Una lista de comprobación de contraste sin instalación

Usa esta secuencia cuando necesites una auditoría rápida pero creíble:

1. Abre la página de producción en un navegador moderno.
2. Lista los principales patrones de texto, UI y estados.
3. Inspecciona los colores computados de primer plano y fondo en DevTools.
4. Usa el selector de color integrado o el panel de accesibilidad para leer el contraste.
5. Fuerza estados hover, focus, active, visited e invalid.
6. Comprueba texto sobre imágenes y degradados contra el peor fondo plausible.
7. Comprueba partes de UI no textuales contra el requisito de 3:1.
8. Ejecuta una auditoría automatizada integrada como red de seguridad, no como auditoría completa.
9. Registra fallos por componente y token.
10. Corrige con margen, no apenas cruzando el umbral.

Eso basta para detectar la mayoría de los problemas de contraste sin añadir otra herramienta a tu stack. Las auditorías más avanzadas siguen teniendo su lugar, especialmente en grandes sistemas de diseño, productos regulados o visualizaciones de datos complejas. Pero para muchos sitios web, el navegador ya te da la evidencia que necesitas. Lo difícil es ser lo bastante sistemático para usarla.