viernes, 11 de octubre de 2013
Entrevista a una persona sordociega
Hace un par de meses publiqué unos vídeos de una entrevista que realicé a Santi Trigueros, una persona sordociega. A continuación incluyo los tres vídeos que forman la entrevista (los vídeos incluyen subtítulos), junto con un enlace a la publicación original en la que se puede encontrar la transcripción del audio de cada vídeo:
jueves, 10 de octubre de 2013
El uso del atributo title
Llevaba tiempo buscando un artículo que desaconsejase el uso del atributo title, y por fin lo he encontrado: Using the HTML title attribute - updated.
En este artículo se explica que hay ciertos grupos de usuarios que no pueden acceder a la información transmitida a través de este atributo:
Aunque sí que es verdad que hay lectores de pantalla que anuncian al usuario el contenido del atributo title, también es verdad que hay lectores que no lo hacen. Así que, no hay que confiar en este atributo para transmitir información esencial.
[Actualización 11/10/2013]
Más información sobre el atributo title:
En este artículo se explica que hay ciertos grupos de usuarios que no pueden acceder a la información transmitida a través de este atributo:
- Usuarios de teléfonos móviles.
- Usuarios de teclado.
- Usuarios de magnificadores de pantalla.
- Usuarios de lectores de pantalla.
- Usuarios con problemas de movilidad.
- Usuarios con problemas cognitivos.
Aunque sí que es verdad que hay lectores de pantalla que anuncian al usuario el contenido del atributo title, también es verdad que hay lectores que no lo hacen. Así que, no hay que confiar en este atributo para transmitir información esencial.
[Actualización 11/10/2013]
Más información sobre el atributo title:
- El atributo title (2/2/2007)
- Sobre el atributo alt y title, ¿cumplen la misma función? (4/3/2011)
miércoles, 9 de octubre de 2013
Los cursos en Coursera tienen que ser accesibles por contrato
Coursera es una de las plataformas más famosas de cursos MOOC. Si no sabes qué es un MOOC, te recomiendo que consultes mi sitio web ¿Qué son los MOOCs?
En julio del año pasado, alguien le pasó a la prensa el contrato firmado entre Coursera y la Universidad de Michigan: The U. of Michigan's Contract With Coursera. El contrato tiene ¡¡¡42 páginas!!! Es un contrato y lo demás son tonterías.
En el apartado 11 ADA COMPLIANCE se indica que la universidad que ofrece los cursos debe cumplir la ley ADA (Americans with Disabilites Act) y debe ofrecer los contenidos de forma que sean accesibles para las personas con discapacidad, y se indica de forma expresa los usuarios ciegos que utilizan un lector de pantallas. Además, se indica que se tienen que proporcionar los transparencias empleadas en los vídeos y descripciones textuales de cualquier material gráfico usado en los ejercicios de tipo test y en los problemas.
Por su lado, Coursera se compromete a que la plataforma sea accesible, a ofrecer los vídeos subtitulados cuando el número de inscripciones en un curso supere las diez mil personas y a realizar el subtitulado de los vídeos en cursos con un número inferior de inscripciones cuando así lo solicite un usuario discapacitado.
En julio del año pasado, alguien le pasó a la prensa el contrato firmado entre Coursera y la Universidad de Michigan: The U. of Michigan's Contract With Coursera. El contrato tiene ¡¡¡42 páginas!!! Es un contrato y lo demás son tonterías.
En el apartado 11 ADA COMPLIANCE se indica que la universidad que ofrece los cursos debe cumplir la ley ADA (Americans with Disabilites Act) y debe ofrecer los contenidos de forma que sean accesibles para las personas con discapacidad, y se indica de forma expresa los usuarios ciegos que utilizan un lector de pantallas. Además, se indica que se tienen que proporcionar los transparencias empleadas en los vídeos y descripciones textuales de cualquier material gráfico usado en los ejercicios de tipo test y en los problemas.
Por su lado, Coursera se compromete a que la plataforma sea accesible, a ofrecer los vídeos subtitulados cuando el número de inscripciones en un curso supere las diez mil personas y a realizar el subtitulado de los vídeos en cursos con un número inferior de inscripciones cuando así lo solicite un usuario discapacitado.
martes, 8 de octubre de 2013
People-first language
People-first language es una recomendación que existe en inglés para referirse a las personas con discapacidad. Esta recomendación indica que primero hay que hacer referencia a la persona, y después a su condición o discapacidad.
En inglés, los adjetivos se colocan antes del nombre. En español, normalmente se colocan después, por lo que no tiene sentido esta recomendación.
En inglés se puede cambiar la posición del adjetivo con oraciones relativas. Por ejemplo:
"He's retard or a retard" se tiene que decir "He is a person with a cognitive disability".
"She's autistic" se tiene que decir "She is an individual with autism".
"He's a wheelchair bound" se tiene que decir "He uses a wheelchair".
"She's dumb or mute" se tiene que decir "She's unable to speak".
"He's crazy or nuts" se tiene que decir "He is a person with mental illness".
Además, esta recomendación también indica que hay que evitar los nombres genéricos. Por ejemplo:
"the handicapped" o "the disabled" se tiene que decir "people with disabilities" o "people who have disabilities".
Además, sólo se tiene que hacer referencia a la discapacidad cuando realmente sea necesario.
Sin embargo, esta forma de usar el lenguaje no es aceptada por todos. Por ejemplo, la comunidad sorda prefiere que se usen los términos "deaf person" o "hard of hearing person", pero no "hearing impaired".
En España hay un movimiento que aboga por el uso del término persona con diversidad funcional. Y recordemos que otros términos, como minusválido o inválido no se deben usar.
En inglés, los adjetivos se colocan antes del nombre. En español, normalmente se colocan después, por lo que no tiene sentido esta recomendación.
En inglés se puede cambiar la posición del adjetivo con oraciones relativas. Por ejemplo:
"He's retard or a retard" se tiene que decir "He is a person with a cognitive disability".
"She's autistic" se tiene que decir "She is an individual with autism".
"He's a wheelchair bound" se tiene que decir "He uses a wheelchair".
"She's dumb or mute" se tiene que decir "She's unable to speak".
"He's crazy or nuts" se tiene que decir "He is a person with mental illness".
Además, esta recomendación también indica que hay que evitar los nombres genéricos. Por ejemplo:
"the handicapped" o "the disabled" se tiene que decir "people with disabilities" o "people who have disabilities".
Además, sólo se tiene que hacer referencia a la discapacidad cuando realmente sea necesario.
Sin embargo, esta forma de usar el lenguaje no es aceptada por todos. Por ejemplo, la comunidad sorda prefiere que se usen los términos "deaf person" o "hard of hearing person", pero no "hearing impaired".
En España hay un movimiento que aboga por el uso del término persona con diversidad funcional. Y recordemos que otros términos, como minusválido o inválido no se deben usar.
lunes, 7 de octubre de 2013
A la tercera, ¿va la vencida?
Recordemos:
- El 21 de abril de 2012 envié un correo a la Oficina de Información y Atención al Ciudadano del Ministerio de Sanidad, Servicios Sociales e Igualdad solicitando información sobre las denuncias en materia de accesibilidad web presentadas en España: ¿Cuántas denuncias por falta de accesibilidad web se han presentado en España? El escrito fue recibido, pero no me enviaron la información.
- El 8 de abril de 2013 volví a escribir un correo: Segundo intento con el Ministerio. A los dos días me contestaron y me dijeron que "confiaban en que en un muy breve plazo iba a recibir la información solicitada": El Ministerio de Sanidad Contesta. La información no llegó.
- El 1 de octubre de 2013 volví a escribir el siguiente correo. En este caso no he recibido ni un acuse de lectura del correo. Sigo esperando una respuesta.
Hola.
Este es el tercer intento de solicitud de información que realizo. La última vez, como pueden ver en este mensaje, fue en abril de este año. Les recuerdo mi solicitud:
Me pongo en contacto con ustedes para recabar información sobre las sanciones impuestas de acuerdo a 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. En concreto, estoy interesado en conocer las sanciones que se han impuesto por incumplimiento de la legislación existente en materia de accesibilidad web, es decir, sitios web que presentan problemas de accesibilidad. Tengo constancia de que la Oficina Permanente Especializada del Consejo Nacional de la Discapacidad tiene abiertos varios expedientes sobre este tema, pero me han indicado que el organismo sancionador es la Dirección General de Políticas de Apoyo a la Discapacidad.
Rogaría que, caso de no ser ustedes, me indicaran a quién debo dirigirme para obtener esta información.
Atentamente,
Sergio Luján Mora
viernes, 4 de octubre de 2013
Un problema de accesibilidad con Flash
Hace unos días, publiqué la entrada El extraño caso de la Confederación Hidrográfica del Segura, en el que mostraba un error que presenta el sitio web de esa entidad.
No tengo ningún problema con esa web, al contrario, me parece que se han preocupado en lograr que sea una buena web, y la accesibilidad ha sido una de sus preocupaciones.
En la página principal hay un panel que muestra el estado de los embalses de la cuenca:
El panel se puede leer bien con un tamaño normal del texto:
Sin embargo, si se amplia mucho el tamaño de la página (si se hace zoom), ocurre algo:
¿Qué ha pasado? ¿Por qué se ve así de mal la leyenda y las etiquetas del gráfico?
¡Es Flash!
Bueno, la culpa no la tiene del todo Flash, porque la lista desplegable en la que se puede elegir un embalse sí que se visualiza correctamente.
No tengo ningún problema con esa web, al contrario, me parece que se han preocupado en lograr que sea una buena web, y la accesibilidad ha sido una de sus preocupaciones.
En la página principal hay un panel que muestra el estado de los embalses de la cuenca:
El panel se puede leer bien con un tamaño normal del texto:
Sin embargo, si se amplia mucho el tamaño de la página (si se hace zoom), ocurre algo:
¿Qué ha pasado? ¿Por qué se ve así de mal la leyenda y las etiquetas del gráfico?
¡Es Flash!
Bueno, la culpa no la tiene del todo Flash, porque la lista desplegable en la que se puede elegir un embalse sí que se visualiza correctamente.
miércoles, 2 de octubre de 2013
KYMCO, creo que me he ganado una moto
Según la Wikipedia, KYMCO es la principal marca de motocicletas de Taiwán.
El sitio web en español de esta marca tiene un apartado sobre la accesibilidad del sitio web.
La declaración de accesibilidad está muy bien:
La verdad es que me ha sorprendido gratamente encontrar esta declaración de accesibilidad en un sitio web que no está obligado a garantizar la accesibilidad.
En una revisión rápida de la página he encontrado algunos detalles interesantes, pero también he encontrado algunas cosas que "chirrían" como una correa de distribución en mal estado.
Por ejemplo, en la página principal aparece un banner central con el texto "Cuando tocas con los pies en el suelo, ¿dónde está tu techo?". Todo el banner es un enlace que lleva a la página de promoción de la KYMCO YAGER GT 125i:
Al ver el código fuente y la página sin hoja de estilo (una simulación rápida de cómo lo percibe una persona ciega que use un lector de pantallas), ¡¡¡no encuentro el enlace!!!
Bueno, sí que encuentro el enlace, ¡¡¡es un enlace vacío!!!
¿Y cuál es el problema? Una persona ciega que utilice un lector de pantallas no tendrá acceso a ese enlace, y por tanto, no tendrá acceso a la información facilitada.
¡Ahhh, pero después hay un span con display:none con un texto significativo! Alguien ha puesto ese span donde no debía... Pero si lo ha puesto con el objetivo de que le aparezca a una persona ciega que utilice un lector de pantallas, se ha equivocado: con display:none se oculta el contenido a todo el mundo.
Hay más, hay más, pero ya que KYMCO parece que se preocupa por la accesibilidad web, no se merece que saque más errores.
¡Ánimo, seguro que lo podéis hacer mejor!
El sitio web en español de esta marca tiene un apartado sobre la accesibilidad del sitio web.
La declaración de accesibilidad está muy bien:
La Web de Kymco está concebida para facilitar el acceso al mayor numero de personas posibles, con o sin limitaciones, sin necesidad de realizar adecuaciones determinadas. Dichas limitaciones pueden ser físicas (visuales, auditivas, cognitivas o motrices) o tecnológicas (conexiones lentas, navegadores obsoletos, dispositivos alternativos, etc.)Seguro que más de uno pensará "¿para qué quiere una persona ciega o con problemas motrices acceder a un sitio web en el que venden motos, si no puede conducir una moto?". Ya, ¿y si le gustan las motos y está buscando información? ¿Y si le quiere comprar una moto a su hijo? ¿Y si la persona ciega o con problemas motrices es el gerente de un concesionario de este fabricante?
La verdad es que me ha sorprendido gratamente encontrar esta declaración de accesibilidad en un sitio web que no está obligado a garantizar la accesibilidad.
En una revisión rápida de la página he encontrado algunos detalles interesantes, pero también he encontrado algunas cosas que "chirrían" como una correa de distribución en mal estado.
Por ejemplo, en la página principal aparece un banner central con el texto "Cuando tocas con los pies en el suelo, ¿dónde está tu techo?". Todo el banner es un enlace que lleva a la página de promoción de la KYMCO YAGER GT 125i:
Al ver el código fuente y la página sin hoja de estilo (una simulación rápida de cómo lo percibe una persona ciega que use un lector de pantallas), ¡¡¡no encuentro el enlace!!!
Bueno, sí que encuentro el enlace, ¡¡¡es un enlace vacío!!!
¿Y cuál es el problema? Una persona ciega que utilice un lector de pantallas no tendrá acceso a ese enlace, y por tanto, no tendrá acceso a la información facilitada.
¡Ahhh, pero después hay un span con display:none con un texto significativo! Alguien ha puesto ese span donde no debía... Pero si lo ha puesto con el objetivo de que le aparezca a una persona ciega que utilice un lector de pantallas, se ha equivocado: con display:none se oculta el contenido a todo el mundo.
Hay más, hay más, pero ya que KYMCO parece que se preocupa por la accesibilidad web, no se merece que saque más errores.
¡Ánimo, seguro que lo podéis hacer mejor!
martes, 1 de octubre de 2013
Tercera edición de iDESWEB
La semana pasada comenzó la tercera edición de iDESWEB, Introducción al desarrollo web.
iDESWEB es un curso de tipo MOOC, totalmente gratuito y disponible en la Web (curso online), con el que vas a aprender los conceptos básicos del desarrollo de aplicaciones web.
Con iDESWEB puedes aprender HTML, CSS, JavaScript, PHP… y los principios básicos del diseño, de la usabilidad y de la accesibilidad web.
El curso tiene una duración de 15 semanas.
iDESWEB es un curso de tipo MOOC, totalmente gratuito y disponible en la Web (curso online), con el que vas a aprender los conceptos básicos del desarrollo de aplicaciones web.
Con iDESWEB puedes aprender HTML, CSS, JavaScript, PHP… y los principios básicos del diseño, de la usabilidad y de la accesibilidad web.
El curso tiene una duración de 15 semanas.
lunes, 30 de septiembre de 2013
Accesibilidad web para las discapacidades cognitivas y los problemas de aprendizaje
Un buen artículo publicado en el sitio web de desarrolladores de Opera: Web accessibility for cognitive disabilities and learning difficulties.
Las personas con una discapacidad cognitiva o problemas de aprendizaje pueden tener problemas en las páginas web con las siguientes tareas:
- Lectura del texto.
- Memoria.
- Resolución de problemas.
- Mantener la atención.
- Calcular.
- Aprendizaje no verbal.
En el artículo se proporcionan consejos para limitar los problemas en estas tareas.
viernes, 27 de septiembre de 2013
Vídeos sobre accesibilidad web publicados en iDESWEB
Un recordatorio de los vídeos sobre accesibilidad web publicados en el curso iDESWEB, Introducción al desarrollo web:
Accesibilidad: Discapacidad en la Web (parte 1)
Qué es discapacidad, tipos de discapacidad (visuales, auditivas, motrices, neurológicas o cognitivas, derivadas del envejecimiento, derivadas del entorno), barreras de la discapacidad visual (ceguera, baja visión, daltonismo), productos de apoyo (lector de pantallas, línea de braille, navegadores de voz, pantallas grandes, ampliadores de pantalla), estrategias.
Accesibilidad: Discapacidad en la Web (parte 2)
Tipos de discapacidad (visuales, auditivas, motrices, neurológicas o cognitivas, derivadas del envejecimiento, derivadas del entorno), discapacidad auditiva (sordera, hipoacusia), discapacidad motriz (muscular, degenerativas), discapacidad neurológica o cognitiva (problemas de aprendizaje, déficit de atención, falta de memoria), discapacidad relacionada con el envejecimiento, limitaciones derivadas del entorno, barreras, productos de apoyo, estrategias.
Accesibilidad web: 4 elementos más problemáticos
¿Qué elemento es el más problemático en una página web?, los cuatro principales problemas de acceso a la información:
1. Flash.
2. Captchas.
3. Enlaces o botones no que no tienen sentido fuera del contexto.
4. Imágenes sin texto alternativo o con un texto alternativo inapropiado.
Accesibilidad: Discapacidad en la Web (parte 1)
Qué es discapacidad, tipos de discapacidad (visuales, auditivas, motrices, neurológicas o cognitivas, derivadas del envejecimiento, derivadas del entorno), barreras de la discapacidad visual (ceguera, baja visión, daltonismo), productos de apoyo (lector de pantallas, línea de braille, navegadores de voz, pantallas grandes, ampliadores de pantalla), estrategias.
Accesibilidad: Discapacidad en la Web (parte 2)
Tipos de discapacidad (visuales, auditivas, motrices, neurológicas o cognitivas, derivadas del envejecimiento, derivadas del entorno), discapacidad auditiva (sordera, hipoacusia), discapacidad motriz (muscular, degenerativas), discapacidad neurológica o cognitiva (problemas de aprendizaje, déficit de atención, falta de memoria), discapacidad relacionada con el envejecimiento, limitaciones derivadas del entorno, barreras, productos de apoyo, estrategias.
Accesibilidad web: 4 elementos más problemáticos
¿Qué elemento es el más problemático en una página web?, los cuatro principales problemas de acceso a la información:
1. Flash.
2. Captchas.
3. Enlaces o botones no que no tienen sentido fuera del contexto.
4. Imágenes sin texto alternativo o con un texto alternativo inapropiado.
jueves, 26 de septiembre de 2013
Accesibilidad de SVG
Current State of Authoring Accessible SVG es un pequeño artículo en el que se tratan dos cosas: las características de accesibilidad que ofrece SVG y el soporte que ofrecen dos herramientas muy populares, Inkscape y Adobe Illustrator, para definir los metadatos necesarios para mejor la accesibilidad.
martes, 24 de septiembre de 2013
El extraño caso de la Confederación Hidrográfica del Segura
Hace unos días me topé con la página de Meteorología de la web de la Confederación Hidrográfica del Segura. En esa página me llamó la atención el mapa de imagen, porque tiene una barra de enlaces que proporciona la misma funcionalidad.
¿Por qué habían puesto esa barra de enlaces los desarrolladores de ese sitio web? ¿Para ofrecer una alternativa y que el mapa de imagen fuera accesible? Seguramente, casi seguro que sí... pero desde hace tiempo no hace falta hacer eso: un mapa de imagen bien hecho es accesible. Pero claro, este mapa de imagen NO ESTABA BIEN HECHO.
Todo eso lo explico en el vídeo ¿Por qué es importante escribir código correcto? El extraño caso de la CHS:
Y la transcripción del vídeo:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y este vídeo forma parte de una serie de videotutoriales dedicados a la accesibilidad web. En este vídeo vamos a ver un error que tiene una página del sitio web de la Confederación Hidrográfica del Segura, y cómo afecta este error al funcionamiento de la página y a su accesibilidad.
Recientemente me he topado con el sitio web de la Confederación Hidrográfica del Segura.
En el pie de página de este sitio web podemos ver todos estos logos, que nos dicen que el HTML y el CSS de la página son válidos y que cumple el nivel AA de accesibilidad del W3C.
¿Es verdad que el código es válido? ¿Es verdad que la página es accesible?
Vamos a revisar esta página, la página que permite consultar la meteorología de las provincias que pertenecen a la Confederación Hidrográfica del Segura. En esta página podemos encontrar este mapa.
Al ver este mapa me llamó la atención esta barra de navegación.
¿Para qué incluir esta barra de navegación si un mapa de imagen es accesible si está bien hecho?
Vamos a probar este mapa de imagen con dos navegadores, con Google Chrome y con Microsoft Internet Explorer.
Con Google Chrome podemos ver que al situar el cursor del ratón encima del mapa, aparece el típico “tool tip” que nos proporciona información sobre el destino del enlace.
Por ejemplo, aquí estoy situado sobre Albacete y me dice “Ver predicción meteorológica de Albacete”. Y si aquí me sitúo sobre la provincia de Alicante me dice “Ver predicción meteorológica de Alicante/Alacante”. Además, al pulsar fíjate en la barra de direcciones del navegador, cómo cambia la dirección y se desplaza al destino, el destino que está situado en la misma página web.
Sin embargo, al realizar lo mismo en el navegador Microsoft Internet Explorer 10, fíjate que al situar el cursor del ratón encima del mapa no aparece ninguna información, y el cursor no cambia a una mano para indicar que se puede pulsar. Además, si pulso, fíjate que no pasa nada.
El mapa de imagen no está funcionando. ¿Qué está ocurriendo?
Aquí tenemos el código del mapa de imagen. Podemos ver que hay un error: la referencia al mapa de imagen en la imagen está mal, porque le falta la almohadilla en el nombre.
¿Cómo?
El sitio web de la Confederación Hidrográfica del Segura emplea XHTML 1.0, que son las mismas etiquetas y la misma semántica que HTML 4.01, pero escrito con la sintaxis más estricta de XML.
Si consultamos la recomendación oficial de HTML 4.01 y buscamos la definición del atributo usemap, vemos que nos dice que el valor de usemap debe coincidir con el valor del atributo name del elemento map asociado. Por tanto, podría parecer que está bien hecho, porque en la página sí que coincide el valor.
Pero nos dice algo más, también nos dice que tiene que ser una URI. Y por ser una URI, si hace referencia a un elemento que está en la misma página, debe comenzar con el carácter almohadilla.
Si no nos queda claro, se pueden consultar los ejemplos que hay en la misma página de la recomendación de HTML. Podemos ver que en todos los ejemplos se hace uso del carácter almohadilla.
En la especificación de HTML5 se explica mejor el uso del atributo usemap.
Ahora se indica que el valor de usemap debe ser una referencia de tipo “hash-name”,
que significa que debe comenzar con el símbolo almohadilla.
Vamos a comprobar que al añadir la almohadilla, el mapa de imagen funciona correctamente en todos los navegadores.
Para estudiar este error he aislado el código de la página web que crea el mapa de imagen. Aquí está el código HTML que he copiado de la página de la Confederación Hidrográfica del Segura.
El problema está en este atributo usemap que no lleva la almohadilla. Coincide su valor con el atributo name del mapa de imagen, pero debe de llevar una almohadilla.
Vamos a comprobar este ejemplo en Google Chrome. Recargo la página y fíjate como sí que funciona, se activan las distintas zonas del mapa, pero si pulso la tecla tabulador no puedo desplazarme al mapa de imagen, el mapa de imagen tiene que ser accesible por teclado.
Y en este caso fíjate como los enlaces, que simplemente se van destacando son los de esta barra pero no se activa el mapa de imagen.
Lo mismo ocurre en Internet Explorer. Recargo la página, fíjate que no funciona el mapa de imagen. Y si pulso la tecla tabulador, solamente me desplazo sobre esta barra.
Ahora voy a modificar el mapa de imagen y en el atributo usemap simplemente le voy a poner la almohadilla. Y ahora verás como todo cambia.
¿Moraleja?
Hasta los mismos validadores pueden fallar. En caso de duda, consulta siempre las especificaciones oficiales.
Si quieres saber más sobre la importancia de escribir código HTML correcto, te recomiendo que veas mi vídeo “HTML5: ¿Por qué es importante escribir código correcto?”, compuesto de tres partes.
Y con esto finaliza este videotutorial que ha mostrado un error extraño que presenta una página de la Confederación Hidrográfica del Segura.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
¿Por qué habían puesto esa barra de enlaces los desarrolladores de ese sitio web? ¿Para ofrecer una alternativa y que el mapa de imagen fuera accesible? Seguramente, casi seguro que sí... pero desde hace tiempo no hace falta hacer eso: un mapa de imagen bien hecho es accesible. Pero claro, este mapa de imagen NO ESTABA BIEN HECHO.
Todo eso lo explico en el vídeo ¿Por qué es importante escribir código correcto? El extraño caso de la CHS:
Y la transcripción del vídeo:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y este vídeo forma parte de una serie de videotutoriales dedicados a la accesibilidad web. En este vídeo vamos a ver un error que tiene una página del sitio web de la Confederación Hidrográfica del Segura, y cómo afecta este error al funcionamiento de la página y a su accesibilidad.
Recientemente me he topado con el sitio web de la Confederación Hidrográfica del Segura.
En el pie de página de este sitio web podemos ver todos estos logos, que nos dicen que el HTML y el CSS de la página son válidos y que cumple el nivel AA de accesibilidad del W3C.
¿Es verdad que el código es válido? ¿Es verdad que la página es accesible?
Vamos a revisar esta página, la página que permite consultar la meteorología de las provincias que pertenecen a la Confederación Hidrográfica del Segura. En esta página podemos encontrar este mapa.
Al ver este mapa me llamó la atención esta barra de navegación.
¿Para qué incluir esta barra de navegación si un mapa de imagen es accesible si está bien hecho?
Vamos a probar este mapa de imagen con dos navegadores, con Google Chrome y con Microsoft Internet Explorer.
Con Google Chrome podemos ver que al situar el cursor del ratón encima del mapa, aparece el típico “tool tip” que nos proporciona información sobre el destino del enlace.
Por ejemplo, aquí estoy situado sobre Albacete y me dice “Ver predicción meteorológica de Albacete”. Y si aquí me sitúo sobre la provincia de Alicante me dice “Ver predicción meteorológica de Alicante/Alacante”. Además, al pulsar fíjate en la barra de direcciones del navegador, cómo cambia la dirección y se desplaza al destino, el destino que está situado en la misma página web.
Sin embargo, al realizar lo mismo en el navegador Microsoft Internet Explorer 10, fíjate que al situar el cursor del ratón encima del mapa no aparece ninguna información, y el cursor no cambia a una mano para indicar que se puede pulsar. Además, si pulso, fíjate que no pasa nada.
El mapa de imagen no está funcionando. ¿Qué está ocurriendo?
Aquí tenemos el código del mapa de imagen. Podemos ver que hay un error: la referencia al mapa de imagen en la imagen está mal, porque le falta la almohadilla en el nombre.
¿Cómo?
El sitio web de la Confederación Hidrográfica del Segura emplea XHTML 1.0, que son las mismas etiquetas y la misma semántica que HTML 4.01, pero escrito con la sintaxis más estricta de XML.
Si consultamos la recomendación oficial de HTML 4.01 y buscamos la definición del atributo usemap, vemos que nos dice que el valor de usemap debe coincidir con el valor del atributo name del elemento map asociado. Por tanto, podría parecer que está bien hecho, porque en la página sí que coincide el valor.
Pero nos dice algo más, también nos dice que tiene que ser una URI. Y por ser una URI, si hace referencia a un elemento que está en la misma página, debe comenzar con el carácter almohadilla.
Si no nos queda claro, se pueden consultar los ejemplos que hay en la misma página de la recomendación de HTML. Podemos ver que en todos los ejemplos se hace uso del carácter almohadilla.
En la especificación de HTML5 se explica mejor el uso del atributo usemap.
Ahora se indica que el valor de usemap debe ser una referencia de tipo “hash-name”,
que significa que debe comenzar con el símbolo almohadilla.
Vamos a comprobar que al añadir la almohadilla, el mapa de imagen funciona correctamente en todos los navegadores.
Para estudiar este error he aislado el código de la página web que crea el mapa de imagen. Aquí está el código HTML que he copiado de la página de la Confederación Hidrográfica del Segura.
El problema está en este atributo usemap que no lleva la almohadilla. Coincide su valor con el atributo name del mapa de imagen, pero debe de llevar una almohadilla.
Vamos a comprobar este ejemplo en Google Chrome. Recargo la página y fíjate como sí que funciona, se activan las distintas zonas del mapa, pero si pulso la tecla tabulador no puedo desplazarme al mapa de imagen, el mapa de imagen tiene que ser accesible por teclado.
Y en este caso fíjate como los enlaces, que simplemente se van destacando son los de esta barra pero no se activa el mapa de imagen.
Lo mismo ocurre en Internet Explorer. Recargo la página, fíjate que no funciona el mapa de imagen. Y si pulso la tecla tabulador, solamente me desplazo sobre esta barra.
Ahora voy a modificar el mapa de imagen y en el atributo usemap simplemente le voy a poner la almohadilla. Y ahora verás como todo cambia.
¿Moraleja?
Hasta los mismos validadores pueden fallar. En caso de duda, consulta siempre las especificaciones oficiales.
Si quieres saber más sobre la importancia de escribir código HTML correcto, te recomiendo que veas mi vídeo “HTML5: ¿Por qué es importante escribir código correcto?”, compuesto de tres partes.
Y con esto finaliza este videotutorial que ha mostrado un error extraño que presenta una página de la Confederación Hidrográfica del Segura.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
lunes, 23 de septiembre de 2013
OneWebDay 2013 – Working for Internet Accessibility
OneWebDay es una celebración que tiene lugar el 22 de septiembre desde el año 2006. El objetivo de ese día es celebrar los beneficios que ha aportado la Web y su integración en la sociedad. Pero también tiene como objetivo concienciar sobre algunos peligros que acechan, como la importancia de mantener los principios abiertos de Internet y la Web que han hecho que sean lo que son.
El tema de este año ha sido "Working for Internet Accessibility". En la página de OneWebDay proponían realizar alguna de las siguientes actividades para colaborar con la celebración:
El tema de este año ha sido "Working for Internet Accessibility". En la página de OneWebDay proponían realizar alguna de las siguientes actividades para colaborar con la celebración:
- On September 22, celebrate OneWebDay by wishing to your friends and everyone else that we continue to enjoy the benefits of an Open Internet. Use the hashtag #OneWebDay.
- Add the OneWebDay badge to your website/blog.
- Organize a local meetup to talk about Internet accessibility.
- If you have a website check it for accessibility using Cynthia Says or another tool. Fix it!
- Check out the Accessibility resources on the Internet Society New York Chapter’s wiki.
- If you have a story or tip about accessibility, add it in a comment below.
- Join the Disability and Special Needs Chapter.
- Sign up with AMARA and transcribe a video.
viernes, 20 de septiembre de 2013
La accesibilidad web como manifestación de la responsabilidad social corporativa
Lo de la responsabilidad social corporativa (RSC) siempre me ha sonado a engañufa: que una empresa tenga como objetivo realizar una contribución activa y voluntaria a la mejora social, económica o ambiental de su entorno, cuando tiene como objetivo maximizar sus beneficios y para ello no tiene inconveniente en explotar a sus trabajadores, engañar a sus clientes y destruir el medio ambiente, es, como mínimo, muy paradójico. Pero así es el ser humano, paradoja y contradicción en estado puro.
Un lector de este blog me pasó la referencia al artículo La autorregulación de la accesibilidad web como manifestación de la responsabilidad social corporativa (publicado en noviembre de 2010 o 2011, no está claro, aparecen dos fechas). Copio las conclusiones del artículo:
Un lector de este blog me pasó la referencia al artículo La autorregulación de la accesibilidad web como manifestación de la responsabilidad social corporativa (publicado en noviembre de 2010 o 2011, no está claro, aparecen dos fechas). Copio las conclusiones del artículo:
Es conocido por todos que las nuevas tecnologías repercuten en numerosos ámbitos de los países desarrollados. Entre los mismos, ocupa una destacada posición Internet. Aunque la red de redes tiene un alcance universal, posibilitando un número realmente elevado de actividades de diferente índole –ocio, laboral, etc.-, lamentablemente, no resulta accesible para todos los usuarios. Existen individuos que sufren diversas modalidades de discapacidad –visual, auditiva, etc.- así como personas de edad avanzada o incluso sujetos que recurren a determinados dispositivos –como, por ejemplo, de reducidas dimensiones- para los que deberían ponerse en práctica diferentes actuaciones que mejorasen la accesibilidad de los sitios Web a los que acceden.
A pesar de que la facilidad de uso de los sitios Web –usabilidad- no es lo mismo que la accesibilidad –que supone que puedan ser accedidas por el mayor número de personas posible-, cuando las páginas Web son más accesibles son, como regla general, más usables. Como vemos, ambos conceptos están relacionados, integrándose en lo que se denomina interfaz del sitio Web.
Son numerosas las normas legales internacionales, comunitarias y nacionales que buscan asegurar la accesibilidad de los sitios Web. Sin embargo, los estudios empíricos operados al respecto, ponen de manifiesto que todavía son limitados los portales que resultan accesibles. Para, precisamente, hacer frente a este handicap, en virtud del fenómeno de la autorregulación, se han elaborado diferentes herramientas, de carácter voluntario, que complementan la legislación. Tales figuras constituyen sugerentes manifestaciones de la RSC en las que concurren ciertas particularidades.
Se trata, por un lado, de los códigos de conducta que, entre otras materias, disciplinan la accesibilidad Web. No obstante, existe una notable heterogeneidad de las cuestiones relativas a la accesibilidad reguladas por cada uno de ellos. Y, por otro, los sellos de confianza en el ámbito de la accesibilidad aseguran el cumplimiento de los estándares de accesibilidad ideados por el W3C.
martes, 17 de septiembre de 2013
La dislexia y la tipografía
Una mala tipografía puede ser una barrera de accesibilidad para las personas con dislexia. ¿Qué se debe hacer para evitar o reducir los problemas que pueden afectar a las personas con dislexia? En el vídeo Accesibilidad web: dislexia y tipografía explico los principales problemas y ofrezco algunos consejos:
Y la transcripción del vídeo:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y este vídeo forma parte de una serie de videotutoriales dedicados a la accesibilidad web. En este vídeo vamos a ver qué es la dislexia y cómo la tipografía puede ser una barrera de accesibilidad para las personas con dislexia.
La Federación Mundial de Neurología define la dislexia como “un trastorno que se manifiesta por la dificultad en aprender a leer (y escribir) a pesar de recibir una enseñanza correcta, mostrar una inteligencia adecuada y disfrutar de las oportunidades socioculturales normales”.
La dislexia se manifiesta normalmente durante el período escolar, en las materias básicas de lectura y escritura.
Un niño con dislexia tiene problemas para aprender palabras nuevas, lo que supone un impedimento para la correcta comprensión y expresión y que, por tanto, dificulta su proceso de aprendizaje en general.
Para resolver estos y otros problemas, se aplican ”estrategias de compensación” que facilitan la adaptación a la vida diaria apoyándose en los puntos fuertes de la persona con dislexia.
Las alteraciones en el lenguaje se pueden manifestar de diferentes formas, pero las más comunes son:
La supresión de letras, como por ejemplo “bazo” por “brazo” o “árbo” por “árbol”.
La confusión de fonemas, como por ejemplo “bile” por “dile”.
La inversión en el orden de las letras o las sílabas, como por ejemplo “pardo” por “prado” o “drala” por “ladra”.
La sustitución de una palabra por otra que empieza por la misma sílaba o tiene un sonido parecido, como por ejemplo “lagarto” por “letardo”.
En especial, se presenta una gran confusión entre las letras que tienen una similitud, tanto en su forma como en su sonido.
Así, se suele confundir la “d” y la “b”; la “p”, la “q” y la “g”; todas las anteriores entre sí, ya que en muchos casos se trata del mismo glifo rotado; la “u” y la “n”; la “h” y la “n”, la “l” con la “i” y el número “1” y otras combinaciones.
Y aquí es donde entra en juego la tipografía.
¿Cuál es el problema con las tipografías que normalmente utilizamos?
En las tipografías normales suele primar el carácter estético antes que el funcional o práctico, aunque esto último también se tiene en cuenta en muchas ocasiones con el fin de mejorar la legibilidad de los textos.
Por ejemplo, supongo que un experto en tipografía será capaz de apreciar diferencias entre estas dos letras y estas otras dos, pero yo las veo exactamente iguales.
Imagina la siguiente ecuación, “l + 1 = j”. Si mostramos esta ecuación con el tipo de letra “Gill Sans MT”, esto es lo que obtenemos.
Se entiende, ¿verdad?
Recientemente, he visitado un sitio web en el que la tipografía utilizada producía unas dificultades de lectura enormes, ya que la letra “e” se confundía con una “c”.
Al principio pensé que era un problema de Google Chrome, el navegador que estaba usando. Sin embargo, al probar la misma página web con los navegadores Mozilla Firefox y Opera se producía el mismo error. Sólo con el navegador Microsoft Internet Explorer se mostraba correctamente la letra “e”.
El tipo de letra que se utiliza en esta página se llama Lato. En concreto, se emplea la versión “Lato Light”.
¿Qué se debe hacer para evitar o reducir los problemas que pueden afectar a las personas con dislexia?
En el artículo “6 malas prácticas sorprendentes que hacen daño a los usuarios con dislexia” se proporcionan seis consejos fáciles de entender y aplicar:
Evita el efecto río que se produce cuando existen grandes huecos vacíos en el texto en líneas consecutivas.
Evita el efecto borroso.
Y evita el efecto de lavado que produce que el texto se vea débil e indistinguible.
En el libro “Accessibility Handbook”, publicado en el año 2012, también se proporcionan algunos consejos para mejorar la accesibilidad de cara a los usuarios con dislexia.
Utiliza una fuente clara y que no produzca confusión porque dos letras distintas tienen un glifo similar (como las letras b, d, p, q, que normalmente son el mismo glifo pero rotado). Curiosamente, en este libro se recomiendo el uso del tipo de letra Comic Sans, odiada por la mayoría de los expertos en tipografía.
Utiliza texto real y no imágenes: esto permite a los usuarios con problemas utilizar hojas de estilo propias con sustitución de la tipografía empleada. En cualquier caso, se recomienda el uso de tipos de letra "sans serif", como Arial, Helvetica, Verdana o Tahoma.
El contenido debe ser claro de leer. Para ello, las frases deben ser cortas (no más de 10-15 palabras por frase) y los párrafos deben ser cortos.
Los colores de alto contraste pueden dificultar la lectura: un texto negro sobre un fondo blanco puede aparecer como borroso para muchas personas con dislexia. Se aconseja que el color del texto sea gris sobre un blanco oscuro. Además, esto cansa menos la vista para todas las personas.
El texto justificado es muy bonito, pero causa problemas. Mejor no usarlo nunca.
Las imágenes pueden ayudar y distraer a la vez, no hay una solución general: a muchos disléxicos les ayudan a comprender el contenido, pero a otros les puede distraer.
Las animaciones son, sin duda, una gran distracción, mejor no usarlas. Si se tienen que usar, no se debe utilizar la opción de "autoplay" y el usuario debe tener el control para detenerlas en cualquier momento.
Por eso mismo, los anuncios (banners) son un problema, una gran distracción.
Cuidado con los fondos, en especial, las imágenes de fondo. Son otra gran distracción y dificultan la lectura.
Algunos usuarios con una dislexia muy severa emplean lectores de pantalla, como los usuarios ciegos. Así que, una página web correctamente accesible para un usuario ciego también ayudará a los usuarios con dislexia severa que utilicen un lector de pantallas.
Algunos usuarios prefieren imprimir la página web y leerla impresa, así que hay que comprobar que la página web se imprime correctamente. Por ejemplo, se puede crear una hoja de estilo CSS específica para impresión.
Se debe de proporcionar un mecanismo de navegación global que no cambie al moverse por el sitio web.
Por último, hemos visto que algunos tipos de letra pueden causar una gran confusión ya que algunas letras se representan exactamente con el mismo glifo.
Existe un tipo de letra llamada “Dyslexie” que ha sido diseñada para facilitar la lectura de textos por parte de personas con dislexia.
En esta tipografía, las letras se han diseñado de forma que sean más fáciles de distinguir unas de otras y así reducir la posibilidad de confusión. Para ello, las diferencias entre las letras conflictivas se ha enfatizado, haciendo que se diferencien más.
Y con esto finaliza este videotutorial que ha explicado los problemas que puede causar la elección de una mala tipografía entre las personas con dislexia.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
Y la transcripción del vídeo:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y este vídeo forma parte de una serie de videotutoriales dedicados a la accesibilidad web. En este vídeo vamos a ver qué es la dislexia y cómo la tipografía puede ser una barrera de accesibilidad para las personas con dislexia.
La Federación Mundial de Neurología define la dislexia como “un trastorno que se manifiesta por la dificultad en aprender a leer (y escribir) a pesar de recibir una enseñanza correcta, mostrar una inteligencia adecuada y disfrutar de las oportunidades socioculturales normales”.
La dislexia se manifiesta normalmente durante el período escolar, en las materias básicas de lectura y escritura.
Un niño con dislexia tiene problemas para aprender palabras nuevas, lo que supone un impedimento para la correcta comprensión y expresión y que, por tanto, dificulta su proceso de aprendizaje en general.
Para resolver estos y otros problemas, se aplican ”estrategias de compensación” que facilitan la adaptación a la vida diaria apoyándose en los puntos fuertes de la persona con dislexia.
Las alteraciones en el lenguaje se pueden manifestar de diferentes formas, pero las más comunes son:
La supresión de letras, como por ejemplo “bazo” por “brazo” o “árbo” por “árbol”.
La confusión de fonemas, como por ejemplo “bile” por “dile”.
La inversión en el orden de las letras o las sílabas, como por ejemplo “pardo” por “prado” o “drala” por “ladra”.
La sustitución de una palabra por otra que empieza por la misma sílaba o tiene un sonido parecido, como por ejemplo “lagarto” por “letardo”.
En especial, se presenta una gran confusión entre las letras que tienen una similitud, tanto en su forma como en su sonido.
Así, se suele confundir la “d” y la “b”; la “p”, la “q” y la “g”; todas las anteriores entre sí, ya que en muchos casos se trata del mismo glifo rotado; la “u” y la “n”; la “h” y la “n”, la “l” con la “i” y el número “1” y otras combinaciones.
Y aquí es donde entra en juego la tipografía.
¿Cuál es el problema con las tipografías que normalmente utilizamos?
En las tipografías normales suele primar el carácter estético antes que el funcional o práctico, aunque esto último también se tiene en cuenta en muchas ocasiones con el fin de mejorar la legibilidad de los textos.
Por ejemplo, supongo que un experto en tipografía será capaz de apreciar diferencias entre estas dos letras y estas otras dos, pero yo las veo exactamente iguales.
Imagina la siguiente ecuación, “l + 1 = j”. Si mostramos esta ecuación con el tipo de letra “Gill Sans MT”, esto es lo que obtenemos.
Se entiende, ¿verdad?
Recientemente, he visitado un sitio web en el que la tipografía utilizada producía unas dificultades de lectura enormes, ya que la letra “e” se confundía con una “c”.
Al principio pensé que era un problema de Google Chrome, el navegador que estaba usando. Sin embargo, al probar la misma página web con los navegadores Mozilla Firefox y Opera se producía el mismo error. Sólo con el navegador Microsoft Internet Explorer se mostraba correctamente la letra “e”.
El tipo de letra que se utiliza en esta página se llama Lato. En concreto, se emplea la versión “Lato Light”.
¿Qué se debe hacer para evitar o reducir los problemas que pueden afectar a las personas con dislexia?
En el artículo “6 malas prácticas sorprendentes que hacen daño a los usuarios con dislexia” se proporcionan seis consejos fáciles de entender y aplicar:
Evita el efecto río que se produce cuando existen grandes huecos vacíos en el texto en líneas consecutivas.
Evita el efecto borroso.
Y evita el efecto de lavado que produce que el texto se vea débil e indistinguible.
En el libro “Accessibility Handbook”, publicado en el año 2012, también se proporcionan algunos consejos para mejorar la accesibilidad de cara a los usuarios con dislexia.
Utiliza una fuente clara y que no produzca confusión porque dos letras distintas tienen un glifo similar (como las letras b, d, p, q, que normalmente son el mismo glifo pero rotado). Curiosamente, en este libro se recomiendo el uso del tipo de letra Comic Sans, odiada por la mayoría de los expertos en tipografía.
Utiliza texto real y no imágenes: esto permite a los usuarios con problemas utilizar hojas de estilo propias con sustitución de la tipografía empleada. En cualquier caso, se recomienda el uso de tipos de letra "sans serif", como Arial, Helvetica, Verdana o Tahoma.
El contenido debe ser claro de leer. Para ello, las frases deben ser cortas (no más de 10-15 palabras por frase) y los párrafos deben ser cortos.
Los colores de alto contraste pueden dificultar la lectura: un texto negro sobre un fondo blanco puede aparecer como borroso para muchas personas con dislexia. Se aconseja que el color del texto sea gris sobre un blanco oscuro. Además, esto cansa menos la vista para todas las personas.
El texto justificado es muy bonito, pero causa problemas. Mejor no usarlo nunca.
Las imágenes pueden ayudar y distraer a la vez, no hay una solución general: a muchos disléxicos les ayudan a comprender el contenido, pero a otros les puede distraer.
Las animaciones son, sin duda, una gran distracción, mejor no usarlas. Si se tienen que usar, no se debe utilizar la opción de "autoplay" y el usuario debe tener el control para detenerlas en cualquier momento.
Por eso mismo, los anuncios (banners) son un problema, una gran distracción.
Cuidado con los fondos, en especial, las imágenes de fondo. Son otra gran distracción y dificultan la lectura.
Algunos usuarios con una dislexia muy severa emplean lectores de pantalla, como los usuarios ciegos. Así que, una página web correctamente accesible para un usuario ciego también ayudará a los usuarios con dislexia severa que utilicen un lector de pantallas.
Algunos usuarios prefieren imprimir la página web y leerla impresa, así que hay que comprobar que la página web se imprime correctamente. Por ejemplo, se puede crear una hoja de estilo CSS específica para impresión.
Se debe de proporcionar un mecanismo de navegación global que no cambie al moverse por el sitio web.
Por último, hemos visto que algunos tipos de letra pueden causar una gran confusión ya que algunas letras se representan exactamente con el mismo glifo.
Existe un tipo de letra llamada “Dyslexie” que ha sido diseñada para facilitar la lectura de textos por parte de personas con dislexia.
En esta tipografía, las letras se han diseñado de forma que sean más fáciles de distinguir unas de otras y así reducir la posibilidad de confusión. Para ello, las diferencias entre las letras conflictivas se ha enfatizado, haciendo que se diferencien más.
Y con esto finaliza este videotutorial que ha explicado los problemas que puede causar la elección de una mala tipografía entre las personas con dislexia.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
lunes, 16 de septiembre de 2013
El contenido oculto
Lo de ocultar cierto contenido de una página web para que lo vean ciertos usuarios, pero otros no, en general no es una buena práctica. Dificulta el desarrollo, dificulta el mantenimiento, y al final puede ser un desastre. Por ello, no hay que abusar de esta posibilidad, pero a veces sí que es una buena solución para ciertos problemas/soluciones (por ejemplo, para ofrecer los enlaces de saltar contenido). Pero se tiene que hacer bien.
El artículo Do not use display:none to visually hide content intended for screen readers nos explica que usar display:none para que no se vea cierto contenido, pero con el propósito de que esté disponible para los usuarios que utilicen un lector de pantallas (screen reader) es un completo error.
En este artículo no se comenta cuál es la mejor técnica para esconder cierto contenido y que esté disponible para los lectores de pantalla. Pero yo eso sí que lo expliqué en mi artículo Técnicas para ocultar contenido.
Bonus, cómo se debería hacer usando WAI-ARIA Hiding visible content from screen readers with aria-hidden.
El artículo Do not use display:none to visually hide content intended for screen readers nos explica que usar display:none para que no se vea cierto contenido, pero con el propósito de que esté disponible para los usuarios que utilicen un lector de pantallas (screen reader) es un completo error.
En este artículo no se comenta cuál es la mejor técnica para esconder cierto contenido y que esté disponible para los lectores de pantalla. Pero yo eso sí que lo expliqué en mi artículo Técnicas para ocultar contenido.
Bonus, cómo se debería hacer usando WAI-ARIA Hiding visible content from screen readers with aria-hidden.
viernes, 13 de septiembre de 2013
Diseño web para todos I
Diseño web para todos I y Diseño web para todos II son dos libros escritos por Carlos Egea García y editados por Icaria Editorial en el año 2007. Son de los pocos libros en español sobre accesibilidad web.
jueves, 12 de septiembre de 2013
Curso gratuito Introduction to Web Accessibility
El martes pasado, Google anunció el curso Introduction to Web Accessibility. El curso comenzará el próximo 17 de septiembre y finalizará el día 30.
Desgraciadamente, si revisamos el contenido del curso veremos que está muy centrado en los usuarios ciegos o con baja visión que emplean un lector de pantallas, y no un lector de pantallas, sino ChromeVox, el lector de pantallas gratuito de Google. Pero bueno, "a caballo regalado, no le mires los dientes..."
En la lista de correo de WebAIM ha causado bastante polémica el contenido del curso, tal como podemos leer en for Chrome devs: intro to accessibility course.
Por último, el vídeo de presentación del curso:
Desgraciadamente, si revisamos el contenido del curso veremos que está muy centrado en los usuarios ciegos o con baja visión que emplean un lector de pantallas, y no un lector de pantallas, sino ChromeVox, el lector de pantallas gratuito de Google. Pero bueno, "a caballo regalado, no le mires los dientes..."
En la lista de correo de WebAIM ha causado bastante polémica el contenido del curso, tal como podemos leer en for Chrome devs: intro to accessibility course.
Por último, el vídeo de presentación del curso:
miércoles, 11 de septiembre de 2013
Stylish
Stylish es un complemento para el navegador Mozilla Firefox que permite personalizar la apariencia de las páginas web y el interfaz de usuario. Es una opción muy interesante para las personas con visión reducida que tienen dificultades para ver el contenido de una página web con los colores o los tamaños de letra por defecto.
Stylish permite gestionar fácilmente los estilos de usuario. Los estilos de usuario mejoran tu experiencia de navegación ya que te permiten mejorar sitios poco atractivos, personalizar la apariencia de tu navegador y cliente de correo o simplemente divertirte. Gracias al repositorio en línea, que encontrarás en userstyles.org, no hace falta que sepas escribir estilos: con solo un par de clics podrás aplicar el estilo que quieras. Stylish es a CSS lo que Greasemonkey es a Javascript pero, al contrario que otros formas de utilizar estilos de usuario, la mayoría de ellos funcionan inmediatamente.Por ejemplo, aquí tenemos el estilo Accessible Facebook Design, con una captura de pantalla de Facebook antes:
Guía del usuario: http://userstyles.org/stylish/help
Informe de errores y solicitud de funciones: http://userstyles.org/stylish/discussion
Y después:
martes, 10 de septiembre de 2013
Redes - Integración social
El 3 de junio de 2012, se emitió en Redes el programa Integración social. La descripción del programa dice:
Está claro que la vida es mejor gracias a la tecnología. Pero la tecnología que sirve para consolidar la vida en sociedad, puede significar un obstáculo que margina a un grupo determinado de personas, como puede ser el colectivo de personas con discapacidad visual.Gracias al altruismo de la sociedad y de organizaciones como la ONCE, la inclusión social de los discapacitados visuales es cada vez mayor. Uno de sus grandes objetivos es lograr que las empresas desarrollen tecnologías que puedan utilizar tanto los ciegos como los videntes. Mientras se avanza en ese camino, la ONCE desarrolla tecnologías propias y adapta otras ya existentes para que las puedan utilizar personas con discapacidad visual.Entrevista de Eduard Punset a María Jesús Varela, directora del Centro de Investigación, Desarrollo y Aplicación Tiflotécnica de la ONCE, y a Elena Gastón, maestra del Centro de Recursos Educativos de la ONCE.Por cierto, en el programa se nombran los "revisores de pantalla", que son los "lectores de pantalla".
lunes, 9 de septiembre de 2013
Desarrolladores web que se preocupan por la accesibilidad web
Una lista de expertos en desarrolladores web que se preocupan por la accesibilidad web, extraída de 10sharpdesign:
viernes, 6 de septiembre de 2013
El uso de tabindex para mejorar la accesibilidad
En WAI-ARIA se redefine el comportamiento del atributo tabindex de HTML. En WAI-ARIA 1.0 Primer está explicado en el punto 2.1.3. Provision of the Keyboard or Input Focus: "What object am I working on?".
En HTML 4.01 y XHTML 1.x, sólo los controles de los formularios (button, input, select, textarea), los enlaces (a y area) y los objetos (object) pueden recibir el foco. Esto dificulta el desarrollo de interfaces avanzadas en las que con los eventos (onclick, onkeydown) podemos hacer que se pueda interactuar con cualquier elemento de la página.
En WAI-ARIA se puede emplear tabindex para permitir que un elemento cualquiera pueda recibir el foco:
En HTML 4.01 y XHTML 1.x, sólo los controles de los formularios (button, input, select, textarea), los enlaces (a y area) y los objetos (object) pueden recibir el foco. Esto dificulta el desarrollo de interfaces avanzadas en las que con los eventos (onclick, onkeydown) podemos hacer que se pueda interactuar con cualquier elemento de la página.
En WAI-ARIA se puede emplear tabindex para permitir que un elemento cualquiera pueda recibir el foco:
- Si no está el atributo tabindex, el comportamiento es el normal, y sólo los controles de un formulario pueden recibir el foco con el ratón o desde JavaScript con element.focus().
- Si tabindex toma un valor negativo (tabindex="-1"), el elemento puede recibir el foco con el ratón o desde JavaScript con element.focus(), pero no se puede navegar a él mediante la tecla tabulación, es decir, el elemento no está en el flujo normal de tabulación.
- Si tabindex toma el valor cero (tabindex="0"), el elemento puede recibir el foco con el ratón o desde JavaScript con element.focus(), y se puede navegar a él mediante la tecla tabulación (la posición que ocupa en el orden de tabulación es la correspondiente a su posición en el documento).
- Finalmente, si tabindex toma un valor positivo (tabindex="1"), el elemento puede recibir el foco con el ratón o desde JavaScript con element.focus(), se puede navegar a él mediante la tecla tabulación, y el valor del atributo indica su posición en el orden de tabulación; además, se colocan por delante de cualquier elemento que tenga tabindex="0" o cualquier elemento que reciba el foco de forma natural (los controles de los formularios y los enlaces).
Bueno, esto es la teoría... luego falta que los navegadores y los lectores de pantalla la cumplan.
En tabindex, keyboard focus and some ARIA in screen readers, se presentan los resultados de unas pruebas realizadas con diferentes ejemplos en diferentes navegadores y con diferentes lectores de pantalla. Con JAWS los resultados son los adecuados con Internet Explorer y Firefox, pero con otros lectores de pantalla (NVDA, SAToGo, Windows-Eyes y VoiceOver) ocurren algunas cosas raras.
jueves, 5 de septiembre de 2013
¿Qué hacer si algo no se puede hacer accesible?
Hace unos días, durante una conversación que tuve con una persona que quería resolver unas dudas sobre accesibilidad web, surgió la cuestión de qué hacer si algo no se podía hacer accesible. Yo le dije que entonces se tendría que proporcionar una alternativa accesible y esta persona me dijo que en la ONCE le habían dicho que eso no se podía hacer, que eso de ofrecer una versión alternativa era discriminación.
¿De verdad?
¿Es discriminación ofrecer un baño adaptado a las personas con discapacidad?
¿Es discriminación incluir un vídeo en una página web, junto con una videodescripción?
Las Pautas de Accesibilidad al Contenido en la Web lo permiten. En WCAG 1.0 podemos leer en la pauta 11 Utilice las tecnologías y pautas W3C:
11.4 Si, después de los mayores esfuerzos, no puede crear una página accesible, proporcione un vínculo a una página alternativa que use tecnologías W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan a menudo como la página (original) inaccesible. [Prioridad 1]
En WCAG 2.0 podemos leer en los niveles de adecuación:
Nivel de conformidad: Uno de los siguientes niveles de conformidad se satisface por completo.
Nivel A: Para lograr conformidad con el Nivel A (el mínimo), la página web satisface todos los Criterios de Conformidad del Nivel A, o proporciona una versión alternativa conforme.
Nivel AA: Para lograr conformidad con el Nivel AA, la página web satisface todos los Criterios de Conformidad de los Niveles A y AA, o proporciona una versión alternativa conforme al Nivel AA.
Nivel AAA: Para lograr conformidad con el Nivel AAA, la página web satisface todos los Criterios de Conformidad de los Niveles A, AA y AAA, o proporciona una versión alternativa conforme al Nivel AAA.
Y una versión alternativa conforme es:
Una versión que:
- es conforme según un nivel designado, y
- proporciona la misma información y funcionalidad en el mismo idioma, y
- se mantiene actualizada con la misma frecuencia que el contenido no conforme, y
- para la cual al menos una de las siguientes condiciones es verdadera:
- se puede acceder a la versión conforme desde la página no conforme a través de un mecanismo compatible con la accesibilidad, o
- sólo se puede acceder a la versión no conforme desde la versión conforme, o
- sólo se puede acceder a la versión no conforme desde una página conforme que además proporciona un mecanismo para llegar a la versión conforme.
Por tanto si tenemos una página web con algo que no es accesible y no se puede accesible, podemos ofrecer una alternativa, pero siempre que se cumpla lo anterior. Y si lo hacemos así, la página web cumplirá con WCAG 2.0.
Mientras que algunas personas pueden entender esta forma de actuar como una discriminación, como "ofrecer una puerta trasera para las personas con discapacidad", hay que entender que no es así y que hay situaciones en las que es la única solución o que es incluso mejor que sea así. Por ejemplo, en el documento Understanding Conforming Alternate Versions muestran varias situaciones que refuerzan esta solución:
Mientras que algunas personas pueden entender esta forma de actuar como una discriminación, como "ofrecer una puerta trasera para las personas con discapacidad", hay que entender que no es así y que hay situaciones en las que es la única solución o que es incluso mejor que sea así. Por ejemplo, en el documento Understanding Conforming Alternate Versions muestran varias situaciones que refuerzan esta solución:
Why does WCAG permit conforming alternate versions of Web pages to be included in conformance claims? That is, why include pages that do not satisfy the Success Criteria for a conformance level in the scope of conformance or a claim?
- Sometimes, pages use technologies that are not yet accessibility supported. When a new technology emerges, assistive technology support may lag behind, or may only be available to some target audiences. So authors may not be able to rely on the new technology for all users. However, there may be other benefits to using the new technology, e.g., better performance, a wider range of modalities available, etc. The alternate version requirement allows authors to include such Web pages in their Web site by providing an accessible alternative page in technologies that are accessibility supported. Users for whom the new technology is adequately supported get the benefits of the new version. Authors who look ahead to future accessibility support can satisfy the Success Criteria now with the alternate version page, and also work with the other page to build in future access when assistive technology (AT) support is available.
- For a variety of reasons, it may not be possible to modify some content on a Web page. For instance,
- It may be critical to include an exact visual copy of a document for legal or historical reasons
- The Web page may be included in a site but the site owner may not have the legal rights to modify the content on the original page
- The company may not legally be able to remove, or alter in any way, something that was previously posted.
- An author may not have permission to alter a document from another department, agency, or company
- Sometimes, the best experience for users with certain types of disabilities is provided by tailoring a Web page specifically to accommodate that disability. In such a situation, it may not be possible or practical to make the Web page accommodate all disabilities by satisfying all of the Success Criteria. The alternate versions requirement permits such specialized pages to be included within a conformance claim as long as there is a fully conformant 'alternate version' page.
A concern when permitting Web pages that do not satisfy the Success Criteria is that people with disabilities will encounter these non-conforming pages, not be able to access their content, and not be able to find the “conforming alternate version." A key part of the Alternate Versions provision, therefore, is the ability to find the conforming page (the alternate version) from the non-conforming page when it is encountered. The conformance requirement that permits alternate pages, therefore, also requires a way for users to find the accessible version among the alternate versions.
- Many sites which are committed to accessibility have large quantities of legacy documents. While the information has been made available in accessible formats, there would be significant institutional resistance and procedural obstacles to removing these files en mass. Some organizations, especially governmental bodies, give precedence to traditional print-oriented processes. Even as these organizations have adapted to Internet publishing and embraced the need for accessible formats, they still retain a paper mindset and often insist on formats designed for hard copy as the "primary" version (even for documents that are only ever "published" electronically). Although the Working Group feels these approaches should be deprecated it does not feel they can be forbidden so long as accessible versions are readily available.
Note that providing an alternate version is a fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible.
miércoles, 4 de septiembre de 2013
Tres cosas que aprendí sobre los usuarios de lectores de pantalla
Aunque es un poco antiguo (año 2004), el artículo Three things I learned about screen reader users es interesante:
- Ninguno de los usuarios que observó el autor de este artículo utilizó los atajos de teclado que había definido en la página.
- Todo el mundo uso el lector de pantallas JAWS. Lo que ocultó con display: none no aparecía en los lectores de pantalla (no es la forma correcta de esconder contenido).
- Cuando los usuarios tenían que rellenar un formulario, utilizan el modo especial de formulario, que permite moverse de un control a otro fácilmente, pero que puede hacer que cierta información desaparezca. Se debe emplear fieldset y legend para proporcionar información adicional.
martes, 3 de septiembre de 2013
HTML5 accessibility
HTML5 accessibility es un sitio web que ya he recomendado en el pasado, pero que conviene recordar de vez en cuando.
En este sitio web encontraremos información sobre el soporte de HTML5 y las nuevas características de accesibilidad por parte de los navegadores más populares.
En este sitio web encontraremos información sobre el soporte de HTML5 y las nuevas características de accesibilidad por parte de los navegadores más populares.
lunes, 2 de septiembre de 2013
Libros sobre accesibilidad web
En mi sitio web sobre accesibilidad web tengo un apartado dedicado a libros sobre accesibilidad web. Algunos están enlazados a versiones gratuitas que se han publicado a Google Books que permite consultar gran parte del libro.
Algunos de los más interesantes son:
Algunos de los más interesantes son:
sábado, 31 de agosto de 2013
Estoy en Twitter y YouTube
Recuerda que también me puedes seguir a través de Twitter en @sergiolujanmora
También puedes consultar mi canal de vídeos en YouTube.
Y mi otro blog sobre programación en Internet.
También puedes consultar mi canal de vídeos en YouTube.
Y mi otro blog sobre programación en Internet.
miércoles, 28 de agosto de 2013
Mejorando la accesibilidad web: la percepción de los webmasters
Interesante el artículo Improving web accessibility: a study of webmaster perceptions, publicado en el año 2004.
¿Nueve años después, la situación sigue igual? El resumen del artículo es:
Large percentages of web sites continue to be inaccessible to people with disabilities. Since tools and guidelines are available to help designers and webmasters in making their web sites accessible, it is unclear why so many sites continue to be inaccessible. In this paper, we present the “Web Accessibility Integration Model,” which highlights the multiple points within web development where accessibility can be incorporated or forgotten. It is uncertain why webmasters do not use the various tools and guidelines that currently are available for making web sites accessible. A survey was created, and data was collected from 175 webmasters, indicating their knowledge on the topic of web accessibility and the reasons for their actions related to web accessibility. Findings and future directions for research are discussed.Y la introducción:
The world wide web provides a wealth of information, and the user population of the web is diverse, including users of all ages, educational levels, and levels of computing experience (Shneiderman, 2000). Many users of the web have various types of disabilities. These disabilities include sensory (e.g. hearing and vision), motor (e.g. limited use of hands) and cognitive (e.g. learning disabilities) impairments. These users with disabilities use various forms of assistive technology to allow them to browse web sites. Assistive technologies include hardware and software such as screen readers, voice recognition, alternative pointing devices, alternate keyboards, and refreshable Braille displays (Paciello, 2000).
Users with disabilities can only utilize a web site if it is designed to be compatible with the various assistive technologies. A web site that is sufficiently flexible to be used by all of these assistive technologies is called an accessible web site (Slatin & Rush, 2003). An accessible web site is very similar to an accessible building. An accessible building offers curb cuts, ramps, and elevators to allow a person with disabilities to enter and navigate through the building with ease. An accessible web site offers similar functionality.
Accessibility is not just a high-level theoretical goal. Currently, there are guidelines that web developers can follow so that their web sites can be accessible. For instance, the Web Accessibility Initiative provides guidelines, called the Web Content Accessibility Guidelines (WCAG) to help developers make their web sites accessible (http://www.w3.org/wai). The United States Government offers similar guidelines to web developers, which are included in the Section 508 initiative (http://www.section508.gov). A copy of the Section 508 guidelines is included in Appendix A. In addition, automated software tools are available to help find accessibility flaws in web sites before the sites are publicly posted. These software tools include Bobby, RAMP, InFocus, and A-Prompt (Ivory, Mankoff, & Le, 2003). In addition, new versions of web development tools (such as DreamWeaver and FrontPage) include tools that assist developers with accessibility-related issues. Given that the guidelines and tools are there, it seems hopeful that most web sites would be accessible. In fact, many governments make web accessibility a requirement for government information on the web. The United States, England, Canada, Portugal, and Australia require some types of government information to be accessible (Slatin & Rush, 2003).
Unfortunately, most web sites are not currently accessible. Recent studies point out that large percentages (70–98%, depending on the category of site) of web sites are not accessible. For instance, in recent studies, private and non-profit web sites (Lazar, Beere, Greenidge, & Nagappa, 2003), for-profit commerce web sites (Sullivan & Matson, 2000), US state web sites (Ceaparu & Shneiderman, 2002), and even US Federal web sites (Stowers, 2002) were found to have major accessibility problems. In addition, over time, web sites are getting more inaccessible (Lazar & Greenidge, in preparation), as accessibility violations have been added to sites.
Web sites need to be accessible to all users, including those with disabilities. Given all of the resources available for making web sites accessible, it is unclear why they remain so inaccessible. Our goal is to learn more about why sites are not accessible. Since the person that has the greatest influence on currently-existing web sites is the webmaster, the researchers decided to start the investigation with webmasters. The researchers created a survey to learn more about webmasters and their perceptions and knowledge on the topic of web accessibility. The results of that survey are discussed in this paper. In addition, we have created a model, called the Web Accessibility Integration Model, which describes the various ways that accessibility flaws enter a web site. Our goal with this research is to increase the knowledge about why web sites are not accessible, so that we can make the web a more accessible place.
lunes, 26 de agosto de 2013
Introducción a la accesibilidad web
Web accessibility es un vídeo de menos de una hora de duración en la que se recoge una conferencia que se impartió en Vanderbilt University en enero de 2011.
viernes, 23 de agosto de 2013
Cinco formas de usar HTML5 con ARIA
El artículo 5 HTML5 and ARIA design patterns explica cinco formas de usar HTML5 con ARIA.
Estos patrones pueden parecer un poco repetitivos, puede parecer que se está diciendo lo mismo dos veces... así es, desgraciadamente no todos los lectores de pantalla actuales ofrecen el mismo soporte de HTML5 y ARIA, así que por ahora "hay que decir lo mismo dos veces".
Estos patrones pueden parecer un poco repetitivos, puede parecer que se está diciendo lo mismo dos veces... así es, desgraciadamente no todos los lectores de pantalla actuales ofrecen el mismo soporte de HTML5 y ARIA, así que por ahora "hay que decir lo mismo dos veces".
jueves, 22 de agosto de 2013
La lucha de las personas ciegas por una Web más accesible
El artículo The blind community's fight for a more accessible Web, publicado en The Daily Dot, me ha sorprendido porque señala que todavía hay gente que piensa que las personas con discapacidad no utilizan la Web.
En el artículo se explica que la Web es muy importante para las personas con discapacidad:
En el artículo se explica que la Web es muy importante para las personas con discapacidad:
The Internet is as critical to these individuals as it is for anyone else—if not more so, since the Web is often used to avoid the challenges and transit that accompanies daily activities like shopping.Se cuenta la historia de un usuario ciego que cuando empezó a navegar por la Web, tenía que copiar los textos de las páginas web al programa de síntesis de voz (parece que no existían todavía los lectores de pantalla):
Blind for as long as he can remember, Olsen has been able to trace the progress of online accessibility since the Internet went mainstream in the mid-90s. He received his first computer at the age of 8. Back then, the only way for him to "surf the ‘net" was to copy and paste text into a speech program.Hacer un sitio web accesible no es un problema desde un punto de vista técnico, es posible. El problema que existe hoy en día es lograr que la gente lo haga:
"The technology is there," he said. "The battle has been getting websites to comply."Y el mayor problema es la ignorancia:
Lazar said most companies that fail to provide accessible websites are acting from a place of ignorance. In his experience, he said many companies just assume they don't have blind or otherwise impaired customers using their website. He said that's a mistaken belief, since many blind people have used websites to better plan trips to retail locations or avoid the hassle of going to stores altogether.
miércoles, 21 de agosto de 2013
Reproductores multimedia accesibles
Es de hace unos meses, pero es una buena referencia: Accessible HTML5 Media Players and More.
martes, 20 de agosto de 2013
Comparativa de la accesibilidad en diferentes países
Muy interesante la página Freedom of expression and access to information. Permite comparar la situación de la accesibilidad web en diferentes países europeos (Austria, Bulgaria, Croacia, ..., España) a través de una serie de preguntas, como por ejemplo:
Is there existing legislation in your country to encourage or ensure that websites, in particular government, public service or other sites providing widespread services of general use (such as hiring services, travel, telephony, energy, education, employment, leisure...) are accessible to visually impaired people? Please be sure to specify in your answer to which categories of site the regulation(s) apply.
What are the standards that are used in your country to measure website accessibility?
Is there an authority in place to establish, measure and control website accessibility?Y así hasta 9 preguntas.
lunes, 19 de agosto de 2013
WCAG también ayuda a las personas mayores
These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.Traducción:
Estas pautas también hacen que el contenido web sea más fácil de usar por las personas mayores con capacidades que cambian debido al envejecimiento y muchas veces mejoran la usabilidad para todos los usuarios en general.WCAG 2.0
viernes, 16 de agosto de 2013
10 acontecimientos que mejoraron la accesibilidad de la informática
El artículo 10 milestones in the mainstreaming of accessibility explica 10 acontecimientos que han ayudado a mejorar la accesibilidad de la informática:
- 1998 – Section 508
- 1999 – The W3C Web Content Accessibility Guidelines (WCAG) 1.0
- 2000 – Narrator in Windows 2000
- 2005 – VoiceOver in Mac OS X 10.4 Tiger
- 2006 – closed captions on YouTube
- 2008 – The W3C Web Content Accessibility Guidelines (WCAG) 2.0
- 2009 – The first mainstream accessible smartphone
- 2011 – Google Android 4.0 Ice Cream Sandwich
- 2012 – Windows 8
- 2013 and beyond – Global Public Inclusive Infrastructure (GPII)
jueves, 15 de agosto de 2013
Los ciegos no pueden averiguar cómo lograr la indulgencia plenaria
No conocía el concepto de indulgencia plenaria de la iglesia católica, es un buen método para ir directo al Cielo sin pasar por el Purgatorio. Pero si eres ciego, lo vas a tener un poco difícil: alguien te lo tendrá que explicar.
En el sitio web del Santuario de Torreciudad hay una página web en la que explican cómo obtener la indulgencia plenaria.
Pero esta página tiene un grave problema: la explicación que se ofrece está en una imagen, que no tiene ni texto alternativo ni descripción larga. Consecuencia: si eres ciego, antes tendrás que pasar por el Purgatorio.
En el sitio web del Santuario de Torreciudad hay una página web en la que explican cómo obtener la indulgencia plenaria.
Pero esta página tiene un grave problema: la explicación que se ofrece está en una imagen, que no tiene ni texto alternativo ni descripción larga. Consecuencia: si eres ciego, antes tendrás que pasar por el Purgatorio.
miércoles, 14 de agosto de 2013
Iberia surrealista
Ayer, Francisco Alcaide mantuvo una conversación surrealista con la cuenta de Twitter de Iberia. La conversación me recordó al famoso programa Eliza, uno de los primeros programas de procesamiento del lenguaje natural, aunque me parece que Eliza mostraba más inteligencia que el community manager de Iberia. Incluyo una captura de pantalla con la conversación:
El texto de la conversación:
Francisco Alcaide @pacoalmar 10h
Y no solo la web, tanpoco sus boletines "@tinitun No me puedo creer lo mala que es la página de @iberia, #accesibilidad de mal en peor"
Iberia @Iberia 10h
@pacoalmar Hola Francisco, en cuanto los boletines puedes hacer una sugerencia aquí: http://www.iberia.com/suggestions/?language=es … Un saludo.
Francisco Alcaide @pacoalmar 9h
@Iberia por ejemplo el control de seguridad tiene captcha inaccesible a lectores de pantalla y otras discapacidades pic.twitter.com/ahp46PrUsp
Iberia @Iberia 9h
@pacoalmar Hola Francisco, ¿has tratado utilizar otro navegador o borrando el cache? Un saludo.
Francisco Alcaide @pacoalmar 8h
Qué tiene que ver con los captchas “@Iberia: @pacoalmar Hola Francisco, ¿has tratado utilizar otro navegador o borrando el cache? Un saludo”
Iberia @Iberia 8h
@pacoalmar Hola Francisco, ¿nos puedes enviar un pantallazo por DM? Un saludo.
Francisco Alcaide @pacoalmar 8h
@Iberia Lo tenéis en el primer tweet referente al capctcha
Y ya que estamos, un par de vídeos que hice sobre los problemas de accesibilidad que presentan los correos (boletines) de Iberia:
El texto de la conversación:
Francisco Alcaide @pacoalmar 10h
Y no solo la web, tanpoco sus boletines "@tinitun No me puedo creer lo mala que es la página de @iberia, #accesibilidad de mal en peor"
Iberia @Iberia 10h
@pacoalmar Hola Francisco, en cuanto los boletines puedes hacer una sugerencia aquí: http://www.iberia.com/suggestions/?language=es … Un saludo.
Francisco Alcaide @pacoalmar 9h
@Iberia por ejemplo el control de seguridad tiene captcha inaccesible a lectores de pantalla y otras discapacidades pic.twitter.com/ahp46PrUsp
Iberia @Iberia 9h
@pacoalmar Hola Francisco, ¿has tratado utilizar otro navegador o borrando el cache? Un saludo.
Francisco Alcaide @pacoalmar 8h
Qué tiene que ver con los captchas “@Iberia: @pacoalmar Hola Francisco, ¿has tratado utilizar otro navegador o borrando el cache? Un saludo”
Iberia @Iberia 8h
@pacoalmar Hola Francisco, ¿nos puedes enviar un pantallazo por DM? Un saludo.
Francisco Alcaide @pacoalmar 8h
@Iberia Lo tenéis en el primer tweet referente al capctcha
lunes, 12 de agosto de 2013
La lengua internacional de signos
De pequeño pensaba que la lengua de signos era universal, se usaba la misma en todo el mundo. Pero no es así, la situación es similar a lo que ocurre con las lenguas orales: la gente tiene la manía de querer tener su propia lengua (¡castigo divino!).
Ahora he descubierto que existe la lengua de signos internacional, International Sign, una versión simplificada de la lengua de signos que tiene el objetivo de que sea fácil de entender. Pero como suele ocurrir (¡castigo divino!), no existe una, sino que existen tres variantes de esta lengua.
Por cierto, en la página del World Report on Disability de la Organización Mundial de la Salud podemos ver unos vídeos en los que se emplea esta lengua.
[Actualización 13/08/2013]
Mar González me pasa un enlace a una entrada de su blog donde habla de la lengua internacional de signos: La lengua de signos universal no existe: el sistema internacional de signos.
Ahora he descubierto que existe la lengua de signos internacional, International Sign, una versión simplificada de la lengua de signos que tiene el objetivo de que sea fácil de entender. Pero como suele ocurrir (¡castigo divino!), no existe una, sino que existen tres variantes de esta lengua.
Por cierto, en la página del World Report on Disability de la Organización Mundial de la Salud podemos ver unos vídeos en los que se emplea esta lengua.
[Actualización 13/08/2013]
Mar González me pasa un enlace a una entrada de su blog donde habla de la lengua internacional de signos: La lengua de signos universal no existe: el sistema internacional de signos.
viernes, 9 de agosto de 2013
Navegación a través de landmarks en Firefox
Los landmark roles de Accessible Rich Internet Applications (WAI-ARIA) 1.0 son regiones especiales de una página web que se definen para que el usuario pueda navegar fácilmente entre ellas. Aunque es una característica que mejora la accesibilidad web, su empleo puede mejorar la usabilidad y, por tanto, puede ser beneficioso para todos los usuarios.
Los landmark roles que se han definido hasta ahora son:
Algunos tienen un equivalente en las etiquetas HTML, como aside, nav o la nueva etiqueta main, mientras que otros no (Using WAI-ARIA Landmarks – 2013).
Los lectores de pantalla modernos son capaces de interpretar los landmark roles. Por ejemplo, en el siguiente vídeo, How ARIA landmark roles help screen reader users, vemos y escuchamos una demostración de su uso:
¿Pero qué pasa con los usuarios que no necesitan y no usan un lector de pantallas, como por ejemplo los usuarios que manejan el ordenador con el teclado? Estos usuarios también se pueden beneficiar de los landmark roles, pero desgraciadamente, los navegadores actuales no proporcionan ningún mecanismo para su uso.
Sin embargo, en el caso de Mozilla Firefox, existe una extensión que resuelve el problema: Enabling landmark-based keyboard navigation in Firefox.
Los landmark roles que se han definido hasta ahora son:
- application
- banner
- complementary
- contentinfo
- form
- main
- navigation
- search
Algunos tienen un equivalente en las etiquetas HTML, como aside, nav o la nueva etiqueta main, mientras que otros no (Using WAI-ARIA Landmarks – 2013).
Los lectores de pantalla modernos son capaces de interpretar los landmark roles. Por ejemplo, en el siguiente vídeo, How ARIA landmark roles help screen reader users, vemos y escuchamos una demostración de su uso:
¿Pero qué pasa con los usuarios que no necesitan y no usan un lector de pantallas, como por ejemplo los usuarios que manejan el ordenador con el teclado? Estos usuarios también se pueden beneficiar de los landmark roles, pero desgraciadamente, los navegadores actuales no proporcionan ningún mecanismo para su uso.
Sin embargo, en el caso de Mozilla Firefox, existe una extensión que resuelve el problema: Enabling landmark-based keyboard navigation in Firefox.
miércoles, 7 de agosto de 2013
Hablamos de accesibilidad web
Un vídeo de menos de tres minutos de duración que explica qué es la accesibilidad web, Hablamos de accesibilidad web:
La accesibilidad web, entendida como me da la gana
Siempre me sorprende la capacidad que tiene la administración pública para hacer lo que le da la gana. En vez de dar ejemplo, son los primeros que se saltan sus propias normas. Supongo que aplican eso de "Juan Palomo, yo me lo guiso, yo me lo como".
Ahí tenemos la página web sobre accesibilidad de El Portal del Mayor de la Comunidad de Madrid:
Ahí tenemos la página web sobre accesibilidad de El Portal del Mayor de la Comunidad de Madrid:
- Hace referencia a la Ley de Servicios de la Sociedad de la Información y el Comercio Electrónico. Esa ley, la Ley 34 del año 2002, ha sido "superada" por otras leyes posteriores.
- Dicen que cumplen las normas WCAG en su nivel A. No indican qué versión de WCAG, el mínimo exigido por la ley es el nivel AA, y eso de que cumplen el nivel A, está por ver...
lunes, 5 de agosto de 2013
En Estados Unidos la cagan igual que en España
En el año 2011, el Gobierno de los Estados Unidos inauguró el sitio web We the people para que la gente pudiera realizar peticiones a su gobierno. Las peticiones tienen que alcanzar un mínimo de firmas para que sean contestadas por el gobierno. Algunas de las peticiones realizadas hasta ahora tienen su sentido (por ejemplo, un mayor control de las armas), mientras que hay otras que son ridículas (construir la Estrella de la Muerte de Star Wars, construir la USS Enterprise de Star Trek).
En el artículo The dumb reason blind Americans can't sign a petition supporting their rights nos cuentan que en la casa blanca la cagaron. El formulario para realizar una petición tenía un captcha visual, y la alternativa sonora era prácticamente ininteligible.
Esto me ha recordado cagadas del Gobierno de España, como la cagada del formulario para enviar comentarios para la ley de transparencia, o la cagada actual del formulario para escribir al presidente del Senado:
¿La Casa Blanca arregló su cagada? Claro, allí intentan limpiar su mierda, mientras que aquí dejan que huela.
Como se puede ver en la siguiente imagen, el captcha visual y sonoro lo cambiaron por un captcha lógico en el que se hacen varias preguntas. Este tipo de captcha presenta un problema importante, la barrera del idioma, pero en este caso en el que el formulario es para realizar una petición que hay que redactar en inglés, no plantea ningún problema.
Otros ejemplos de preguntas:
Black, jelly and yellow: how many colours in the list?
Eye, glove, white, cake, prison and prison: how many colours in the list?
En el artículo The dumb reason blind Americans can't sign a petition supporting their rights nos cuentan que en la casa blanca la cagaron. El formulario para realizar una petición tenía un captcha visual, y la alternativa sonora era prácticamente ininteligible.
Esto me ha recordado cagadas del Gobierno de España, como la cagada del formulario para enviar comentarios para la ley de transparencia, o la cagada actual del formulario para escribir al presidente del Senado:
¿La Casa Blanca arregló su cagada? Claro, allí intentan limpiar su mierda, mientras que aquí dejan que huela.
Como se puede ver en la siguiente imagen, el captcha visual y sonoro lo cambiaron por un captcha lógico en el que se hacen varias preguntas. Este tipo de captcha presenta un problema importante, la barrera del idioma, pero en este caso en el que el formulario es para realizar una petición que hay que redactar en inglés, no plantea ningún problema.
Otros ejemplos de preguntas:
Black, jelly and yellow: how many colours in the list?
Eye, glove, white, cake, prison and prison: how many colours in the list?
viernes, 2 de agosto de 2013
La legislación europea sobre accesibilidad web
Gracias a Álvaro, un lector de este blog, me ha llegado esta noticia: El modelo español como paradigma en la futura legislación europea sobre accesibilidad de los Sitios Web.
Hace unos meses comenté que la Unión Europea está preparando una directiva para regular la accesibilidad de los sitios web de los organismos públicos.
Según parece, esta directiva se inspira en el modelo español. Pero claro, además de tener una directiva, es importante que también se cumpla (y hacer que se cumpla). En la noticia podemos leer:
Hace unos meses comenté que la Unión Europea está preparando una directiva para regular la accesibilidad de los sitios web de los organismos públicos.
Según parece, esta directiva se inspira en el modelo español. Pero claro, además de tener una directiva, es importante que también se cumpla (y hacer que se cumpla). En la noticia podemos leer:
Desde la Comisión europea la visión es distinta y exponen la situación que se encuentran ante realidades diversas que se corresponden con 25 Estados miembros. Uno de los problemas hace referencia al incumplimiento de las normas, como expone Sanmartín: "Nosotros nos hemos dado cuenta, según una serie de estudios, que se puede tener una legislación vigente y eso no garantiza que el nivel de accesibilidad se cumpla. Los últimos datos que manejamos dicen que en España la legislación puede estar muy bien redactada pero los datos de cumplimiento están en torno a un 60 por ciento de accesibilidad en las páginas web del sector público, lo cual hace pensar que hay un trabajo por hacer, y nosotros queremos que esos porcentajes se incrementen. En ese sentido nuestra idea ha sido reducir un poco el alcance para maximizar el cumplimiento".
jueves, 1 de agosto de 2013
Denuncia por falta de accesibilidad de un curso en línea
Hace unos pocos días, el 23 de julio, el Departamento de Justicia de los Estados Unidos publicó una nota de prensa en el que se informaba del acuerdo alcanzado con Louisiana Tech University a raíz de una denuncia presentada por un alumno ciego que no podía acceder a los materiales de su curso porque no eran accesibles.
El problema estaba en el uso de una plataforma de aprendizaje en línea (e-learning) llamada MyOMLab que tenía problemas de accesibilidad.
En el acuerdo alcanzado, la universidad se compromete a revisar sus políticas en materia de accesibilidad, se compromete a cumplir el nivel AA de WCAG 2.0 en todas las páginas y materiales publicados a partir del año 2010. Además, la universidad formará a sus profesores y administrativos para que sepan crear documentos accesibles y tendrá que pagar al alumno $23.543 en concepto de daños.
El problema estaba en el uso de una plataforma de aprendizaje en línea (e-learning) llamada MyOMLab que tenía problemas de accesibilidad.
En el acuerdo alcanzado, la universidad se compromete a revisar sus políticas en materia de accesibilidad, se compromete a cumplir el nivel AA de WCAG 2.0 en todas las páginas y materiales publicados a partir del año 2010. Además, la universidad formará a sus profesores y administrativos para que sepan crear documentos accesibles y tendrá que pagar al alumno $23.543 en concepto de daños.
miércoles, 31 de julio de 2013
23 años de ADA
El 26 de julio de 1990, el presidente George H. W. Bush (el padre) firmó la ley Americans with Disabilities Act (ADA). El propósito principal de esta ley era proteger los derechos de las personas con discapacidad.
El viernes pasado se celebró el aniversario de esta ley que marcó un antes y un después en los Estados Unidos.
La mayoría de las denuncias que se han presentado en Estados Unidos por la falta de accesibilidad de un sitio web han estado fundamentadas en esta ley. Mañana comentaré una de las últimas denuncias que se han dado a conocer.
El viernes pasado se celebró el aniversario de esta ley que marcó un antes y un después en los Estados Unidos.
La mayoría de las denuncias que se han presentado en Estados Unidos por la falta de accesibilidad de un sitio web han estado fundamentadas en esta ley. Mañana comentaré una de las últimas denuncias que se han dado a conocer.
martes, 30 de julio de 2013
Barreras de accesibilidad en sitios web de universidades
Me he leído el artículo Web-Based Student Processes at Community Colleges: Removing Barriers to Access, un estudio sobre los problemas de usabilidad y accesibilidad que experimentan los estudiantes frente a los sitios web de universidades en Estados Unidos.
El estudio está realizado por la Cornell University y es un poco viejo (del año 2006 y publicado en 2007), pero es interesante.
El estudio está realizado por la Cornell University y es un poco viejo (del año 2006 y publicado en 2007), pero es interesante.
lunes, 29 de julio de 2013
Ejemplo de uso del enlace [D]
Hacía tiempo que no veía una imagen con el enlace [D] de información detallada.
El atributo longdesc se emplea para proporcionar más información sobre una imagen cuando el atributo alt no es suficiente. El valor de este atributo es una URL a otra página web en la que se describe la imagen "con todo lujo de detalles". Desgraciadamente, este atributo no es muy conocido, y los navegadores populares no lo soportan, así que en su lugar, hay gente que emplea el enlace [D] (descripción), una enlace textual que se suele situar cerca del elemento al que se refiere, como puede ser el título de un gráfico.
En la página How many people with disabilities are there? de NOAA se puede encontrar un ejemplo de este enlace:
Este enlace permite navegar a una página en la que se pueden consultar los datos empleados para confeccionar el gráfico de barras:
El atributo longdesc se emplea para proporcionar más información sobre una imagen cuando el atributo alt no es suficiente. El valor de este atributo es una URL a otra página web en la que se describe la imagen "con todo lujo de detalles". Desgraciadamente, este atributo no es muy conocido, y los navegadores populares no lo soportan, así que en su lugar, hay gente que emplea el enlace [D] (descripción), una enlace textual que se suele situar cerca del elemento al que se refiere, como puede ser el título de un gráfico.
En la página How many people with disabilities are there? de NOAA se puede encontrar un ejemplo de este enlace:
Este enlace permite navegar a una página en la que se pueden consultar los datos empleados para confeccionar el gráfico de barras:
viernes, 26 de julio de 2013
Recursos sobre accesibilidad web
Web accessibility resources es una página del proyecto Web Accessibility Toolkit de la Cornell University que contiene mucha información sobre diferentes recursos relacionados con la accesibilidad web.
jueves, 25 de julio de 2013
Artículos sobre accesibilidad
En el sitio web Access iQ podemos encontrar varios artículos sobre accesibilidad web muy interesantes. Desgraciadamente, muchos son de pago :-(
Recomiendo la serie de artículos The ultimate accessible HTML and CSS checklist for developers: son listas de verificación, no muy útiles para el que no sepa, pero interesantes para el que ya sepa accesibilidad.
Recomiendo la serie de artículos The ultimate accessible HTML and CSS checklist for developers: son listas de verificación, no muy útiles para el que no sepa, pero interesantes para el que ya sepa accesibilidad.
Suscribirse a:
Entradas (Atom)