Ir al contenido principal
Carlos Moreno, sonriente, con barba y bigote, lleva una camiseta negra y está posando frente a un fondo gris oscuro.Carlos Moreno - Squad Lead en Stratesys, especializado en sistemas de diseño y accesibilidad en entornos digitales complejos.

Fecha de publicación:

Cuando hablamos de accesibilidad en el contexto de sistemas de diseño, es fácil caer en la trampa de pensar que con que los textos tengan contraste suficiente y los inputs tengan etiquetas visibles, ya está todo hecho. Pero quienes trabajamos en esto a diario sabemos que no es tan simple.

Participo en la creación de sistemas de diseño, donde ayudamos a organizaciones grandes a estructurar y escalar sus productos especialmente B2B. Casi siempre partimos de un UI kit más o menos montado de varias tecnologías (SAP, Salesforce, etc.), y el reto no es construir desde cero, sino poner orden y coherencia . Y ahí es donde la accesibilidad se convierte en un pilar.

Un UI kit puede tener componentes técnicamente accesibles, sí. Pero eso no garantiza una experiencia accesible..

Del botón al caos

Pongo un ejemplo que me gusta utilizar mucho, el botón.

Un botón bien diseñado (con contraste, rol semántico, etc.) puede pasar cualquier test. Pero cuando ese botón se integra dentro de un componente más complejo (como un desplegable o una modal) todo puede fallar

  • El foco no se gestiona correctamente.
  • El orden de lectura se rompe.
  • El lector de pantalla no anuncia lo que debería.

Y entonces te das cuenta de que la accesibilidad no es una propiedad que se hereda por defecto. Hay que diseñarla. Y mantenerla. Porque a medida que los componentes se vuelven más complejos, también lo hace su accesibilidad.

Cómo lo abordamos en nuestros sistemas de diseño

En los sistemas que participo, lo primero que hacemos es pasar del inventario visual a una estructura funcional accesible. Trabajamos sobre

  • Foundations accesibles: Establecer una base cromática global que garantice accesibilidad y coherencia cumpliendo los estándares de contraste requeridos, estilos de tamaños de tipografía legibles, focus states claramente visibles y coherentes con la identidad visual del producto.
  • Componentes modulares probados en contexto: No solo montamos el componente aislado, sino que lo testeamos dentro de flujos reales. Por ejemplo, un modal que se activa desde distintos puntos.
  • Anotaciones en diseño: En Figma, marcamos qué elementos son botones, enlaces, headings, etc. Añadimos sugerencias para etiquetas aria, roles, y el orden esperado del foco. Esto es clave para alinearse con desarrollo.
  • Guías de uso que no se quedan en el “cómo se ve”: Incluimos ejemplos de buen uso y de mal uso. Casos reales en los que algo puede parecer accesible pero no lo es en la práctica
Componente del sistema de diseño con anotaciones visuales de accesibilidad indicando el rol de cada elemento, el orden de lectura recomendado, y los nombres accesibles asignados a los botones.
Anotaciones accesibles en Figma para roles, foco y nombres de botones.

No basta con seguir WCAG, hay que intentar testear

Cumplir con los criterios WCAG es un paso importante. Nos dan una base técnica clara; contraste, estructura, roles, navegación por teclado... todo eso es fundamental, y además, se puede automatizar en parte de ellos gracias a la tokenización. Pero si te quedas solo ahí, te estás perdiendo una parte esencial del proceso.

Ahora bien, también entiendo que testear no siempre es fácil. A veces los tiempos del proyecto no lo permiten, otras veces el cliente no ve el valor inmediato o no quiere invertir en sesiones de validación. Nos pasa a todos. Pero incluso en esos contextos,intentar testear mínimamente marca la diferencia.

Y no hablo solo de testear con personas con discapacidad (que ojalá siempre se pueda hacer) sino de testear con distintos tipos de usuarios: personas mayores, gente que no usa ratón, usuarios con dificultades cognitivas o con poca experiencia digital. Cuanta más diversidad incluyamos, mejor sabremos si nuestro diseño realmente funciona para todos.

Porque al final, ese es el objetivo de la accesibilidad, que cualquier persona, con cualquier capacidad o limitación, pueda usar el producto con autonomía.

Por eso, siempre que podemos, intentamos incorporar al menos una validación general antes de cerrar un diseño. A veces es con prototipos navegables, otras con sesiones más estructuradas. Lo importante no es hacerlo perfecto, sino no olvidar para quién estamos diseñando.

Si podemos hacerlo, genial. Si no, dejémoslo planificado, documentado o al menos propuesto. Porque si no entra ahora, que al menos entre después.

Accesibilidad no como excepción, sino como parte del diseño

Una de las cosas más importantes que intento transmitir (a mi equipo, a otros diseñadores y también a los propios clientes) es que la accesibilidad no es una capa que se añade después. Es parte del diseño. Desde el principio.

