Componentes accesibles en sistemas de diseño

Si un componente base falla en accesibilidad, el mismo fallo se copia en todo el producto. Así de simple.

Yo resumiría el tema en cinco puntos:

• La accesibilidad no va al final: debe entrar en diseño, código, contenido y pruebas desde el primer día.

• Los fallos más repetidos están en contraste, foco, teclado, semántica y nombres accesibles.

• Los datos son claros: en 2025, WebAIM detectó casi 60 millones de errores en 1 millón de páginas, y el 94,8 % tenía al menos un fallo WCAG.

• En España y la UE ya no es opcional: EN 301 549 aplica al sector público y la EAA amplía esta exigencia desde junio de 2025.

• La base mínima pasa por usar HTML semántico, foco visible, contraste correcto, reglas de contenido y pruebas con herramientas como axe-core, teclado y lector de pantalla.

En otras palabras: yo no intentaría “arreglar” la accesibilidad pantalla por pantalla. La pondría dentro de la biblioteca de componentes para cortar el problema de raíz. Si el botón, el modal o el campo de formulario nacen bien, el sistema deja de repetir errores en cada entrega.

Qué me llevaría de este artículo:

• un componente accesible no depende solo del aspecto visual;

• ARIA no sustituye al HTML nativo;

• sin documentación de uso, cada equipo aplica el componente a su manera;

• sin pruebas en el pipeline, las regresiones acaban en producción;

• sin responsables claros, el nivel baja con el tiempo.

Si yo tuviera que dejar una sola idea, sería esta: un sistema de diseño accesible no se corrige al final; se construye bien desde el inicio y se revisa en cada cambio.

Cómo tratar la accesibilidad en un Design System

Los fallos de accesibilidad más comunes en los componentes de un sistema de diseño

Los fallos de accesibilidad suelen empezar en un componente base. A partir de ahí, se copian una y otra vez en cada producto que lo reutiliza. Por eso el problema escala tan deprisa. En general, estos fallos se mueven en tres frentes: visual, teclado y contenido.

Contraste deficiente, temas inaccesibles y foco invisible

Muchas paletas de marca no llegan al ratio mínimo de 4,5:1 que pide WCAG 2.1 AA para texto normal, y los estados deshabilitados o de error suelen empeorar aún más la legibilidad. El tropiezo no está solo en el color del texto. También aparece en los estados de foco: si se eliminan o apenas se ven, quien navega solo con teclado pierde la pista de dónde está dentro de la interfaz.

Aquí es donde un sistema de diseño se la juega. Si el componente base no deja reglas claras, cada equipo acaba resolviéndolo como puede. Y cuando el paso de diseño a código no incluye contraste, foco, semántica y uso por teclado, llega la improvisación.

Flujos de teclado rotos y semántica incorrecta

Hay componentes que van bien con ratón y, sin embargo, se rompen por completo con teclado. Pasa mucho más de lo que parece. Los modales que no gestionan el foco, los menús que no responden a las flechas o los controles interactivos montados con div o span en vez de usar elementos HTML nativos son casos muy comunes.

La idea aquí es simple: el HTML semántico resuelve gran parte de la accesibilidad básica. ARIA no está para sustituirlo, sino para completar lo que HTML no cubre.

Reglas de contenido ausentes, documentación escasa y sin base de pruebas

También hay errores que nacen del contenido. Botones con solo un icono y sin aria-label, textos de enlace genéricos como "pulsa aquí" o imágenes informativas sin alt crean deuda de accesibilidad desde el primer día. Puede parecer un detalle menor, pero no lo es. Si el componente no dice bien qué hace, la experiencia se vuelve confusa.

A esto se suma otro problema: muchos sistemas de diseño no traen notas de accesibilidad por componente ni criterios de aceptación ligados a WCAG. Sin esa guía, cada equipo aplica el componente a su manera. Y si además no hay pruebas automatizadas en el pipeline, como axe-core, las regresiones terminan llegando a producción.

La corrección pasa por meter tokens, semántica y pruebas desde el inicio. No como parche, sino como parte del propio sistema.

Estos errores no suelen venir solos. Lo normal es que se mezclen y se hagan más graves entre sí.

Cómo construir componentes accesibles: soluciones para cada fallo común

Métodos de Prueba de Accesibilidad: Cobertura, Esfuerzo e Impacto

La clave no está en ir apagando fuegos uno a uno. Está en fijar reglas reutilizables para que el mismo fallo no vuelva a aparecer en todo el sistema. Si esas reglas viven en los tokens, la semántica, la documentación y las pruebas, el trabajo deja de ser parchear y pasa a ser prevenir.

Define sistemas de tokens e interacciones que pasen las comprobaciones de accesibilidad

Crea tokens semánticos para texto, fondo, borde y estados como error, éxito y advertencia. Después, valida cada uno con los ratios de WCAG 2.1 AA: 4,5:1 para texto normal y 3:1 para texto grande o componentes de interfaz como iconos y bordes.

También conviene dejar por escrito los estados de interacción: hover, foco, activo y deshabilitado. El foco debe verse con claridad. Para eso, define :focus-visible y usa un mínimo de 2 px. En pestañas y grupos de botones de opción, aplica roving tabindex para que la navegación con teclado siga una lógica clara y estable.

Cuando los tokens ya están bien resueltos, la base del componente debe apoyarse primero en la semántica y después en lo visual.

Usa HTML semántico primero y aplica ARIA solo donde añada valor

El HTML nativo resuelve buena parte de la accesibilidad antes de tocar ARIA. Usa <button> para acciones y <a> para navegación. Marca las zonas de la página con <nav>, <header>, <main> y <footer>. Y, si tienes campos relacionados, agrúpalos con <fieldset> y <legend>.

