Guía práctica para construir un sistema de diseño accesible: especificaciones de componentes, diseño de tokens, criterios de aceptación WCAG 2.1 AA y gobernanza continua

Resumen (puntos clave primero)

• La accesibilidad es más sólida cuando está protegida por sistemas, no por el esfuerzo individual. Convertirla en un sistema de diseño es el camino más corto.
• La clave del éxito es construir en este orden: (1) tokens de diseño (color/espaciado/tipografía/foco) → (2) especificaciones de componentes (interacción/estados/textos) → (3) criterios de aceptación (comprobables) → (4) operaciones (gobernanza).
• Intentar saltar directamente a AAA agota a los equipos. Empieza incorporando las áreas más propensas a errores de WCAG 2.1 AA (formularios, modales, pestañas, menús, tablas, vídeo) en componentes estándar.
• Este artículo incluye una plantilla de especificación de componentes, ejemplos de tokens, cómo escribir criterios de aceptación de accesibilidad, reglas operativas y una prueba rápida de 5 minutos.

Lectores previstos (ejemplos): diseñadores UI/UX, ingenieros frontend, PMs/directores, QA, especialistas en accesibilidad, responsables de estandarización en agencias, equipos de operaciones multiproducto
Nivel de accesibilidad: orientado a cumplimiento WCAG 2.1 AA (incluyendo operaciones de mejora continua)

1. Introducción: la accesibilidad se vuelve más fácil cuando se estandariza

Cuanto más cuidadosamente intentas hacer la accesibilidad “de la manera correcta”, más tiende a depender del esfuerzo y la experiencia individuales.
“¿Cómo anunciamos los errores en este formulario?” “¿Dónde debe volver el foco después de cerrar un modal?” “¿Cómo añadimos significado más allá del color?”: si empiezas desde cero cada vez, el tiempo y el coste aumentan, y la calidad fluctúa cuando cambia la persona responsable.

Ahí es donde brilla un sistema de diseño accesible.
Integras los requisitos de accesibilidad en tokens (color/espaciado/foco) y componentes (botones/formularios/modales) desde el principio. Luego, incluso cuando los productos crecen, las páginas se multiplican y se publican actualizaciones, la “amabilidad” tiene muchas menos probabilidades de romperse.
Esta guía no es solo idealista: está escrita para ser práctica y operativa, desde el diseño hasta la gobernanza.

2. La visión general: construir un sistema de diseño accesible en cuatro capas

Estandarizar la accesibilidad es más fácil cuando se apila en este orden:

2.1 Capa 1: Tokens de diseño

• Colores (fondo/texto/enlace/borde/foco)
• Tipografía (tamaño/altura de línea/peso)
• Espaciado (relleno/márgenes)
• Radio, sombras, bordes
• Movimiento (intensidad y ajustes de “reducir movimiento”)

Objetivo: fijar las bases no solo para la coherencia, sino también para el contraste, la visibilidad del foco y el tamaño de los objetivos.

2.2 Capa 2: Especificaciones de componentes

• Estructura (HTML/ARIA básicos)
• Interacción (comportamiento de teclado, transiciones de foco)
• Estados (hover/foco/deshabilitado/error/seleccionado)
• Reglas de texto (etiquetas, texto de ayuda, texto de error)
• Casos límite (carga, estados vacíos, cero resultados)

Objetivo: mantener la experiencia consistente incluso cuando cambian los implementadores.

2.3 Capa 3: Criterios de aceptación

Definir el comportamiento en términos de resultados, no solo de “números WCAG”.
Ejemplos:
“El proceso de compra puede completarse usando solo Tab.” “El foco se mueve al resumen de errores.” “Esc cierra y el foco vuelve al disparador.”

Objetivo: hacer que las revisiones no sean subjetivas y dar a QA e ingeniería un lenguaje compartido.

2.4 Capa 4: Operaciones y gobernanza

• Gestión de cambios (cambios incompatibles, versionado)
• Auditorías (revisiones trimestrales en pantallas representativas)
• Canal de soporte (punto de contacto de accesibilidad)
• Educación (onboarding, listas de verificación)

Objetivo: pasar de “lo intentamos una vez” a “podemos mantenerlo seguro para siempre”.

3. Diseño de tokens: integrar los requisitos de accesibilidad desde el inicio

