De Figma a HTML accesible: guía práctica

Respuesta rápida: la accesibilidad en un flujo de trabajo de Figma a HTML no es un ajuste que se activa una vez — son varias decisiones concretas: elementos semánticos reales en lugar de <div> con estilos, un orden de encabezados que coincide con la estructura del contenido (Figma no tiene un concepto nativo de niveles de encabezado), campos de formulario y botones de solo icono con etiqueta, estados de foco visibles, contraste de color suficiente, y ARIA usado con moderación — solo donde el HTML semántico no puede expresar la interacción por sí solo. El resultado automatizado te lleva la mayor parte del camino; una breve revisión manual sigue detectando lo que un archivo de diseño no puede transmitir.

Por qué la accesibilidad se pierde en la traducción de Figma a HTML

Un archivo de Figma describe cómo se ve un diseño. No describe qué debería anunciar un lector de pantalla, qué elemento debería recibir el foco a continuación, o si un par de colores es legible para alguien con baja visión. Esa brecha es la razón real por la que la accesibilidad se rompe durante la conversión — no por descuido, sino porque parte de lo que la accesibilidad necesita simplemente no es información que un archivo de diseño contenga. Una coincidencia visual pixel-perfect puede seguir siendo un fallo de accesibilidad si el marcado que hay debajo son <div> genéricos sin estructura, sin etiquetas y sin soporte de teclado.

La solución no es una única pasada automatizada. Es entender qué partes de la accesibilidad ya resuelve bien un buen conversor al generar estructura real en lugar de marcado solo visual, y qué partes siempre necesitan una decisión deliberada — de un diseñador, un desarrollador, o ambos — porque el archivo de diseño sencillamente no lleva esa información.

Decisiones de diseño en Figma que afectan a la accesibilidad

Unos cuantos hábitos comunes en Figma generan problemas de accesibilidad más adelante, incluso antes de que intervenga cualquier herramienta de conversión:

• El color como única señal. Un campo de formulario obligatorio marcado en rojo, o un botón deshabilitado que es solo un tono más claro del mismo color — ambos invisibles para alguien que no puede distinguir esos matices. La distinción necesita una segunda señal (un icono, una etiqueta, un patrón), no solo un cambio de color.
• Texto incrustado en imágenes. Un titular exportado como PNG aplanado puede verse idéntico a una capa de texto real, pero no puede leerlo un lector de pantalla, no puede redimensionarlo el navegador, ni indexarlo un rastreador.
• Sin estado de foco visual diseñado. La mayoría de los conjuntos de componentes de Figma tienen un estado por defecto, uno de hover y a veces uno deshabilitado — un estado de foco (para usuarios de teclado que navegan tabulando por la página) a menudo simplemente nunca se diseña, así que no hay nada que la conversión pueda trasladar.
• Botones de solo icono sin ningún nombre accesible en el archivo. Un icono de papelera que significa "eliminar" es obvio visualmente. Nada en la capa de Figma le indica a un conversor — ni a un lector de pantalla — qué significa el icono, a menos que la propia capa tenga un nombre significativo.
• Tamaños de encabezado inconsistentes. Figma no tiene un elemento "Heading 2" como sí lo tiene un CMS o un procesador de texto — las capas de texto son solo texto, estilizado para verse de cierto tamaño. Dos encabezados visualmente similares en distintos frames pueden representar niveles completamente diferentes en la jerarquía real del contenido.

Ninguno de estos es un error de conversión. Son decisiones que hay que tomar en algún punto del proceso, y conviene saberlo de antemano en lugar de asumir que una herramienta las va a inferir.

HTML semántico y landmarks

Esta es la parte de la accesibilidad que un buen conversor de Figma a código debería resolver por defecto: elementos <header>, <nav>, <main>, <article>, <section>, <aside> y <footer> reales, en lugar de una página construida enteramente con <div> sin etiquetar. Los landmarks importan porque son la forma en que un usuario de lector de pantalla salta directamente a "contenido principal" o "navegación" en lugar de tabular linealmente por toda la página. Consulta Figma to Semantic HTML para ver cómo es estructuralmente el resultado de MarkupGen, y ¿El resultado de Figma a HTML está listo para SEO? para el solapamiento entre marcado semántico y rastreabilidad — los dos problemas comparten una causa raíz y, en su mayor parte, comparten solución.

Jerarquía de encabezados

