[cadius] Sobre usabilidad en formularios.

[Juan José Fernández García]

Hola
Me atrevo a dar algunas respuestas sobre las dudas surgidas sobre la 
implementación en los formularios de Pau Ramón.

Debo precisar primero que, yo por lo menos, suelo contestar y contestarme 
estas y otras preguntas entendiendo como primera premisa que "lo que no es 
accesible, no es usable" y que, por extensión "si mejoramos la accesibilidad 
de algo, estaremos mejorando seguramente, su usabilidad"... Con esto de por 
medio, creo poder dar algunas respuestas:


1.- "¿Es mejor poner la "label" a la izquierda de las cajas de texto o 
encima?"
Las cajas de etxto del formato "textarea", "ocupan" un espacio considerable 
porque no queremos meterle al usuaio el engorro de escribir algo complejo en 
un sitio angosto. Todos parecemos inclinados a que si type="text" pues lo 
lógico es izquierda-derecha, mientras que si es un "textarea" entonces queda 
en encima-debajo, generalmente gracias a un simple e inocuo < /br> Algunos 
navegadores de usuarios con discapacidad no reconocen la asociación entre un 
campo y su label si aquel no está inmediatamente precedido de éste. La 
inserción del < /br> afecta a esta restricción.

2.- "¿Es mejor señalar los campos obligatorios o los opcionales? y si hay 
más opcionales que obligatorios?"
Entiendo que, se ha convertido en costumbre, (y aunque es algo pueril, es 
argumento no contradicho por otros) el indicar qué campos son los 
obligatorios y no otros. Esta indicación se suele hacer de varias formas, 
siendo una de las más extendidas, colocar un asterisco en el final del 
"label" y una nota adicional al comienzo o al final del formulario 
recordando que los campos con tal característica son obligatorios. 
Lamentablemente hay gente empeñada en marcar esa obligatoriedad con colores 
(rojo, por ejemplo) sin ninguna indicación escrita lo que excluye 
automáticamente a las personas con discapacidad visual.


3.- "¿Si hay alguna restricción (como por ejemplo un número mínimo de 
caracteres), donde ponerla? Es correcto dentro de las cajas de texto?"
Para los pequeños avisos (que siempre deben ser claros, concisos y escuetos) 
tenemos la etiqueta "title" y la etiqueta "alt" de la que no siempre parece 
que nos acordemos y cuya interactividad con el usuario es muy intuitiva. Por 
contra introducirlo dentro de la caja puede producir muchos desconciertos. 
Paso a continuación un ejemplo de algo que, entiendo bien hecho:
<label class="obligatorio" for="dir">Dirección Postal* </label> <input 
id="dir" name="dir" type="Cubrir sólo en caso de domicilio diferente al del 
pagador." value="(Sin datos)" alt="" onblur="if(this.value=='') 
this.value='(Sin datos)';" onfocus="if(this.value=='(Sin datos)') 
this.value='';" />


4.- "¿Para un conjunto de 2 a 5 opciones, es mejor usar radio buttons o 
combo boxs?"
En función del número y de la complejidad del texto asociada a cada ítem (a 
textos largos, complejos, o poco fáciles de diferenciar) es preferible el 
radio button porque puedes leer todas las alternativas con calma mientras 
que con los combos, anda la manipulación del ratón y/o del teclado de por 
medio. Y en cuanto al número, pues como ya te han dicho, para números bajos 
los radio y para altos los combos aunque dando más prioridad, entiendo yo, a 
la complejidad de la que hablaba antes.


5.- "¿Formularios largos o separados en varios pasos?"
La sencillez tiene que estar siempre de por medio. Nuestra experiencia como 
gente que está todo el día detrás de estos cacharros nos empuja muchas veces 
a la creencia de que los demás tienen equivalentes niveles de destreza y no 
es así. Lo lógico es hacer agrupamientos temáticos que ayuden al usuario a, 
no perder de vista el bosque aunque tenga un árbol delante, comprender mejor 
la globalidad del procedimiento al que lo estamos sometiendo (no olvidemos 
que lo estamos sometiendo, aunque sea con dulces palabritas). Pueden ser 
varios pasos temporales, varias pestañas, etc. e incluso, si el asunto es 
muy complejo, poder guardar los datos en el servidor de manera temporal para 
luego rescatarlos y continuar con ellos en otra ocasión. No olvidemos 
tampoco que los departamentos de sistemas nos están exigiendo constantemente 
que los "timeout" sean muy breves para no comprometer (ellos dicen que la 
seguridad y nosotros intuimos que el sobrecalentamiento del servidor) y que 
si el formulario para un no experto supone un tiempo de ejecución cercano o 
mayor al del timeout, habrá que pensar en esos depósitos temporales para que 
se pueda acometer el formulario en varias atacadas.


6.- "¿Validación vía ajax, tradicional o ambas?"
Esta pregunta me sobrepasa, carezco de la formación necesaria para poder 
contestar sin titubeos, pero ten en cuenta algo fundamental: ajax, 
javascripts y demás scripts, no son, por si, accesibles, que tendrás por lo 
tanto grupos de usuarios a los que no les va a funcionar porque simplemente 
no tienen habilitadadas las ejecuciones de los scripts y que, por lo tanto, 
no van a ser analizados por esas validaciones. Su formulario cubierto 
debería llegará a ti (de lo contrario es que tu diseño no es accesible y, 
por lo tanto, tampoco usable), pero aún llegando a tí, llegará sin validar y 
debes tenerlo previsto.


Perdón por ser tan extenso...
Es algo que forma parte de mi naturaleza y me es difícil sustraerme a tal 
vicio.
Juan.