Planteamiento y contexto
La búsqueda, el guardado y la subida se completan sin navegación ni movimiento del foco. Los usuarios visuales ven “Guardando”, “Guardado” o “Error al guardar”, mientras que la actualización puede ocurrir fuera del control enfocado. El objetivo es un anuncio breve y accionable que no interrumpa la entrada de datos, con alternativas para teclado, sin scripts y fallos de red.
Qué evalúa el entrevistador
La respuesta debe distinguir entre estado informativo, errores y alertas urgentes; establecer una live region antes de las actualizaciones; controlar anuncios duplicados, condiciones de carrera y movimiento del foco; e incluir resultados del servidor, acciones de reintento y pruebas en lugar de limitarse a agregar un único atributo aria-live.
Preguntas para clarificar
- ¿Qué actualizaciones son informativas y cuáles bloquean la siguiente acción?
- ¿Pueden los usuarios disparar solicitudes concurrentes y las respuestas llevan números de secuencia?
- ¿El fallo cuenta con una acción de reintento en línea, deshacer o detalles?
- ¿Debe permanecer el foco en el editor tras el éxito y hacia dónde debe ir en caso de error?
- ¿Se requieren el envío de formularios ordinario, el uso de teclado, el zoom y los colores forzados?
Respuesta en 30 segundos
Renderizaría una región role="status" vacía en el DOM inicial y escribiría en ella mensajes ordinarios de progreso y finalización. Su comportamiento cortés (polite) no debería robar el foco. Los errores accionables obtienen texto visible y una ruta de recuperación cerca del control; solo los eventos verdaderamente urgentes utilizan una alerta. Descartaría duplicados y regularía los anuncios, rechazaría respuestas obsoletas mediante números de secuencia y probaría el teclado, el lector de pantalla, los fallos de red y las solicitudes concurrentes.
Respuesta detallada paso a paso
Paso 1: Modelar el estado explícitamente
Mantén separados idle, pending, success, error y cancelled. La región de estado indica el resultado actual, como “Guardando”, “Guardado” o “Error al guardar; reintentar”, en lugar de nombres de solicitudes internas o cada porcentaje. Almacena los errores de campo, las acciones de reintento y las asociaciones de controles por separado.
Paso 2: Crear primero la live region
La W3C y MDN recomiendan crear la live region antes de cambiar su contenido. role="status" es adecuado para información consultiva y tiene un aria-live="polite" implícito; no agregues el atributo únicamente cuando ocurra una actualización.
<p id="save-status" role="status" aria-atomic="true"></p>
<button type="submit">Save</button>Paso 3: Controlar la cadencia de anuncios
No escribas texto idéntico repetidamente ni anuncies cada pulsación de tecla durante la búsqueda. Aplica debounce a los resultados de alta frecuencia y anuncia un resumen significativo como “Resultados actualizados”. La finalización, el fallo y la acción requerida deben indicar el siguiente paso. aria-live="assertive" interrumpe la voz y debe ser poco común.
Paso 4: Manejar carreras y cancelaciones
Asigna a cada solicitud una secuencia incremental o un AbortController. Solo la respuesta más reciente de un componente montado puede actualizar el estado. Una solicitud cancelada no es un anuncio de fallo; una nueva solicitud reemplaza el mensaje pendiente anterior.
Paso 5: Coordinar el foco y los errores
No muevas el foco ante un éxito ordinario; permite que el usuario continúe. Para los fallos, renderiza texto visible y asócialo con el control mediante aria-describedby; los fallos a nivel de página necesitan un resumen enfocable y un botón de reintento. Elige un canal principal para que un salto de foco y un anuncio en vivo no se dupliquen entre sí.
Paso 6: Preservar una ruta de respaldo
El servidor aún debe aceptar el envío ordinario de formularios y devolver resultados estructurados. Ante un fallo de JavaScript, un tiempo de espera agotado o un permiso expirado, el texto debe indicar el estado y la acción, como “Error al guardar; inténtalo de nuevo”, en lugar de dejar un indicador de carga. No borres la entrada del usuario.
Compensaciones y límites
status, alert y errores visibles
status es para notificaciones corteses; alert interrumpe y no debe reemplazar a todos los errores. Los errores visibles siguen siendo necesarios porque la voz no es el único canal. El color, los íconos y la animación complementan el texto.
Detalle del progreso frente al ruido
Muestra los porcentajes de subida visualmente, pero anuncia solo el inicio, las fases significativas y la finalización. Actualizar una live region con cada uno por ciento genera ruido; calibra la regulación con dispositivos y usuarios reales.
Plan de implementación y evidencia
Componente y contrato de API
Centraliza el texto de los mensajes, la deduplicación y las comprobaciones de secuencia en un solo componente de estado. La API devuelve campos estructurados success, retryable y fieldErrors; el componente los asigna al idioma del usuario en lugar de exponer códigos del servidor.
Matriz de verificación
Completa la búsqueda, el guardado y la subida mediante el teclado y confirma un único anuncio en NVDA y VoiceOver. Cubre redes lentas, tiempos de espera agotados, dobles clics, respuestas fuera de orden, cancelación, descarga de página, colores forzados y zoom al 200%. Automatiza la semántica del DOM y luego verifica manualmente el orden hablado.
Errores comunes y preguntas de seguimiento
Error: agregar aria-live dinámicamente
Mantén presentes el nodo y el atributo, y luego actualiza su texto; de lo contrario, algunas tecnologías de asistencia pueden perderse el primer cambio.
Error: mover el foco al texto de éxito
Eso interrumpe la edición. Mantén el foco a menos que el usuario deba solucionar un error o inspeccionar un resultado.
Error: hacer que cada error sea asertivo (assertive)
La voz de alta prioridad interrumpe la lectura. Resérvala para una atención genuinamente urgente y proporciona una recuperación visible.
Pregunta de seguimiento: prevenir respuestas obsoletas
Compara una secuencia monotónica o combina la cancelación con una comprobación de secuencia; la cancelación por sí sola no demuestra que una retrollamada no pueda ejecutarse.
Pregunta de seguimiento: demostrar la eficacia
Aporta observaciones de lectores de pantalla, flujos de teclado, fallos de red y evidencia de condiciones de carrera en lugar de únicamente el resultado de un escaneo automatizado.