Contraste WCAG para paneles de SaaS: La auditoría de 5 minutos que detecta la mayoría de los errores

TL;DR

• El texto del cuerpo normal necesita un contraste de 4.5:1 (AA); el texto grande necesita 3:1.
• Los componentes de la interfaz de usuario (UI), iconos, anillos de enfoque y elementos de gráficos necesitan 3:1 (SC 1.4.11).
• Alrededor de tres cuartas partes de los paneles de SaaS no superan las pruebas de contraste en al menos un elemento crítico — generalmente métricas apagadas, verde de éxito sobre blanco, etiquetas de gráficos, anillos de enfoque o estados que solo se muestran al pasar el cursor.
• Errores comunes: texto secundario en slate-400 (3.1:1, falla) y green-500 sobre blanco (2.5:1, falla).
• Una auditoría de 5 minutos (captura de pantalla → verificador de contraste → modo de alto contraste del SO → linter automatizado) detecta los fallos obvios antes de que lo hagan los clientes.

Tu panel probablemente no cumple con WCAG. El mío tampoco.

Realizo una pequeña auditoría en cada panel de SaaS que veo. El patrón es consistente: las páginas de marketing suelen estar bien. Las páginas de configuración también. Sin embargo, el panel en sí (la parte principal del producto) no supera el contraste WCAG en al menos un elemento crítico alrededor de tres cuartas partes de las veces.

Los sospechosos habituales:

• Métricas secundarias apagadas — los números pequeños y de baja importancia.
• Etiquetas de los ejes de los gráficos — líneas finas y texto diminuto.
• Botones "fantasma" — bajo contraste por diseño.
• Texto verde de éxito sobre blanco — se ve bien, pero muestra resultados terribles.
• El estado deshabilitado del botón principal.

Estos son exactamente los elementos que los diseñadores iteran más y, por la presión de los sprints, son los primeros que se ajustan alejándolos de la paleta de marca segura.

Esta publicación cubre la auditoría de 5 minutos que realizo, las cuatro reglas de contraste que valen la pena memorizar y las herramientas (incluyendo un verificador de ratio de contraste gratuito) que detectan los fallos antes de que un cliente presente una queja por accesibilidad.

Las reglas de contraste, destiladas

Las Pautas de Accesibilidad para el Contenido Web (WCAG) del W3C definen dos niveles de contraste para el texto. Después de años depurando paneles reales, los he reducido a una sola tabla que tengo en una nota adhesiva junto a mi monitor:

Estos datos provienen de WCAG 2.1 Criterio de Éxito 1.4.3 (Contraste Mínimo) y 1.4.11 (Contraste No Textual). No son negociables para el cumplimiento legal en la mayoría de las jurisdicciones y se alinean sorprendentemente bien con lo que resulta legible.

Dos implicaciones prácticas que la mayoría de los equipos pasan por alto:

1. Los minigráficos y los trazos de los gráficos son componentes de la UI, no texto. Caen bajo la regla del 3:1, pero #cbd5e1 (slate-300) sobre blanco es 1.65:1. La mayoría de los gráficos de paneles que veo fallan en esto y nadie lo hace cumplir.

2. Los estados deshabilitados están exentos de los requisitos de contraste bajo el SC 1.4.3, pero solo si son genuinamente no interactivos. Si un botón "deshabilitado" sigue activando una descripción emergente (tooltip) o muestra un error al hacer clic, es interactivo, y las reglas se aplican.

Los 5 patrones que fallan en cada panel que audito

Después de auditar docenas de interfaces de SaaS, estos son los mismos cinco fallos que se repiten una y otra vez:

1. Métricas secundarias apagadas. "Actualizado por última vez hace 2 horas" en #94a3b8 (slate-400) sobre un fondo #f8fafc. Eso da 3.1:1, lo cual no supera el nivel AA para el texto del cuerpo. La solución es un tono más oscuro (slate-500 es 4.6:1). Los diseñadores eligen slate-400 por defecto porque "se ve elegante"; también es ilegal.

2. Texto de éxito/peligro sobre blanco. #22c55e (Tailwind green-500) sobre blanco es 2.5:1. Un fallo catastrófico. Usa green-700 (#15803d) con un mínimo de 4.7:1. Esto hace tropezar a casi todos los paneles que usan un marco de color predeterminado sin ajustes.

3. Etiquetas de los ejes de los gráficos. Las líneas y el texto pequeño en #94a3b8 fallan. Los gráficos necesitan al menos slate-500 (4.6:1) para las etiquetas y un contraste ≥ 3:1 para las líneas en sí.

4. Anillos de enfoque. La moderna reinicialización de "sin anillo de enfoque" rompe el criterio 2.4.7 (Enfoque Visible) por completo. Si has eliminado el anillo de enfoque predeterminado, necesitas uno personalizado con un contraste ≥ 3:1 contra el fondo. The A11y Project tiene una guía exhaustiva sobre la visibilidad del enfoque que vale la pena leer al menos una vez.

5. Contraste solo al pasar el cursor (hover). Un botón que no cumple con el contraste en reposo pero lo aprueba al pasar el cursor no satisface el criterio. El estado en reposo es lo que se audita.

La auditoría de 5 minutos

