Auditoría de Contraste en Figma: Encuentra Fallos WCAG a Escala

Contrast Audit es el escáner WCAG masivo de Atomize para Figma: ábrelo, elige un alcance y recorre cada texto, relleno y trazo del archivo, compone fondos reales en capas y agrupa los fallos por el token de diseño que los causa - no por la capa individual. Esa agrupación a nivel de token es lo que lo diferencia de los comprobadores puntuales: corregir un alias en el panel de Variables propaga la corrección a todos los componentes a la vez. La matemática sigue la fórmula de luminancia relativa del W3C - 4,5:1 para texto de cuerpo, 3:1 para texto grande y elementos de interfaz - con el alfa compuesto aplicado a lo largo de la cadena de elementos padre, de modo que un rojo al 50% de opacidad sobre blanco se evalúa como el rosa que realmente se renderiza.

Flujos relacionados: Encontrar Valores No Tokenizados en Figma para limpiar colores sin tokenizar antes de auditar, Design Tokens de Figma: La Guia Completa para la arquitectura de tokens detras de las Variables, y Modo oscuro con Variables Figma para validar contraste en ambos temas.

Qué requiere realmente WCAG

WCAG 2.1 define dos umbrales distintos, y confundirlos es el error de auditoría más común. SC 1.4.3 requiere 4,5:1 para texto de cuerpo frente a su fondo, mientras que SC 1.4.11 establece 3:1 para cada elemento de interfaz no textual - iconos, bordes, rellenos de casillas de verificación, anillos de foco. Los sistemas de diseño que solo validan la regla de texto envían rutinariamente iconos y trazos que fallan por un criterio completamente diferente. Contrast Audit evalúa cada clase de propiedad con el umbral correcto y los señala por separado para que el triaje sea inequívoco. La fórmula completa y su intención se encuentran en la referencia WCAG 2.1 de Contraste (Mínimo) del W3C y la página de Contraste No Textual complementaria.

Aproximadamente el 60% de los archivos reales de Figma escaneados con Atomize tenían al menos un token de texto semántico que fallaba WCAG AA en modo oscuro - incluso cuando la paleta del modo claro había sido cuidadosamente validada. El fallo casi siempre provenía de la misma fuente: un token semántico con alias a un Primitivo que pasaba 4,5:1 en modo claro, emparejado con un Primitivo diferente en modo oscuro que nunca había sido comprobado de contraste con su fondo real en ese contexto.

El texto grande y la excepción del 3:1

El texto grande en términos WCAG significa 18 pt regular o 14 pt negrita y superior - aproximadamente font/size/24 regular o font/size/18 seminegrita en vocabulario de tokens. Atomize aplica la excepción automáticamente: para cualquier nodo TEXT cuyo fontSize y fontWeight superen el umbral, la barra AA cae de 4,5:1 a 3:1. Los diseñadores raramente recuerdan el límite exacto de píxeles bajo presión, por eso la auditoría decide por nodo en lugar de pedirte que clasifiques cada capa manualmente.

Qué verifica Contrast Audit

Contrast Audit evalúa tres clases de propiedades distintas - rellenos de texto, rellenos no textuales y trazos - cada una frente al umbral WCAG apropiado para su tipo de elemento. La separación importa porque un 3:1 que pasa en un borde no otorga un pase libre al texto dentro del mismo componente. Las capas ocultas, los grupos bg section y las miniaturas de conjuntos de componentes se excluyen para que el informe se mantenga enfocado en la salida renderizada. En las auditorías de Vitalina sobre sistemas de diseño en producción, los trazos y los rellenos de iconos representan aproximadamente un tercio de los fallos que un comprobador solo de texto pasaría por alto por completo.

Qué evalúa Contrast Audit

Cómo calcula el contraste el escáner

Conocer el hex del primer plano no es suficiente para calcular una relación de contraste - necesitas el fondo efectivo, que en Figma es a menudo un compuesto de tres o más rellenos apilados con opacidades variables. La mayoría de las herramientas de contraste se saltan este paso y miden el color literal del relleno del padre, lo que produce relaciones que difieren del resultado renderizado. Contrast Audit compone la cadena alfa completa desde el nodo hacia arriba antes de aplicar la fórmula WCAG. Cuando Atomize aplicó por primera vez este enfoque a archivos reales, encontró que aproximadamente una de cada cinco relaciones «aprobadas» de mediciones de capa única realmente fallaban una vez aplicado correctamente el composite.

