Incorporando accesibilidad a un producto basado en lienzo

Similar a un videojuego, el lienzo de Figma se encarga del renderizado en lugar del navegador para maximizar el rendimiento. Esto nos permite ofrecer características potentes como el zoom infinito y el multiusuario en tiempo real. Sin embargo, como no usamos HTML tradicional ni DOM para renderizar el lienzo de Figma, no obtenemos ninguna de las funciones de accesibilidad que vienen integradas en el navegador por defecto.

Para hacer Figma accesible para más personas, creamos una estructura de Mirror DOM que pudiera mantenerse en sincronía con cualquier Figma Design. Aquí vamos a ir detrás de las escenas de cómo hicimos posible que cualquiera navegara un archivo de Figma con un lector de pantalla, escuchara los cambios a medida que se anuncian, y operara el editor con un teclado.

Obtén más información sobre las mejoras de accesibilidad para teclado y lectores de pantalla de Figma.

Sintetizando el DOM

Los motores de los navegadores tienen un concepto llamado árbol de accesibilidad: una estructura de datos extraída del documento que contiene la información no visual necesaria para que funcionen las tecnologías de asistencia. Cuando un usuario de lector de pantalla ejecuta el comando “ir al siguiente campo de formulario”, el árbol de accesibilidad le indica al lector de pantalla a dónde ir. El navegador construye este árbol a partir del DOM, HTML semántico, atributos ARIA y algún estado computado adicional.

En una aplicación web típica, cada componente tiene su propio elemento DOM como <button>, <p> o <img>. Sin embargo, como Figma no utiliza HTML para renderizar, el lienzo solo tiene un elemento <input> que mantiene el foco sin importar cuántas capas tenga el diseño. Esto significaba que el árbol de accesibilidad del navegador estaba prácticamente vacío para un archivo de Figma.

Para solucionarlo, añadimos elementos DOM sintéticos de nuevo para el lienzo, de modo que los lectores de pantalla pudieran navegar y editar archivos.

Funcionamiento del sistema

Detrás del lienzo, invisible para los usuarios videntes, renderizamos elementos DOM que reflejan las partes del gráfico de escena que son importantes para la tecnología de asistencia. Hay cuatro sistemas que colaboran:

• Un “árbol de accesibilidad” interno de Figma que almacena en caché los detalles de accesibilidad de cada capa de diseño, y realiza actualizaciones quirúrgicas en lugar de reconstruir desde cero a medida que se realizan ediciones.
• Un componente de React “Mirror DOM” que es responsable de insertar realmente los elementos en el DOM, utilizando el árbol de accesibilidad interno como referencia.
• Un sistema de sincronización bidireccional para la selección. Cuando seleccionas un nodo en el lienzo, el elemento DOM correspondiente recibe el enfoque. Por el contrario, actualizamos la selección del lienzo cuando se utilizan herramientas de lectores de pantalla para navegar por el Mirror DOM.
• Un sistema de anuncios que alerta al usuario sobre ediciones y otros cambios no de navegación—desplazamientos, cambios de herramientas, y cualquier otra cosa obvia para un usuario vidente.

El árbol de accesibilidad interno

Para determinar qué elementos del DOM renderizar y cómo, trabajamos hacia atrás desde lo que el navegador debería conocer con el fin de construir su árbol de accesibilidad. Así que construimos nuestro propio árbol de accesibilidad interno, que captura la información no visual que los lectores de pantalla requerirían para cualquier documento de Figma dado.

Para cada capa en el documento, creamos un "resumen accesible" que será leído por los lectores de pantalla. Este resumen puede depender del contexto y del tipo de aplicación en que se encuentra el usuario. Por ejemplo, en prototipos, podemos omitir la mayoría de las funciones de edición y solo emular el contenido para el espectador final: solo el texto de los campos de texto, o un rol de botón para un elemento con una interacción de clic. Por otro lado, los marcos de auto-layout, que están excluidos del árbol de accesibilidad para prototipos, deben incluirse cuando el usuario está editando un documento.

Después de resumir las capas una por una, recorremos el árbol de arriba abajo, eliminando cualquier nodo omitido. Mientras construimos completamente nuestro árbol de accesibilidad interno al cargar por primera vez un documento, monitoreamos las ediciones a medida que avanza la sesión para poder actualizar nuestro árbol quirúrgicamente, evitando reconstrucciones costosas.

El Mirror DOM

Con nuestro árbol de accesibilidad listo, podemos generar el DOM. Esto es manejado por un componente de React que se renderiza a sí mismo de manera recursiva, con cada instancia de ese componente suscribiéndose a cambios en el árbol de accesibilidad para una capa de diseño específica.

function ScreenReaderElement({ layerId }: { layerId: string }) {
  const { label, role, children } = useAccessibleSummary(layerId);
  return <div role={role} ariaLabel={label}>
    {children.map((c) => <ScreenReaderElement key={c} layerId={c}>)}
  </div>
}

A medida que hacemos cambios mínimos e incrementales en el árbol de accesibilidad para seguir las ediciones, confiamos en React para mantener también nuestra modificación del DOM al mínimo.

Un detalle del Mirror DOM que podría ser sorprendente es que no usamos el estilo visualmente oculto típico para este contenido accesible pero visualmente oculto. Mientras que tales técnicas permiten que las tecnologías de asistencia interpreten el contenido sin impactar la disposición de la página, en realidad necesitamos que los elementos del Mirror DOM estén diseñados. La razón es que la disposición espacial de un documento de Figma es crítico para su significado, e incluso sin mostrarlo visualmente, la posición de estos elementos alimenta a las tecnologías de asistencia; los magnificadores de pantalla podrían desplazarse para mantener el elemento enfocado a la vista; los lectores de pantalla rinden un esquema de alto contraste para usuarios parcialmente videntes; las herramientas de control por voz también podrían mostrar indicaciones en pantalla.

