DESY

Sistema de Diseño del Gobierno de Aragón.

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

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

Anatomía de un input con todos sus subcomponentes
  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

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 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

Qué tener en cuenta
Qué usar Dónde Función
aria-label o aria-labelledby Etiqueta <form> Describe el propósito del formulario. Debe ser visible
<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.