it-swarm-es.com

¿Cuál es la mejor práctica para diseñar mensajes de error de formulario?

He visto mucha investigación sobre diseño de formularios, pero hasta ahora, no he encontrado ningún estudio sobre las mejores prácticas de diseño de mensajes de error. El único consejo parece ser que cada error debe estar claramente asociado con el campo de formulario no válido que pretende corregir. ¿Ha habido alguna investigación sobre esto?

Tengo algunos problemas específicos que estoy tratando de resolver y agradecería cualquier idea o recursos.

Ubicación del mensaje de error

Cuando tiene validación de formulario en vivo, ¿dónde debería aparecer un mensaje de error (o éxito) en relación con el elemento de formulario?

Algunas opciones:


¡A la derecha de la entrada

mockup

descargar fuente bmml - Wireframes creados con Balsamiq Mockups


¡A la derecha de la etiqueta

mockup

descargar fuente bmml


¡Sobre la etiqueta

mockup

descargar fuente bmml


¡Debajo de la etiqueta

mockup

descargar fuente bmml


¡Debajo de la entrada

mockup

descargar fuente bmml


Hay algunos problemas espinosos que también deben tenerse en cuenta con respecto a la ubicación:

  • ¿Cómo se muestran los errores para los grupos de radio o casillas de verificación?
  • ¿Qué tan ancho es el mensaje de error?
  • ¿El mensaje de error es de varias líneas?

Visibilidad del mensaje de error

Además de la ubicación, también estoy interesado en cómo la visibilidad del mensaje de error afecta su usabilidad. ¿Importa o es estrictamente una decisión estética? Considere las siguientes 3 opciones:

mockup

descargar fuente bmml

Editar : Ha habido algunos puntos excelentes sobre accesibilidad en algunas de las respuestas hasta ahora, así como algunos ejemplos interesantes. Sin embargo, me gustaría ver algunos datos de ¡estudios reales, si es posible. Además, ninguna de las respuestas hasta ahora ha abordado realmente las dos preguntas que tenía arriba:

  • ¿Dónde debe ubicarse el error en relación con la entrada y la etiqueta?
  • ¿Cómo afecta el diseño y la visibilidad del mensaje de error en sí mismo a su usabilidad?

Con respecto a la accesibilidad de los formularios, me parece que podría haber dos casos de uso potencialmente conflictivos, la validación en vivo y la validación del lado del servidor (lo que requeriría volver a cargar la página). Si la página se vuelve a cargar y el usuario vuelve a comenzar en la parte superior del formulario, tiene sentido un resumen de error, especialmente desde una perspectiva de accesibilidad. Sin embargo, en el caso de la validación en vivo, el resumen de errores en la parte superior tiene mucho menos sentido, tanto para el diseño de formularios como para fines de accesibilidad.

Considere cómo un usuario realmente usaría un formulario con validación en vivo:

La validación se produce en el evento de desenfoque. Por lo general, el enfoque estará en el siguiente elemento del formulario, no en la lista en la parte superior. Según tengo entendido los lectores de pantalla, no habría ninguna razón para volver al principio del formulario para leer la lista de errores. Para los usuarios que no usan lectores de pantalla, la lista de errores en la parte superior empuja todo el formulario hacia abajo, de manera doble si el error también ocupa espacio vertical cerca del campo del formulario. En formas más largas, este es un problema de usabilidad ya que el resumen de error puede no ser visible. En formularios más cortos que tienen errores por campo, como un inicio de sesión, el resumen del error parece excesivo. Para todas las formas, la interfaz se empujaría hacia abajo, lo que crearía una experiencia de usuario deficiente.

Para la validación en vivo, si realmente desea que los errores de formulario sean accesibles, creo que usar ARIA Live Regions podría ser la solución preferida.

152
Virtuosi Media

Los indicadores encapsulados son la única solución que he encontrado que llegan a todos los casos Edge. Señalar la bandera en la etiqueta en lugar de la entrada permite la coherencia con los botones de opción y los grupos de marcas de verificación o entradas extrañas como controles deslizantes o clasificadores.

Resaltar el campo con rojo también es útil, pero no siempre es posible. Ejemplos de uso a continuación.

mockup

descargar fuente bmml - Wireframes creados con Balsamiq Mockups

mockup

descargar fuente bmml

mockup

descargar fuente bmml

