La muestra comprende 50 archivos de Figma de 28 equipos de producto en los sectores de SaaS, comercio minorista, fintech, sector público y edtech. Se negoció el acceso de solo lectura en régimen de no atribución: nada en este artículo identifica a una marca, un equipo ni un diseñador. Los archivos se eligieron para reflejar lo que un ingeniero recibiría realmente en el traspaso —no un estudio de caso pulido de un sitio de porfolio—, por lo que se pidió a cada equipo que compartiera el archivo del que se entregó la funcionalidad más reciente, no el archivo del que más orgullosos estaban. Doce de los archivos procedían de equipos con una práctica dedicada de sistema de diseño; los otros 38 eran archivos a nivel de producto que importaban una librería de sistema o desarrollaban sus propios componentes en línea.

Se recorrió cada archivo en busca de cinco propiedades de accesibilidad: diseño del estado de foco en cada componente interactivo, anotaciones de texto alternativo en cada imagen o icono no decorativo, documentación del orden de lectura en todo el diseño, gestión de la preferencia de movimiento para cualquier elemento animado o en transición, y especificación del contraste en modo oscuro para cualquier componente entregado en ambos temas, claro y oscuro. Para cada propiedad, un archivo recibía la calificación de «documentado» solo si un ingeniero competente podía implementar el diseño sin tener que inventar la respuesta por sí mismo. «Mencionado en una nota adhesiva» no contaba. «Hex especificado en un único estado de hover» no contaba. El criterio era: ¿está la decisión en el archivo en una forma sobre la que el ingeniero puede actuar sin preguntar?

La conclusión principal es que el traspaso, según este criterio, omite las decisiones de accesibilidad con mucha más frecuencia de las que las incluye. El diseño del estado de foco apareció en aprox. el 40 % de los componentes interactivos del corpus. Las anotaciones de texto alternativo aparecieron en aproximadamente el 22 % de las imágenes que lo necesitaban. El orden de lectura estaba explícitamente documentado en el 16 % de los archivos. Las preferencias de movimiento se abordaron en el 10 %. El contraste en modo oscuro —en los 31 archivos que se entregaron con ambos temas— se especificó para el 30 % de los componentes. La brecha no está en ninguna propiedad concreta. Está en las cinco, y el ingeniero queda encargado de cerrarlas decisión a decisión.

De los aproximadamente 1.800 componentes interactivos revisados en el corpus —botones, enlaces, inputs, checkboxes, switches, tabs, comboboxes, elementos de menú, tarjetas como botón, cualquier elemento al que pueda llegar un usuario de teclado—, aproximadamente el 40 % entregó un estado de foco diseñado. El otro 60 % entregó un estado predeterminado, uno activo y uno de hover, y ahí se detuvo. El ingeniero que construye el componente elige un contorno de foco en el momento de la implementación, normalmente copiando el predeterminado del navegador, normalmente sin comprobar que el predeterminado tiene un contraste de 3:1 frente a la superficie del componente en ambos temas, claro y oscuro, que entrega el archivo.

¿Qué aspecto tiene en la práctica «sin diseño de estado de foco»? El aspecto de un componente botón con tres variantes en el lienzo —reposo, hover, presionado— sin una cuarta variante. El aspecto de un campo de input con un borde con estilo y sin un segundo estilo de borde para el estado enfocado. El aspecto de un checkbox primitivo con un anillo de foco solo en la variante de reposo, con el ingeniero obligado a adivinar si el mismo anillo debería aparecer en la variante marcada o indeterminada. El patrón se repite en componentes, equipos y sectores. Es la única brecha de accesibilidad más grande del corpus y la más fácil de diseñar.

Los equipos que sí diseñaron bien los estados de foco contaban con una de dos cosas. La primera, una regla explícita del sistema de diseño: cada componente interactivo debe entregarse con una variante cuyo nombre comience por focus-, y el componente no se publica en la librería hasta que esa variante existe. La segunda, una propiedad de componente de Figma llamada state con focus, focus-visible y focus-within como valores enumerados, de modo que el navegador de componentes del archivo muestra visualmente las variantes que faltan. Los equipos sin ninguno de esos dos andamiajes dejaron el estado de foco para el ingeniero aproximadamente nueve de cada diez veces.