3.1 Tokens de color: pasar de “comprobaciones manuales” a “seguridad integrada”

El color es flexible y, por tanto, fácil de romper. Un enfoque sólido es definir tokens de color por propósito:

• --color-bg (fondo)
• --color-fg (texto principal)
• --color-muted (texto secundario)
• --color-link (enlaces)
• --color-border (bordes)
• --color-focus (anillo de foco)
• --color-danger (error)
• --color-success (éxito)

Luego documentar explícitamente estas suposiciones a nivel de token:

• El contraste del texto principal es ≥ 4.5:1 (texto normal)
• El contraste del texto grande es ≥ 3:1
• El contraste de elementos no textuales (bordes, iconos, foco) es ≥ 3:1
• Los enlaces no deben depender solo del color (combinarlos con subrayado, etc.)

3.2 Tokens de foco: hacer del foco visible una característica por defecto

Si los anillos de foco se dejan “al gusto de cada producto”, se eliminan.
Por eso hay que fijarlos como tokens.

:root{
  --focus-color: #FF9900;
  --focus-width: 3px;
  --focus-offset: 3px;
}
:focus-visible{
  outline: var(--focus-width) solid var(--focus-color);
  outline-offset: var(--focus-offset);
}
@media (prefers-contrast: more){
  :focus-visible{ outline-width: 4px; }
}

3.3 Espaciado y tamaño de objetivo: crear “clicabilidad” con padding

Para botones y casillas, el “área tocable” importa más que lo visual.

• Regla general: ~44px de altura equivalente (especialmente en móvil)
• Asegúrate de que el área clicable incluya padding (no hagas clicable solo el texto)

3.4 Movimiento: usar movimiento “suave” por defecto

Los esqueletos y animaciones de carga pueden aumentar la carga cognitiva o el mareo.

• Por defecto: más lento, menor contraste, sin parpadeos
• Respetar prefers-reduced-motion: reduce (detener o reducir significativamente)

4. Especificaciones de componentes: convertir la accesibilidad en un plano

Aquí tienes una “forma de especificación” reutilizable que puedes aplicar a cada componente.

4.1 Plantilla de especificación recomendada (secciones)

1. Propósito: para qué sirve el componente
2. Estructura: elementos HTML base; supuestos ARIA si se usan
3. Estados: por defecto / hover / foco / deshabilitado / error / seleccionado
4. Comportamiento de teclado: Tab, flechas, Enter/Espacio, Esc, Inicio/Fin
5. Gestión del foco: foco inicial, retorno del foco, reglas de atrapamiento
6. Reglas de texto: etiquetas, texto de ayuda, cómo escribir errores
7. Comportamiento responsive: comportamiento en pantallas estrechas
8. Patrones prohibidos: casos comunes de fallo
9. Criterios de aceptación: declaraciones comprobables
10. Ejemplos: implementación mínima, ejemplos buenos vs malos

Cuando cada componente usa la misma plantilla, las revisiones se vuelven mucho más fáciles.

5. Especificaciones estándar para componentes de alto impacto (donde más compensa)

5.1 Botón

Estructura

• Usar <button> por defecto (no construir divs clicables)
• Los botones solo con icono deben tener aria-label

Teclado

• Tab para enfocar
• Enter/Espacio activan

Criterios de aceptación (ejemplos)

• El botón puede activarse con el teclado
• El foco es visible (en temas claros y oscuros)
• El estado deshabilitado usa el atributo disabled, no solo la apariencia

Ejemplo

<button type="button">Guardar</button>

<button type="button" aria-label="Cerrar">
  <img src="close.svg" alt="">
</button>

5.2 Campos de formulario (TextField / Select / Checkbox)

(Los formularios son de alto riesgo, por lo que la estandarización ofrece el mayor beneficio.)

Estructura

• Conectar siempre label y for
• Vincular ayudas mediante aria-describedby
• Los errores usan aria-invalid="true" + asociación del texto de error

Reglas de texto

• Los errores deben indicar: “dónde / por qué / cómo corregir”
• Requerido/opcional debe ser explícito en la etiqueta (no depender solo del color)

Criterios de aceptación (ejemplos)

• Existe una etiqueta visible y el nombre del campo es claro para lectores de pantalla
• Cuando hay errores, aparece un resumen y el foco puede moverse al primer error
• autocomplete es apropiado (correo, dirección, nombre, etc.)

