Anotar la accesibilidad en los diseños (Figma): entregables para desarrollo

Un diseño en Figma muestra cómo se ve la interfaz, pero no cómo se oye, cómo se recorre con teclado ni qué nombre tiene cada botón de icono. Si esa información no viaja con el diseño, el equipo de desarrollo la inventa, y la inventa de forma distinta en cada componente. Las anotaciones de accesibilidad son la forma de cerrar ese hueco: una capa de notas sobre el diseño que especifica semántica, orden, nombres y comportamientos. Esta lección explica qué anotar, cómo hacerlo en Figma y cómo convertirlo en un entregable que desarrollo y QA puedan usar. Es el último paso del diseño: anota cuando el diseño ya ha pasado las pruebas de estrés de la lección anterior.

Por qué anotar

Una parte muy importante de los problemas de accesibilidad que aparecen en las auditorías tiene su origen en decisiones de diseño o de contenido, no de código: un botón sin nombre, un orden de lectura confuso, un estado de foco inexistente, un color sin contraste. Anotarlos en el diseño cuesta minutos; corregirlos tras el desarrollo cuesta días. Además, las anotaciones convierten la accesibilidad en un requisito explícito y verificable: QA puede comprobar el resultado contra la anotación, igual que comprueba un color o un margen.

Qué anotar

Cómo anotar en Figma

1. Crea una página o una capa «A11y» por pantalla, separada del diseño visual, que se pueda ocultar al presentar al cliente y mostrar a desarrollo.
2. Usa un kit de anotaciones. Hay varios gratuitos en la comunidad de Figma y plugins pensados para ello: Include (de eBay), A11y Annotation Kit, Stark, Axe for Designers (de Deque) o A11y - Focus Order. Elige uno y úsalo en todo el proyecto; la coherencia importa más que la herramienta.
3. Numera el orden de foco con marcadores sobre cada elemento interactivo. Si el orden visual y el de foco difieren, es una señal de que hay que replantear el diseño, no de que hay que anotar más.
4. Anota los nombres accesibles con el texto literal, entre comillas, en el idioma de la interfaz. Evita «poner un aria-label descriptivo»: decide tú el texto.
5. Documenta los componentes en la biblioteca, no en cada pantalla: el estado de foco, las teclas y el rol se anotan una vez en el componente del sistema de diseño y se heredan.
6. Comprueba el contraste en el propio Figma con un plugin (Stark, Contrast, A11y - Color Contrast Checker) y anota el ratio junto a la paleta. Define en los estilos de color pares «texto sobre fondo» ya validados.
7. Incluye los estados de error y vacío de cada formulario y lista, con su texto exacto. Son los que más se olvidan.

Del diseño al desarrollo y a QA

• Revisión conjunta: una sesión corta de diseño y desarrollo por pantalla para repasar las anotaciones evita malentendidos.
• Criterios de aceptación: cada anotación se convierte en una condición verificable en la historia de usuario («el botón de cerrar tiene el nombre accesible Cerrar diálogo y al cerrar el foco vuelve al botón que lo abrió»).
• Checklist de QA derivada de las anotaciones: recorrido con teclado, lectura con lector de pantalla, zoom al 200 y 400 %, contraste medido.
• Mantenimiento: cuando un componente cambia, cambia su anotación. Las anotaciones desactualizadas son peores que ninguna.

Resumen

• Muchas barreras nacen en diseño y contenido; anotarlas en Figma es la forma más barata de evitarlas.
• Anota encabezados, landmarks, orden de foco, nombres accesibles literales, alt, estados, rol, teclado, anuncios, contraste y comportamiento responsive.
• Capa «A11y» separada, kit de anotaciones único, documentación en los componentes de la biblioteca, contraste validado en los estilos de color.
• Las anotaciones se convierten en criterios de aceptación y en la checklist de QA.
• Mantén las anotaciones al día cuando cambie el componente.