Cómo incorporamos la accesibilidad a un producto basado en lienzo

Al igual que un videojuego, el lienzo de Figma asume el control del renderizado en lugar del navegador para maximizar el rendimiento. Esto nos permite ofrecer funcionalidades avanzadas, como el zoom infinito y la colaboración multiusuario en tiempo real. Sin embargo, como no utilizamos HTML ni el DOM tradicionales para renderizar el lienzo de Figma, tampoco contamos con las funcionalidades de accesibilidad que el navegador incorpora de forma predeterminada.

Para hacer que Figma fuera accesible para más personas, creamos una estructura Mirror DOM capaz de mantenerse sincronizada con cualquier diseño de Figma. En este artículo te mostraremos cómo hicimos posible que cualquier persona pueda recorrer un archivo de Figma con un lector de pantalla, escuchar los cambios a medida que se anuncian y utilizar el editor únicamente con el teclado.

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

Generar un DOM sintético

Los motores de los navegadores utilizan un concepto denominado árbol de accesibilidad (accessibility tree): una estructura de datos derivada del documento que contiene la información no visual necesaria para que las tecnologías de asistencia funcionen correctamente. Cuando un usuario que utiliza un lector de pantalla ejecuta el comando "ir al siguiente campo de formulario", el árbol de accesibilidad le indica al lector de pantalla adónde debe ir. El navegador construye este árbol a partir del DOM, del HTML semántico, de los atributos ARIA y de otros estados calculados.

En una app web convencional, cada componente tiene su propio elemento del DOM, como <button>, <p> o <img>. Sin embargo, como Figma no utiliza HTML para renderizar el contenido, el lienzo solo contiene un único elemento <input>, que mantiene el foco independientemente de la cantidad de capas que existan en el diseño. Esto hacía que el árbol de accesibilidad del navegador estuviera prácticamente vacío al abrir un archivo de Figma.

Para resolver este problema, volvimos a incorporar elementos sintéticos al DOM del lienzo para que los lectores de pantalla pudieran recorrer y editar los archivos.

Cómo funciona el sistema

Detrás del lienzo, e invisibles para quienes ven la interfaz, renderizamos elementos del DOM que reflejan las partes del scenegraph relevantes para las tecnologías de asistencia. El sistema se compone de cuatro mecanismos que trabajan de forma coordinada:

• Un "árbol de accesibilidad" interno de Figma, que almacena en caché la información de accesibilidad de cada capa del diseño y realiza actualizaciones puntuales en lugar de reconstruir todo el árbol cada vez que se produce un cambio.
• Un componente de React denominado "Mirror DOM", responsable de insertar los elementos en el DOM utilizando como referencia el árbol de accesibilidad interno.
• Un sistema bidireccional de sincronización de la selección. Cuando seleccionas un nodo en el lienzo, el elemento correspondiente del DOM recibe el foco. Del mismo modo, cuando el usuario navega por el Mirror DOM mediante un lector de pantalla, la selección del lienzo se actualiza automáticamente.
• Un sistema de anuncios que alerta al usuario sobre ediciones y otros cambios que no implican navegación, como ajustar finamente mediante las flechas, cambiar de herramienta o cualquier otra acción que resultaría evidente para una persona que ve la pantalla.

El árbol de accesibilidad interno

Para determinar qué elementos del DOM debíamos renderizar y de qué manera, partimos de la información que el navegador necesita para construir su árbol de accesibilidad. Con ese objetivo desarrollamos nuestro propio árbol de accesibilidad interno, que reúne toda la información no visual que un lector de pantalla necesita para interpretar cualquier documento de Figma.

Para cada capa del documento generamos un resumen accesible, que será leído por el lector de pantalla. Ese resumen puede variar según el contexto y el tipo de aplicación en la que se encuentre el usuario. Por ejemplo, en los prototipos podemos omitir la mayoría de las funcionalidades de edición y emular únicamente el contenido que verá el usuario final: el texto de los campos de texto o el rol de botón para un elemento con una interacción de clic. En cambio, los marcos con disposición automática, que se excluyen del árbol de accesibilidad en los prototipos, sí deben incluirse cuando el usuario está editando un documento.

Después de resumir cada capa individualmente, recorremos el árbol de arriba hacia abajo y aplanamos los nodos que se hayan omitido. Aunque construimos por completo el árbol de accesibilidad interno cuando un documento se carga por primera vez, seguimos supervisando las ediciones durante toda la sesión para actualizar únicamente las partes necesarias del árbol y evitar reconstrucciones costosas.

El Mirror DOM

Una vez que el árbol de accesibilidad está listo, podemos generar el DOM. Para ello utilizamos un componente de React que se renderiza de forma recursiva. Cada instancia de ese componente se suscribe a los cambios del árbol de accesibilidad de una capa específica del diseño.

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 realizamos cambios mínimos e incrementales en el árbol de accesibilidad para reflejar las ediciones, confiamos en React para que las modificaciones del DOM también se mantengan al mínimo.

Un aspecto del Mirror DOM que puede resultar sorprendente es que no utilizamos las técnicas habituales para ocultar visualmente este contenido accesible. Aunque esos métodos permiten que las tecnologías de asistencia interpreten el contenido sin afectar el diseño de la página, nosotros necesitamos que los elementos del Mirror DOM sí se distribuyan visualmente. La razón es que la disposición espacial de un documento de Figma es fundamental para su significado y, aunque esos elementos no sean visibles, su posición sigue siendo utilizada por las tecnologías de asistencia: los magnificadores de pantalla pueden desplazarse para mantener visible el elemento que tiene el foco; los lectores de pantalla muestran un contorno de alto contraste para personas con baja visión; y las herramientas de control por voz también pueden presentar indicadores en la pantalla.