Este es el flujo de trabajo que ejecuto en cualquier panel antes de lanzar un rediseño. Cinco pasos, cinco minutos:

1. Abre la página en cuestión. Elige la pantalla más concurrida, no el estado vacío.

2. Toma una captura de pantalla. Arrástrala a un verificador de contraste. Para cada par de colores que te preocupe, extrae los valores de los píxeles y comprueba el ratio.

3. Genera una paleta "segura" candidata utilizando un generador de paletas de colores. Incluso si no usas el resultado, los ratios de contraste que muestra para cada par son una rápida verificación de cordura para tu paleta actual.

4. Prueba con la configuración de accesibilidad "Aumentar contraste" a nivel de sistema operativo activada (macOS: Configuración del Sistema → Accesibilidad → Pantalla). Alrededor del 8% de los usuarios tienen esto encendido. Si tus elementos "sutiles" desaparecen por completo, tienes un problema.

5. Pasa la página por un linter automatizado (Axe DevTools, Lighthouse, WAVE). Estos detectan quizás el 30-40% de los problemas, pero atrapan aquellos de los que te avergonzarías más.

Esta auditoría no sustituye a la contratación de un consultor de accesibilidad para un producto real. Es suficiente para detectar los fallos obvios que se lanzan cada viernes por la tarde.

Donde las herramientas automatizadas fallan

Tres modos de fallo que los verificadores automatizados no detectan:

• Contraste dependiente de los datos. Si tu estado "bajo" es gray-300 y el "alto" es red-600, el contraste entre ellos está bien. Sin embargo, el contraste de cada uno individualmente contra el fondo aún necesita ser ≥ 3:1, y un verificador no sabrá que el estado "bajo" puede ocurrir por sí solo.
• Contraste compuesto. Las superposiciones translúcidas apiladas (el aspecto moderno de glassmorfismo) cambian el contraste dependiendo de lo que haya detrás. Los verificadores estáticos solo ven el color de primer plano.
• Cambios de estado que alteran el contexto. Una píldora de estado que cambia de gris a ámbar no cambia su contraste contra el fondo; cambia de significado. Los usuarios daltónicos pueden pasar por alto el cambio por completo. La guía de Smashing Magazine sobre patrones de accesibilidad en paneles cubre bien este tipo de señalización multicanal.

La solución para los tres es la misma: empareja cada señal de color con una señal no cromática (icono, etiqueta, grosor). Cinturón y tirantes.

Una paleta pragmática

Si quieres un punto de partida que casi siempre supla el nivel AA cuando se usa correctamente:

• Texto del cuerpo: slate-700 (#334155) sobre slate-50 (#f8fafc) = 10.8:1
• Texto secundario: slate-500 (#64748b) = 5.3:1 (supera AA para cuerpo, falla AAA)
• Acento sobre blanco: cualquier tono en el rango de peso 600 de los principales marcos de trabajo
• Éxito: green-700 (#15803d) = 4.7:1
• Peligro: red-700 (#b91c1c) = 6.0:1

Pasa cualquier valor personalizado por un verificador de contraste de color antes de lanzarlo. Dos minutos ahorrados en una discusión con un diseñador valen dos horas que no tendrás que pasar reajustando la paleta después de que un cliente presente una queja de accesibilidad.

El cambio de mentalidad

La mayoría de los fallos de contraste no se deben a que los diseñadores ignoren la accesibilidad. Son diseñadores que buscan la "elegancia" y no se dan cuenta de que la opción elegante también es la ilegible. La solución es poner una verificación de contraste junto a cada decisión de color en el sistema de diseño, no al final como un paso de cumplimiento.

Si no haces nada más de esta publicación: abre tu panel actual, abre un verificador de contraste de color y revisa los tres colores de texto más apagados. Casi con seguridad encontrarás al menos un fallo. Dedica 10 minutos a solucionarlo antes de la próxima revisión de diseño. Es la única tarea de accesibilidad con mayor retorno de inversión (ROI) en el tablero.

En resumen: Memoriza los tres ratios (4.5:1 cuerpo, 3:1 texto grande, 3:1 UI/gráficos) y revisa el contraste junto a cada decisión de color, no como un paso de cumplimiento a última hora. Cinco minutos hoy evitan una queja de accesibilidad de un cliente mañana.

No olvides el anillo de enfoque

El contraste no trata solo de texto e iconos; también se trata del indicador de enfoque que muestra en qué control ha aterrizado un usuario de teclado. WCAG 2.4.7 (Enfoque Visible, nivel AA) requiere que ese indicador sea perceptible, y un contorno débil de un píxel que desaparece contra un botón de color fracasa ante las personas que navegan sin ratón. La versión más común de este error es eliminar el contorno predeterminado del navegador por "limpieza". No lo hagas: conserva un estilo de enfoque visible con un contraste real tanto contra el componente como contra la página, y verifica el estado de enfoque de cada elemento interactivo, no solo sus colores en reposo y al pasar el cursor.

Fuentes

1. W3C: WCAG 2.1 Success Criterion 1.4.3: Contrast (Minimum)
2. The A11y Project: Never remove CSS outlines
3. Smashing Magazine: Accessibility best practices for tabs and dashboards