Una parte muy a tener en cuenta a la hora de desarrollar nuestras aplicaciones Web son los formularios. Estos han de ser simples, consistentes, comprensibles, accesibles, etc. En este artículo de hoy voy a enseñaros la forma en la que suelo hacer mis formularios, y los motivos por los que he elegido determinados detalles que acostumbro a usar.
Para hacer más sencilla la comprensión de todo esto he creado un sencillo ejemplo con un mismo formulario dividido en tres estados distintos, donde cada uno de ellos muestra una etapa de la "vida de un formulario".
Primera etapa: Formulario en estado normal
La primera etapa de todo formulario es aquella en la que nos lo encontramos por primera vez, impoluto, limpio completamente, esperando ser cumplimentado y enviado.
Es una etapa muy importante, ya que debemos conseguir que de un simple vistazo el formulario sea comprensible para el usuario. Y por si fuera poco, hemos de usar nuestro lenguaje de marcado favorito de forma correcta, preocupándonos además por la accesibilidad del formulario.
Hay diversas cosas que suelo realizar siempre que hago un formulario. Una de ellas es englobarlo con el elemento fieldset con un atributo title bien descriptivo, y colocándole su correspondiente legend:
<fieldset title="Formulario general en estado normal que realiza una función determinada">
<legend>Formulario general en estado normal</legend>
</fieldset>
Otra cosa imprescindible es el uso de los label. A todos los controles del formulario, salvo a los botones, les coloco su label correspondiente. Debo destacar que normalmente acostumbro a englobar todo el control con el label además de usar el atributo for de este, me explico:
<label for="cajaTexto1">Caja de Texto 1 <span class="obligatorio">(Obligatorio)</span><br />
<input type="text" id="cajaTexto1" name="cajaTexto1" maxlength="255" title="Caja de Texto. (Campo obligatorio, con un límite de 255 caracteres.)" />
</label>
Como podeis ver, toda la caja de texto se encuentra englobada dentro de un label, y este a su vez hace uso del atributo for para referenciar a la caja de texto. Hay personas que sólo hacen uso del atributo for, pero hay algunos agentes de usuario que todavía no soportan esta forma de referenciación, así que procuramos mantener ambas formas para evitar incompatibilidades.
Si os fijais, la caja de texto usa el atributo maxlength, que nos permite limitar el número de caracteres que van a poder introducirse en ella. Si se conoce este límite, es más que recomendable hacer uso de este atributo, para ahorrarnos sustos si, por ejemplo, los datos van a guardarse en una Base de Datos y al usuario le da por meter un capítulo entero de El Quijote.
Además también es recomendable dotar a todos y cada uno de los controles del formulario del atributo title, explicando brevemente qué se debe hacer en ese control, y si es posible, informar de las limitaciones: obligatorio o no, tipos de datos que acepta, (sólo números, sólo letras, etc.) Con respecto a este mismo tema, en el texto del label, y para que el usuario tenga acceso a esta información a golpe de vista, suelo añadir también de forma muy breve, las limitaciones del campo. Las englobo en un span para poder manejarlas posteriormente de forma sencilla con CSS.
Por destacar otro detalle, en el ejemplo podéis ver que en el desplegable hago uso de optgroup para dividir los grupos de elementos que componen el control. Es importante que useis este elemento si vuestros desplegables necesitan subdividir en grupos los elementos, nada de usar option con guiones ni nada de eso.
<label for="combo">Desplegable <span class="obligatorio">(Obligatorio)</span><br />
<select id="combo" name="combo" title="Desplegable con 5 opciones divididas en 2 grupos. (Obligatorio elegir una opción)">
<optgroup label="Grupo 1">
<option selected="selected" value="1">Opción 1</option>
<option value="2">Opción 2</option>
</optgroup>
<optgroup label="Grupo 2">
<option value="3">Opción 3</option>
<option value="4">Opción 4</option>
<option value="5">Opción 5</option>
</optgroup>
</select>
</label>
Ver ejemplo para el formulario en estado normal
Segunda etapa: Formulario con mensajes de error
Esta etapa, obviamente, no siempre va a ocurrir, pero debemos tener especial cuidado a la hora de controlarla, porque un formulario con mensajes de error poco claros, e incluso liosos o inexistentes, hará que todo el proceso se vaya al garete.
Mis formularios suelen tener tres formas de aviso distintas para los errores:
- Mensaje general con una lista de puntos a comprobar
- Estilos CSS distintos en los controles incorrectos
- Mensaje informativo breve junto a cada control incorrecto
Todos estos mensajes han de destacar de forma muy clara por encima del aspecto normal del formulario, para que así el usuario pueda localizarlos y comprenderlos sin el menor esfuerzo.
Si observais el ejemplo, lo podreis ver claramente. Tonos rojos para todos los mensajes, un grosor de borde significativo para los controles incorrectos, y un pequeño texto junto a cada uno de ellos.
Mirando el código del mensaje general justo al comienzo del fieldset os dareis cuenta de que he usado el elemento big con un span interno que contiene un texto llamativo que luego oculto con CSS. Esto lo hago pensando en los usuarios que no tienen los estilos CSS activados. Puesto que no se percataran de los estilos con tonos rojos y demás, les doy un elemento "distinto" y un texto impactante para que su atención se centre sobre el mensaje de forma más sencilla.
<div class="mensaje error">
<p><big><span>*** !ATENCIÓN!</span> Encabezado error</big></p>
<p>Etiam porta semper nisl. Aenean lacus risus, condimentum id, pharetra in, dictum vel, quam. Maecenas non mauris ut dolor cursus dignissim.</p>
<ul title="Lista de puntos a verificar">
<li>Debes rellenar el campo obligatorio "Caja de Texto 1"</li>
<li>El campo "Caja de Texto 2" no tiene un formato correcto. Sólo se aceptan caracteres alfanuméricos</li>
</ul>
<hr />
</div>
Ver ejemplo para el formulario con mensajes de error
Tercera etapa: Formulario ejecutado de forma satisfactoria
Esta es una etapa meramente informativa, y no es absolutamente necesario, ya que un formulario puede terminar con una redirección a otra página, con un mensaje simple porque no se necesite tener el formulario de nuevo, etc.
De todas formas la estructura es exactamente igual que la del mensaje general de errores de la etapa anterior, salvo que con unos estilos distintos en tonos "menos preocupantes" que el rojo. También, del mismo modo que antes, pienso en los usuarios con CSS desactivado colocando un mensaje llamativo que capte su atención incluso sin estilos.
Ver ejemplo para el formulario ejecutado satisfactoriamente
