Design systems accesibles: componentes, documentación y tokens

Un design system (sistema de diseño) es el conjunto de componentes, estilos, reglas y documentación que una organización reutiliza en todos sus productos. Es la palanca más potente para la accesibilidad: si el botón, el campo de formulario, el diálogo y la pestaña del sistema son accesibles, cientos de pantallas lo serán sin esfuerzo adicional; si no lo son, cientos de pantallas heredarán los mismos fallos. En esta lección verás qué hace accesible a un design system en sus tres capas (componentes, documentación y tokens) y cómo gobernarlo.

Capa 1: componentes

Un componente accesible es uno que funciona con teclado, expone nombre, rol, estado y valor correctos a las tecnologías de apoyo, y cumple los requisitos visuales (contraste, foco, tamaño). Las reglas de construcción:

HTML nativo primero

Antes de crear un componente personalizado, pregúntate si un elemento nativo lo resuelve: <button>, <a>, <select>, <details>, <dialog>, <input type="checkbox">. Los elementos nativos traen gratis el comportamiento de teclado, la semántica y el soporte de las tecnologías de apoyo. La primera regla de ARIA dice precisamente eso.

Patrones APG para lo que no es nativo

Para pestañas, acordeones, menús, cuadros combinados, deslizadores o árboles, sigue el patrón correspondiente de la ARIA Authoring Practices Guide (se abre en una ventana nueva) (APG) del W3C: define roles, estados, propiedades y, sobre todo, la interacción con teclado esperada (flechas para moverse entre pestañas, Inicio y Fin, Esc para cerrar). Un componente que inventa su propio teclado es un componente que nadie sabe usar.

Estados completos y foco gestionado

Cada componente define sus estados (reposo, hover, foco, activo, deshabilitado, error, cargando, seleccionado) con contraste verificado, y gestiona el foco cuando corresponde: un diálogo lleva el foco dentro al abrirse, lo retiene y lo devuelve al elemento que lo abrió al cerrarse.

<div class="icon-btn" onclick="cerrar()">
  <svg>…</svg>
</div>

<button type="button" class="icon-btn" aria-label="Cerrar">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

Capa 2: documentación

Un componente accesible mal usado produce una pantalla inaccesible. La documentación de cada componente debe incluir una sección de accesibilidad con, al menos:

• Cuándo usarlo y cuándo no: un enlace navega, un botón actúa; un diálogo modal solo para tareas que exigen atención exclusiva.
• Interacción con teclado: tabla de teclas y comportamiento.
• Semántica expuesta: rol, nombre, estados y cómo se calculan (qué propiedad alimenta aria-label, cuándo se usa aria-describedby).
• Propiedades obligatorias de accesibilidad: por ejemplo, label en campos, alt en imágenes, title en diálogos.
• Criterios WCAG relacionados y cómo el componente los cumple.
• Lo que el consumidor debe hacer: el componente no puede decidir el texto del botón, el orden en la página ni el contexto; la documentación lo señala.
• Pruebas realizadas: con qué navegadores y tecnologías de apoyo se ha verificado, y fecha.

Capa 3: tokens

Los design tokens son los valores de diseño con nombre (colores, tamaños, espaciados, tipografías) que comparten diseño y código. Son el lugar ideal para fijar la accesibilidad de forma estructural:

• Color: define los pares permitidos (texto sobre fondo) y verifica su contraste en la propia definición de tokens. Un token color-text-on-primary solo existe si cumple 4,5:1 sobre color-primary. Incluye tokens para el modo oscuro y para el modo de colores forzados.
• Foco: un token focus-ring (color, grosor, desplazamiento) que todos los componentes consumen, con contraste ≥ 3:1 frente a los fondos adyacentes (2.4.7 Foco visible exige que el foco se vea; el umbral de 3:1 procede de 1.4.11 Contraste no textual y, para quien quiera ir más allá, de 2.4.13 Apariencia del foco, nivel AAA).
• Tamaño: tokens de tamaño mínimo de objetivo (target-min: 24px, target-comfortable: 44px) y de espaciado entre objetivos.
• Tipografía: tamaños en unidades relativas (rem), interlineado mínimo 1,5 en párrafos, y nada que impida a la persona ampliar el espaciado del texto (1.4.12 Espaciado del texto).
• Movimiento: token de duración de animación que se anula bajo prefers-reduced-motion.

:root {
  --color-primary: #0b4f8a;
  --color-text-on-primary: #ffffff; /* 8,4:1 sobre primary */
  --focus-ring-color: #1a1a1a; /* 17,4:1 sobre el fondo blanco */
  --focus-ring-width: 3px;
  --target-min: 24px;
  --motion-duration: 200ms;
}
@media (prefers-reduced-motion: reduce) {
  :root { --motion-duration: 0ms; }
}
:focus-visible {
  outline: var(--focus-ring-width) solid var(--focus-ring-color);
  outline-offset: 2px;
}

Pruebas y gobernanza del design system

Cada componente del sistema debería tener pruebas automáticas de accesibilidad (axe-core sobre sus estados, por ejemplo con Storybook y su complemento de accesibilidad o con pruebas unitarias) y una revisión manual documentada con teclado y lector de pantalla antes de publicarse. Las versiones se gestionan con un registro de cambios que señala cualquier modificación de accesibilidad.

La gobernanza define quién puede añadir un componente, qué revisión pasa, cómo se solicitan cambios y cómo se retiran componentes inaccesibles. Un modelo habitual es un equipo núcleo pequeño con un comité de contribución en el que participa la persona responsable de accesibilidad. Mide la adopción: el porcentaje de pantallas construidas con componentes del sistema frente a componentes a medida es un indicador directo del riesgo.

Resumen

• Un design system accesible multiplica la accesibilidad: componentes nativos cuando existen y patrones APG cuando no, con todos los estados y la gestión del foco resuelta.
• La documentación de cada componente incluye cuándo usarlo, teclado, semántica, propiedades obligatorias, criterios WCAG, lo que debe hacer el consumidor y las pruebas realizadas.
• Los tokens fijan la accesibilidad de forma estructural: pares de color con contraste verificado, anillo de foco único, tamaño mínimo de objetivo y movimiento respetuoso con las preferencias del usuario.
• Gobernanza y pruebas por componente evitan la degradación; mide la adopción del sistema como indicador de riesgo.