De los archivos del corpus que incluían imágenes de contenido —fotografía de producto, ilustraciones de hero, botones solo con icono, figuras infográficas—, el 78 % no tenía anotaciones de texto alternativo en las capas de imagen. La imagen estaba colocada, dimensionada y con estilo; el equivalente textual que se esperaba que el ingeniero pusiera en el <img> renderizado no estaba en el archivo. Ocho de los 50 archivos tenían texto alternativo en algunas imágenes pero no en todas, normalmente con la ilustración del hero anotada y las imágenes de contenido en el cuerpo en blanco. Tres archivos tenían texto alternativo en todas las imágenes. El ingeniero, en 47 de 50 archivos, debía inventar el texto alternativo —y en la práctica a menudo lo heredaba del nombre del archivo, del figcaption o de cualquier cadena que encajara en el ritmo visual.

La brecha es estructural al primitivo de imagen de Figma. No hay ninguna propiedad «alt» nativa en un relleno de imagen o una capa de imagen; el texto alternativo debe llevarse como nombre de capa, comentario, nota adhesiva, documento de especificación separado o campo añadido por un plugin. Ninguno de esos medios se transmite a través del panel de inspección por defecto, de modo que el ingeniero que lee el archivo en la vista de inspección no ve el texto alternativo aunque el diseñador lo haya escrito en otro lugar. Los equipos que cerraron la brecha de forma consistente usaron una de tres soluciones: campos de texto alternativo gestionados por plugin en cada variante de imagen, una convención documentada de que el nombre de la capa es el texto alternativo, o una hoja de cálculo de texto alternativo separada indexada por nombres de archivo de imagen que se entregaba junto con el archivo.

Los botones solo con icono fueron un subfallo dentro de este modo de fallo. En 41 de 50 archivos, los botones de icono —la lupa de búsqueda, el menú hamburguesa, la X de cerrar, la flecha de compartir— no tenían anotación de nombre accesible, dejando al ingeniero escribir aria-label=“Buscar” a partir del contexto visual sin confirmación de que «Buscar» era la palabra correcta en la voz de la marca (¿era «Encontrar»? ¿era «Consultar»? ¿era nada porque el botón abre un panel con etiqueta en otro lugar?). La denominación de iconos es exactamente el tipo de decisión de microcopia que se beneficia de la pluma de un diseñador, y exactamente el tipo que el traspaso pierde.

Las tres propiedades restantes presentaron formas de fallo diferenciadas. El orden de lectura —el orden en que un lector de pantalla narrará la página, que en los diseños responsivos modernos ya no está garantizado que coincida con el orden visual de arriba abajo— estaba documentado en el 16 % de los archivos. La documentación, donde existía, era normalmente una superposición numerada en el lienzo (1, 2, 3…) añadida con un plugin. El 84 % restante dejaba al ingeniero trazar el orden de lectura a partir del orden del DOM que escribía, que en un diseño de CSS Grid con posicionamiento explícito de filas y columnas puede divergir del diseño visual en toda una columna.

Las preferencias de movimiento obtuvieron el peor resultado. El 10 % de los archivos mencionaba prefers-reduced-motion en absoluto. El 90 % restante especificaba animaciones y transiciones —entradas de modales, expansiones de acordeones, deslizamientos de snackbars, transiciones de página— sin especificar qué debería hacer el mismo componente cuando el usuario ha activado la reducción de movimiento. El ingeniero o bien construía el caso de reducción de movimiento en el momento de la implementación (a menudo sin referencia visual) o bien entregaba la misma animación a todos, que es el comportamiento predeterminado y que viola el criterio de conformidad WCAG 2.3.3 Animación desde interacciones para los usuarios que configuran la preferencia.

El contraste en modo oscuro se especificó para el 30 % de los componentes en los archivos que se entregaron con ambos temas. El otro 70 % especificaba el contraste del tema claro —normalmente con una anotación de Stark o del comprobador de contraste en el archivo— y luego publicaba el tema oscuro con una paleta con los colores invertidos, dejando al ingeniero comprobar si el par invertido seguía superando 4,5:1 en texto de cuerpo y 3:1 en componentes de interfaz. En aproximadamente una quinta parte de los 31 archivos con doble tema, al menos un componente caía por debajo del umbral de contraste en el tema oscuro porque tanto la superficie oscura como el texto oscuro habían sido ajustados para el cálculo de contraste del tema claro, no del oscuro.