Al leer la respuesta de @jonW, no podría estar más de acuerdo con sus pensamientos sobre los lectores de pantalla, y mi solución puede ser igualmente efectiva dependiendo de la implementación. Puede colocar las banderas justo al norte en las entradas en el marcado, y usar aria para lograr la misma accesibilidad


La sección "Validación en línea y Eventos de validación" en esta página parece ideal: http://semantic-ui.com/modules/form.html

61
Fresheyeball

Parece que ya estás marcando campos de formulario opcionales en lugar de los obligatorios . Parece que no hay indicadores 'obligatorios', pero tampoco indicadores 'opcionales', así que quería mencionar eso.

Lo que me gusta hacer en los formularios es "micro-gamificarlos": para cada campo del formulario, proporcione un "indicador de validación". Por simplicidad, digamos que es solo un pequeño círculo. Esto comienza en una posición neutral: un círculo gris con un signo de interrogación. Para los campos opcionales, es un círculo gris con una marca de verificación. Cada vez que el usuario deja un campo de formulario, se valida en vivo y suceden las siguientes cosas:

  1. el indicador cambia a "éxito", p. círculo verde + marca de verificación o "error" (por ejemplo, círculo rojo + signo de exclamación)

  2. si hubo un error, el campo se resalta

  3. si hay un error, el botón de enviar se atenuará (hacer clic en él seguirá funcionando, pero solo llevará al usuario al primer error) y se mostrará un mensaje de información general sobre él.

Si está escribiendo buenas sugerencias, debería ser suficiente solo resaltar el campo y la sugerencia. Si siente que necesita un mensaje de error por separado, es probable que sus sugerencias puedan necesitar algo de trabajo. En mi experiencia, casi siempre es posible cubrir los errores de entrada del usuario con buenas sugerencias.

enter image description here

Al usuario no le gusta regresar mentalmente en un formulario. Se procesa campo por campo, el usuario se enfoca en campo por campo y pasa por una lista de verificación mental. Al señalar los errores a medida que ocurren, admitimos este modo y no hacemos que el usuario regrese "más adelante". Es una interrupción en el flujo del usuario y una molestia hacer clic en "enviar" y luego ser "bloqueado" y "enviado de vuelta". Es una experiencia mucho más fluida si los problemas se resaltan y, por lo tanto, pueden corregirse a medida que ocurren.

44
Christian

El mensaje de error debe aparecer antes del campo del formulario en sí (como mínimo en el marcado en sí, pero idealmente también se muestra visualmente de esta manera en la pantalla) para que cuando alguien lea el formulario, lea que el campo haya errado antes de leer el campo en cuestión: de esa forma el usuario está preparado mentalmente para que "el contenido de este campo que estoy a punto de leer es incorrecto y, por lo tanto, necesito modificarlo".

Esto es aún más importante para crear formularios accesibles . Si alguien está leyendo el formulario a través del lector de pantalla, se le debe presentar el error antes de leer el campo del formulario por el mismo motivo que se detalla anteriormente. (No quieren tener que regresar después de escuchar el contenido de un campo y ¡entonces cuando se les dice que ese campo tiene un error). Esta es la razón por la cual es ¡la etiqueta del formulario en sí misma que debe contener el texto de error, y no solo una ventana emergente o una alerta con guión porque no puede garantizar que los lectores de pantalla o los navegadores antiguos sean capaz de detectar este texto.

Además, si es un formulario largo, o si el usuario está navegando por el teclado y usando el botón Tabulador, pueden existir varios de los campos debajo del pliegue, por lo que si tabula el formulario, es posible que no note que un campo está en error hasta que luego se ha tabulado en el siguiente (el campo se desplazará a la vista, pero si el mensaje de error está debajo de él, el error podría aparecer fuera de la pantalla).

Finalmente, hay una ruta adicional que probablemente debería tomar para sus mensajes de error:

Debe resumir los errores justo al comienzo del formulario para que el usuario sepa ¡cuántos errores hay, y ¡qué esos errores son. Realmente, estos deberían ser enlaces que lo lleven a los campos con errores en cuestión (otra razón por la cual el mensaje de error en esos campos debe estar antes del campo en sí)

Gran parte de esta información se puede encontrar en artículo de WebAIM: Validación de formularios y recuperación de errores utilizables y accesibles

Aquí hay un ejemplo. Los errores se muestran al comienzo del formulario y también son enlaces para que el usuario pueda navegar fácilmente a los campos en cuestión, donde también se muestra el texto del error:


mockup

descargar fuente bmml - Wireframes creados con Balsamiq Mockups

30
JonW