Ejemplo

<div class="field">
  <label for="email">Correo electrónico (obligatorio)</label>
  <input id="email" type="email" autocomplete="email"
         aria-describedby="email-hint email-err"
         aria-invalid="true">
  <p id="email-hint">Ejemplo: ejemplo@ejemplo.com</p>
  <p id="email-err" class="error" role="alert">El formato no es válido.</p>
</div>

5.3 Modal (diálogo)

Estructura

• Preferir <dialog> nativo si es posible; si no, implementar con role="dialog"
• Hacer el fondo inerte (inert cuando esté soportado; proporcionar alternativas)

Gestión del foco

• Al abrir: mover el foco al primer elemento accionable
• Tab circula dentro del modal (trampa)
• Esc cierra
• Al cerrar: devolver el foco al disparador

Criterios de aceptación (ejemplos)

• Mientras está abierto, el foco no se mueve a elementos de fondo
• Esc cierra y el foco vuelve al botón disparador original
• El título del diálogo se anuncia (se proporciona un nombre)

5.4 Pestañas y menús

Reglas estándar

• Tab: moverse entre regiones; flechas: moverse dentro de una región (tabindex rotativo)
• Inicio/Fin: saltar al primero/último
• Exponer el estado de selección (p. ej., aria-selected)

Criterios de aceptación (ejemplos)

• Las flechas se mueven a las pestañas adyacentes
• La pestaña seleccionada es identificable en la salida del lector de pantalla
• Mostrar/ocultar paneles no rompe el diseño ni la semántica

5.5 Tabla

(Un “componente estándar” potente, especialmente junto con tu artículo previo.)

Estructura

• Las celdas de encabezado usan th
• Usar scope por defecto; para tablas complejas, usar headers/id o dividir tablas
• Usar caption para describir el propósito de la tabla

Criterios de aceptación (ejemplos)

• Al navegar por celdas con un lector de pantalla, los encabezados son claros
• En móvil, la información no se pierde (p. ej., desplazamiento horizontal en lugar de truncar)

5.6 Carga y notificaciones (estado/alerta)

Reglas estándar

• Los errores críticos usan role="alert"
• El éxito/finalización usa role="status" (evitar interrupciones excesivas)
• Los spinners son aria-hidden="true" y se proporciona texto como “Cargando…”

Criterios de aceptación (ejemplos)

• El estado de carga es comprensible mediante texto
• El movimiento se detiene o se reduce significativamente con prefers-reduced-motion

6. Redacción de criterios de aceptación: priorizar “resultados” frente a solo IDs WCAG

Los criterios de aceptación son el lenguaje que crea alineación en el equipo.
Si solo enumeras IDs WCAG, los equipos suelen preguntar “¿qué probamos exactamente?”. El siguiente formato funciona bien.

6.1 Formato recomendado de criterios de aceptación

• Contexto: qué pantalla/componente
• Acción: qué hace el usuario (Tab, flechas, Enter, Esc, etc.)
• Resultado esperado: qué debería ocurrir (foco, anuncio, cambio de estado)
• Excepciones: documentar cualquier excepción (contenido de terceros incrustado, etc.)

Ejemplo (Modal)

• Acción: pulsar Enter en el botón Ajustes para abrir el modal
• Resultado esperado: el foco se mueve al primer elemento accionable dentro del modal
• Acción: pulsar Esc
• Resultado esperado: el modal se cierra y el foco vuelve al botón Ajustes

Esto hace que diseñadores, desarrolladores y QA hablen el mismo idioma.

7. Revisión de diseño vs revisión de implementación: qué comprobar en cada una

7.1 Revisión de diseño (Figma, etc.)

• Contraste (texto/enlaces/no textuales)
• Visibilidad del anillo de foco (incluido en fondos complejos)
• Estados (hover/foco/deshabilitado/error/seleccionado)
• Objetivos táctiles (~44px)
• Texto (etiquetas, ayuda, redacción de errores)
• No depender solo del color (combinar con iconos/texto)

7.2 Revisión de implementación

• Preferir elementos nativos (button, a, input)
• Landmarks y jerarquía de encabezados
• ¿Puede completarse el flujo solo con teclado?
• Corrección de ARIA (demasiado ARIA también es un fallo)
• Transiciones de foco (modal/menú/estados de error)

