...
2. El navegador soporta javascript. �Como hacer que la validaci�n sea usable, y al tiempo accesible por personas que por ejemplo usan lector de pantalla?
...
Lo m�s seguro es usar los elementos nativos de cada sistema, que por otro lado ya se supone son conocidos por los usuarios. Al menos, tienes la certeza de que los alert de javascript son mucho m�s frecuentes que cualquier sistema que t� inventes, y por lo tanto ya se entienden.
Es que al tema he leido un art�culo donde dec�a que esto �ltimo no era del todo posible, y propon�a sacrificar un poco la usabilidad sacando mensajes de alert con javascript con un error cada vez, de uno en uno seg�n se vayan corrigiendo, de forma que un lector pueda leerlo.
Esta t�cnica es la que m�s me ha convencido aunque est�ticamente no es tan llamativa y puede ser molesta . Siempre tengo en cuenta que hay tres tipos de verificaciones en los formularios normales:
1) Campos con verificaci�n inmediata: Por ejemplo, no es del tipo correcto. Esto se puede validar con JS "onchange" y mostrar la alerta de inmediato y devolver el foco al campo (o bien vaciar el campo). Seg�n mi experiencia he visto que para usuarios recurrentes esta opci�n termina funcionando como alerta de errores de tipeo m�s que otra cosa, y suele agradecerse.
2) Campos en requeridos en blanco: utilizo verificaci�n JS y un (1) solo mensaje de alerta "Llene todos los campos", que devuelve el foco al primer campo requerido sin llenar. La suposici�n aqu� es que al leer el mensaje (y no hay otra opci�n que leerlo si usas un alert) el usuario llena el campo y hace una verificaci�n del resto de los campos faltantes. Si no los verifica, el algoritmo se repite devolviendo el foco al siguiente requerido faltante.
3) Verificaci�n en servidor. Nada que decir ac�, ya hay consenso :)
Pero no me gusta esta opci�n demasiado porque resulta algo molesto para los usuarios "corrientes", que suelen ser la mayor�a.
En algunos casos, como la verificaci�n, me interesa que sea molesta pues como programador le "proh�bo" al usuario que use mal mis formularios y se lo hago saber as�. No creo que "usable" sea algo que necesariamente despierte sentimientos alegres.
En fin, quiz� la mejor opci�n que veo es no usar validaci�n en cliente y hacerla solo en servidor como dices. Aunque tarde un poco m�s, tambi�n el ancho de banda cada vez va en aumento, as� que no debe de ser mucho problema.
Jos� Luis, el costo y molestia me parece mucho mayor en la validaci�n exclusiva del servidor, sin intentar javascript antes. Al enviar los datos se tiene la "esperanza" de que todo ha funcionado correctamente y supone una cierta sorpresa encontrar recargado el mismo formulario con los errores se�alados. Bueno, esto �ltimo es una opini�n personal pero la creo firmemente.
Hay aplicaciones del DOM en formularios muy agradables de ver en la pr�ctica, dejan el c�digo puro y se acoplan como capa opcional. En particular, podr�as mirar el uso de <LABEL> que hacen en youngpup.net
http://www.youngpup.net/2001/labels
Muchos saludos!
Juan Pablo Gil Ram�rez
Trabajando para : http://www.conectu.com - http://www.turismochile.com
Web personal: http://www.huinca.net/ (sobre fundamentalismo web)
(56)(45)248000 - Temuco - Chile
_______________________________________________ altas, bajas y modificaciones: http://cadius.org/mailman/listinfo/lista_cadius.org