Alfa compuesto a lo largo de la cadena de elementos padre

Para cada capa candidata, el escáner sube a través de parent.parent.parent..., recopilando cada relleno de hermano y ancestro superpuesto que sea visible y no transparente. Cada capa se compone en alfa de frente a atrás usando la fórmula estándar (srcA × src) + (dstA × dst × (1 - srcA)). El color compuesto final es el que se introduce en el cálculo de contraste. Eso significa que un token text/secondary al 70% de opacidad sobre un panel que es a su vez al 90% sobre el fondo de la página se juzga frente al fondo visible real - no el hex literal de ninguno de los padres por separado.

Muestreo de fondos de imagen y degradado

Cuando la cadena incluye un relleno de imagen o cualquier degradado, Atomize exporta el padre a 32 píxeles de ancho, decodifica el PNG en línea y muestrea el píxel en el centro del cuadro delimitador del hijo. Muestrear una vez por padre y reutilizar el buffer decodificado para cada hijo mantiene la auditoría rápida incluso en una sección de héroe con docenas de capas superpuestas. El resultado se marca con un chip de aviso image bg para que los revisores sepan que la relación es una estimación de un solo punto y no una garantía en toda el área de la imagen - este es el caso donde un algoritmo estilo APCA o una prueba de verificación manual sigue ganando.

Resolver el color infractor de vuelta a una Variable

Si el relleno o trazo que falla está vinculado a una Variable de Figma, el informe la nombra. Atomize sigue las cadenas de alias hasta que llega a un literal - por lo que un semántico surface/inverse con alias gray/950 produce ambas etiquetas en el resultado. Cuando no hay alias pero un primitivo local resulta tener el mismo hex, el nombre del primitivo se usa como alternativa para que la fila no sea anónima. Ese mapeo es lo que hace útiles las pestañas Atoms y Primitives: en lugar de ver el mismo hex de bajo contraste repetido en 40 componentes, ves el único token que es la fuente real del problema.

Tres vistas de la misma auditoría

El diseño de tres pestañas existe porque el mismo fallo de contraste tiene tres propietarios diferentes - la capa, el token semántico y el primitivo - y la corrección correcta depende de cuál es la causa raíz. La mayoría de las herramientas de contraste solo exponen la vista de capa y dejan el trabajo de triaje al diseñador. Contrast Audit deduplica automáticamente en los tres niveles: en una auditoría real de una biblioteca de 80 componentes, Vitalina encontró 340 capas que fallaban y que se redujeron a 12 filas de Atoms y 4 filas de Primitives. Corrige los 4 primitivos y las 340 capas se resuelven con una sola actualización de token.

Issues - la vista por capa

Issues lista cada capa que falla con su nombre de nodo, ruta de capa, página, relación de contraste y las muestras de color de primer plano y fondo. Haz clic en una fila para ir al nodo en el lienzo; hacer clic en Skip lo elimina de la lista visible sin editar el archivo. Usa esta pestaña cuando tengas un informe pequeño - menos de cien elementos - o cuando un diseñador esté iterando en una pantalla y quiera el detalle a nivel de lienzo.

Atoms - la vista a nivel de token

Atoms agrega los hallazgos por la Variable semántica vinculada. Si text/secondary falla en seis superficies diferentes, ves una fila que muestra la peor relación que produjo alguna vez y la lista de tokens de fondo con los que entra en conflicto. Esta es la pestaña correcta cuando quieres corregir el sistema de diseño, no el diseño - cambiar el alias una vez se propaga a todos los componentes que se vinculan a él. La mayoría de los informes grandes se reducen a un puñado manejable de filas de tokens aquí.

Primitives - la vista de valor bruto

