Tag Archives: formularios accesibles

Validación en el cliente con Mootools para formularios accesibles

Tal como discutimos en el artículo anterior acerca de formularios –Un básico copia y pega de un formulario de contacto accesible –  hicimos la validación del formulario usando una clase que resalta y nos indica los elementos que necesitan ser llenados o corregidos en caso de que la validación haya fallado.

Ahora, el único punto débil desde el punto de vista del usuario es el hecho de que necesitamos recargar la página cada vez que se haga click en submit y esto es de alguna forma fastidioso. Hoy en día la mayoría de los navegadores ofrecen capacidades de procesamiento en el lado del cliente (javascript) que puede ser usado para validación local – evitando recargar la página.

No me malinterpreten, la parte del lado del servidor necesita permanecer intacta para propósitos de accesibilidad.

La versión mas reciente de MooTools ofrece agregados de validación en el paquete “mootools-more”, que nos ayudará a resolver nuestras tareas. Básicamente necesitamos añadir algunas clases para dar salida a las entradas, para reflejar el tipo de validación que queremos. Para nuestro formulario sólo necesitamos un nombre – obligatorio, y correo electrónico – obligatorio + formato correcto de correo electrónico.

Así que usaremos requerido: required y validar email: validate-email de la lista de validadores que se encuentran incluidos, así:

<label for="name">Name <span>(required)</span></label>
<input  tabindex="1" type="text" name="name" id="name" class="required" />
<label for="mail">Email <span>(required)</span></label>
<input  tabindex="2" type="text" name="mail" id="mail" class="validate-email required" />

Crear el código que haga la validación

En el evento domready de la ventana (necesitamos permitir al html cargar y entonces será capaz de acceder a él), nosotros adjuntamos el validador a nuestro formulario con los métodos necesarios para mostrar al usuario lo que ha hecho mal (en caso de que lo haya hecho). Para mantener la presentación y la accesibilidad intacta – como en la validación definitiva – añadiremos el siguiente código:

window.addEvent('domready', function(){
 
var myFormValidator = new FormValidator($('contact'), {
 
onFormValidate: function(ok) {
 if (!ok) {
  $('error_wrapper').getElements('a').dispose();
  if (!ok) {
 
   $('contact').getElements('.validation-failed')
   .each( function(el) {
      var a = new Element( "a",{'href' : "#add"})
      .addEvent('click', function(){ el.focus(); return false; })
      .set('text', el.get('id').capitalize() )
      .inject($('error_wrapper'));
 
  })
 
 $('error_wrapper').setStyle('display','block');
 }
 else {
   $('error_wrapper').setStyle('display','none');
 }
 
}
},
stopOnFailure:true,
evaluateFieldsOnBlur:false
 
});
 
})

Ok, es un poco largo, pero básicamente está validando cada campo que se necesite, tal como se especifica en la clase, y adjunta en la envoltura del error (error_wraper) las etiquetas para las entradas erróneas. Es mejor estudiar el código fuente para ver cómo está hecho.

Validación en el cliente con Mootools

La librería de Mootools está validando cada campo que le especificamos en el evento enviar (submit) del formulario y añade predeterminadamente una clase validation-failed o validation-passed a cada campo que fue enviado a la rutina de validación.

Podemos usar esas dos clases para mejorar visualmente al formulario – aquí sólo hice que los fallidos fuesen rojos. Si la validación fallare, el evento enviar (submit) de la forma será detenido y los datos incompletos no alcanzarán a llegar al servidor.

Validacion con Mootools

Próximo paso: completar la data correctamente y reenviar.

Aquí esta el DEMO

La clase validadora del formulario es mas poderosa que esta así que dale un vistazo a la documentación en el sitio de MooTools. De cualquier manera, no importa lo que haga, no olvide hacer la validación del lado del servidor también. Es obligatorio para la seguridad de su servidor.

Accesibilidad con sentido común 2.0

En lo que se refiere a accesibilidad, cada codificador es un pequeño gurú. En los sitios web en los que postulé proyectos, todo el mundo es un experto en accesibilidad y usabilidad (incluyéndome, lo admito).

Aunque estas reglas existen desde hace algún tiempo, hay codificadores quienes las encuentran difícil de implementar – Así que estoy tratando de encontrar aquí cuales son los trucos que usan en sus códigos para hacerlos accesibles. Por ejemplo, aunque escribir código semántico ayude (y mucho) no siempre es suficiente. Algunos tratan de ver sus páginas con CSS e imágenes deshabilitadas, algunos no lo hacen. Algunos de nosotros tenemos trucos que no queremos compartir con otros programadores. Algunos sí compartimos. No todos somos gurú, verdad? Alguien tiene que comenzar de algún sitio.

