Formularios accesibles: etiquetas, errores y consultas útiles

Un formulario de consulta accesible necesita etiquetas comprensibles, requisitos claros, errores que se puedan corregir y una confirmación confiable. Eliminar obstáculos evitables puede ayudar a completar la tarea, pero trabajar la accesibilidad no justifica prometer un aumento de conversión. Evalúe el comportamiento real antes de atribuirle resultados.

La primera pregunta es sencilla: ¿qué información necesita su equipo para tomar la siguiente acción útil? Los demás campos deben justificar su presencia.

Dé una razón y una etiqueta permanente a cada campo

Mantenga un campo obligatorio solo si su ausencia impide la siguiente acción. El teléfono puede ser indispensable para solicitar una devolución de llamada, pero innecesario para una consulta que se responde por correo. Explique los requisitos poco habituales donde la persona los encuentra.

Use etiquetas visibles que permanezcan después de escribir. Asócielas con sus controles; la guía de etiquetas del W3C explica la relación entre etiqueta y campo. Los ejemplos dentro del campo pueden complementar la etiqueta, pero no deberían contener toda la instrucción.

En un formulario bilingüe, traduzca ayudas y mensajes de error además de los nombres. No obligue a compradores de Costa Rica a usar un formato telefónico exclusivo de Estados Unidos. Acepte variaciones razonables y normalícelas cuando el sistema receptor lo requiera.

Diseñe la corrección antes que el éxito

Un borde rojo no explica qué ocurrió. Nombre el campo, describa el problema e indique cómo corregirlo. Conserve las respuestas válidas cuando falle la validación.

En formularios largos, un resumen de errores puede enlazar los campos afectados. El tutorial de notificaciones del W3C describe ese enfoque y la asociación de errores mediante aria-describedby. Los mensajes dinámicos también necesitan una forma apropiada de anunciarse, probada con tecnología de asistencia.

Distinga los datos inválidos de un fallo de envío. “Revise su correo” es incorrecto si la dirección pasó la validación y después falló la red. Ese mensaje lleva a cambiar información correcta y reenviar sin saber si la consulta se recibió.

Recorra una consulta hipotética

En esta revisión hipotética, un proveedor costarricense de mantenimiento recibe consultas en español e inglés.

El formulario pide correo, tipo de equipo y descripción. La fotografía es opcional. La persona omite el tipo de equipo e intenta enviar. El formulario conserva la descripción, muestra un error específico y permite llegar al campo pendiente mediante teclado.

Después de corregirlo, el servidor acepta la solicitud y crea una referencia. Solo entonces la interfaz confirma la recepción. Si el envío falla, explica el problema y permite reintentar sin borrar el texto. La confirmación promete un plazo de respuesta únicamente si el equipo operativo lo aprobó.

El ejemplo separa cuatro cosas que suelen mezclarse en un botón: validar, enviar, aceptar la solicitud y dar seguimiento humano. Esa distinción también ayuda a probar el sistema y a interpretar su analítica.

Use una lista breve de aceptación

Pruebe el recorrido completo, no solamente los campos vacíos:

• Complete y corrija el formulario usando solo el teclado.
• Compruebe que cada control tenga un nombre accesible comprensible.
• Envíe un valor inválido y revise que la corrección sea útil.
• Simule un fallo de red y confirme que el texto permanezca.
• Verifique que el éxito corresponda a una aceptación del servidor, no a un clic.
• Repita las pruebas en el otro idioma y en una pantalla estrecha.

Tome su formulario actual y anote por qué cada campo obligatorio es necesario. Después revise sus estados de fallo con diseño UX/UI de 5e Labs antes de cambiar el estilo visual o agregar más preguntas de calificación.