Formularios

Índice de apartados de esta página

• Inputs
• Grupos de Inputs
• Anatomía de un input
• Estados de los inputs
• Tamaño
• Composición
• Accesibilidad
• Buenas prácticas

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 #

1. Etiqueta. Indica la información a incluir en el campo, siempre tiene que estar.
2. Pista. Opcional, es una descripción del dato a introducir.
3. 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.
4. Placeholder. Indica un ejemplo del valor que se debe introducir.
5. 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 #

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.

Accesibilidad #

Cómo funciona #

• Rodeado con el elemento <form>, donde se encuentran los distintos <fieldset> que agrupan los inputs. Cada <form> tiene una etiqueta que identifica su propósito.
• Cuando se realiza un submit de un formulario con errores, el foco debe ir a un aviso con el resumen de errores. Adicionalmente, cada input con error, además de destacar visualmente, debe tener un mensaje de error que lo identifique con una serie de atributos ARIA.
• Cada input tiene unos elementos comunes:
• El label apunta al id del input y debe ser único para cada uno.
• El hint es un párrafo con un id único. Es llamado por el aria-describedby del input.
• El mensaje de error es un párrafo con un id y un <span> con Error: al inicio del mismo, sólo visible para lectores de pantalla. Es llamado por el aria-errormesage del input. Adicionalmente, el input debe llevar un aria-invalid=true.

Más información en la sección ARIA Landmarks Example de W3C

Buenas prácticas #

• El elemento label es obligatorio.
• 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 bloques de datos que se adaptan a móvil automáticamente.
• 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.