Cómo recuperar una carga fallida sin vaciar el formulario

Un cliente ha descrito una solicitud, elegido un servicio y adjuntado una foto. La carga falla y la página vacía todo el formulario. El problema estaba en el archivo; obligar a escribir de nuevo la solicitud añade otro fallo que el producto podía evitar.

Define la recuperación del adjunto antes de aprobar un formulario. El objetivo es conservar la información que la aplicación tiene permitido retener, explicar qué ocurrió con el archivo y ofrecer un siguiente paso que no envíe la solicitud dos veces por accidente. El ejemplo siguiente es una propuesta de prueba, no un resultado obtenido para un cliente.

Ilustración conceptual generada con IA; no es una captura de un cliente.

Separa el borrador del estado del adjunto

Define cada estado. Un archivo seleccionado está disponible para la página actual; uno cargado ha llegado al servidor; un adjunto aceptado ha superado las comprobaciones exigidas por la aplicación. Una solicitud enviada es otro resultado empresarial. No llames “Listo” a las cuatro situaciones.

En una solicitud ficticia de mantenimiento, acuerda que la descripción y el servicio elegido sigan siendo editables después de un error de carga. Decide por separado si esos campos pueden conservarse al recargar o solo mientras permanezca abierta la página. El cierre de sesión, los dispositivos compartidos y la información sensible necesitan reglas expresas; guardar todo en el navegador no es un plan de recuperación por defecto.

Muestra el estado del adjunto junto a su nombre. Si la página solo recuerda el nombre del archivo, no debe presentarlo como prueba de que el servidor conserva un adjunto aceptado.

Respeta lo que el navegador puede restaurar

La documentación de MDN sobre el selector de archivos explica que un script no puede completarlo asignando un nombre local a su valor. También aclara que el atributo accept orienta la selección, pero no valida el archivo; el servidor debe comprobar la carga.

Si la página conserva el archivo, puede reutilizarlo al reintentar. Si no, pide seleccionarlo y conserva el texto permitido. Promete restauración tras recargar solo si el diseño de almacenamiento lo permite.

Ofrece un siguiente paso para cada fallo

• Archivo rechazado: identifica la regla de formato o tamaño y permite elegir un sustituto.
• Transferencia interrumpida: conserva el borrador permitido y ofrece un reintento limitado cuando corresponda.
• Resultado incierto: consulta la referencia de la carga en el servidor antes de crear otro adjunto.
• Selección o transferencia cancelada: explica si se conserva un adjunto anterior ya aceptado.

La guía de notificaciones de formularios de W3C WAI recomienda informar con claridad del éxito y los errores e indicar cómo resolver los problemas. Aplica ese principio al control del archivo y al resultado general de la solicitud.

Por ejemplo: “No se pudo cargar la foto. Tu descripción sigue aquí. Elige Reintentar o elimina la foto”. Usa ese mensaje solo si el borrador está disponible y ambas acciones funcionan. Si el adjunto es obligatorio, explica por qué no se puede finalizar. Si es opcional, enviar sin él debe ser una decisión explícita.

Ejecuta una prueba de recuperación concreta

Utiliza una cuenta de prueba, un archivo de muestra inocuo y un borrador identificado. Registra la versión de la aplicación y el navegador. Completa los campos relevantes para que cualquier borrado inesperado resulte visible.

1. Rechaza una muestra mediante una regla de validación acordada. Sustituye solo el adjunto y comprueba que los demás campos conservan sus valores.
2. Interrumpe una transferencia en el entorno de prueba. Recupera la conexión, reintenta y verifica un único adjunto aceptado en el mismo borrador.
3. Simula una respuesta perdida después de que el servidor reciba el archivo. Confirma el resultado existente antes de aprobar otra carga.
4. Cancela una sustitución y comprueba si permanece el adjunto anterior, según la regla acordada.
5. Recarga la página y verifica la retención documentada. Si hay que volver a seleccionar el archivo, revisa la instrucción y los campos que permanecen.

Completa también la recuperación con el teclado y revisa los avisos con la tecnología de asistencia compatible. Que el error sea visible no demuestra que todas las personas puedan encontrar la siguiente acción.

Aprueba el resultado guardado, no solo el indicador de progreso

Tras recuperar la carga, envía una vez la solicitud de prueba y vuelve a abrirla. Compara descripción, servicio y adjunto con los valores previstos. Verifica que eliminar o sustituir un archivo no deje un adjunto no deseado vinculado a la solicitud.

Conserva una ficha breve: condición del fallo, campos retenidos, estado del adjunto, siguiente acción y referencia final de la solicitud. La limpieza de archivos temporales y los permisos de acceso son requisitos adicionales de implementación. Superar esta prueba no certifica la seguridad del sistema de cargas.

Contacta con Dynelink para definir la recuperación de adjuntos y sus pruebas de aceptación en un formulario empresarial o portal de clientes.