¿Qué son los sistemas de diseño para la accesibilidad?
Un sistema de diseño accesible integra teclado, contraste y ARIA en componentes reutilizables. Qué incluye, un ejemplo y por qué no basta solo.
¿Qué es un sistema de diseño para la accesibilidad?
Un sistema de diseño es una biblioteca compartida de componentes, tokens de diseño y reglas de uso que los equipos reutilizan en todo el producto. Es "para la accesibilidad" cuando cada componente se construye y se prueba una sola vez para cumplir requisitos como operación con teclado, foco visible, contraste suficiente y etiquetas correctas, de modo que cada equipo que lo usa hereda ese trabajo en lugar de repetirlo.
Qué contiene un sistema de diseño accesible
- Tokens de diseño: pares de colores comprobados frente a los umbrales de contraste de las WCAG, véase paletas de color accesibles, además de estilos de foco, espaciados y tamaños mínimos de los elementos pulsables.
- Componentes con comportamiento integrado: botones, campos de formulario, menús y diálogos que funcionan con el teclado, gestionan el foco y exponen el rol, el nombre y el estado correctos a las tecnologías de apoyo.
- Guías: cuándo usar cada componente, cómo redactar etiquetas y mensajes de error, y cuándo recurrir a ARIA solo porque el HTML nativo no basta.
- Un registro de pruebas: qué se comprobó, con qué herramientas y qué sigue abierto.
Ejemplo
Un diálogo modal es fácil de hacer mal: el foco debe entrar en él, permanecer dentro mientras está abierto, volver al elemento que lo abrió al cerrarse, y Escape debe cerrarlo. Si eso se construye y se prueba una vez en el componente de diálogo del sistema, todas las pantallas que lo usan obtienen el comportamiento, incluido el orden de navegación por teclado. Lo mismo vale para un campo de formulario con su etiqueta, su ayuda y su mensaje de error vinculados.
El U.S. Web Design System es un ejemplo público. Apunta a WCAG 2.1 AA, prueba los componentes con lectores de pantalla, uso solo con teclado, zoom y táctil, y ejecuta análisis automáticos en cada cambio de código.
Errores comunes
- Suponer que los componentes hacen accesible el producto. El U.S. Web Design System afirma con claridad que usar componentes accesibles no garantiza un servicio accesible. El diseño de página, el contenido, los encabezados y el flujo siguen siendo cosa tuya.
- Corregir los componentes en una app y no en el sistema. La corrección se pierde para el resto de equipos.
- Sobrescribir los estilos de los componentes. Un cambio de color local puede romper el contraste, y quitar el contorno de foco rompe el uso con teclado.
- No documentar el uso accesible. Un buen componente usado como otro elemento sigue fallando.
- Probar solo con herramientas automáticas. Detectan solo una parte de los problemas; véanse las pruebas automatizadas de accesibilidad, y añade revisiones manuales y con tecnologías de apoyo.
Relación con las pruebas y la monitorización
Prueba cada componente por separado y después páginas reales construidas con ellos, porque la accesibilidad puede romperse en la combinación. Las comprobaciones automáticas en la integración continua detectan regresiones tras un cambio. La monitorización de velocidad de página de LoadFocus registra de forma programada la puntuación de Accesibilidad de Lighthouse desde 25 regiones en la nube, así que una caída tras un despliegue se ve. Esa puntuación es una señal automática, no una prueba de conformidad. Sobre cómo conviven accesibilidad y velocidad en las pruebas, consulta performance testing y métricas de accesibilidad (en inglés).
Preguntas frecuentes: sistemas de diseño para la accesibilidad
¿Un sistema de diseño hace accesible mi sitio?
No. Elimina muchos errores repetidos a nivel de componente, pero la estructura de la página, el contenido y los flujos necesitan sus propias comprobaciones.
¿Qué estándar debe seguir un sistema de diseño?
La mayoría de equipos apunta a WCAG 2.1 o 2.2 nivel AA. El U.S. Web Design System, por ejemplo, apunta a 2.1 AA y avanza hacia criterios de 2.2.
¿Quién es responsable de la accesibilidad en un sistema de diseño?
El equipo del sistema responde del comportamiento y la documentación de los componentes. Los equipos de producto responden de cómo se combinan en páginas y de su contenido.
¿Cómo pruebo un componente accesible?
Combina análisis automáticos, uso solo con teclado, una pasada con lector de pantalla y comprobaciones de zoom. Repítelo tras cada cambio del componente.
Términos relacionados
- ¿Qué son los trastornos desencadenados por el movimiento en el software?
- ARIA: Accessible Rich Internet Applications
- ¿Qué son las pruebas de accesibilidad automatizadas?
- ¿Qué es la experiencia de usuario (UX)? Definición, pilares, ejemplos
- Pruebas de conformidad de accesibilidad (ACT) explicadas
- Definición de accesibilidad: qué significa en tecnología
- Tecnología de apoyo (AT): definición, tipos y ejemplos web
- Pruebas manuales de accesibilidad
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus, la misma plataforma que potencia todo lo que acabas de leer.