He encontrado la noticia Entrega de la II Edición del Premio Complutense-Microsoft de Diseño Accesible.
El premio ha sido entregado al proyecto WebCS del Centro de Referencia en Accesibilidad y Estándares Web del Instituto Nacional de Tecnología de la Información (INTECO). El jurado "ha considerado el "Proyecto WebCS" merecedor de dicho premio por tratarse de una herramienta desarrollada con el objetivo de garantizar la accesibilidad de las páginas web editadas, basándose en la separación total entre contenido y presentación, una de las principales premisas de la accesibilidad".
miércoles, 13 de febrero de 2008
Los errores más comunes
He encontrado estas páginas que comentan cuales son los errores más comunes respecto a la accesibilidad web:
- 7 errores de accesibilidad que se cometen a menudo: son consejos bastante generales, poca información técnica.
- Aciertos y fallos en el artículo: "10 common errors when implementing accessibility": crítica del artículo 10 common errors when implementing accessibility. Es un excelente artículo donde explica y corrige claramente los consejos del artículo original.
martes, 12 de febrero de 2008
La accesibilidad web y los dispositivos móviles
Normalmente la accesibilidad web se asocia con la idea de desarrollar páginas web que puedan ser utilizadas por las personas con discapacidad.
Sin embargo, hoy en día la accesibilidad web no está orientada exclusivamente a las personas con discapacidad. Con el aumento del uso de los dispositivos móviles que permiten el acceso a la Web con las mismas prestaciones que desde un ordenador, la accesibilidad web pasa a significar que la Web es única (no diferentes versiones según el dispositivo o el navegador que se utilice) y universal (utilizable independientemente de las características del usuario).
Debido a ello, el W3C está desarrollando actividades para fomentar que las páginas web sean totalmente accesibles, incluyendo en esta accesibilidad los dispositivos móviles.
Más información:
Sin embargo, hoy en día la accesibilidad web no está orientada exclusivamente a las personas con discapacidad. Con el aumento del uso de los dispositivos móviles que permiten el acceso a la Web con las mismas prestaciones que desde un ordenador, la accesibilidad web pasa a significar que la Web es única (no diferentes versiones según el dispositivo o el navegador que se utilice) y universal (utilizable independientemente de las características del usuario).
Debido a ello, el W3C está desarrollando actividades para fomentar que las páginas web sean totalmente accesibles, incluyendo en esta accesibilidad los dispositivos móviles.
Más información:
miércoles, 6 de febrero de 2008
Serie "Guía breve": Marcos: use el elemento noframes y títulos con sentido
Consejo 8: Marcos: Use el elemento noframes y títulos con sentido.
Los marcos (frames) son un elemento del HTML que siempre han causado problemas. Tanto es así que en XHTML 1.0 Strict y Transitional no se pueden emplear y tenemos que utilizar XHTML 1.0 Frameset si queremos tener marcos.
En XHTML 1.1 Modularization, si se quieren emplear los marcos se tiene que implementar el módulo Frames que define los elementos frameset, frame y noframes.
¿Qué problemas tienen los marcos? Un par de páginas sobre el tema:
¿Y si aún así quiero utilizar los marcos? Pues tendremos algunos problemas de accesibilidad:
Además, se tiene que proporcionar una versión alternativa sin marcos para aquellos agentes de usuario (navegadores) que no sean capaces de interpretar los marcos. Para ello se tiene que emplear la etiqueta <noframes>.
Los marcos (frames) son un elemento del HTML que siempre han causado problemas. Tanto es así que en XHTML 1.0 Strict y Transitional no se pueden emplear y tenemos que utilizar XHTML 1.0 Frameset si queremos tener marcos.
En XHTML 1.1 Modularization, si se quieren emplear los marcos se tiene que implementar el módulo Frames que define los elementos frameset, frame y noframes.
¿Qué problemas tienen los marcos? Un par de páginas sobre el tema:
¿Y si aún así quiero utilizar los marcos? Pues tendremos algunos problemas de accesibilidad:
1.1 Proporcione un texto equivalente para todo elemento no textual (Por ejemplo, a través de "alt", "longdesc" o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones (Por ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos, banda sonora del vídeo y vídeos. [Prioridad 1]Cada marco debe tener un título y una descripción. Para ello, se tienen que emplear los atributos title y longdesc en la etiqueta <frame>.
12.1 Titule cada marco para facilitar su identificación y navegación. [Prioridad 1]
12.2 Describa el propósito de los marcos y como éstos se relacionan entre sí, si no resulta obvio solamente con el título del marco. [Prioridad 2]
Fuente: Pautas de Accesibilidad al Contenido en la Web 1.0, Recomendación W3C de 5 de mayo de 1999
Además, se tiene que proporcionar una versión alternativa sin marcos para aquellos agentes de usuario (navegadores) que no sean capaces de interpretar los marcos. Para ello se tiene que emplear la etiqueta <noframes>.
El atributo target
Siempre se aconseja que para mejorar la accesibilidad de las páginas web se deben emplear los estándares. Respecto al HTML, en la actualidad se debe emplear XHTML 1.0 Strict, pero esta elección puede implicar algunos problemas a los desarrolladores, ya que descubrirán que algunos elementos y atributos de HTML no están. Uno de ellos es el atributo target.
El atributo target de HTML se emplea para abrir un enlace en un destino distinto a la ventana actual. Este atributo se puede aplicar a las etiquetas A, AREA, BASE, FORM y LINK. Según HTML 4.01 Specification de W3C:
¿Y cómo está la situación con las nuevas versiones de XHTML?
En XHTML 1.1 Modularization, XHTML 1.0 Strict se divide en una serie de módulos abstractos que agrupan los elementos y atributos relacionados entre ellos. El objetivo es proporcionar la máxima flexibilidad y que un dispositivo (navegador) implemente únicamente aquellos módulos que necesite o que pueda implementar. Con el fin de asegurar cierta consistencia, existen cuatro módulos básicos (core) que son necesarios siempre:
Si se quiere emplear el atributo target es necesario incluir el módulo Target, que incluye la definición de este atributo para las etiquetas a, area, base, link y form.
Más información: Standards-Compliant New Windows
El atributo target de HTML se emplea para abrir un enlace en un destino distinto a la ventana actual. Este atributo se puede aplicar a las etiquetas A, AREA, BASE, FORM y LINK. Según HTML 4.01 Specification de W3C:
This attribute specifies the name of a frame where a document is to be opened.¿Presenta algún problema de accesibilidad este atributo? Sí, porque la apertura de ventanas nuevas o el uso de marcos puede dificultar la navegación de algunos grupos de usuarios:
The following target names are reserved and have special meanings.
_blank
The user agent should load the designated document in a new, unnamed window.
_self
The user agent should load the document in the same frame as the element that refers to this target.
_parent
The user agent should load the document into the immediate FRAMESET parent of the current frame. This value is equivalent to _self if the current frame has no parent.
_top
The user agent should load the document into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent.
Por tanto, se debe reducir su uso todo lo posible. Además, XHTML 1.0 Strict no permite su uso. Si queremos utilizarlo, tenemos que emplear XHTML 1.0 Transitional o Frameset.10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana actual sin informar al usuario. [Prioridad 2]
Fuente: Pautas de Accesibilidad al Contenido en la Web 1.0, Recomendación W3C de 5 de mayo de 1999, Pauta 10. Utilice soluciones provisionales
¿Y cómo está la situación con las nuevas versiones de XHTML?
En XHTML 1.1 Modularization, XHTML 1.0 Strict se divide en una serie de módulos abstractos que agrupan los elementos y atributos relacionados entre ellos. El objetivo es proporcionar la máxima flexibilidad y que un dispositivo (navegador) implemente únicamente aquellos módulos que necesite o que pueda implementar. Con el fin de asegurar cierta consistencia, existen cuatro módulos básicos (core) que son necesarios siempre:
- Structure: define body, head, html y title.
- Text: define, entre otras, br, cite, div, h1...h6, p, span, etc.
- Hypertext: define a.
- List: define dl, dt, dd, ol, ul y li.
Si se quiere emplear el atributo target es necesario incluir el módulo Target, que incluye la definición de este atributo para las etiquetas a, area, base, link y form.
Más información: Standards-Compliant New Windows
martes, 5 de febrero de 2008
HTML 5
He encontrado el comentario El HTML 5: el futuro del contenido web. Copio el comentario:
Hoy ha publicado el W3C un borrador del HTML 5, lo que ellos mismos llaman el futuro del contenido web, pero aunque todavía pasará mucho tiempo hasta que este estándar vea la luz (ya sabemos la velocidad que llevan las cosas del W3C), es conveniente empezar a saber que va a suponer el HTML 5, por lo que vamos a responder una serie de preguntas básicas para comenzar a conocer este nuevo estándar.
¿Este nuevo estándar supone cambios para las nuevas guías de accesibilidad?
Por supuesto que no, las guías de accesibilidad son totalmente independientes del estándar (X)HTML que se utilice, por lo tanto lo único que supondrá es añadir un nuevo enlace al nuevo estándar.
¿Se necesitan unos nuevos estándares de HTML?
Personalmente pienso que lo que se necesita es que se cumplan, pero si es verdad que los anteriores son ya muy antiguos y todos sabemos la velocidad a la que se mueve la tecnología en el mundo de la informática.
¿Qué pasará con nuestras páginas realizadas en HTML 4.0 o XHTML 1.0?
Pues es de suponer que si tus páginas cumplen con los estándares correctamente no debe pasar nada, se deben seguir viendo correctamente en los navegadores futuros. Otra cosa es que páginas que no cumplan con los estándares y que ahora se ven bien en un determinado navegador, se sigan viendo bien en un futuro; ésto me parece que va a ser más difícil.
¿Nos aseguraremos que si nuestra página cumple con los estándares HTML 5 se verá por fin correctamente en todos los navegadores?
Pues aunque en la redacción de estos nuevos estándares está trabajando un grupo formado por personas de los principales navegadores, sería muy optimista pensar que nuestra página por cumplir con los estándares HTML 5 se va a ver correctamente en todos los navegadores. Me temo que este problema no será tan fácil de solucionar.
¿Qué características nuevas nos aporta el HTML 5?
Pues según el W3C, algunas de las características más interesantes para los autores son APIs para dibujar gráficos en dos dimensiones, incorporar y controlar contenido de audio y vídeo, mantener persistente en la parte del cliente el almacenamiento de datos y para ofrecer a los usuarios la edición de documentos, o partes de éstos, de forma interactiva. Otras características facilitan la representación de elementos familiares de las páginas, incluyendo (sección) (pie); (para navegación) y (para asignación de un título a una foto u otro contenido incluido en la página).
¿Tendremos que aprender un nuevo lenguaje de etiquetado web?
Pues seguro que no, sólo habrá que ver que etiquetas han cambiado su uso y cuales se han añadido nuevas.
¿Tenemos que empezar a usar HTML 5 en nuestras páginas web?
Ahora mismo ni pensarlo, recordar que en estos momentos es sólo un borrador y con total seguridad sufrirá muchos cambios, por lo que nos queda esperar hasta que se apruebe definitivamente.
martes, 29 de enero de 2008
Serie "Guía breve": Scripts, applets y plug-ins
Consejo 7: Scripts, applets y plug-ins: Proporcione una alternativa en caso de que los recursos utilizados no sean accesibles o compatibles.
Algunos de los navegadores que emplean las personas discapacitadas no son capaces de interpretar el código de script (JavaScript) o algunos elementos multimedia como applets programados en Java u objetos realizados con Macromedia Flash que requieren de un plug-in. Además, aún en el caso de que pudiesen interpretarlos, sería muy difícil proporcionar una representación alternativa (por ejemplo, una representación textual para una animación de un applet).
Por regla general, el HTML Dinámico (DHTML) no funcionará con un navegador no visual y no será accesible. Cualquier efecto que se base en mostrar u ocultar capas como respuesta a un evento del ratón, como por ejemplo, menús desplegables o información adicional al pasar el ratón por encima de un elemento, no será accesible y es necesario proporcionar una alternativa.
En entradas anteriores se ha explicado cómo lograr que el código JavaScript sea accesible. Estas entradas han sido:
Algunos de los navegadores que emplean las personas discapacitadas no son capaces de interpretar el código de script (JavaScript) o algunos elementos multimedia como applets programados en Java u objetos realizados con Macromedia Flash que requieren de un plug-in. Además, aún en el caso de que pudiesen interpretarlos, sería muy difícil proporcionar una representación alternativa (por ejemplo, una representación textual para una animación de un applet).
Por regla general, el HTML Dinámico (DHTML) no funcionará con un navegador no visual y no será accesible. Cualquier efecto que se base en mostrar u ocultar capas como respuesta a un evento del ratón, como por ejemplo, menús desplegables o información adicional al pasar el ratón por encima de un elemento, no será accesible y es necesario proporcionar una alternativa.
En entradas anteriores se ha explicado cómo lograr que el código JavaScript sea accesible. Estas entradas han sido:
Un joystick vocal
He encontrado la noticia Un Joystick Vocal ayuda a los discapacitados a manejar el ordenador. La noticia dice:
Informáticos e ingenieros de la Universidad de Washington han creado un “Joystick Vocal” que permite mover el cursor del ordenador a personas discapacitadas. El sistema convierte sonidos vocálicos sencillos en movimientos del cursor sobre la pantalla. Asimismo, es capaz de simular los clics que hacemos con los botones derecho e izquierdo del ratón. Frente a otros sistemas, éste no requiere una gran inversión de hardware, ya que sólo precisa un micrófono y un ordenador para poder usarlo. Sus creadores han hecho otros desarrollos de esta tecnología para buscar en la web, jugar a juegos o manejar un brazo robótico.
Ratón con el movimiento de la cabeza
He encontrado la noticia HeadMouse: mouse virtual para personas con discapacidad. La noticia dice:
La página oficial del proyecto es HeadMouse (Grupo de Robótica, Universidad de Lérida).
Resulta que también existe un producto comercial con el mismo nombre: HeadMouse Extreme. ¿Qué diferencias hay entre uno y otro? ¿Por qué le ponen el mismo nombre?
El dispositivo se basa en la utilización de una cámara de bajo coste para captar las acciones del usuario delante de la pantalla. Las personas con discapacidad motriz acceden al control del mouse a través de los movimientos de la cabeza con todas las funciones incorporadas de «arrastrar», mientras que las acciones faciales se convierten en diversas modalidades de «clic».
La página oficial del proyecto es HeadMouse (Grupo de Robótica, Universidad de Lérida).
Resulta que también existe un producto comercial con el mismo nombre: HeadMouse Extreme. ¿Qué diferencias hay entre uno y otro? ¿Por qué le ponen el mismo nombre?
lunes, 28 de enero de 2008
Ejemplo de vídeo con subtítulos
He encontrado la página web Uso de subtítulos en la presentación de un segmento de baile con descripción por medio de audio. En esta página se explica cómo crear vídeo con subtítulos mediante SMIL para que sea empleado por el reproductor RealPlayer.
miércoles, 16 de enero de 2008
La versión demo de JAWS no se puede utilizar para evaluar
He encontrado el comentario El lector de pantallas JAWS no se podrá usar para evaluar la accesibilidad web. Según parece, Freedom Scientific, el fabricante de JAWS, ha modificado la licencia de uso de la versión demostrativa de su lector de pantallas y ya no se puede utilizar para evaluar la accesibilidad de un sitio web.
Según leo en JAWS license not developer friendly, la licencia dice en uno de sus párrafos:
Así que, nos tenemos que comprar JAWS y pagar unos 900$.
Según leo en JAWS license not developer friendly, la licencia dice en uno de sus párrafos:
… these demonstration or evaluation licenses are not permitted for purposes of development and testing of JAWS scripts, applications, HTML coding, or other Web Based code.
Así que, nos tenemos que comprar JAWS y pagar unos 900$.
jueves, 10 de enero de 2008
Nuevas leyes sobre accesibilidad web
El 2007 ha sido un buen año para la accesibilidad web en cuanto a leyes en España.
Las nuevas leyes que se han promulgado complementan a las que ya se tenían desde hace unos años:
El 27 de diciembre de 2007 se publicó en el BOE la LEY 49/2007, de 26 de diciembre, por la que se establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad. Las infracciones serán multas entre los 301 euros y el millón de euros. Su entrada en vigor está fijada a los tres meses de su publicación.
El 29 de diciembre de 2007 se publicó en el BOE la LEY 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Esta ley obliga a las empresas que cumplan una serie de condiciones a satisfacer un nivel de accesibilidad en sus páginas web equivalente al nivel AA del W3C.
Las nuevas leyes que se han promulgado complementan a las que ya se tenían desde hace unos años:
- BOE n. 166 de 12/7/2002: LEY 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico.
- BOE n. 289 de 3/12/2003: LEY 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad.
El 27 de diciembre de 2007 se publicó en el BOE la LEY 49/2007, de 26 de diciembre, por la que se establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad. Las infracciones serán multas entre los 301 euros y el millón de euros. Su entrada en vigor está fijada a los tres meses de su publicación.
El 29 de diciembre de 2007 se publicó en el BOE la LEY 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Esta ley obliga a las empresas que cumplan una serie de condiciones a satisfacer un nivel de accesibilidad en sus páginas web equivalente al nivel AA del W3C.
miércoles, 9 de enero de 2008
Llegó la hora de las empresas
He encontrado esta noticia en el periódico El Mundo: Las grandes empresas deberán hacer accesibles sus páginas web a discapacitados.
A partir del 31 de diciembre de 2008, es decir, en 12 meses, una serie de empresas que cumplan una serie de condiciones, deberán de satisfacer en sus páginas web el nivel medio (prioridades 1 y 2) de la Norma UNE 139803:2004 (equivalente al nivel AA del W3C).
La noticia dice:
A partir del 31 de diciembre de 2008, es decir, en 12 meses, una serie de empresas que cumplan una serie de condiciones, deberán de satisfacer en sus páginas web el nivel medio (prioridades 1 y 2) de la Norma UNE 139803:2004 (equivalente al nivel AA del W3C).
La noticia dice:
Las páginas de Internet de las empresas que presten servicios al público de especial trascendencia económica deberán alcanzar el 31 de diciembre de 2008 el nivel medio de los criterios de accesibilidad para personas con discapacidad, según establece la nueva Ley de Medidas de Impulso de Sociedad de la Información, que ya ha entrado en vigor.
Según esta nueva norma legal, son consideradas empresas que prestan servicios al público en general de especial trascendencia económica aquéllas con más de cien trabajadores o cuyo volumen anual de operaciones supere los seis millones de euros.
Además, deben operar en el sector de los servicios de las comunicaciones electrónicas o en servicios financieros destinados a consumidores, que incluyen los servicios bancarios, de crédito o de pago, los servicios de inversión, las operaciones de seguros privados, los planes de pensiones y la actividad de mediación de seguros.Hasta la aprobación de esta ley, la obligación de accesibilidad sólo vinculaba a las páginas de Internet de las Administraciones Públicas.
martes, 8 de enero de 2008
¿El portal de ayuntamiento más accesible?
He encontrado esta noticia en el periódico El Mundo: El portal de Internet del Ayuntamiento de Pamplona, el único 100% accesible.
La noticia dice:
La noticia dice:
El Ayuntamiento de Pamplona cuenta con el primer portal de internet que alcanza el 100% de éxito en el cumplimiento de los criterios de accesibilidad analizados por el Observatorio de la Infoaccesibilidad de la Fundación Once. Por esta razón será galardonado el próximo día 17 de enero, según informó el consistorio en un comunicado.
El estudio llevado a cabo por el Observatorio de la Infoaccesibilidad ha analizado 19 portales y 93 páginas web. El Ayuntamiento de Pamplona es el único que ha alcanzado la cota máxima. A continuación se han situado Bankinter, que supera el 81 por ciento en el cumplimiento de los criterios de referencia, y la Seguridad Social con su portal de vida laboral que presenta el 85,71 por ciento de éxito.
El estudio intersectorial el Observatorio de la Infoaccesibilidad revisa comparativamente el estado de accesibilidad de las webs y su evolución a lo largo de tres años. El Observatorio, para este estudio eligió 19 portales, los tres mejores en la evaluación técnica de accesibilidad de cada uno de los ocho informes/áreas observadas.
Estos informes abarcaban distintos campos: universidades, administración general del Estado, comunidades autónomas, ayuntamientos, viajes y transportes, banca y diarios digitales.
El propósito de los resultados publicados consiste en dar a conocer y destacar, además de niveles de cumplimiento respecto a las pautas vigentes, prácticas favorables y las principales barreras e impedimentos en la web, incluyendo en esta valoración la perspectiva de los usuarios.
lunes, 7 de enero de 2008
Ley de Medidas de Impulso de la Sociedad de la Información
He encontrado esta noticia en el periódico El Mundo: Garantizado el acceso de personas con discapacidad a las nuevas tecnologías.
La noticia dice:
La noticia dice:
El Boletín Oficial del Estado publicó, el pasado sábado 29 de diciembre, la Ley de Medidas de Impulso de la Sociedad de la Información (LMISI), que garantiza el acceso de las personas con discapacidad a la información en Internet y en otros soportes de nuevas tecnologías de la información y la comunicación.
Además, esta ley garantizará la accesibilidad de las cabinas telefónicas a los usuarios con alguna discapacidad, así como el establecimiento de una oferta tal que pueda cubrir la demanda nacional en todos las provincias.
La disposición adicional undécima de la LMISI recuerda también a las administraciones y entidades públicas su obligación de promover y garantizar el diseño accesibles para personas con discapacidad de todos los elementos y procesos basados en las nuevas tecnologías de la Sociedad de la Información.
Esta norma, que entró en vigor el pasado domingo 30 de diciembre, establece, además, que el incumplimiento de las medidas de acceso a la sociedad de la información será regulado por la ley de infracciones y sanciones que el BOE publicó el 27 de diciembre y que comenzará a funcionar pasados tres meses de su publicación en el BOE.
jueves, 20 de diciembre de 2007
Vídeos sobre accesibilidad web
Tres vídeos de un seminario sobre la accesibilidad web. El contenido está bien, pero el sonido es muy malo.
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)
viernes, 30 de noviembre de 2007
III Premios TAW 2007
He encontrado esta noticia en el periódico El País: Los portales del Ministerio de Fomento y Ayuntamiento de Madrid los más accesibles. TAW ya ha otorgado sus premios anuales a las páginas web más accesibles. En la página Los portales del Ministerio de Fomento y Ayuntamiento de Madrid ganan los III Premios TAW a las web públicas más accesibles podemos encontrar la nota de prensa de TAW y en la página Premiados 2007 la lista de premiados que reproduzco:
Reunido el jurado para la concesión de los III Premios TAW a la Accesibilidad Web, el día 15 de Noviembre de 2007 en la sede de la Fundación CTIC, resuelven conceder los premios por categorías a:
T.1. Premio TAW a la Web pública más Accesible I.
GANADOR: Sitio web Ministerio de Fomento
Finalista: Sitio web Ministerio de Cultura
Finalista: Sitio web Autoridad Administrativa CITES
T.2. Premio TAW a la Web pública más Accesible II.
GANADOR: Sitio Web Ayuntamiento de Madrid
Finalista: Sitio web Ayuntamiento de Ermua
Finalista: Sitio web Ayuntamiento de Murcia
T.3. Premio TAW a la Web Empresarial más Accesible I.
GANADOR: Sitio web Cajastur
Finalista: Sitio web Gamesa
Finalista: Sitio web Babel Sistemas de información
T.4. Premio TAW a la Web Empresarial más Accesible II.
GANADOR: Sitio web Cafetto Kaldi
Finalista: Sitio web Serviweb S.L.
Finalista: Sitio web Gateway S.C.S.
T.5. Premio TAW a la Web de entidades sin ánimo de lucro más Accesible.
GANADOR: Sitio web Aspaym Cantabria
Finalista: Sitio web Asociación Síndrome Prader-Willi
Finalista: Sitio web Fundación Estudios e Análises
T.6. Premio TAW al Mejor Proyecto en Accesibilidad Web.
El jurado declara desierta esta categoría.
Suscribirse a:
Entradas (Atom)