Existe un documento técnico antiguo (2007) presentado por Human Factors International que contiene algunos datos sobre mensajes de error. La conclusión a la que llegaron entonces fue:

... la mayoría de los usuarios pasan por una fase de finalización, en la que el objetivo es completar el formulario, seguida de una fase de corrección o revisión, en la que se corrigen los errores ... los errores inmediatos se ignoraron en gran medida hasta que se completó el formulario.

Por lo tanto, de las seis formas posibles de presentar mensajes de error, estas tres resultaron más efectivas que las otras.

  1. Presente los errores después, incrustados en el formulario, todos a la vez
  2. Presente los errores después, incrustados en el formulario, uno por uno
  3. Presente los errores después, en diálogos, uno por uno

Obviamente ya no haríamos el número 3. El libro blanco se llama "Lo que hemos aprendido: mirando hacia atrás a 2007." Puede descargarlo de su sitio, después de completar un formulario . :)

Realmente no habla sobre la colocación de mensajes de error, excepto el cuadro de diálogo incrustado, por lo que no estoy seguro de si esto es realmente útil.

10
Julia D

Lo que voy a sugerir es simplemente lo que me vino a la mente como una solución que usaría cuando leyera su pregunta, por lo que claramente no puede encontrar ninguna investigación o material relacionado para fundamentarla.

Me dirijo específicamente a la pregunta "Cuando tiene una validación de formulario en vivo, ¿dónde debería aparecer un mensaje de error (o éxito) en relación con el elemento de formulario?"

¿Qué pasa si mostramos el mensaje en lugar de la etiqueta misma?

enter image description here

A medida que se resuelven los errores (teniendo en cuenta que son validaciones del lado del cliente de nivel de formulario), puede volver a la vista original de las etiquetas para ayudar al usuario a realizar un seguimiento de las restantes.

Para que este enfoque funcione, es posible que desee redactar cuidadosamente sus mensajes para transmitir completamente lo que el usuario debe hacer en la menor cantidad de palabras posible. Si los mensajes son largos, puede ajustarlos a la longitud de los campos.

4
roni

Justo encima del botón de envío, podría haber una lista de elementos obligatorios en forma de etiquetas. Cada etiqueta debe estar vinculada al campo respectivo. A medida que el usuario comienza a llenar el formulario desde la parte superior, las etiquetas siguen desapareciendo. Antes de que el usuario presione el botón Enviar, puede verificar si todos los campos obligatorios se han completado o no. Si ha perdido algún elemento, puede volver fácilmente al campo presionando la etiqueta correspondiente.

4
Rutvij Kotecha

Como la pregunta se refiere a los resultados de estudios reales, aquí hay un enlace a un estudio de 2009 sobre diferentes variaciones de mensajes de validación por Luke Wroblewski (autor de Fill in the Blanks).

Proporciona información muy interesante sobre la mejor manera de mostrar mensajes de validación, algunos de los cuales pueden interesarle. Por ejemplo,

[EN BLUR] MÉTODO AYUDA A LOS USUARIOS A COMPLETAR LOS FORMULARIOS MÁS RÁPIDAMENTE Cuando usamos el método "después" ([en el desenfoque]) ..., los participantes completaron el formulario de siete a diez segundos más rápido que cuando usamos el "mientras" ([en pulsación de tecla]) y "antes y mientras" métodos respectivamente.

En cuanto a la posición del mensaje de error, el estudio revela que

NO ESTÁ LEJOS: MANTENGA LOS MENSAJES DE ÉXITO PROCEDENTES FUERA DE LOS CAMPOS DE FORMULARIO Al mostrar la validación dentro de los campos de formulario no se logró ningún beneficio sustancial. El posicionamiento de estos mensajes fue, necesariamente, inconsistente. (Si bien es posible hacer que los mensajes de validación aparezcan dentro de los campos del formulario, es mucho más difícil mostrarlos dentro de las listas desplegables estándar, por lo que los mostramos fuera de estos elementos). La validación en el campo no fue más notable que los mensajes mostrados afuera los campos.

2- Con respecto a la visibilidad del mensaje (color, etc.), aquí está otro artículo sugiriendo a los diseñadores de UX que atenúen la severidad de esos mensajes y realmente hagan que los usuarios se sientan bien con su progreso (y no se sientan frustrados por su sin progreso)

Entre otras cosas, básicamente dice que deberíamos usar el color naranja/naranja para los mensajes de error de formulario: lo suficientemente alarmante cuando los usuarios lo ven pero menos estimulante físicamente como rojo (es probable que provoque pánico).

