Cómo comprobar el contraste de colores para la accesibilidad
Aproximadamente 1 de cada 12 hombres y 1 de cada 200 mujeres tienen alguna forma de deficiencia de vision de color. Millones mas tienen baja vision, ojos envejecidos, o estan viendo pantallas bajo el sol brillante. Si su texto no tiene suficiente contraste contra su fondo, estas personas no pueden leerlo. El contraste de color no es solo algo bueno, es un requisito basico de accesibilidad. Un verificador de contraste basado en navegador maneja todo el trabajo localmente sin subir ningun color o dato a un servidor.
Lo que WCAG requiere
Las Pautas de Accesibilidad para el Contenido Web (WCAG) definen ratios minimos de contraste entre texto y su fondo:
| Nivel | Texto normal | Texto grande | UI no-texto |
|---|---|---|---|
| AA (minimo) | 4.5:1 | 3:1 | 3:1 |
| AAA (mejorado) | 7:1 | 4.5:1 | 3:1 |
«Texto grande» significa 18px negrita o 24px regular o mas. El ratio de contraste va desde 1:1 (sin contraste, blanco sobre blanco) hasta 21:1 (contraste maximo, negro sobre blanco).
Como verificar el contraste
- Seleccione sus colores: ingrese los colores de primer plano (texto) y fondo usando codigos HEX, valores RGB o selectores de color.
- Verifique los resultados: la herramienta muestra instantaneamente el ratio de contraste y si su combinacion pasa WCAG AA y AAA para texto normal y grande.
- Ajuste si es necesario: si el contraste falla, oscurezca el texto o aclare el fondo (o viceversa) hasta que pase el nivel requerido.
Una breve historia de los estandares de contraste de color
Antes de WCAG, la accesibilidad web era un mosaico de reglas especificas de proveedor. El W3C publico WCAG 1.0 en 1999, con orientacion sobre contraste pero sin ratio especifico. WCAG 2.0 (2008) introdujo la formula 4.5:1 / 7:1 basada en la ciencia del color de la Dra. Lillian Yetenekian y el laboratorio de IBM Research, con aportes de investigadores de baja vision. La formula esta disenada para que una persona con vision 20/40 (baja vision leve) pueda leer texto conforme con AA, y una persona con vision 20/80 (baja vision significativa) pueda leer texto conforme con AAA.
WCAG 2.1 (2018) anadio requisitos de contraste para componentes UI (3:1 para no-texto), objetos graficos e indicadores de foco. WCAG 2.2 (2023) anadio mas requisitos en torno a tamanos de objetivo y visibilidad de foco.
El borrador de trabajo actual de WCAG 3.0 propone una nueva formula de contraste (APCA, Accessible Perceptual Contrast Algorithm) que coincide mejor con la percepcion humana, especialmente para texto mas oscuro. APCA aun no es una recomendacion del W3C pero ya esta soportada por algunas herramientas como vista previa.
La adopcion legal de WCAG ha sido constante:
- EE. UU.: Seccion 508 de la Ley de Rehabilitacion (federal) y la jurisprudencia ADA requieren WCAG 2.0 / 2.1 AA
- UE: Directiva de Accesibilidad Web (2016/2102) y Acta Europea de Accesibilidad (2025) requieren EN 301 549, que es WCAG 2.1 AA
- Reino Unido: Public Sector Bodies Accessibility Regulations requiere WCAG 2.1 AA
- Canada: ACA (Accessible Canada Act) para sector federal, AODA (Ontario) para empresas
- Australia: jurisprudencia DDA trata WCAG 2.1 AA como estandar
- Japon: JIS X 8341-3:2016 (basado en WCAG 2.0)
Para la mayoria de los sitios web de cara al publico, WCAG 2.1 AA es el minimo legal de facto.
Como se calcula el ratio de contraste
El ratio de contraste se calcula usando la luminancia relativa de cada color:
- Convertir cada color de sRGB a RGB lineal (correccion gamma)
- Calcular luminancia relativa: L = 0.2126 R + 0.7152 G + 0.0722 B
- Contraste = (L_mas_claro + 0.05) / (L_mas_oscuro + 0.05)
El resultado es un numero de 1 (sin contraste) a 21 (contraste maximo). Los desplazamientos de 0.05 evitan la division por cero y modelan ligeramente la contribucion de la luz ambiente al contraste percibido.
La formula fue disenada deliberadamente para ser determinista y computable, de modo que los mismos colores siempre produzcan el mismo ratio. No toma en cuenta:
- Daltonismo: un par rojo/verde puede tener un ratio de 7:1 pero ser invisible para una persona con daltonismo rojo/verde
- Peso de fuente mas alla de negrita: las fuentes ultra-delgadas o de hilo necesitan mas contraste
- Artefactos de anti-aliasing: trazos muy delgados pueden parecer mas claros de lo que sugiere el valor del color
- Patrones de fondo: gradientes, imagenes o ruido detras del texto degradan el contraste efectivo
Por eso las verificaciones WCAG son necesarias pero no suficientes. La revision visual con usuarios diversos (incluidos los daltonicos) captura el resto.
Errores comunes de contraste
Texto gris claro sobre blanco: #999999 sobre #ffffff tiene un ratio de solo 2.8:1. Esto falla WCAG AA. Puede verse «limpio» para un disenador con vision perfecta, pero es ilegible para muchas personas.
Texto coloreado sobre fondos coloreados: un boton azul con texto blanco a menudo pasa, pero un boton verde con texto blanco puede no pasar. Siempre verifique, no puede juzgar el ratio de contraste a simple vista.
Texto de marcador de posicion: los marcadores de posicion de campos de formulario son notoriamente de bajo contraste. Aunque WCAG no requiere estrictamente que los marcadores de posicion cumplan con los ratios de contraste, los usuarios aun necesitan leerlos.
Modo oscuro: los disenadores a menudo usan texto gris medio sobre fondos gris oscuro para un aspecto «sutil». Esto falla frecuentemente las verificaciones de contraste.
Texto sobre imagenes: el texto colocado sobre una imagen heroe a menudo pasa cuando la imagen es oscura y falla cuando la imagen es clara. Use una capa de gradiente oscura/clara o un telon de fondo solido detras del texto sobre imagenes.
Desplazamientos de color de marca: la identidad corporativa a menudo dicta un color principal de marca. Si ese color falla como texto del cuerpo, uselo para encabezados (texto grande, umbral 3:1) y use un tono mas oscuro para el cuerpo.
Colores de enlace: los enlaces deben ser distinguibles del texto circundante. WCAG requiere un ratio de 3:1 entre el enlace y el texto del cuerpo, mas otro indicio visual (subrayado, negrita o icono).
Indicadores de foco: el contorno alrededor de un boton o enlace enfocado debe cumplir 3:1 de contraste contra su fondo. Los anillos de foco por defecto del navegador suelen ser seguros; los estilos de foco personalizados a menudo fallan.
Errores comunes
- Probar solo encabezados: el contraste debe verificarse para cada combinacion de tamano y peso de texto en la pagina. El texto del cuerpo, leyendas, etiquetas, botones, iconos y campos de formulario todos necesitan verificacion.
- Olvidar estados hover y activo: un enlace que pasa el contraste por defecto puede fallar al pasar el cursor (color mas claro) o activo (fondo diferente). Verifique todos los estados.
- Estados deshabilitados ignorados: WCAG excluye explicitamente los estados deshabilitados de los requisitos de contraste, pero el diseno accesible aun apunta a alguna distincion visible.
- Capas traslucidas: el texto sobre una capa oscura transparente al 50% se comporta como su color efectivo, no el color de entrada. Componga el color efectivo antes de verificar.
- Texto delgado con anti-aliasing: 12px Inter Thin a 8.5:1 sigue siendo dificil de leer. Verifique con la fuente renderizada real, no solo el valor del color.
- Deriva de conversion HSL: ajustar colores en el espacio HSL puede producir valores que se ven similares pero fallan el contraste. Siempre vuelva a verificar despues de ajustes de color.
- Colores de marca bloqueados por partes interesadas: cuando un color de marca no puede cambiarse, uselo estrategicamente (solo texto grande) y elija un color diferente para el cuerpo. Documente la justificacion para las partes interesadas.
- Olvidar contraste de impresion: un sitio web puede pasar el contraste en pantalla pero fallar cuando se imprime en escala de grises. Pruebe la salida impresa para documentos destinados a impresion.
- Texto sobre video: los fondos de video cambian constantemente. O fije un fotograma estatico, anada una capa de gradiente o use un telon de fondo solido.
- La internacionalizacion cambia la densidad de caracteres: los caracteres chinos, japoneses y coreanos son mas densos que los latinos. Un ratio de 4.5:1 que se lee bien en ingles puede forzar a los lectores de idiomas CJK al mismo tamano. Suba a 7:1 para texto internacional.
Mas alla de WCAG: APCA y el contraste perceptivo moderno
El Algoritmo Accesible de Contraste Perceptivo (APCA) es una formula mas nueva propuesta por Andrew Somers para WCAG 3.0. A diferencia de la formula WCAG 2, APCA:
- Considera el peso y tamano de fuente en la puntuacion de contraste: las fuentes mas delgadas o pequenas necesitan mas contraste
- Usa escalado perceptivo no lineal: coincide con como la vision humana realmente responde a la luminancia
- Maneja mejor los fondos oscuros: WCAG 2 sobrevalora el contraste sobre fondos oscuros; APCA corrige esto
- Produce una puntuacion consciente de la polaridad: positiva para texto oscuro sobre fondo claro, negativa para lo contrario
Las puntuaciones APCA van aproximadamente de -108 a +108. Una puntuacion de 60 (positiva o negativa) es aproximadamente equivalente al 4.5:1 de WCAG 2. APCA aun no es legalmente requerido en ningun lugar, pero esta siendo adoptado por sistemas de diseno como Material Design e IBM Carbon como un estandar mirando hacia adelante.
Para la mayoria de los propositos practicos hoy, WCAG 2.1 AA (4.5:1 / 3:1) sigue siendo el estandar legal e industrial. Algunos equipos usan APCA en paralelo como verificacion de calidad.
Herramientas e integraciones
| Herramienta | Caso de uso |
|---|---|
| Browser DevTools (Chrome, Firefox) | Inspeccionar elemento muestra el ratio de contraste en tiempo real |
| axe DevTools | Auditoria WCAG automatizada incluyendo contraste |
| WAVE (WebAIM) | Extension de navegador visualizando errores de contraste |
| Stark (plugin de Figma) | Verificacion de contraste en tiempo de diseno |
| Color Contrast Analyser (TPGi) | App de escritorio con cuentagotas |
| Lighthouse (Chrome) | Auditoria de accesibilidad integrada incluyendo contraste |
| ARC Toolkit (Deque) | Extension de navegador de accesibilidad completa |
| Polypane | Navegador para disenadores con herramientas de contraste integradas |
| GitHub Action: a11y-actions | Verificaciones automatizadas a nivel PR |
| CI: pa11y, axe-core/cli | Bloquear PRs que introducen fallos de contraste |
Integre al menos una herramienta automatizada en CI para que los fallos de contraste no puedan enviarse sin ser detectados.
Consejos
- Verifique cada combinacion de texto/fondo: no asuma. Incluso los disenadores experimentados se sorprenden por que combinaciones fallan.
- Pruebe ambos temas: si su sitio tiene modos claro y oscuro, verifique el contraste en ambos. Un color que funciona sobre blanco puede fallar sobre gris oscuro.
- Use sus colores de marca con sabiduria: si su azul de marca falla como color de texto, uselo para elementos mas grandes (botones, encabezados) donde aplica el umbral de texto grande (3:1), y use un tono mas oscuro para el texto del cuerpo.
- No confie en el color solamente: ademas de un contraste suficiente, nunca transmita informacion solo por color. Use iconos, etiquetas de texto o patrones junto con el color para asegurar que todos puedan entender el contenido.
- Pruebe con simuladores: un simulador de daltonismo muestra como se ve su diseno para usuarios con protanopia, deuteranopia o tritanopia. Los pares comunes (rojo/verde) a menudo fallan.
- Pruebe a la luz del sol: lleve su telefono afuera en un dia brillante. El texto que apenas pasa WCAG puede volverse ilegible bajo la luz solar directa. El contraste AAA (7:1) es el minimo practico para la visibilidad al aire libre.
- Guarde paletas de colores accesibles: construya una paleta donde cada color de texto pase contra cada color de fondo. Restriccion al frente, sin sorpresas de contraste despues.
- Eduque a las partes interesadas: las partes interesadas que demandan un color de marca de bajo contraste a menudo cambian de opinion cuando se les muestra el diseno a traves de un simulador de baja vision.
Privacidad y datos de diseno
El verificador de contraste de color se ejecuta completamente en su navegador. Los colores y valores que ingresa, los calculos y los resultados de contraste se quedan todos en su dispositivo. Nada se sube a un servidor, se registra o se comparte con nadie.
Esto importa menos para colores individuales (no son secretos) y mas para la verificacion por lotes o el trabajo de sistema de diseno donde podria pegar una paleta de marca completa, colores internos de mockup de producto, o especificaciones de UI de producto no lanzadas. Las herramientas de contraste en la nube registran cada pegado en sus registros de solicitud, a veces los retienen para «mejora del servicio», y podrian filtrar colores de marca no lanzados o disenos UI. Un verificador basado en navegador tiene exposicion cero: los colores nunca salen de su maquina.
La verificacion de contraste basada en navegador tambien funciona sin conexion una vez cargada la pagina, util para revisiones de diseno en aviones, en entornos seguros sin acceso a internet, o en cualquier lugar donde no pueda o no deba compartir datos de diseno con un servicio de terceros.
Preguntas frecuentes
¿A qué relación de contraste apuntar?
Para texto normal, apunta al menos a 4,5 : 1 (WCAG AA). Para texto grande (18 px negrita o 24 px regular), 3 : 1 basta. Para el nivel de accesibilidad más alto (AAA), apunta a 7 : 1 para texto normal.
¿Esto solo se aplica al texto?
No. WCAG 2.1 también exige un contraste suficiente para los componentes de interfaz y los objetos gráficos (iconos, bordes de campos, indicadores de foco). El mínimo para los elementos no textuales es 3 : 1.
¿Y en modo oscuro?
El modo oscuro requiere las mismas comprobaciones de contraste. Texto blanco sobre fondo oscuro suele pasar fácilmente, pero texto gris sobre fondo gris oscuro suele fallar. Prueba ambos modos.
¿El contraste de color es un requisito legal?
En muchas jurisdicciones, sí. La ADA (EE. UU.), EN 301 549 (UE) y leyes similares imponen la accesibilidad digital. La conformidad WCAG es el estándar reconocido para cumplirlos.