8. La prueba rápida de 5 minutos: convertirla en un “ritual” del sistema de diseño

Un conjunto mínimo de pruebas compartidas, aplicado a nivel de componente, evita regresiones.

1. Los flujos principales pueden completarse usando solo Tab
2. El foco es visible (temas claro/oscuro)
3. Modal: abrir → interactuar → Esc → el foco vuelve
4. Formularios: etiqueta + indicador de requerido + resumen de errores + asociación de error por campo
5. El significado no depende solo del color (enlaces, errores, estados)
6. No hay roturas al 200% de zoom (excepto tablas/código según se indique)
7. El movimiento se reduce con prefers-reduced-motion
8. Los lectores de pantalla pueden identificar al menos nombre/rol/estado

9. Operaciones y gobernanza: mantener el sistema de diseño “usado y mantenido”

9.1 Gestión de cambios (versionado)

• Cambios incompatibles (p. ej., cambio de API del modal) = versión mayor
• Pequeñas mejoras (adiciones de texto, mejoras menores) = versión menor/parche
• Escribir primero “qué mejoró” en las notas de versión (ayuda a la adopción)

9.2 Excepciones (cuando realmente no se puede cumplir)

No puedes hacer desaparecer las excepciones. La clave es estandarizar cómo se gestionan:

• Solicitud de excepción (motivo, impacto, alternativas, solución planificada)
• Añadir una fecha límite (evitar excepciones permanentes)
• Enlazar a declaraciones de accesibilidad/canales de contacto (evitar el abandono)

9.3 Roles (configuración mínima)

• Responsable: decide política y prioridad
• Mantenedores: actualizan componentes y documentación
• Revisores: comprueban criterios de aceptación
• Contacto de soporte: recoge problemas y los convierte en mejoras

Puedes empezar pequeño, pero sin roles acabará deteriorándose inevitablemente.

10. Valor por rol (beneficios concretos)

• Diseñadores: menos incertidumbre; estados/foco/textos estandarizados aceleran la creación
• Ingenieros: patrones estandarizados de ARIA y gestión del foco reducen regresiones
• QA: criterios basados en resultados hacen la verificación reproducible
• PM/Ops: la calidad se mantiene estable a medida que crecen los productos; se acumulan responsabilidad y confianza
• Usuarios: interacción consistente entre pantallas; caminos claros cuando algo falla

11. Evaluación del nivel de accesibilidad (lo que logra esta guía)

Esta guía se centra en diseño + operaciones que cumplen continuamente WCAG 2.1 AA, alineándose especialmente con:

• 1.1.1 Contenido no textual: estandarización del manejo de iconos/imágenes
• 1.3.1 Información y relaciones: formularios/tablas/encabezados/landmarks estructurados
• 1.4.1 Uso del color / 1.4.3 Contraste / 1.4.11 Contraste no textual: aplicados mediante tokens
• 1.4.10 Reflujo: definido en las especificaciones responsive de componentes
• 2.1.1 Teclado: interacción estandarizada de componentes
• 2.4.3 Orden del foco / 2.4.7 Foco visible: fijados mediante tokens y especificaciones de foco
• 3.3.x Ayuda en la entrada: patrones estandarizados de mensajes de error y prevención
• 4.1.2 Nombre, rol, valor: uso mínimo y correcto de ARIA
  Al incluir pruebas y gobernanza, no apunta a un “cumplimiento puntual”, sino a un cumplimiento mantenible.

12. Conclusión: convertir la amabilidad en componentes y en fortaleza del equipo

1. La accesibilidad se vuelve poderosa cuando se integra en tokens y componentes.
2. Las especificaciones deben agrupar estructura, interacción, estados, textos y criterios de aceptación.
3. Los criterios de aceptación deben priorizar resultados comprobables sobre IDs WCAG.
4. Haz de la prueba rápida de 5 minutos un ritual para evitar regresiones.
5. Gestiona las excepciones con solicitudes y plazos; no dejes a los usuarios atrás.
6. Con operaciones y gobernanza, la accesibilidad perdura y la confianza se acumula.

La accesibilidad es más hermosa cuando no es “especial”, sino parte de los estándares cotidianos.
Que la “amabilidad” de tu equipo continúe de forma natural junto con el crecimiento de tu producto.