3
Son Do Lenh

No he encontrado ningún estudio sobre dónde es el mejor lugar para colocar mensajes de validación. Sin embargo, desde un punto de vista práctico, creo que las pautas de la interfaz de usuario son lo suficientemente cercanas. Microsoft es bien conocido por haber realizado una gran cantidad de investigación de primera mano en sus laboratorios de usabilidad para obtener la información en sus directrices. Por mucho que a todos nos guste elegir Microsoft por algunas prácticas de interfaz de usuario pobres, en general esas prácticas no siguieron sus Pautas de diseño de interfaz de usuario :)

Entonces ... Microsoft Windows User Experience Interaction Guidelines esencialmente elige un asterisco a la izquierda de la etiqueta y una información sobre herramientas con el mensaje :

mockup

descargar fuente bmml - Wireframes creados con Balsamiq Mockups

Las pautas también hacen algunos puntos perspicaces, que he resumido a continuación:

  • Si la mayoría de los controles son opcionales, no indique nada (Maneje la entrada requerida faltante con mensajes de error. Este enfoque reduce el desorden).
  • Si la mayoría de los controles requieren entrada, indique entradas opcionales con "(opcional)" después de la etiqueta.
  • Si todos los controles requieren entrada, coloque "Toda entrada requerida" en la parte superior del área de contenido.
  • Valide la entrada temprano, muestre los errores cerca del punto de entrada.
  • Use globos emergentes para errores de entrada del usuario que se pueden detectar de inmediato . * Los globos no requieren espacio de pantalla disponible o el diseño dinámico que se requiere para mostrar mensajes en el lugar.
  • Muestra solo un globo a la vez.
  • Use los errores en el lugar para la detección de errores retrasados ​​ (por ejemplo, después de enviar un formulario).

Curiosamente, no hay muchos detalles en Pautas de la interfaz humana de Apple sobre este tema, pero a continuación se muestra un resumen de los puntos relevantes que encontré:

  • Validar entrada temprano
  • Evite validar la entrada después de cada pulsación de tecla. La validación frecuente es molesta.

Nuevamente, aunque me doy cuenta de que no se trata de "estudios sobre mejores prácticas de diseño de mensajes de error", estoy seguro de que la investigación se centró en la formación de estas pautas y, como herramienta práctica, son un gran punto de referencia para este tema.

2
Scott Willeke

Marcar los campos obligatorios con * o marcar qué campos son opcionales con (opcional); lo que es mejor depende del punto de inflexión en el formulario.

Si tiene un formulario largo, digamos 40 campos (para exagerar, no estoy sugiriendo que un formulario debe tener 40 campos en una pantalla) y de esos 40, se requieren 36, entonces marcar 36 con * es ruidoso y se vuelve redundante.

Es mucho más simple hacer una declaración en la parte superior de que "todos los campos son obligatorios, excepto donde se marca como opcional". Por el contrario, un formulario con relativamente pocos campos obligatorios debe indicar los obligatorios.

En otras palabras, ¿cuáles debemos resaltar como excepciones?.

La tendencia hacia los formularios web de cara al público es solo pedir la información requerida para reducir las tasas de abandono, por lo tanto, el movimiento hacia el marcado opcional en lugar de requerido, ya que todos tienden a ser necesarios. Este no es siempre el caso en los sistemas corporativos/comerciales, aunque existen formas legítimas en profundidad que contienen campos legítimos opcionales y obligatorios.

Con respecto a la pregunta principal de ubicación del mensaje de error:
Depende del diseño del formulario con respecto a los campos etiqueta->.
Suponiendo que la etiqueta sobre el campo pondría el mensaje de error a la derecha del campo y proporcionaría tantas señales visuales como sea posible, como resaltar el borde del campo en rojo y el 'este campo es obligatorio' en rojo.

Razones:
1) colocación proximal del mensaje de error en el campo
2) no rompe la proximidad y la asociación de la etiqueta (lo que pondría el error entre la etiqueta y el campo)
3) su mensaje de error está actuando como una señal de lo que necesita arreglarse (el texto indica cómo). En este sentido, desea que su cartel sea una flecha que apunte a lo que el usuario necesita para actuar, que es el campo, no la etiqueta.
4) la mensajería de tipo de información sobre herramientas no es una convención bien establecida y, como alguien más ha señalado, corre el riesgo o cubre elementos (es poco probable que sea una información sobre herramientas real donde el usuario toma medidas para hacer esto) - también lo es Es poco probable que sea bueno para la accesibilidad.