El cálculo de esa posición consta de varios pasos. Cada capa de un diseño de Figma tiene una transformación afín (affine transform): una estructura de datos de tamaño fijo que registra el desplazamiento, el escalado y la rotación. Las transformaciones afines son una herramienta muy potente en gráficos por computadora, ya que cualquier secuencia de transformaciones puede combinarse en una única transformación. Aprovechamos estas capacidades para posicionar los elementos del Mirror DOM mediante CSS, incluidas las rotaciones y las inclinaciones.

Mantener el foco y la selección sincronizados

Con las funcionalidades descritas hasta aquí, ya podíamos permitir que los usuarios recorrieran prototipos y otros contenidos publicados mediante un lector de pantalla. El siguiente paso consistió en ofrecer esa misma posibilidad dentro de las aplicaciones de edición de Figma. Para lograrlo, tuvimos que volver a implementar otra función que normalmente proporciona el navegador: la semántica de selección y foco sobre la que se apoyan las tecnologías de asistencia.

Al navegar por el lienzo de Figma, la tecla Tab cambia el nodo seleccionado sin modificar el foco del sistema del teclado. Como consecuencia, para los lectores de pantalla el lienzo aparecía como un único y gran elemento de navegación. Necesitábamos asegurarnos de que el foco se desplazara al nodo seleccionado dentro del lienzo, tal como esperan los usuarios.

Por eso desarrollamos un sistema de sincronización bidireccional entre la selección del lienzo y el foco del sistema del teclado, integrado en nuestro Mirror DOM. Cuando haces clic en el lienzo, el elemento correcto recibe el foco para el lector de pantalla; y cuando una acción del lector de pantalla cambia el foco, actualizamos el resaltado de la selección visible en el lienzo. Gracias a este mecanismo, incluso controles específicos de los lectores de pantalla, como el rotor de VoiceOver, pueden utilizarse para seleccionar nodos en el lienzo de Figma.

Anunciar acciones y cambios

El árbol de accesibilidad interno y el Mirror DOM permiten que las tecnologías de asistencia accedan al contenido de los archivos de Figma. Sin embargo, por sí solos no bastan para las tareas de edición, donde la aplicación también debe confirmar al usuario las acciones que realiza. Acciones como desplazar un elemento con las teclas de dirección, cuyo resultado es evidente para quien ve la pantalla, también necesitan proporcionar un contexto textual que pueda anunciarse por voz. En la práctica, existe una única forma de hacerlo:utilizar las live regions que los navegadores ofrecen como parte del estándar ARIA.

Nuestra implementación añade el marcado de live regions a todos los mensajes emergentes (toast notifications) del producto y también permite generar anuncios invisibles para eventos que, para quienes ven la interfaz, resultarían redundantes. Por ejemplo, probablemente la mayoría de los usuarios no considere útil que aparezca un mensaje emergente cada vez que se ajusta finamente un píxel con una tecla de dirección, pero esas notificaciones sí son importantes desde el punto de vista de la accesibilidad. También implementamos un mecanismo de agrupación automática. Si varios eventos de la misma categoría ocurren en rápida sucesión, podemos fusionarlos en un único anuncio. Siguiendo el ejemplo anterior, si ajustas finamente un elemento un píxel cinco veces consecutivas con las teclas de dirección, el sistema anuncia una sola vez "Se desplazó cinco píxeles", en lugar de repetir "Se desplazó un píxel" cinco veces.

Lo que ya hemos logrado y lo que viene

Nuestro trabajo para hacer que Figma sea más accesible se ha desarrollado a lo largo de varios años y ha estado guiado por el feedback de usuarios que utilizan tecnologías de asistencia, gracias a nuestra colaboración con Fable. Todo comenzó con el visualizador de prototipos en 2022, continuó con FigJam en 2023 y dio un gran salto durante 2024 y 2025: incorporamos la configuración Adapt content for screen readers en Design, Dev Mode y Slides; lanzamos la primera versión de los controles del lienzo mediante teclado; añadimos el modo de contraste mejorado e implementamos más de quince mejoras adicionales centradas en la accesibilidad.

Estamos integrando la accesibilidad en la forma en que diseñamos, desarrollamos y lanzamos nuevos productos. Todas las funcionalidades nuevas se revisan desde el punto de vista de la accesibilidad y, además, nuestro equipo está invirtiendo en herramientas internas, como un agente de IA con contexto específico de Figma y orientación del equipo de sistemas de diseño, para ampliar el conocimiento sobre accesibilidad en toda la organización de desarrollo de productos de Figma.

También queremos facilitar la creación de productos accesibles en Figma. Actualmente puedes comprobar desde el selector de color si una combinación cumple las pautas de accesibilidad y asignar nombres a las capas visibles para que los lectores de pantalla utilicen esas denominaciones. Además, hace poco lanzamos Check designs, una nueva funcionalidad de Figma Design que permite comparar los diseños con el sistema de diseño correspondiente para detectar desviaciones y corregirlas con un solo clic. Entre otras cosas, identifica problemas de contraste insuficiente y sugiere colores compatibles con WCAG 2.0 AA o AAA antes de transferir el trabajo al equipo de ingeniería.

El trabajo en accesibilidad nunca termina. Cada mejora elimina una barrera más y permite que más personas participen del proceso creativo, compartan sus ideas y contribuyan a dar forma a los productos que todos utilizamos. Seguiremos escuchando, aprendiendo y construyendo un futuro cada vez más accesible.