Migrar un Design System sin perder accesibilidad

Cambiar de Design System suele venir acompañado de una promesa: componentes más modernos, más coherencia y menos trabajo repetido.

Y muchas veces es verdad.

El problema aparece cuando damos por hecho que, si el nuevo Design System es accesible, el producto también lo será automáticamente.

Pero no funciona así.

Podemos tener una librería perfectamente construida y terminar con una experiencia difícil de usar. Porque buena parte de la accesibilidad está en cómo combinamos los componentes, en el orden en el que aparecen y en lo que pasa cuando alguien interactúa con ellos.

Un componente accesible no garantiza una pantalla accesible

Imaginemos un campo de formulario diseñado correctamente.

Tiene su etiqueta, buen contraste y un mensaje de error preparado para las tecnologías de asistencia.

Sobre el papel, todo está bien.

Sin embargo, al incorporarlo al producto, la etiqueta se oculta para ahorrar espacio, el mensaje de error aparece lejos del campo y el foco no se desplaza al lugar correcto cuando falla la validación.

El componente continúa siendo accesible dentro de la librería. La experiencia que hemos construido con él ya no tanto.

Lo mismo puede pasar con una modal, un menú desplegable o una tabla. Podemos cumplir las especificaciones de cada pieza por separado y perder la accesibilidad cuando las conectamos.

Es parecido a tener todos los ingredientes adecuados y equivocarse con la receta.

El riesgo de las migraciones

Cuando migramos un producto a un nuevo Design System, solemos concentrarnos en encontrar equivalencias.

Este botón se sustituye por este otro. Este selector antiguo se cambia por el nuevo. Esta modal pasa a usar el componente actualizado.

Visualmente, la pantalla empieza a encajar.

Sin embargo, durante ese proceso también podemos perder pequeños comportamientos que no aparecen en una captura de Figma:

• El orden correcto de navegación con teclado.
• La posición del foco al abrir o cerrar una ventana.
• La relación entre una etiqueta, un campo y su mensaje de ayuda.
• Los errores bien identificados y los avisos que aparecen después de una acción.
• Los estados que no dependen solo del color.
• La posibilidad de ampliar el contenido sin romper la interfaz.

Son detalles que se escapan fácilmente en una revisión visual. Pero para una persona que usa el teclado, un lector de pantalla o necesita ampliar mucho la interfaz, pueden ser la diferencia entre completar una tarea y quedarse atascada.

Las WCAG 2.2 incluyen criterios sobre la navegación con teclado, la visibilidad del foco, la identificación de errores y los mensajes de estado.

Y ninguno se resuelve en un componente suelto: todos dependen de cómo se comporta la pantalla entera.

La accesibilidad necesita contexto

En un Design System podemos comprobar que un botón tiene suficiente contraste o que un campo incluye todos los estados necesarios.

Pero difícilmente podremos anticipar todas las situaciones en las que esos elementos acabarán usándose.

¿Qué sucede cuando colocamos dos modales una encima de otra? ¿Y cuando un menú desplegable aparece dentro de una tabla? ¿Qué ocurre cuando un formulario tiene veinte campos, varias secciones plegables y errores repartidos por toda la página?

Ahí es donde el contexto cambia las reglas.

Una tabla puede ser accesible y, sin embargo, resultar imposible de entender si incluye demasiadas acciones sin nombres claros. Una modal puede funcionar correctamente hasta que se abre desde otra modal y el foco se pierde. Un mensaje puede ser perfectamente legible, pero pasar inadvertido si aparece fuera de la zona visible.

El componente es solo el punto de partida.

No todo se resuelve en Figma

Desde diseño podemos definir colores, estados y anotaciones de accesibilidad. Podemos documentar cómo debería funcionar un componente y qué usos conviene evitar.

Todo eso es necesario.

Pero hay aspectos que no podemos validar del todo dentro de Figma.

No podemos comprobar cómo recorre una pantalla un lector de pantalla. Tampoco cómo se anuncia un mensaje dinámico, si el foco queda atrapado o si el orden real del DOM coincide con el orden visual.

Por eso la accesibilidad tiene que seguir después de entregar el diseño.

Tiene que continuar durante el desarrollo y las pruebas. Diseño, desarrollo, accesibilidad y producto tienen que compartir criterios y revisar juntos el resultado.

Las herramientas automáticas pueden detectar problemas importantes, pero tampoco bastan por sí solas. Pueden avisarnos de un contraste incorrecto o de la ausencia de determinados atributos. Lo que no siempre pueden decirnos es si la experiencia tiene sentido, si el mensaje se entiende o si completar una tarea resulta innecesariamente complicado.

Migrar no es copiar y pegar

Una migración puede parecer un trabajo de sustitución, pero también es una oportunidad para revisar decisiones que llevan años dentro del producto.

Es el momento de preguntarnos si la estructura sigue teniendo sentido, si hay patrones innecesariamente complejos o si algunos flujos deberían simplificarse.

Si no lo hacemos, acabamos con los mismos problemas del sistema anterior, pero con un aspecto más moderno. Mejor aprovechar la migración para corregirlos.

Para hacerlo bien, conviene revisar al menos tres niveles:

Si solo comprobamos el primero, nos dejamos fuera justo lo que suele fallar.

El Design System ayuda, pero no hace magia

Un buen Design System puede evitar muchos errores.

Puede ofrecer componentes accesibles desde el origen y documentar bien los usos correctos e incorrectos. También puede reducir la dependencia de soluciones improvisadas que después resultan difíciles de mantener.

Pero no puede decidir por nosotros cómo construir cada experiencia.

La accesibilidad continúa necesitando criterio, pruebas y colaboración. Necesita que alguien mire el producto completo y no solo las piezas que lo forman.

Ahí está precisamente el valor del trabajo de diseño.

Elegir componentes de una librería es solo una parte. El resto es entender el contexto, anticipar problemas y conectar las decisiones del sistema con las necesidades reales de las personas.

Un Design System accesible es una buena base.

Pero la accesibilidad del producto se consigue cuando esa base se usa bien, se comprueba en el código y se valida dentro de la experiencia real.

Porque cambiar de sistema puede mejorar mucho un producto.

Lo importante es no perder por el camino a las personas que tienen que usarlo.