Mi impresión inicial de los iconos de estilo de cara + resaltado + mensaje es que se trata de una sobrecarga sensorial. No estoy seguro de dónde debería enfocar mi ojo para obtener la información. El campo es lo que necesita arreglarse en el medio, pero hay información visual compitiendo por mi atención antes y después de esto, lo que significa mucho movimiento ocular y esfuerzo para que el usuario asimile el significado (Hipótesis pura, nunca he realizado pruebas de usuario en una configuración de formulario bastante similar)

2
GlenFinch

Después de leer Diseño de formulario web: completar los espacios en blanco e investigar sobre esto en la web, descubrí que los mejores están debajo de la entrada o a la derecha de la entrada.

Además, la presunción de que * = Requerido no siempre es correcta, algunas personas no lo saben. La forma más popular de hacerlo es tener una explicación de qué * está en la parte superior del formulario. O mi favorito es deshacerme de todos los campos no requeridos y tener "todos los campos requeridos" o algo similar en la parte superior del formulario.

2
Igor-G

Se hicieron buenas sugerencias sobre el resumen de los campos obligatorios sobre el formulario como un retiro del mercado.

Yo diría que el primer ejemplo que se muestra aquí es bastante bueno (mensaje de error al lado del mismo). Es posible que desee resaltar el campo en rojo también, pero no se ha demostrado que sea más efectivo.

Ahora, con respecto al tema de los botones de radio, diría que si necesita un mensaje de error de este tipo para un botón de radio, significa que el botón de radio no es la opción de diseño correcta por primera vez: de hecho, en esencia, un el botón de radio DEBE tener y DEBE tener SOLO una sola opción seleccionada por defecto. Esto significa que un botón de radio siempre debe presentar una opción predeterminada seleccionada, ya sea una opción "ninguna". En cualquier otro caso, debe considerar usar cualquier otra opción de diseño que se ajuste a sus necesidades (por ejemplo: casillas de verificación si se pueden seleccionar varias opciones, o menú desplegable o lo que sea).

2
Ivan

Los mensajes de error alarmantes pueden hacer que los usuarios estén ansiosos. La ansiedad del usuario puede hacer que los usuarios abandonen su formulario. No tiene que enfatizar lo mal que el usuario se equivocó para que lo arreglen.

Los mensajes de error tranquilizadores harán que los usuarios se sientan más cómodos reparando sus errores. El objetivo es llamar su atención y guiarlos a corregir sus errores, no impresionarles de que cometieron un gran error.

1
Relvid

Desafortunadamente, no parece haber una forma "estándar" de mostrar un error para un from, que era la pregunta original.

Intenté buscar una respuesta más detallada, pero creo que no hay una solución definitiva porque hay muchos estilos diferentes de formas. Los formularios vistos en un escritorio generalmente tendrán más espacio para texto de error que un formulario en un dispositivo móvil. Recientemente, incluso tiene que pensar para qué sistema operativo está diseñando ahora que el estilo moderno de Windows 8 (formalmente Metro) tiene pautas de estilo específicas para IE. Agregue el hecho de que cada navegador moderno tiene su propio estilo para la validación de formularios HTML5, y estandarizar esto se convierte en un desastre.