De hecho, diseñar con accesibilidad desde el principio

  • No es más caro,
  • No es más lento,
  • No es más feo (De verdad, échale un vistazo a sistemas de diseño como los de Wise o GOV.UK),

No los cito como referentes absolutos de accesibilidad, porque ningún sistema lo es actualmente. Pero bajo mi punto de vista, hay muchas decisiones acertadas.

La accesibilidad requiere simplemente tenerla en mente desde la fase de definición. Como el responsive, como la marca, como cualquier otro criterio de calidad.

¿Y si no tienes un sistema de diseño completo?

No hace falta ser GOV.UK para empezar. Si tienes un equipo pequeño, o un producto en fase inicial, puedes aplicar muchas de estas prácticas

  • Asegura contraste y jerarquía tipográfica,
  • Usa HTML semántico (y no solo divs con clases),
  • Añade estados de foco visibles y consistentes,
  • Testea con teclado. Y con usuarios, si puedes,
  • Documenta cómo deben usarse los componentes, no solo cómo se ven.

Lo importante es tener un enfoque sistémico. Porque cuando tienes un sistema claro, accesible y bien documentado, la accesibilidad escala. Y se vuelve parte natural del flujo de diseño y desarrollo.

Sección de documentación en Notion donde describimos los criterios de accesibilidad según las WCAG, con ejemplos, buenas prácticas y recomendaciones.
Ejemplo de documentación de criterios WCAG en Notion.

Conclusión personal

Y sí, es cierto que ahora se habla más que nunca de accesibilidad. Hay charlas, artículos, webinars, y de repente han aparecido muchos “expertos” en la materia. A veces se nota que el tema se toca desde cierta superficialidad, y entiendo que eso puede generar rechazo en quienes llevan más tiempo con esto.

Pero también creo que hay que aprovechar este auge.

Yo recuerdo cuando entré a mi actual trabajo y empecé hablando de contrastes de color (que era más o menos lo único que sabía). En aquel momento, la accesibilidad parecía un tema lejano, incluso incómodo. Hoy puedo hablar de esto con equipos que antes ni sabían que existían leyes relacionadas. Incluso con clientes. Y sí, a veces la motivación es evitar multas, pero en muchos casos también hay una voluntad de entender y mejorar.

Gracias a esta “moda” (si se me permite decirlo así) estamos llevando el debate a más lugares, y eso es una oportunidad. Hay que cuidarla, aprovecharla y mantenerla viva. Porque el objetivo no es cumplir una norma. El objetivo es no dejar a nadie fuera. Sé que no siempre es fácil: los tiempos van justos, no todos los equipos están formados, hay clientes que no lo ven prioritario, y muchas veces el testeo con usuarios reales (especialmente con personas con discapacidad) se queda fuera del plan. Pero si de verdad queremos hacer productos accesibles, tenemos que pelear para que ese testeo entre. Porque es ahí donde realmente entendemos si lo que diseñamos funciona.

Y aunque no siempre se logre a la primera, hay que insistir, proponer, documentar, reservar ese hueco cuando se pueda. Porque cuando lo conseguimos, los resultados son evidentes. Y lo agradece todo el mundo, no solo las personas con discapacidad.

Diseñar accesible no es un lujo, ni una carga. Es un acto de responsabilidad. Y es una de esas pequeñas grandes cosas que, como diseñadores, podemos hacer para mejorar un poquito el mundo.

Y además (sí, también) tus productos serán más usables, llegarán a más personas y funcionarán mejor. Pero sobre todo, estarán mejor hechos.

Carlos Moreno, sonriente, con barba y bigote, lleva una camiseta negra y está posando frente a un fondo gris oscuro.
Carlos Moreno
Squad Lead en Stratesys, especializado en sistemas de diseño y accesibilidad en entornos digitales complejos.

Diseñador digital especializado en sistemas de diseño y accesibilidad. Actualmente trabaja como Squad Lead en Design System & Accessibility en Stratesys, donde lidera la estrategia, desarrollo e implementación de soluciones de diseño escalables, accesibles y consistentes en proyectos digitales complejos. Con amplia experiencia en formación, liderazgo de equipos y consultoría, ha impulsado la mejora de procesos, la adopción de buenas prácticas en accesibilidad y la creación de sistemas de diseño desde cero para grandes organizaciones, especialmente en entornos SAP. Además, participa activamente en la divulgación de buenas prácticas en diseño accesible dentro y fuera de su equipo, siempre con un enfoque aplicado y colaborativo. Su trabajo se basa en combinar estrategia, formación y atención al detalle para contribuir a productos digitales más usables e inclusivos..

Descubre más sobre Carlos Moreno

Preguntas frecuentes sobre Accesibilidad y Sistemas de Diseño

No. Un botón accesible puede dejar de serlo cuando forma parte de un modal mal implementado. La accesibilidad hay que evaluarla en contexto, no solo en lo visual o lo técnico.

Comparte esta página