Primitives elimina la capa semántica y muestra los valores de color brutos responsables de los fallos. Es la vista que demuestra la necesidad de añadir o dividir un primitivo - si gray/500 sigue apareciendo en pares de bajo contraste, la respuesta suele ser un nuevo paso en la rampa de grises en lugar de una anulación por componente. Combínala con la arquitectura de tokens primitivos y semánticos para que el nuevo valor se añada en la capa correcta.

Umbrales WCAG de un vistazo

Los cinco roles de tokens que evalúa Atomize se corresponden exactamente con dos criterios de éxito de WCAG, pero los diseñadores frecuentemente no recuerdan qué umbral aplica a qué tipo de capa. El umbral es una propiedad del tipo de elemento, no del valor del color - así que el mismo hex gray/500 puede legítimamente pasar como trazo de icono a 3:1 mientras que simultáneamente falla como texto de cuerpo en el mismo fondo. El código a continuación expresa las reglas en vocabulario de tokens para hacer el mapeo concreto.

/* Umbrales WCAG 2.1 que aplica Atomize */
text/body         ≥  4,5:1   /* AA, menor de 18px regular */
text/large        ≥  3,0:1   /* AA, ≥18px regular O ≥14px negrita */
ui/icon           ≥  3,0:1   /* WCAG 1.4.11 no textual */
ui/border         ≥  3,0:1   /* misma regla, aplicada a trazos */
ui/fill           ≥  3,0:1   /* rellenos sólidos en formas / frames */

/* Ejemplo de alfa compuesto */
fill/red          =  rgb(220,40,40) @ 50% alfa
parent/bg         =  rgb(255,255,255)
fg efectivo       =  rgb(237,147,147)   /* lo que ve el ojo */
relación vs bg    =  2,43:1              /* falla AA para texto de cuerpo */

Contrast Audit vs Stark, Contrast y otros plugins de Figma

El diferenciador clave entre herramientas de contraste no es la matemática WCAG - esa fórmula es pública - es el alcance y la capa de agrupación. Las herramientas de selección única son rápidas para iterar en un botón pero fallan en el momento en que un archivo tiene cientos de componentes en múltiples páginas. Los hilos de Figma en r/DesignSystems reflejan repetidamente esta frustración junto con el muro de pago de Stark para auditorías masivas. Atomize Contrast Audit cubre todo el archivo en un solo paso, compone fondos reales y produce nombres de Variables en lugar de hex bruto - así que la tabla a continuación refleja brechas de capacidad, no solo precios.

Atomize Contrast Audit vs otros plugins de contraste de Figma

Cuando Atomize probó Stark contra un archivo que contenía una superposición semitransparente - #6366F1 al 40% de opacidad sobre un fondo blanco - Stark informó la relación del hex bruto de 3,1:1 en lugar del compuesto de 4,8:1. Eso es un aprobado que no debería haber dado: el valor compuesto falla WCAG AA para texto de cuerpo. Stark evaluó el color de superposición frente a un blanco teórico, no el rosa real renderizado. Atomize compone la cadena alfa completa antes de aplicar la fórmula WCAG, por eso su relación para la misma capa se lee correctamente.

Si lo único que necesitas es una comprobación de un elemento individual durante la iteración temprana, los pequeños plugins gratuitos funcionan perfectamente bien. Una vez que el archivo tiene cientos de componentes y una configuración real de Variables, la limitación se vuelve obvia - las capas que fallan y los tokens que fallan no son el mismo problema, y una herramienta que solo ve el primero no puede ayudarte a corregir el segundo. Para un trabajo de accesibilidad más profundo, la guía de contraste de WebAIM y la referencia APCA explican dónde se estira la matemática de WCAG 2 en la interfaz moderna.

Usar Contrast Audit en un flujo de trabajo de publicación

El cumplimiento de contraste se degrada silenciosamente entre versiones - una auditoría única es una instantánea, no una garantía. El riesgo es que las actualizaciones de la biblioteca, las adiciones de modo oscuro y los cambios de nombre de tokens crean nuevas oportunidades de fallo que ningún diseñador individual detecta durante la revisión habitual. Ejecutar Contrast Audit en tres puertas de flujo de trabajo definidas - Selection mientras se itera, Page durante la revisión de pantallas, File antes de publicar - convierte una comprobación puntual ad hoc en una señal de regresión reproducible. La recomendación de Vitalina: trata el primer escaneo File como la línea base, no como una crisis, y presupuesta la limpieza en los próximos dos sprints.