Los dos plugins que aparecen con más frecuencia en el corpus son Stark y Able. Ambos son maduros, ambos gozan de buena reputación y ambos ofrecen funciones que cierran varias de las brechas documentadas anteriormente. Stark añade un comprobador de contraste, una superposición de orden de foco, una previsualización de movimiento reducido y un campo de anotación de texto alternativo en capas de imagen. Able añade un inspector de contraste de color, una superposición de simulación de visión y un comprobador de objetivo táctil. Cualquiera de los dos plugins, usado de forma consistente en todo un archivo, sacaría ese archivo del cuartil inferior del corpus.

Usado de forma consistente es la frase clave. En los 50 archivos, Stark estaba instalado y visiblemente usado en 18, y Able en 11. En los archivos donde se usó el plugin, normalmente se usó en el componente hero y en el CTA principal —los componentes con más probabilidades de estar en el lienzo cuando el diseñador abrió el plugin— y solo esporádicamente en los demás. Seis archivos usaron Stark en un recorrido global; uno usó Able en un recorrido global. El patrón es: los plugins existen, los diseñadores los conocen, se usan para comprobaciones puntuales y luego la comprobación puntual se detiene en los componentes que el diseñador tenía delante cuando el plugin estaba abierto.

Los dos equipos que cerraron la auditoría en el uso de plugins hicieron una cosa diferente: ejecutaron la función de auditoría del plugin en cada página del archivo como paso de barrera de publicación antes de que el archivo se compartiera con ingeniería. La auditoría se ejecutó en el archivo, produjo un informe y el informe debía estar vacío (o sus excepciones documentadas) antes de que el archivo pasara de «en diseño» a «listo para ingeniería». Esto es plugin-como-flujo de trabajo en lugar de plugin-como-comprobación-puntual, y es la diferencia entre una cobertura del 80 % y del 20 % en la muestra.

La auditoría produce una lista de verificación y un contrato. La lista de verificación es lo que un diseñador debería poder marcar antes de que el archivo se comparta con ingeniería. El contrato es la forma de los tokens de diseño que acompañan al archivo para que el ingeniero asigne variables de Figma a propiedades personalizadas de CSS sin inventar valores intermedios. Ambos son breves a propósito: cada elemento de la lista de verificación es una propiedad que la auditoría midió, y cada token del contrato es un valor que cerró una brecha en el corpus.

La auditoría de 50 archivos concluye con una conclusión sencilla. El traspaso está fallando en accesibilidad no porque a los diseñadores no les importe y no porque a los ingenieros no les importe, sino porque el archivo —el archivo de Figma, el único artefacto que todas las partes leen— no lleva las decisiones de accesibilidad como propiedades de primer orden. Estados de foco, texto alternativo, orden de lectura, preferencias de movimiento, contraste en modo oscuro: cada uno de ellos es una decisión de diseño, cada uno pertenece al archivo, cada uno está actualmente en otro lugar. En una nota adhesiva, en un mensaje de Slack, en una hoja de cálculo separada, en la cabeza del ingeniero a las 4 de la tarde de un viernes.

La corrección no es un diseñador heroico ni un ingeniero heroico. Es un cambio de flujo de trabajo a nivel de equipo: cada componente interactivo se entrega con una variante de foco, cada imagen lleva texto alternativo en una única ubicación gestionada por plugin, el orden de lectura se superpone en cualquier página no trivial, las animaciones especifican su equivalente de movimiento reducido, el contraste en modo oscuro se comprueba por separado del claro, y el archivo se entrega junto con un contrato de tokens que nombra cada variable a la que la implementación está vinculada. Ninguno de estos pasos es nuevo, ninguno requiere una herramienta que no tengamos ya, y cualquier equipo que los adopte como pasos de barrera de publicación cerrará la mayoría de las brechas medidas en un único ciclo de publicación.

La conclusión más profunda es que los equipos con sistema de diseño ya hacen esto aproximadamente al doble de la tasa de los equipos de producto. La ventaja que ofrecen los equipos con sistema de diseño es exactamente la ventaja que impone la disciplina de construir un sistema: los componentes tienen nombre, las propiedades están enumeradas, las variantes son visibles, los tokens son explícitos. Llevar la misma disciplina a los archivos a nivel de producto —incluso sin un sistema de diseño completo por debajo— cierra la mayor parte de la brecha del traspaso. Ya no es un problema de herramientas. Es una elección de flujo de trabajo.