Tres vídeos de un seminario sobre la accesibilidad web. El contenido está bien, pero el sonido es muy malo.
jueves, 20 de diciembre de 2007
jueves, 13 de diciembre de 2007
Legibilidad de una página web
En ¿Tu Sitio es Entendible y Fácil de Leer? nos presentan la herramienta TxReadability (versión en español) que evalúa la facilidad de lectura de una página web, para textos en español, inglés y japonés.
El W3C, en la pauta 14 de sus Pautas de Accesibilidad al Contenido en la Web 1.0 nos dice:
El W3C, en la pauta 14 de sus Pautas de Accesibilidad al Contenido en la Web 1.0 nos dice:
Pauta 14. Asegúrese de que los documentos sean claros y simples.Esta herramienta nos puede ayudar a cumplir esta pauta.
Asegure que los documentos son claros y simples para que puedan ser más fácilmente comprendidos.
La maquetación coherente de páginas, los gráficos reconocibles y el lenguaje fácilmente comprensible benefician a todos los usuarios. En particular, ayudan a personas con discapacidades cognitivas o con dificultades en la lectura. (Por tanto, asegúrese de que las imágenes tienen textos equivalentes para los ciegos, los de baja visión o para cualquier usuario que no puede o ha elegido no ver los gráficos. Consulte también la pauta 1).
La utilización de un lenguaje claro y simple promueve una comunicación efectiva. El acceso a la información escrita puede ser difícil para personas con discapacidades cognitivas o de aprendizaje. La utilización de un lenguaje claro y simple también beneficia a las personas cuyo primer idioma es diferente al del autor, incluidos aquellos que se comunican principalmente mediante lengua de signos.
Puntos de verificación:
14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. [Prioridad 1]
Técnicas para el punto de verificación 14.1.
14.2 Complemente el texto con presentaciones gráficas o auditivas cuando ello facilite la comprensión de la página. [Prioridad 3]
Consultar también la pauta 1.
Técnicas para el punto de verificación 14.2.
14.3 Cree un estilo de presentación que sea coherente para todas las páginas. [Prioridad 3]
Técnicas para el punto de verificación 14.3.
Nuevo borrador de WCAG 2.0
Con fecha 11/12/07 se ha publicado un nuevo borrador de las Web Content Accessibility Guidelines 2.0. La fecha límite para enviar comentarios es el 01/02/08. ¿Para cuándo la recomendación definitiva?
En la entrada ¿Qué pasa con WCAG 2.0? comenté los problemas que está teniendo esta nueva recomendación.
En la entrada ¿Qué pasa con WCAG 2.0? comenté los problemas que está teniendo esta nueva recomendación.
miércoles, 5 de diciembre de 2007
JavaScript no molesto (5): validación de formularios
En la entrada JavaScript no molesto (4): separación del JavaScript se explicó cómo aprovechar el atributo class para separar el código JavaScript del código XHTML. En esta entrada se va a explicar cómo utilizar la misma técnica para validar formularios.
function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}
<input type="button" value="Enviar" onclick="validar()"> Para solucionar este problema, se deben emplear los botones de tipo submit y utilizar el evento onsubmit para llamar al código de validación:
function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}
<form action="unapagina.php" onsubmit="return validar()"></form> Consejo 2: utiliza múltiples clases para indicar el tipo de validación que requiere cada control de un formulario
En el artículo A Guide to Unobtrusive JavaScript Validation se presentan técnicas para separar el código JavaScript que realiza la validación de un formulario:
<input type="text" name="correo" class="required email">
Para más información sobre cómo lograr un manejo de formularios correcto con JavaScript:
Los formularios se deben validar en el navegador por varias razones, las más importantes son:
- Disminuye el tiempo de respuesta de la aplicación: el usuario no tiene que esperar a que se envíen los datos al servidor, se validen en el servidor y se reciba una respuesta para saber si los datos están bien o están mal.
- Se reduce la carga de trabajo del servidor (no del todo, como ahora se explicará): en el servidor no se tienen que validar los formularios de todos los usuarios, en el navegador de cada usuario se validan los datos que ha introducido.
La segunda razón no es verdad en parte, porque SIEMPRE hay que validar los datos que se reciben en el servidor, ya que un usuario malicioso los puede enviar directamente, sin pasar antes por la validación de nuestro formulario. Por tanto, la solución que vamos a ver para separar el JavaScript del XHTML no supone un problema cuando no se dispone de JavaScript, ya que los datos serán validados en el servidor.
Sí que puede haber problemas cuando se emplea JavaScript para actualizar un control del formulario o una página web en función de las acciones del usuario. Por ejemplo, el típico caso de las listas desplegables en cascada (una lista que muestra sus valores en función de lo que se ha elegido en otra lista) realizado con JavaScript no funcionaría si está desactivado. Este problema es distinto al que se explica en esta entrada y merece una para él solo.
Consejo 1: no se debe usar botones de tipo button con el evento onclick para enviar un formulario
El código siguiente presenta un grave problema de accesibilidad: cuando JavaScript no está disponible, el formulario no se puede enviar.function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}
function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}
En el artículo A Guide to Unobtrusive JavaScript Validation se presentan técnicas para separar el código JavaScript que realiza la validación de un formulario:
- Utilizar campos ocultos (hidden) para indicar las validaciones que se tienen que realizar (valor requerido, correo electrónico, código postal).
- Utilizar el atributo class para indicar el tipo de validación.
- Crear un DTD propio para añadir atributos que indican el tipo de validación.
La primera opción es poco práctica, ya que no es adecuada para formularios complejos con muchos campos. La tercera opción tampoco es práctica, ya que una página web basada en un DTD propio no es una página válida respecto a XHTML. Por tanto, la opción más recomendable es la segunda.
En el class se pueden añadir valores para indicar el tipo de validación que requiere el control:
- required
- notrequired
- integer
- date
Por ejemplo:
Para más información sobre cómo lograr un manejo de formularios correcto con JavaScript:
- A Guide to Unobtrusive JavaScript Validation
- Unobtrusive Javascript
- Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)
Suscribirse a:
Entradas (Atom)