Así que si tiene algo interesante que decir, añada su propia regla aquí.

Comencemos con sentido común básico:

  1. Escriba código semántico y válido – use etiquetas correctas al tratar de satisfacer las necesidades de Google – Adapte las etiquetas al contexto.
  2. Use listas para navegación y para bloques de enlaces consecutivos.
  3. Escriba formularios accesibles: use etiquetas, validación en el servidor, incluso
    cuando sean necesarios. Debo usar type=”image” con texto alterno en vez de un botón enviar? No lo sé… A mi me gusta el botón type=”submit”. A Camino no le gusta. 🙁
  4. Use los saltos a contenidos o saltos a enlaces de navegación. Todos dicen que debería…
  5. Usar una clase .wai para ocultar el texto que podría ayudar a los lectores de las pantallas – algunas personas usan display:none (no es buena opción), algunos usan alguna identación negativa.
  6. Provea transcripciones para los archivos de vídeo (hace eso Google por YouTube?), marcas alternas, marcas de descripción larga, explicaciones para los gráficos (los codificadores que construyeron sitios Forex hicieron eso?), audio CAPTCHA (usted hace esto?).
  7. otras ideas con sentido común: usan em o porcentaje en vez de px (no obstante, mozilla es muy buen amigo y conoce como incrementar em, px, % y también imágenes, pero se llama zoom y la gente lo odia), utilice un texto grande en botones, colores con contrastes apropiados, imágenes .gifs sin animación/parpadeo/movimiento, alineación del texto a la izquierda, no use enlaces de “presione aquí” porque TODOS los enlaces son para hacer click ahí.
  8. Escriba tablas accesibles: use th scope=”row” y “column”, id y atributos de encabezado para asociar las celdas de datos con las celdas de cabecera, use sumarios y etiquetas para dar pistas adicionales acerca del contenido de la tabla (aunque usualmente las tablas se encuentran precedidas por encabezados y pequeños párrafos de texto). Use las tablas para mostrar sólo datos.
  9. Provea de una función para buscar – aunque yo construí un pequeño sitio de trípticos y no se incluí la búsqueda en él, lo haría usted? Para pequeños sitios?
  10. Provea botones para incrementar el tamaño de letra. Algunas veces yo lo hago, algunas veces no, dependiendo de lo que los clientes requieran. Creo que las personas quienes tienen necesidades especiales saben de la combinación CTRL +, y la usan, los botones A-, A+, parecen ser un poco redundantes. Quizás me equivoque… Además, yo no proveo de un botón para incrementar el alto de la linea y otros espacios en blanco, yo coloco el alto de linea en el CSS para que sea mas grande que el predeterminado. Es esto bueno? Es esto malo? Dígamelo usted, estoy ansiosa por saberlo.

Más reglas

Además de estas reglar, hay muchas más, algunas tienen sentido y son usadas, y algunas que no recuerdo aquí. Estoy teniendo una pequeña lista de elementos que ya no uso, principalmente porque ya no tengo contacto con ellas y olvido (o quiero olvidar) que ellas existen. Yo todavía estoy aprendiendo acerca de elementos más sensibles para las personas que lo necesiten, así que tal vez estoy ignorando algunos detalles.

Así que las siguientes reglas no son mis favoritas:

  1. Use las teclas alternas “altkey” para navegación – muchas personas todavía discuten acerca de eso, estoy esperando a ver quien gana.
  2. Use títulos para los marcos – debería decir “evite los marcos”, pero para quienes los usen… usen títulos.
  3. El asunto del target=”_blank” – Todavía existe mucha discusión acerca de forzar al usuario a una acción que el/ella no quiere. Es sentido común también pero para los codificadores que no respetan las reglas de arriba también lo es… en lo profundo. Para mi es como que si alguien le ponga azúcar a mi café luego de haber dicho que lo quería sin azúcar. Que tal si tengo diabetes?
  4. Use el indicador de foco – Reconozco que no me preocupo mucho por darle estilo, aunque sí uso el tabulador para navegar a través de los enlaces o elementos de un formulario.

Esto es todo por ahora, estas son algunas reglas básicas que tengo en mente cuando codifico. Trato de visualizar el sitio con el CSS/imágenes deshabilitadas pero estoy consciente de que no es suficiente. El simple hecho de que este tratando de mejorar mi conocimiento es mi excusa. Pero yo sé que no es suficiente y si usted tiene un juego similar de reglas que lo guíe, por favor compartalas aquí – para guiar a los demás que tratan de aprender algo útil.

Ohhh, Se me olvidó: use técnicas de reemplazo de imágenes, es un gran invento.