Un <h1> por página, y encabezados que bajan de nivel en orden — un <h3> debería estar dentro de una sección que ya tiene un <h2>, no aparecer ahí porque una capa de texto resultó verse de ese tamaño en el diseño. Como se mencionó antes, Figma no tiene un concepto nativo de niveles de encabezado, así que una capa de texto con estilo grande no se convierte automáticamente en un <h1> — esto merece una revisión manual sin importar qué herramienta haya generado el marcado, porque depende de entender la estructura real del contenido, no solo su tamaño visual.

Botones frente a enlaces

Este es uno de los errores de accesibilidad más comunes en el marcado convertido, y la estructura de componentes de Figma no lo resuelve por ti: un <button> es para una acción en la página actual (enviar, abrir un modal, eliminar un elemento); un <a href> es para navegar a otra página o vista. Un archivo de diseño lleno de formas de píldora con estilos similares no da ninguna pista de cuál es cuál — esa es una decisión semántica, no visual, y afecta directamente tanto al comportamiento con teclado (los botones y los enlaces responden a teclas distintas por defecto) como a lo que anuncia un lector de pantalla.

Formularios y etiquetas

Cada campo necesita un <label> real, asociado programáticamente — no un placeholder haciendo las veces de etiqueta. El texto de placeholder desaparece en cuanto el usuario empieza a escribir, tiene por defecto un contraste notoriamente pobre, y no todos los lectores de pantalla lo leen de forma fiable como sustituto de una etiqueta. Si un formulario necesita verse sin etiquetas por razones de diseño, usa una etiqueta oculta visualmente en lugar de eliminarla por completo del marcado. Los mensajes de error deben estar asociados a su campo (habitualmente mediante aria-describedby), no solo colocados cerca con el color como única señal del problema.

Imágenes y texto alternativo

Las imágenes exportadas necesitan atributos alt con significado, no cadenas vacías ni un nombre de archivo. Esta es un área donde una revisión manual es realmente inevitable: para qué sirve una imagen de fondo decorativa, frente a lo que necesita describirse en la foto de un producto, no siempre es evidente solo con el frame de Figma — el archivo de diseño no transmite la intención, solo los píxeles. Las imágenes puramente decorativas deberían llevar un alt="" vacío (para que los lectores de pantalla las omitan), mientras que las imágenes con significado necesitan una descripción real de lo que transmiten, no solo de lo que muestran.

Navegación por teclado

Todo elemento interactivo — enlaces, botones, campos de formulario — necesita poder alcanzarse y operarse solo con teclado, en un orden que coincida con el orden de lectura visual. Aquí es donde Auto Layout realmente ayuda: como la estructura de Auto Layout se traslada a un orden de DOM lógico en lugar de fragmentos posicionados de forma absoluta, el orden de tabulación tiende a seguir el orden de lectura automáticamente, en lugar de saltar de forma impredecible como puede ocurrir con layouts libres y posicionados de forma absoluta.

Estados de foco

Como los conjuntos de componentes de Figma rara vez incluyen un estado de foco diseñado, esta suele ser la brecha de accesibilidad más común en una página convertida: un usuario de teclado tabula por la interfaz y no puede saber visualmente dónde está. Como mínimo, no elimines el contorno de foco por defecto del navegador (outline: none) sin reemplazarlo por algo igual de visible — un error común y fácil de dejar pasar, cometido en nombre de encajar con un diseño que nunca lo contempló.

Contraste de color

Figma te permite elegir cualquier par de colores, sean o no legibles juntos, así que esto necesita una comprobación explícita en lugar de una suposición. WCAG AA pide al menos un contraste de 4.5:1 para el texto normal del cuerpo y de 3:1 para texto grande (18px+ en negrita, o 24px+ regular) y para componentes de interfaz con significado, como iconos y bordes de campos. Pasa los pares de colores reales del diseño por un verificador de contraste antes de la conversión — es mucho más barato corregir un token en Figma que perseguirlo después por todo el marcado generado.

ARIA: cuándo ayuda y cuándo perjudica activamente

La primera regla de ARIA sigue siendo la correcta: no usar ARIA es mejor que usar mal ARIA. Un <button> nativo ya tiene el rol correcto, es enfocable y responde a Enter y Espacio por defecto — añadirle role="button" no aporta nada útil y corre el riesgo de entrar en conflicto con la semántica real del elemento. ARIA se gana su lugar específicamente donde el HTML semántico no puede expresar la interacción por sí solo:

• Úsalo: aria-label en un botón de solo icono sin texto visible (un icono de papelera que significa "eliminar"), aria-expanded en un control que despliega una sección colapsable, aria-live="polite" en una región que se actualiza sin recargar la página (un mensaje de validación de formulario, un contador de carrito).
• No lo uses: añadir roles ARIA a elementos que ya tienen la semántica nativa correcta, ARIA decorativo que duplica lo que ya es visible y se anuncia, o aria-live="assertive" en cualquier cosa que no sea genuinamente urgente — interrumpe la salida del lector de pantalla y es fácil de sobreusar.

Accesibilidad responsive

Los problemas de accesibilidad no se quedan resueltos en todos los breakpoints solo porque se hayan solucionado en un tamaño. Los objetivos táctiles deben mantenerse en al menos unos 44×44px en móvil, incluso cuando los layouts se compriman — un botón que se pulsa cómodamente en escritorio puede volverse demasiado pequeño para tocarlo con fiabilidad una vez que las restricciones de redimensionado de Auto Layout lo reducen. El texto necesita reajustarse (reflow) en lugar de recortarse o superponerse en anchos estrechos, y el orden del contenido no debería cambiar de forma confusa entre breakpoints, de manera que rompa el orden de lectura lógico del que depende un lector de pantalla.

Errores comunes de accesibilidad al pasar de Figma a HTML

• Todo elemento pulsable convertido en un <div onclick> en lugar de un <button> o <a> real.
• Botones de solo icono sin aria-label, porque la capa de Figma simplemente se llamaba "Icon 4."
• El color como única forma de comunicar un estado (error, deshabilitado, seleccionado).
• outline: none en los estados de foco sin nada visible puesto en su lugar.
• Texto de placeholder usado como única etiqueta de un campo de formulario.
• Imágenes decorativas con un nombre de archivo como texto alt en lugar de un alt="" vacío.
• Niveles de encabezado elegidos según el tamaño de fuente en el diseño, en lugar de la estructura real del contenido.

Antes / después: un botón de solo icono

Antes — visualmente correcto, no accesible:

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- trash icon --></svg>
</div>

Después — mismo resultado visual, realmente utilizable:

<button type="button" class="icon-btn" aria-label="Delete item" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- trash icon --></svg>
</button>

La diferencia no es visual en absoluto — es un elemento <button> real (enfocable, operable con teclado, anunciado correctamente por un lector de pantalla), un aria-label que le da al icono un nombre accesible, y aria-hidden="true" en el SVG decorativo para que no se anuncie dos veces.

Lista de comprobación práctica de accesibilidad

• Un <h1> por página; los encabezados bajan de nivel en orden, no según el tamaño de fuente
• Presencia de elementos landmark reales (header, nav, main, footer)
• Toda acción pulsable es un <button>; todo enlace de navegación es un <a href>
• Todo campo de formulario tiene un <label> real y asociado — no solo un placeholder
• Las imágenes con significado tienen texto alt descriptivo; las decorativas tienen alt=""
• Los estados de foco son visibles en todo elemento interactivo
• El orden de tabulación coincide con el orden de lectura visual
• El contraste del texto y de los componentes de interfaz cumple WCAG AA (4.5:1 / 3:1)
• El color nunca es la única señal de estado o significado
• ARIA se usa solo donde el HTML semántico no puede expresar la interacción
• Los objetivos táctiles se mantienen utilizables en los breakpoints móviles
• El layout se reajusta sin recortar ni superponer texto en anchos estrechos

Cómo debería revisarse el código generado antes de producción

El resultado de MarkupGen favorece elementos semánticos y una estructura de encabezados real por defecto, en lugar de como un ajuste opcional, y que la estructura de Auto Layout se traslade a un orden de DOM lógico es, en gran parte, lo que hace posible un orden de tabulación correcto desde el principio. La puntuación de calidad automática por IA que recibe cada exportación es una primera señal genuinamente útil — pero es explícitamente una puntuación de coincidencia visual, que compara la vista previa renderizada con el diseño original. No audita la corrección de ARIA, las ratios de contraste ni el comportamiento con teclado, porque nada de eso es visible en una comparación de capturas de pantalla. Trata la lista de comprobación anterior como la revisión manual que llega después de una puntuación visual alta, no en su lugar — consulta How to Evaluate AI-Generated HTML Before You Ship It para el mismo principio aplicado a la revisión de código de forma más general.

Pruébalo con tu propio diseño

La forma más rápida de ver dónde un diseño necesita una revisión de accesibilidad es convertirlo y abrir el marcado real. Prueba MarkupGen gratis, o empieza con la guía completa de conversión de Figma a HTML para el flujo de trabajo de extremo a extremo sobre el que se construye esta guía.