En proyectos reales, la accesibilidad rara vez se rompe por desconocimiento técnico. Se rompe por decisiones de diseño acumuladas, pequeñas concesiones que parecen inocuas y que, con el tiempo, generan barreras difíciles de revertir.

No siempre es un problema de ARIA o de roles mal usados. Muchas veces es deuda de diseño.

---

¿Qué entendemos por deuda de diseño?

Igual que la deuda técnica, la deuda de diseño aparece cuando se prioriza avanzar rápido sin pensar en la sostenibilidad del sistema visual.

Algunos síntomas comunes:

- Componentes únicos “solo para esta pantalla”
- Estados no documentados
- Excepciones visuales constantes
- Decisiones tomadas por estética puntual

Cada decisión aislada parece razonable. El problema aparece cuando el sistema crece.

---

Cuando el diseño complica la accesibilidad

Muchas barreras de accesibilidad nacen antes de escribir una línea de código.

Ejemplos habituales:

- Contrastes ajustados al límite “porque queda más limpio”
- Componentes sin estados claros (hover, focus, disabled)
- Interacciones implícitas no documentadas
- Dependencia excesiva del color o de la animación

El código solo ejecuta una decisión que ya venía rota.

---

Componentes imposibles de escalar

Un componente visual puede funcionar en un contexto concreto y fallar estrepitosamente al reutilizarse.

Señales de alerta:

- El componente necesita overrides constantes
- Cada uso requiere ajustes de contraste
- El foco se “arregla” caso a caso
- La accesibilidad depende del contexto

Eso no es flexibilidad, es deuda acumulada.

---

Diseño sin estados = experiencia frágil

Uno de los errores más comunes es diseñar solo el estado “ideal”.

¿Qué suele faltar?

- Estados de error
- Estados disabled reales
- Estados de carga
- Estados vacíos

Cuando estos estados no existen en diseño, aparecen improvisados en desarrollo… y casi siempre rompen la accesibilidad.

---

Accesibilidad como síntoma, no como causa

Cuando una auditoría detecta muchos problemas, el error no suele estar en el último commit.

Suele estar en:

- Sistemas visuales incompletos
- Falta de criterios compartidos
- Decisiones no documentadas
- Diseño y desarrollo desconectados

La accesibilidad revela problemas estructurales que ya existían.

---

Checklist rápido para detectar deuda de diseño

Antes de que el problema llegue al código, revisa:

- ¿El sistema define todos los estados del componente?
- ¿Los contrastes están pensados por rol, no por color?
- ¿El foco forma parte del diseño visual?
- ¿El componente funciona sin animaciones?
- ¿Puede escalar sin ajustes manuales?

Si alguna respuesta es “depende”, hay deuda.

---

Cómo reducirla (sin frenar al equipo)

No se trata de diseñar más, sino de diseñar mejor:

- Sistemas visuales claros y limitados
- Estados definidos desde el inicio
- Accesibilidad como criterio de diseño
- Documentación viva, no decorativa

La accesibilidad no ralentiza. Lo que ralentiza es arreglarla tarde.

---

Conclusión

Muchos problemas de accesibilidad no se solucionan con más código, sino con mejores decisiones de diseño.

Cuando el diseño es consistente, los componentes escalan. Cuando los componentes escalan, la accesibilidad aparece casi sola.

La deuda de diseño no se ve…
hasta que empieza a costar tiempo, dinero y usuarios.