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. _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
