Índice de páginas
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.
- Debes marcar qué elementos son obligatorios. Si lo haces con un asterisco (*) debes aclarar su significado al principio del formulario.
- 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.
Í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.
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.
Calendario
Desplegable que permite elegir una fecha o rango de fechas de manera visual.
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.
- 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 un ejemplo del valor que se debe introducir.
- 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.
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 elaria-describedby
del input. - El mensaje de error es un párrafo con un
id
y un<span>
conError:
al inicio del mismo, sólo visible para lectores de pantalla. Es llamado por elaria-errormesage
del input. Adicionalmente, el input debe llevar unaria-invalid=true
.
Más información en la sección ARIA Landmarks Example de W3C
Qué usar | Dónde | Función |
---|---|---|
aria-label o aria-labelledby |
Etiqueta <form> |
Describe el propósito del formulario. |
<legend> |
Dentro del <fieldset> |
Título del grupo de datos. |
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.