Índice de apartados de esta página
Formularios
Cuando diseñes un formulario, ten en cuenta que...
- Solemos utilizar una serie de patrones de formularios para solicitar información.
- 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.
Índice de apartados de esta página
- Inputs
- Grupos de Inputs
- Anatomía de un input
- Estados de los inputs
- Tamaño
- Composición
- Errores
- Buenas prácticas
Inputs #
Son campos de formulario independientes para introducir un dato en concreto.
Entrada de texto
Elemento básico de formulario que permite la inserción y edición de texto en una única línea.
Área de texto
Elemento de formulario que permite la inserción y edición de texto en varias líneas.
Selector
Permite seleccionar una opción de entre un listado de varias. Plegado, muestra la opción seleccionada.
Carga de archivos
Permite abrir el explorador de archivos para cargar un fichero en el formulario.
Grupos de Inputs #
Son varios campos agrupados para introducir datos relacionados entre sí.
Botón de radio
Se utiliza cuando solo puede seleccionarse una opción en un listado de varias de ellas.
Casilla de verificación
Ofrece la posibilidad de seleccionar una o varias opciones de las que se ofrecen.
Árbol
Ofrece la posibilidad de seleccionar una o varias opciones organizadas jerárquicamente.
Bloques de datos
Grupos estandarizados de entradas de texto, las cuales comparten sentido semántico.
Anatomía de un input #
- Etiqueta. Indica la información a incluir en el campo, siempre tiene que estar. En caso de que se quiera ocultar deberá tener la clase sr-only, para que sea legible por los lectores de pantalla.
- Pista. Opcional, es una descripción del dato a introducir.
- Mensaje de error. En caso de que el campo requiera validación o sea obligatorio, puede aparecer un error indicando el problema con el dato introducido.
- Placeholder Indica la información a incluir en el campo, siempre tiene que estar. En caso de que se quiera ocultar deberá tener la clase sr-only, para que sea legible por los lectores de pantalla.
- Contador de caracteres. En caso de los campos de tipo entrada de texto o área de texto se puede incluir un placeholder que de pistas de la información a introducir.
Estados de los inputs #
Error:Error
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.
Título del mensaje de error
Por favor, corrige los siguientes errores
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 #
- 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.