Formularios que permiten continuar

Cada campo añade trabajo. Un formulario útil explica qué necesita, por qué lo pide cuando no resulta evidente y cómo corregir una respuesta. El éxito no consiste solo en que el botón envíe: la persona debe poder entender qué ocurrirá y recuperar su tarea después de un error.

Empieza por una tarea y un inventario de datos

Define el resultado: solicitar una cita, crear una cuenta o descargar un recurso no requieren necesariamente los mismos datos. Para cada campo, anota quién utiliza la respuesta y en qué momento. Elimina lo que no tenga una finalidad y aplaza lo que no sea necesario ahora. No reduzcas campos a costa de obligar después a resolver dudas por teléfono.

Ordena las preguntas según la tarea de la persona. Si divides el formulario en pasos, anticipa el recorrido, conserva respuestas al volver y evita pedir otra vez datos ya disponibles. Un proceso largo no se convierte en fácil solo por repartirlo en varias pantallas.

Etiquetas visibles e instrucciones donde hacen falta

Mantén una etiqueta visible asociada al campo mediante label. El placeholder puede mostrar un ejemplo, pero desaparece al escribir y no sustituye esa etiqueta. Explica antes de la entrada los formatos no evidentes y el significado de obligatorio u opcional; no dependas únicamente de un asterisco sin explicación.

<label for="correo">Correo electrónico (obligatorio)</label>
<p id="correo-ayuda">Te enviaremos la respuesta a esta dirección.</p>
<input type="email" id="correo" name="correo"
       autocomplete="email" required
       aria-describedby="correo-ayuda">

Fragmento de campo implementable: intégralo en un formulario con acción real y validación en servidor. required comunica obligatoriedad y permite validación nativa. type="email" facilita un teclado adecuado y comprueba parte del formato; no demuestra que el buzón exista ni que pertenezca a quien escribe.

Agrupa decisiones y facilita introducir datos

Usa fieldset y legend cuando varias opciones responden a una misma pregunta. Un radio sirve para una elección entre opciones; una casilla, para activar una opción independiente. Un select nativo suele bastar para una lista sencilla. Mantén nombres e instrucciones junto a los controles, sin depender del color o de su posición.

Aplica autocomplete adecuado para los datos personales pertinentes. inputmode sugiere el teclado y no valida el valor. Un código postal, teléfono o identificador no es automáticamente una cantidad: conservar ceros iniciales o signos puede ser necesario. Permite pegar y utilizar gestores de contraseñas; evitarlo aumenta el esfuerzo y puede crear barreras.

Cuándo validar y cómo presentar el error

No declares erróneo un campo antes de que la persona haya podido completarlo. La validación al enviar ofrece un momento claro; en campos concretos puede ayudar validar después de salir, si no genera interrupciones. Comprueba siempre en servidor: la validación del navegador ayuda a la interacción, no sustituye la seguridad o las reglas del negocio.

• Identifica el problema en texto: «Escribe el correo con un formato como nombre@dominio.es».
• Relaciona el mensaje con el campo y usa aria-invalid="true" cuando se haya detectado un error. Retíralo o cambia a false al corregirlo.
• Conserva los datos válidos y no vacíes el formulario por un error en un solo campo.
• Si hay varios errores, ofrece un resumen con enlaces a los campos. Tras enviar, mover el foco a ese resumen puede orientar; no lo hagas por cada pulsación.
• No comuniques el fallo solo con un borde rojo y no uses alertas repetidas para cada carácter.

Este fragmento es ilustrativo de un estado de error ya validado, no un formulario completo. La aplicación debe generar el mensaje, actualizar el atributo y gestionar el foco según el envío.

<label for="correo-error">Correo electrónico (obligatorio)</label>
<input id="correo-error" name="correo" type="email" required
       autocomplete="email" aria-invalid="true"
       aria-describedby="mensaje-correo">
<p id="mensaje-correo">Escribe una dirección como nombre@dominio.es.</p>

El envío también tiene estados

El botón debe nombrar el resultado: «Solicitar cita» informa mejor que «Enviar». Mientras se procesa, explica que la solicitud está en curso y evita envíos duplicados sin dejar una interfaz bloqueada para siempre. Si falla la red, conserva lo escrito, explica si se recibió la solicitud cuando puedas saberlo y ofrece una recuperación segura.

Una confirmación solo debe aparecer tras el éxito real. Explica qué se ha registrado, qué ocurrirá después y cuándo corresponde volver a actuar. Si la operación puede tener consecuencias importantes, considera una revisión previa o una forma de corregirla apropiada al caso.

Móvil, teclado y ampliación

Prueba con el teclado virtual abierto, con texto ampliado y con ayudas largas. La etiqueta, el valor y el error deben seguir siendo reconocibles. Deja suficiente área de activación y separación entre controles. Mantén el orden visual y el orden de foco alineados; no intentes reparar una distribución confusa mediante tabindex positivo.

En teclado, recorre todos los campos, opciones, enlaces de ayuda y botones. Verifica que volver a un campo desde el resumen no pierde el mensaje ni el valor. Un calendario personalizado requiere pruebas específicas; cuando sea suficiente, un campo nativo reduce la cantidad de interacción que debes programar.

Cómo saber si la mejora funciona

Usa un caso de prueba con datos ficticios y cubre vacío, formato incorrecto, respuesta válida, fallo de servidor y doble pulsación. Prueba también copiar y pegar, autocompletar y regresar al paso anterior. Anota qué dispositivos y tecnologías has comprobado; no presupongas compatibilidad con todos.

Fuentes y siguientes pasos

• WAI: formularios accesibles
• WAI: etiquetas de campos
• WAI: notificar errores y éxito
• Guía de WAI-ARIA
• Usabilidad móvil
• Evaluar con tareas