Ese cálculo de posicionamiento tiene algunos pasos. Cada capa en un diseño de Figma tiene una transformación afín: una estructura de datos de tamaño fijo que rastrea el desplazamiento, escalado y rotación. Las transformaciones afines son una herramienta poderosa para los gráficos por computadora porque cualquier secuencia de transformaciones puede concatenarse en una única transformación. Utilizamos esas capacidades para posicionar elementos en el DOM reflejo usando CSS, incluidas rotaciones o inclinaciones.

Manteniendo el enfoque y la selección sincronizados

Con las características anteriores, podemos admitir la navegación de prototipos y otro contenido “publicado” con un lector de pantalla. El siguiente paso fue admitir la navegación de aplicaciones “en edición” en Figma. Para hacer esto, necesitábamos agregar nuevamente otra cosa que los navegadores generalmente manejan por nosotros: la semántica de selección y enfoque a la que las tecnologías de asistencia pueden conectarse.

Al navegar en el lienzo de Figma, la tecla Tab cambia el nodo seleccionado sin modificar el enfoque del teclado del sistema. Esto significaba que el lienzo parecía ser un gran objetivo de navegación para los lectores de pantalla. Necesitábamos asegurarnos de que el enfoque se moviera al nodo seleccionado dentro del lienzo, tal y como esperan los usuarios.

Por lo tanto, construimos una sincronización bidireccional entre la selección del lienzo y el enfoque del teclado del sistema, en nuestro sistema DOM reflejo. Cuando haces clic en el lienzo, el elemento correcto se enfoca para el lector de pantalla, y cuando una acción del lector de pantalla mueve el enfoque, actualizamos los destacados visibles de selección. Gracias a este sistema, incluso los controles de lector de pantalla como el rotor de VoiceOver pueden seleccionar nodos en el lienzo de Figma.

Anunciando acciones y cambios

Los sistemas internos de árbol de accesibilidad y DOM reflejo exponen el contenido de los archivos de Figma a las tecnologías de asistencia. Sin embargo, estas herramientas por sí solas no son suficientes para la edición, donde la aplicación debe confirmar las acciones del usuario de regreso a ellos. Gestos como el desplazamiento, cuyos resultados son obvios para un usuario vidente, también necesitan proporcionar contexto textual que pueda ser anunciado audiblemente. Realmente solo hay una manera de hacer esto: confiamos en las regiones en vivo proporcionadas por los navegadores web como parte del estándar ARIA.

Nuestra implementación agrega un marcado de región en vivo a cada anuncio de toast en el producto, y admite anuncios invisibles para eventos que probablemente se percibirían como ruido redundante por los usuarios videntes, por ejemplo, la mayoría de los usuarios probablemente no encontrarían útil ver una ventana emergente de toast confirmando cada desplazamiento con la tecla de flecha, pero estas notificaciones son importantes para la accesibilidad. También manejamos la "coalescencia" automática: si ocurren múltiples eventos en la misma categoría cerca uno del otro, podemos fusionarlos. Nuevamente, usando los desplazamientos de teclas de flecha como ejemplo, si empujas un solo píxel cinco veces seguidas podemos enviar un anuncio confirmando "Movido cinco píxeles" en lugar de repetir "Movido un píxel" cinco veces.

Lo que está en marcha y lo que sigue

Nuestro trabajo para hacer Figma más accesible ha crecido a lo largo de varios años, moldeado por los comentarios de los usuarios de tecnologías de asistencia a través de nuestra asociación con Fable. Comenzó con el visor de prototipos en 2022, luego FigJam en 2023, y finalmente hicimos avances significativos durante el curso de 2024 y 2025: lanzamos la configuración de Ajustar contenido para lectores de pantalla en Diseño, Dev Mode y Diapositivas, lanzamos la primera versión de controles del teclado para lienzo, añadimos modo de contraste mejorado y realizamos más de 15 mejoras adicionales centradas en la accesibilidad.

Estamos integrando la accesibilidad en la manera en que diseñamos, construimos y lanzamos nuevos productos. Cada nueva característica se revisa para el soporte de accesibilidad, y nuestro equipo también está invirtiendo en herramientas internas como un agente de IA equipado con contexto específico de Figma y orientación del equipo de sistemas de diseño para ayudar a escalar el contexto accesible en toda la organización de desarrollo de productos de Figma.

También queremos facilitar que las personas construyan productos accesibles en Figma. Hoy, puedes identificar si una combinación de colores cumple con las pautas de accesibilidad en el selector de color y renombrar capas visibles para pasar esos nombres a los lectores de pantalla. Además, recientemente lanzamos revisar diseños, una nueva función en Figma Design que ofrece a los diseñadores una forma de comparar diseños con su sistema de diseño para identificar lo que está mal y solucionarlo con un clic, incluyendo señalar bajo contraste y sugerir colores que cumplan con WCAG 2.0 AA o AAA antes de entregarlo a ingeniería.

El trabajo de accesibilidad nunca termina realmente. Cada mejora ayuda a eliminar otra barrera, haciendo posible que más personas participen en el proceso creativo, compartan sus ideas y modelen los productos que todos usamos. Seguiremos escuchando, aprendiendo y construyendo hacia un futuro más accesible.