Step Indicators

El stepper horizontal con nodos y labels funciona en desktop para 3-5 pasos porque hay suficiente espacio horizontal para mostrar el estado de cada paso y su label sin truncar. En mobile con 5 o más pasos, los nodos se comprimen hasta ser ilegibles en 375px y los labels desaparecen; un contador textual "Paso 2 de 6" más una barra segmentada comunican la misma información orientacional con cero riesgo de desbordamiento. Los dots (sin labels) solo son apropiados para ≤5 pasos y onboarding ultra-linear donde el usuario no necesita saber el nombre de cada paso. Usar la estrategia incorrecta para el contexto es uno de los antipatrones más frecuentes en formularios multi-paso.

Un stepper con solo 2 estados (completado/pendiente) no puede comunicar errores en pasos ya visitados ni distinguir pasos opcionales de obligatorios. Los 5 estados cubren la totalidad de escenarios reales: completed (checkmark verde, paso exitoso), active (anillo de acento con glow, paso actual), upcoming (border y número en gris, contraste reducido pero visible), error (rojo con "!" SVG, reemplaza el número por completo) y optional (border dashed, con badge "Opcional" lateral). Mezclar completed y optional visualmente genera confusión sobre si el usuario puede saltarse el paso sin consecuencias. El estado error exige atención inmediata y debe ser el más visualmente prominente de los 5.

WAI-ARIA 1.2 define el token "step" específicamente para el paso actual en una secuencia de pasos; usar aria-current="true" o "page" comunica semántica incorrecta al AT. Cada nodo necesita un span con clase sr-only que verbalice el estado completo ("Completado: Datos personales", "Actual: Seleccionar plan") porque el estado se transmite visualmente por color pero el AT no puede inferirlo. Envolver la lista en un nav con aria-label y usar ol (no ul) comunica la naturaleza secuencial y el número total de ítems al lector de pantalla, lo que permite anunciar "1 de 4" automáticamente en algunos navegadores.

En formularios de onboarding y configuración, los pasos completados deben ser navegables porque los datos de cada paso son independientes y el usuario puede querer corregir un dato sin perder progreso. Hacer los pasos clickeables en este contexto aumenta la sensación de control. En checkout, los pasos tienen dependencias de datos (el método de envío elegido en el paso 1 afecta los costos calculados en el paso 3) y la navegación libre puede producir estados inconsistentes o totales incorrectos. La solución en checkout es un botón "Atrás" explícito y siempre visible que gestiona las dependencias de forma controlada, sin convertir los indicadores en links.

Una barra de progreso dividida en segmentos de igual anchura para pasos de duración desigual engaña al usuario: el primer paso de 30 segundos llena el 25% de la barra igual que el paso de 4 minutos que viene después. El resultado es que el avance se detiene inesperadamente, generando el "90% completado forever" que los usuarios asocian con instaladores de software rotos. Asignar anchuras proporcionales al esfuerzo real (número de campos, tiempo estimado) produce un avance visual que coincide con la experiencia del usuario y mantiene su confianza durante todo el flujo.

Cuando un paso contiene datos inválidos que impiden continuar, el nodo del step indicator debe mostrar un ícono SVG "!" que reemplaza completamente el número o checkmark; mantener el número junto al estado rojo mezcla dos semánticas y reduce la claridad. El color de la línea conectora saliente del nodo en error también debe reflejar el estado (rojo o rojo translúcido) para comunicar que la ruta de progreso está interrumpida. Adicionalmente, el label debajo del nodo en error debe cambiar al color de error, y el sistema debe guiar al usuario directamente al primer paso con error cuando intente continuar.

Sin gestión explícita del foco, al avanzar al siguiente paso el foco permanece en el botón "Siguiente" del paso anterior (que puede haber desaparecido del DOM) o salta al inicio del documento. El usuario de teclado no tiene señal de que el contenido cambió y queda desorientado. La solución es mover el foco programáticamente al heading h2 del nuevo paso usando tabindex="-1" (hace el elemento focuseable sin incluirlo en el tab order natural) y llamar a .focus() al montarse. El AT anuncia el heading completo, el usuario sabe en qué paso está, y desde ahí Tab lleva secuencialmente a los campos del formulario.

Tres antipatrones son especialmente frecuentes en step indicators de producción. Primero, la fragmentación extrema (1 campo por paso): multiplica los pasos sin reducir la carga cognitiva, añade 5 o más oportunidades de abandono y hace que el flujo se sienta burocrático. Segundo, dots sin labels con 6 o más pasos: el usuario tiene que contar los puntos para orientarse y no puede saber qué contiene cada paso ni cuánto falta. Tercero, barra con segmentos de igual tamaño para pasos de duración muy distinta: el avance visual contradice el esfuerzo percibido y genera desconfianza, el mismo síntoma del "instalador atascado al 90%".