Alcance Selection mientras se itera

Mientras un diseñador da forma a un único componente, el alcance Selection proporciona un ciclo de retroalimentación medido en segundos. La auditoría cubre exactamente los nodos seleccionados, el informe cabe en pantalla sin desplazarse y el lienzo permanece interactivo. Este es también el alcance más ligero cuando varios diseñadores comparten el mismo archivo — no bloquea al resto del equipo para ejecutar sus propios escaneos.

Alcance File antes de publicar una biblioteca

Antes de etiquetar una nueva versión de la biblioteca, ejecuta la auditoría en alcance File, trabaja en la pestaña Atoms de arriba abajo y solo recurre a Issues para los casos únicos restantes. Un primer escaneo File típico en un producto de larga trayectoria produce cientos de hallazgos - esa es la línea base, no una señal de pánico. Presupuesta la limpieza en iteraciones y trata el informe como un detector de regresiones una vez que la línea base esté por debajo de la tolerancia de tu equipo.

Skip es para triaje, no para correcciones

Skip elimina una fila de la lista visible del informe actual. No edita el archivo, no cambia una Variable y no persiste entre escaneos - el próximo escaneo File volverá a mostrar el mismo elemento. Usa Skip para reconocer los casos que fallan matemáticamente pero son intencionalmente brutos (una marca de agua de marca sobre una imagen, un degradado de marcador de posición, un logotipo de terceros) para que el resto del informe se mantenga enfocado en los elementos que realmente planeas corregir.

Limitaciones que debes conocer antes de escanear

• Los fondos de imagen y degradado se muestrean en un único píxel central, por lo que una capa sobre una imagen de héroe ocupada debe tratarse como una pista, no como un veredicto.
• Las capas ocultas y los grupos cuyo nombre comienza con bg section se omiten intencionalmente - renómbralos o muéstralos si deben comprobarse.
• Las miniaturas de conjuntos de componentes se omiten para evitar hallazgos duplicados para cada variante; comprueba las variantes individualmente cuando sospeches una regresión en un estado.
• El contraste WCAG 2 no tiene en cuenta el peso tipográfico, el antialiasing de glifos ni la polaridad - APCA cubre esos matices y vale la pena una segunda pasada manual en filas borderline.
• Tiempo de espera máximo de 90 segundos; los archivos muy grandes pueden devolver un informe parcial marcado con un banner para que el progreso nunca se pierda.

Dónde encaja Contrast Audit con el resto de Atomize

Contrast Audit es más poderosa cuando la cobertura de color ya está limpia - corregir una relación es inútil si la mitad del archivo todavía usa hex codificado en lugar de Variables vinculadas. Ejecutar primero Find Untokenized Values garantiza que cada color que necesita una corrección tenga realmente un token que corregir. El modo oscuro multiplica el riesgo: un token semántico que pasa 4,5:1 en modo claro puede caer silenciosamente a 2,8:1 en modo oscuro cuando su alias se resuelve a un primitivo diferente, por lo que Contrast Audit debe ejecutarse con ambos modos activos si la biblioteca usa Variables de Figma para modo oscuro. Trata esta secuencia - tokenizar, luego auditar - como la puerta mínima viable de accesibilidad antes de cualquier publicación de biblioteca.

Veredicto final - Contrast Audit

Contrast Audit reemplaza una lista de comprobación de accesibilidad manual con una señal de regresión repetible anclada a la capa de tokens. La diferencia práctica es que corregir un alias propaga la corrección a todos los componentes que se vinculan a él, en lugar de requerir un barrido capa por capa. Los equipos que usan Atomize informan completar lo que solían ser revisiones de accesibilidad de varios días en un solo sprint, porque la pestaña Atoms colapsa cientos de fallos de capa en una lista corta de ediciones de tokens. Ejecútala antes de cada publicación de biblioteca, trata la primera línea base del escaneo sin pánico y gana su lugar como una puerta permanente en el flujo de trabajo de publicación.