Lo máximo que pude encontrar fue un conjunto de pautas de Jakob Nielsen ( http://www.useit.com/alertbox/20010624.html ). Estas pautas son muy amplias, con la única regla explícita de que no solo puede confiar en el color (cambiar el texto para el campo rojo) porque eso puede dificultar la lectura de los usuarios con discapacidades. Los usuarios daltónicos o aquellos que usan lectores de pantalla no podrán diferenciar el texto.

Esa es la única reserva que tengo con la solución de llamada también publicada aquí. ¿Los usuarios con discapacidad podrían leerlo?

Una solución podría ser adaptar un estilo que sea utilizado por la mayoría de los usuarios específicos (Microsoft, Google o Apple) e ir con eso.

1
Kevin G

compartiendo uno de los enfoques que diseñé para un proyecto muy intensivo en formularios y fue apreciado por el equipo, pero debido a alguna restricción no pudimos construirlo.

Interacción: en el momento en que mueva el cursor, la IU le mostrará un mensaje de instrucciones del lado del cliente para corregirlo antes de activar el botón de envío.

enter image description here

1
Rajesh R. Nair

Creo que google tiene una solución simple para los mensajes de error en su formulario de registro; cambie el borde a rojo para resaltar el campo y un mensaje simple debajo con un mensaje en rojo.

Esto es fácil cuando se escala un diseño a un dispositivo pequeño y es claro y conciso.

0
Jay

Creo que la forma en que Facebook muestra mensajes de error es más eficiente y fácil de usar. Mira la captura de pantalla. Este no está consumiendo ningún espacio extra. El usuario obtiene lo que está mal y también para saber con más detalle, puede simplemente desplazarse en el campo para saber por qué el campo es obligatorio. enter image description here

0
Parag Bandewar

Estoy de acuerdo con otros en que debería haber un resumen. Ya sea una cuenta específica o "Algo salió mal aquí. Revise las entradas resaltadas, realice los cambios necesarios y vuelva a enviar el formulario. Gracias".

Este mensaje podría estar en la parte superior o inferior del formulario de envío, pero solo debe ser visible y destacarse para el usuario, sin desplazarse, de inmediato. Entonces, si la magia de JavaScript puede mantener la página baja con el botón de enviar, genial. Ahí es donde estaba el usuario, por lo que hay menos movimiento/parpadeo de la página.

Entonces, creo que la convención más simple será la versión "Debajo de la etiqueta", de sus ejemplos. La etiqueta es cómo se orientará primero el usuario, y tener el texto de error justo debajo tiene sentido, con un lugar accionable (el campo), justo debajo.

Me gustan los ejemplos de 'caja roja' y las burbujas de desplazamiento, pero mi interfaz de usuario favorita para esto sería uno donde los campos en cuestión son:

  • Marcado con texto de error que se ve diferente más allá del color. La cursiva o negrita con color es mejor que solo el color. El color único (con rojo como estándar) es bueno, pero todos sabemos acerca de los usuarios daltónicos, ¿verdad?
  • Destacando entre los otros campos de una manera más allá del texto y el color del texto. Sería genial que todos los campos "ok" estuvieran un poco atenuados, de modo que uno pudiera ver los que necesitan edición destacarse en un contraste más nítido. Sin embargo, si uno quisiera editar uno de estos campos "ok", un clic debería "abrirlos" para una edición "brillante".
0
Tom Quick

Quiero secundar lo que dijo JonW con una ligera alteración. Para aquellos usuarios en lectores de pantalla, querrás resumir los errores en la parte superior del formulario. Luego, una vez que ingrese al formulario, desea notificar a los lectores de pantalla de los errores individuales antes de los campos.

Me encontré con este problema en el trabajo y quería encontrar un método que fuera utilizable y accesible. Encontré esta publicación de blog http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/ que ayudó enormemente. Siendo que trabajo en el desarrollo de aplicaciones para una universidad, cosas como esta son muy importantes.

Hay mejores prácticas, métodos que han demostrado que funcionan, pero nada supera las pruebas reales de los usuarios. Es invaluable.

El ejemplo se basa en jQuery y el complemento validar.

Para resumir:

  • Agrupe todos los errores para que los usuarios con tecnología de asistencia (AT) entiendan lo que está mal desde la perspectiva de un pájaro.
  • Coloque los errores individuales sobre cada campo del formulario, de modo que AT) alerta a los usuarios del error antes de que completen el campo.
  • Si es posible, vincule los errores resumidos a los campos individuales en cuestión, como en el ejemplo.

Finalmente, si necesita un cierto formato, asegúrese de mencionar el formato en la etiqueta para reducir la cantidad de errores (y para facilitar la vida de aquellos que no pueden ver bien o nada).

0
zxbEPREF

Siempre es mejor

  1. Mostrar mensajes de error en línea
  2. Y establezca el foco en el primer campo de mandato vacío o en el campo con datos no válidos después del envío del formulario.

En caso de validación de datos en tiempo real/en vivo

  1. Enfocando el campo rojo y mostrando un mensaje de error en línea

En caso de validación del lado del servidor, por ejemplo, donde js está deshabilitado -

  1. Todavía muestra un mensaje de error en línea con foco en el campo vacío o el campo con datos no válidos

Práctica habitual -

  1. La validación de datos debe ser en tiempo real (la información sobre herramientas sugiere el formato correcto cuando el usuario ingresa datos no válidos)
  2. La verificación del campo del mandato debe ocurrir en el envío del formulario: esto ayuda a evitar demasiada intervención del sistema en la entrada de datos del usuario)

Aún así, la forma tradicional de marcar los campos de mandato con "*" es la mejor