ARIA entra en juego solo cuando HTML no llega. Por ejemplo:

• aria-label en botones que solo muestran un icono

• aria-describedby para enlazar un campo con su mensaje de error

• aria-live="polite" para anunciar cambios dinámicos

Meter ARIA porque sí puede salir caro. A veces, en lugar de arreglar el problema, mete otros nuevos.

La accesibilidad no aguanta solo con buen marcado. Si la guía de uso y las pruebas no acompañan al componente, tarde o temprano algo se rompe.

Documenta el uso y prueba cada componente desde el inicio

Cada página de componente debería incluir, como poco, el nombre accesible que se exige, las reglas de contenido, ejemplos de uso correcto e incorrecto, y los atajos o teclas de uso, por ejemplo «Enter o Espacio para activar». Y las pruebas deben entrar en el ciclo desde el principio, no cuando ya está todo hecho.

Resumen de cobertura por método:

Lo normal es combinar pruebas automáticas, manuales y con usuarios según la criticidad del componente. Así cierras el control de calidad antes de publicarlo.

Gobernanza y flujo de trabajo: cómo los equipos mantienen los componentes accesibles con el tiempo

Cuando un componente ya está documentado y probado, el trabajo no se acaba ahí. A partir de ese momento, lo importante es mantener ese nivel en cada entrega. Si no hay un proceso claro de revisión y aprobación, el contraste, el foco y la semántica acaban deteriorándose poco a poco.

Asigna responsabilidades de revisión entre diseño, desarrollo y accesibilidad

La forma más simple de evitarlo es repartir bien la responsabilidad desde el principio:

Cuando cada rol sabe qué le toca, es mucho más fácil detectar fallos antes de que lleguen a producción. Y también evita ese problema tan común: que todo el mundo piense que “ya lo revisará otro”.

Elige un modelo de gobernanza que mantenga la calidad a escala

Después, toca decidir quién aprueba los cambios y cómo se mantienen con el paso del tiempo. Aquí suele haber dos caminos:

El modelo centralizado suele encajar mejor cuando lo primero es la consistencia. Hay una sola referencia y queda claro quién decide. La pega es evidente: si todo pasa por el mismo equipo, ese equipo puede frenar el ritmo.

El modelo distribuido da más margen a cada equipo para avanzar por su cuenta. Va mejor cuando hay referentes de accesibilidad dentro de cada equipo, pero pide mucha coordinación. Si esa coordinación falla, aparecen diferencias entre componentes que deberían comportarse igual.

Conecta la accesibilidad entre el handoff de Figma, el desarrollo y el mantenimiento

El handoff no sirve de mucho si la especificación no deja claro qué tiene que respetar el código. No basta con enseñar el aspecto visual. La documentación debe indicar rol, estado y navegación, porque Figma no resuelve eso por sí solo.

También conviene trabajar con variantes y tokens ya aprobados, evitar cambios improvisados y revisar el comportamiento en cada actualización. Si no existe ese circuito de revisión, los mismos errores vuelven una y otra vez en cada entrega.

Conclusión: el sistema mínimo para evitar problemas de accesibilidad recurrentes

Después de revisar fallos, soluciones y gobernanza, la idea central queda bastante clara: un sistema de diseño accesible se decide desde el principio. No se arregla al final ni se deja para una revisión de última hora. Empieza con semántica correcta, buen contraste, interacción cuidada y pruebas desde el arranque.

Los errores, además, no aparecen en lugares raros. Se repiten una y otra vez en botones, formularios, enlaces y estados de foco, justo donde el sistema debería aguantar mejor.

En España, la accesibilidad no es opcional. Pasarla por alto hace que los mismos fallos vuelvan en cada entrega y en cada equipo que usa esos componentes. Es el típico problema que se arrastra sprint tras sprint.

La base mínima no tiene misterio:

• semántica correcta

• foco visible

• contraste suficiente

• documentación clara sobre uso con teclado y lectores de pantalla

• pruebas repetidas con responsabilidades bien definidas

Si el componente nace bien, el sistema deja de ir sembrando errores por todas partes.

FAQs

¿Por dónde empezar si mi sistema ya tiene componentes con fallos?

Empieza por tratar la accesibilidad como una parte básica de la calidad, no como un añadido de última hora. El primer paso suele estar en lo más simple: revisar el HTML semántico y comprobar que el contraste de color de tus componentes sea correcto.

A partir de ahí, conviene pulir varios puntos que marcan la diferencia en el día a día:

• navegación por teclado y gestión del foco

• etiquetas ARIA con sentido

• tratamiento accesible de los errores

• validación automatizada en tu CI para evitar regresiones

Dicho de forma simple: si la base falla, todo lo demás cojea. Un botón que parece un botón, pero no lo es en el HTML, acaba dando problemas. Y un formulario con errores mal comunicados frustra al usuario en segundos.

¿Qué componentes conviene revisar primero?

Conviene revisar primero el HTML semántico, porque aporta cerca del 70 % de la accesibilidad casi “de serie”.

Además, deja una base firme antes de sumar otras capas, como ARIA.

¿Cada cuánto hay que auditar la accesibilidad?

Se recomienda revisar la accesibilidad de forma regular durante todo el proceso de diseño y desarrollo.

Así es mucho más fácil detectar fallos y corregirlos cuanto antes, en lugar de encontrarlos al final cuando todo cuesta más tiempo y más trabajo.

Publicaciones de blog relacionadas

• Checklist: Lanzar tu Web en Menos de 12 Semanas

• Cómo Mejorar el UX/UI de tu Aplicación Web

• Cómo Medir el Éxito de un Sistema de Diseño

• Checklist para implementar design tokens en tu app