El proyecto no comenzó como mejora interna.
Llegó tras una auditoría externa para un cliente importante.

El informe señalaba múltiples incumplimientos y debilidades estructurales. No era una optimización opcional. Era una corrección obligatoria bajo presión, con deadlines definidos y exposición directa ante stakeholders.

El equipo era pequeño:
un frontend developer y dos maquetadores.
Asumí la coordinación técnica del proceso.

No fue perfecto desde el primer día.

Descomponer la auditoría sin colapsar al equipo

La auditoría era extensa y técnicamente densa. Tratarla como una lista lineal de issues habría saturado al equipo rápidamente.

Reorganizamos los hallazgos por criterios:

- Estructura y semántica
- Navegación y gestión del foco
- Formularios y lógica de validación
- Componentes reutilizables
- Consistencia del sistema visual

Agrupar por criterio permitió detectar patrones recurrentes y dependencias cruzadas.
Pasamos de corregir páginas aisladas a intervenir capas estructurales del sistema.

Ese cambio aportó claridad estratégica.
No eliminó los errores iniciales.

Reparto de tareas en un equipo reducido

Con un frontend y dos perfiles de maquetación, la asignación debía ser precisa y realista.

Estructura inicial:

- Maquetadores → correcciones HTML estructurales, jerarquía de headings, labels y ajustes semánticos globales
- Frontend → control de foco, comportamiento dinámico, validaciones, estados interactivos y edge cases
- Coordinación → supervisión transversal por criterio, validación final y comunicación con cliente

Sobre el papel funcionaba.

En la práctica, los cambios estructurales impactaban la lógica JavaScript existente. Ajustar el DOM a veces rompía interacciones que no detectábamos de inmediato. No por falta de conocimiento, sino por sincronización insuficiente.

La accesibilidad impacta estructura y comportamiento al mismo tiempo.
Eso exige coordinación deliberada.

Las primeras regresiones

El error principal fue avanzar demasiado rápido sin una capa sólida de control entre markup y lógica.

Ejemplos reales:

- Cambios en modales que rompieron el focus trapping
- Actualizaciones en formularios que alteraron flujos de validación
- Ajustes en la jerarquía de headings que afectaron estilos dependientes y tests visuales

Nada provocó una caída total del sistema.
Pero sí generó retrabajo y fricción interna.

Subestimamos el impacto sistémico de las correcciones estructurales.
Las mejoras de accesibilidad son intervenciones arquitectónicas.

Ajuste de proceso y estabilización

Tras las primeras regresiones, pausamos y revisamos el workflow completo.

Implementamos:

- Revisión cruzada entre maquetación y frontend antes de cerrar cada bloque de criterio
- Validación completa de flujos interactivos tras cambios estructurales
- Checklist mínimo obligatorio antes de pasar tareas a QA

La velocidad bajó temporalmente.
La estabilidad mejoró de forma clara.

Reducir ritmo fue una decisión estratégica. Nos devolvió el control.

Trabajo transversal por criterios

Refinamos aún más el enfoque basado en criterios.

En lugar de correcciones aisladas, definimos patrones reutilizables:

- Estructura estándar de formulario accesible
- Implementación única de modal con foco controlado
- Regla consistente de foco visible aplicada a todo el sistema

Cada patrón corregido se aplicaba globalmente.

La accesibilidad dejó de ser parche reactivo.
Se convirtió en normalización estructural.

Comunicación transparente con el cliente

Tras los primeros problemas, optamos por la claridad.

Reportábamos por criterio:

- Qué estaba completamente corregido
- Qué impacto habían tenido ciertos cambios
- Qué mejoras internas de proceso habíamos implementado

La transparencia reforzó la confianza.

El cliente pasó de ver correcciones aisladas a percibir control sistémico y liderazgo técnico.

Lo que significó liderar este proceso

Liderar no fue citar más estándares.
Fue estructurar ejecución bajo presión real.

Aprendí a:

- Descomponer problemas complejos en sistemas manejables
- Distribuir responsabilidades según especialización real
- Ajustar el proceso tras errores sin buscar culpables
- Mantener coherencia técnica bajo alta visibilidad externa

Las regresiones iniciales no fueron fracaso.
Fueron calibración.

Conclusión

No fue una historia de ejecución impecable.
Fue una historia de adaptación.

Movimos demasiado rápido.
Introdujimos regresiones.
Ajustamos el sistema.

La lección estructural fue clara: los cambios de accesibilidad son cambios arquitectónicos. Exigen coordinación real entre markup y lógica, especialmente en equipos pequeños donde cada modificación tiene impacto directo.

La auditoría expuso debilidades.

El proceso de corrección fortaleció al equipo, refinó la disciplina de ejecución y consolidó un estándar interno más sólido para futuros proyectos.