Usar atributo TITLE remplazando a LABEL

post - - 2 replies - share

Supongamos que tenemos la siguiente tabla de datos:

En la tabla vemos que hay unos campos de formulario para introducir el número de unidades de cada producto y que no tienen un texto que pueda usarse como LABEL. Ante esta situación he pensado que podría asociar explícitamente el INPUT con un LABEL de cada campo en la columna producto (reproductor mp3, impresora, caja 25 dvd).

<tr>
	<th id="pro1">
		<label for="a_uds">
			Reproductor <dfn title="Es un formato de audio digital"><abbr lang="en" xml:lang="en" title="MPEG-1 Audio Layer 3">MP3</abbr></dfn>
		</label>
	</th>
	<td headers="pro1 tpvp">
		40 €
	</td>
	<td headers="pro1 tuds">
		<input type="text" id="a_uds" name="a_uds" value="1" size="4" />
	</td>
</tr>

Vemos que LABEL e INPUT se encuentran asociados por el identificador “a_uds”.

Aunque esta forma de proceder no sea “mala”, quizás la etiqueta textual queda “lejos” del control de formulario, lo que puede provocar cierta confusión a los usuarios de lectores de pantalla.

La solución más directa en estos casos es usar el atributo TITLE de los controles de formulario.

<tr>
	<th id="pro1">
		Reproductor <dfn title="Es un formato de audio digital"><abbr lang="en" xml:lang="en" title="MPEG-1 Audio Layer 3">MP3</abbr></dfn>
	</th>
	<td headers="pro1 tpvp">
		40 €
	</td>
	<td headers="pro1 tuds">
		<input type="text" title="Número de unidades para: Reproductor mp3" name="a_uds" value="1" size="4" />
	</td>
</tr>

Usando title="Número de unidades para: Reproductor mp3" podemos ayudar a que el usuario sepa como actuar con ese control.

Etiquetas dentro del control input (III)

post - - 1 reply - share

Hace casi un año hablaba sobre un posible problema de usabilidad y accesibilidad en el formulario de inicio de sesión que tiene Facebook.

Desde entonces han mejorado un poquito la accesibilidad, aunque siguen sin usar la etiqueta label para el campo de Email de inicio de sesión. En su lugar han puesto los atributos title y value. El problema es que algunas ayudas asistivas pueden no interpretar el atributo title, por lo que esta solución no sería suficiente.

Respecto a la usabilidad puede ser debatida, pero el hecho de perder (lo que tienes que rellenar en ese campo) cuando haces clic en el, me parece un error. Eso si, visualmente y a nivel de interacción queda chulisimo.

Hoy, Kus (de uninstallme.com) me comenta:

Acabo de encontrar esto http://www.csskarma.com/lab/slidinglabels/ y me he acordado de este post. No lo he analizado a fondo, pero me ha parecido una buena idea.

Y tanto que es buena idea, la accesibilidad es impecable. Se usa JavaScript como un complemento no intrusivo que se encarga de realizar el efecto y la transición del label. Solo le veo una pega, que puede resultar cansino, yo lo usaría para formularios muy pequeños, con 2 o 3 inputs.

Un lujo contar con tus aportaciones María 😉

Button y img, botón de formulario con icono

post - - 7 replies - share

Para crear un botón en HTML contamos con dos etiquetas:

Ambas son válidas. La segunda de ellas es menos usada (con diferencia) aunque esconde tras de si muchas ventajas al poder anidar en su interior contenido.

Botón tradicional con input

<input type="submit" value="Eliminar" />

Botón + icono con button

<button type="submit"><img src="delete.gif" alt="x" />Eliminar</button>

Nota: En este caso se ha usado un GIF con el mismo color de fondo que el botón. Cuidado con el formato PNG y sus problemas en Internet Explorer.

Read more

Asociación implícita de etiquetas LABEL para controles de formulario

post - - 9 replies - share

Aprovechando las bondades del tag LABEL podemos mejorar tanto la accesibilidad como la usabilidad de los formularios en las interfaces web.

LABEL se encarga de asociar la etiqueta textual a un control determinado (input, radio, select, etc.) proporcionando información acerca del control.

Cabe destacar que LABEL cuando recibe el foco, automáticamente se lo cede al control asociado.

Read more

Merece la pena crear un interfaz y personalizar controles

post - - leave a reply - share

Empeñarse en crear/personalizar: botones, campos de texto, checks, radios, y demás controles, ¿es realmente beneficioso para crear un sentimiento de marca?

Reflexión

Pienso que esta bien dotar de cierta personalidad un interfaz, pero nunca con fines de marca. Pensemos que los usuarios ven miles de Web, ellos simplemente quieren alcanzar sus objetivos en cada sitio Web, ¿como van a recordar los diseños y acciones de los botones de un determinado sitio Web?.
Tampoco creo que sea bueno empeñarse en diseñar todos los botones y controles de una interfaz, haciéndolos distintos a los suministrados por el sistema operativo, simplemente por razones de diseño.

Tener en cuenta la usabilidad

En usabilidad, y para las aplicaciones mas o menos grandes, siempre que se puedan usar los controles del sistema operativo deberían de usarse. Es inútil personalizar controles propios, para formularios o lo que sea. Lo considero perdida de tiempo, volver a inventar una rueda ya creada.
Las compañías que desarrollan los SO, invierten miles de millones en investigación para diseñar y desarrollar estos controles. Al final son estos controles (los que ofrecen MacOS, Windows, Linux) los que el usuario conoce, y no los de nuestra aplicación Web en concreto.

No nos dejemos arrastrar por modas

Pienso que no se debe usar tal o cual tecnología por ser novedosa. Se deben usar las tecnologías novedosas, pero no para desarrollar cosas que en la actualidad ya tienen solución (controles de formulario), que al final resultan: mas factibles, mas estándares, mas usables, mas accesibles. Y por que no decirlo: mas económicos pues no tienes que invertir en tiempo de desarrollo.

Recordemos que implica la usabilidad

Usabilidad también se puede entender como “no hacer pensar al usuario”, “no sobresaltarle”. Si ve que algo ocurre normalmente, y que conoce los controles, entonces se sentiría seguro, es ahí cuando hay usabilidad (cuando no se da cuenta de que todo esta a la perfección y es amigable).