Formularios

Recomendaciones generales #

• En el caso de formularios muy largos, es conveniente agrupar los elementos del formulario por contexto.
• Si, en un formulario, la mayoría de los campos son obligatorios, es más adecuado destacar aquellos que son opcionales.
• Si se comete un error al completar un formulario, los campos que provocan dicho error deben ser fácilmente identificables y siempre acompañados de la razón del error.
• En ocasiones, puede ser interesante ofrecer algún texto de ayuda al usuario que se mantenga visible en todo momento y muestre pautas relativas al campo. Este texto de ayuda solo debe emplearse en aquellos campos de formularios que se consideren complejos o propensos al error.

Elementos de los formularios #

Los formularios están compuestos por Inputs y grupos de inputs. En general, todos los elementos tienen una anatomía similar y cuentan con los mismos estados (activo, relleno, error, desactivado, enfocado) y opciones de tamaño (base y pequeño).

Inputs #

Son campos de formulario independientes para introducir un dato en concreto.

Grupos de Inputs #

Son varios campos agrupados para introducir datos relacionados entre sí.

Anatomía de un input #

Estados de los inputs #

Activo #

El campo está activo y listo para ser usado.

Desactivado #

El campo no se puede usar.

Error #

Indica que hay un problema con el campo introducido, es necesario acompañar este estado con un mensaje de error claro.

Enfocado, con cursor encima (focus, hover) #

Son estados de apoyo a la interacción que nos ayudan a identificar sobre el elemento que estamos actuando.

Tamaño #

Tamaño base #

Utilizar por defecto para cualquier tipo de situaciones y layouts. Siempre que sea posible se recomienda usar este tamaño por motivos de accesibilidad.

Tamaño pequeño #

Se recomienda su uso cuando el elemento estándar sea demasiado grande para el espacio donde debe de encajar, por ejemplo dentro de tablas, cards, grupos de filtros o similares.

No deben convivir en un mismo grupo componentes de diferentes tamaños.

Composición #

Campo en columna #

Es el que se debe usar por defecto, ya que facilita la lectura y la maquetación responsive.

Campo en línea #

Se puede usar en situaciones concretas en las que se necesite reducir el espacio del formulario o cuando los campos a rellenar están muy relacionados entre sí, por ejemplo nombre y apellidos.

Errores #

En general se recomienda que la validación de los formularios se realice al onsubmit para evitar inconsistencias y malos usos de la validación automática. Puedes consultar la página del componente Resumen de errores en la sección de Avisos.

Mensaje de error general #

Cuando se activan los errores de un formulario es necesario que aparezca un mensaje general indicando todos los errores detectados y su causa.

Cada error debe tener un ancla al campo concreto que da error para facilitar que se encuentren los campos problemáticos en formularios largos.

Este mensaje debe estar localizado en un sitio que sea visible tras pulsar en el submit.

• Si al hacer la validación la página se recarga y no mantiene el scroll, el mensaje debe aparecer en la parte de arriba del formulario.
• Pero si la validación se hace sin recargar la página se debe mostrar encima del botón de submit.

Mensaje de error por campo #

Por lo general, los errores aparecen en dos situaciones: cuando el campo es requerido y no se ha completado o cuando el formato del dato introducido no es correcto. Cuando se muestran errores debe aparecer un error en el campo específico indicando de manera clara la causa del error.

Buenas prácticas generales para los campos #

• El elemento label es obligatorio. En caso de que se quiera ocultar por tener poco espacio se debe añadir la clase sr-only, para que sea legible por los lectores de pantalla. En tal caso se recomienda incluir un placeholder o una pista visual clara de la información a incluir en el campo.
• Las labels deben ser claras y concisas. Emplear lenguaje claro que sea comprensible por las personas que lo usen, evitar tecnicismos y en caso de ser necesario se puede incluir descripción adicional en el hint.
• Siempre que sea posible, se recomienda disponer todos los campos de formulario en una sola columna. para asegurar una buena visibilidad de los componentes en dispositivos móviles. Hay algunos input group que vienen predefinidos que se adaptan a los móviles.
• En el caso de input de texto o selectores, se recomienda que el ancho del input corresponda con el tamaño del dato a introducir, para dar pistas del dato que se solicita, por ejemplo un código postal.
• Por lo general no deben convivir en un mismo formulario componentes de diferentes tamaños.